From c7006a254b167dc5b2c6994c5bcce70fd877f84c Mon Sep 17 00:00:00 2001 From: Nathan Conrad Date: Tue, 17 Sep 2019 13:27:35 -0400 Subject: change 3 --- docs/concurrency.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 docs/concurrency.md (limited to 'docs') diff --git a/docs/concurrency.md b/docs/concurrency.md new file mode 100644 index 000000000..e05ca6ffe --- /dev/null +++ b/docs/concurrency.md @@ -0,0 +1,36 @@ +# Concurrency + +The TinyUSB library is designed to operate on single-core MCUs with multi-threaded applications in mind. Interaction with interrupts is especially important to pay attention to. +It is compatible with optionally using a RTOS. + +## General + +When writing code, keep in mind that the OS (if using a RTOS) may swap out your code at any time. Also, your code can be preempted by an interrupt at any time. + +## Application Code + +The USB core does not execute application callbacks while in an interrupt context. Calls to application code are from within the USB core task context. Note that the application core will call class drivers from within their own task. + +## Class Drivers + +Class driver code should never be called from an interrupt context by the USB core, though the application is allowed to call class driver functions from interrupts. USB core functions may be called simultaneously by multiple tasks. Use care that proper locking is used to guard the USBD core functions from this case. + +Class drivers are allowed to call `usbd_*` functions, but not `dcd_*` functions. + +## USB Core + +All functions that may be called from an (USB core) interrupt context have a `bool in_isr` parameter to remind the implementer that special care must be taken. + +Interrupt handlers must not directly call class driver code, they must pass a message to the USB core's task. + + `usbd_*` functions may be called from interrupts without any notice. They may also be called simultaneously by multiple tasks. + +## Device Drivers + +Much of the processing of the USB stack is done in an interrupt context, and care must be taken in order to ensure variables are handled in the appropriate ways by the compiler and optimizer. + +In particular: + +- Ensure that all memory-mapped registers (including packet memory) are marked as volatile. GCC's optimizer will even combine memory access (like two 16-bit to be a 32-bit) if you don't mark the pointers as volatile. On some architectures, this can use macros like `_I`, `_O`, or `_IO'. +- All defined global variables are marked as `static`. + -- cgit v1.3.1 From 44013e6e85e859abe6c47c567415a0acea003b1b Mon Sep 17 00:00:00 2001 From: hathach Date: Fri, 13 Sep 2019 18:42:58 +0700 Subject: Update boards.md --- docs/boards.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/boards.md b/docs/boards.md index 96650b20b..de6328aa2 100644 --- a/docs/boards.md +++ b/docs/boards.md @@ -48,8 +48,8 @@ This code base already had supported for a handful of following boards - [STM32F407vg Discovery](https://www.st.com/en/evaluation-tools/stm32f4discovery.html) - [STM32F411ve Discovery](https://www.st.com/en/evaluation-tools/32f411ediscovery.html) - [STM32F412zg Discovery](https://www.st.com/en/evaluation-tools/32f412gdiscovery.html) -- [Nucleo STM32F767zi](https://www.st.com/en/evaluation-tools/nucleo-f767zi.html) -- [Nucleo H743zi](https://www.st.com/en/evaluation-tools/nucleo-h743zi.html) +- [STM32F767zi Nucleo](https://www.st.com/en/evaluation-tools/nucleo-f767zi.html) +- [STM32H743zi Nucleo](https://www.st.com/en/evaluation-tools/nucleo-h743zi.html) ## Add your own board -- cgit v1.3.1 From fd4be239004946cd295b8a85215999a308f0b6ed Mon Sep 17 00:00:00 2001 From: hathach Date: Fri, 13 Sep 2019 18:43:46 +0700 Subject: Update boards.md --- docs/boards.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'docs') diff --git a/docs/boards.md b/docs/boards.md index de6328aa2..30b0eb958 100644 --- a/docs/boards.md +++ b/docs/boards.md @@ -41,15 +41,15 @@ This code base already had supported for a handful of following boards ### ST STM32 -- [STM32F070rb Nucleo](https://www.st.com/en/evaluation-tools/nucleo-f070rb.html) -- [STM32F072rb Discovery](https://www.st.com/en/evaluation-tools/32f072bdiscovery.html) -- [STM32F207zg Nucleo](https://www.st.com/en/evaluation-tools/nucleo-f207zg.html) -- [STM32F303vc Discovery](https://www.st.com/en/evaluation-tools/stm32f3discovery.html) -- [STM32F407vg Discovery](https://www.st.com/en/evaluation-tools/stm32f4discovery.html) -- [STM32F411ve Discovery](https://www.st.com/en/evaluation-tools/32f411ediscovery.html) -- [STM32F412zg Discovery](https://www.st.com/en/evaluation-tools/32f412gdiscovery.html) -- [STM32F767zi Nucleo](https://www.st.com/en/evaluation-tools/nucleo-f767zi.html) -- [STM32H743zi Nucleo](https://www.st.com/en/evaluation-tools/nucleo-h743zi.html) +- [STM32 F070rb Nucleo](https://www.st.com/en/evaluation-tools/nucleo-f070rb.html) +- [STM32 F072rb Discovery](https://www.st.com/en/evaluation-tools/32f072bdiscovery.html) +- [STM32 F207zg Nucleo](https://www.st.com/en/evaluation-tools/nucleo-f207zg.html) +- [STM32 F303vc Discovery](https://www.st.com/en/evaluation-tools/stm32f3discovery.html) +- [STM32 F407vg Discovery](https://www.st.com/en/evaluation-tools/stm32f4discovery.html) +- [STM32 F411ve Discovery](https://www.st.com/en/evaluation-tools/32f411ediscovery.html) +- [STM32 F412zg Discovery](https://www.st.com/en/evaluation-tools/32f412gdiscovery.html) +- [STM32 F767zi Nucleo](https://www.st.com/en/evaluation-tools/nucleo-f767zi.html) +- [STM32 H743zi Nucleo](https://www.st.com/en/evaluation-tools/nucleo-h743zi.html) ## Add your own board -- cgit v1.3.1