andy/tinyUSB
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

clean up usbh, rename doxygen folder to docs

Browse Source
This commit is contained in:
hathach
2018-12-06 21:46:34 +07:00
parent 1d3583785f
commit 5b09774ae0
18 changed files with 87 additions and 105 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/changelog.md Normal file
View File

@@ -0,0 +1,5 @@
# Change Log #
## 0.4 ##
Initial release.

80
docs/coding_standard.md Normal file
View File

@@ -0,0 +1,80 @@
# Coding Standards #
C is a dangerous language by itself, plus tinyusb make use of goodies features of C99, which saves a tons of code lines (also means save a tons of bugs). However, those features can be misused and pave the way for bugs sneaking into. Therefore, to minimize bugs, the author try to comply with published Coding Standards like:
- [MISRA-C](http://www.misra-c.com/Activities/MISRAC/tabid/160/Default.aspx)
- [Power of 10](http://spinroot.com/p10/)
- [Jet Propulsion Laboratory (JPL) for C](http://lars-lab.jpl.nasa.gov)
Where is possible, standards are followed but it is almost impossible to follow all of these without making some exceptions. I am pretty sure this code base violates more than what are described below, if you can find any, please report it to me or file an issue on github.
## MISRA-C 2004 Exceptions ##
MISRA-C is well respected & a bar for industrial coding standard.
- **Rule 2.2: use only**
It has long passed the day that C99 comment style // will cause any issues, especially compiler's C99 mode is required to build tinyusb.
- **Rule 8.5: No definitions of objects or function in a header file**
function definitions in header files are used to allow 'inlining'
- **Rule 14.7: A function shall have a single point of exit at the end of the function**
Unfortunately, following this rule will have a lot of nesting if-else, I prefer to exit as soon as possible with assert style and flatten if-else.
- **Rule 18.4: Unions shall not be used**
sorry MISRA, union is required to effectively mapped to MCU's registers
- expect to have more & more exceptions.
## Power of 10 ##
is a small & easy to remember but yet powerful coding guideline. Most (if not all) of the rules here are included in JPL. Because it is very small, all the rules will be listed here, those with *italic* are compliant, **bold** are violated.
1. *Restrict to simple control flow constructs*
yes, I hate goto statement, therefore there is none of those here
2. *Give all loops a fixed upper-bound*
one of my favorite rule
3. *Do not use dynamic memory allocation after initialization*
the tinyusb uses the static memory for all of its data.
4. **Limit functions to no more than 60 lines of text**
60 is a little bit too strict, I will update the relaxing number later
5. *Use minimally two assertions per function on average*
not sure the exact number, but I use a tons of those assert
6. *Declare data objects at the smallest possible level of scope*
one of the best & easiest rule to follow
7. *Check the return value of non-void functions, and check the validity of function parameters*
I did check all of the public application API's parameters. For internal API, calling function needs to trust their caller to reduce duplicated check.
8. **Limit the use of the preprocessor to file inclusion and simple macros**
Although I prefer inline function, however C macros are far powerful than that. I simply cannot hold myself to use, for example X-Macro technique to simplify code.
9. *Limit the use of pointers. Use no more than two levels of dereferencing per expression*
never intend to get in trouble with complex pointer dereferencing.
10. *Compile with all warnings enabled, and use one or more source code analyzers*
I try to use all the defensive options of gnu, let me know if I miss some.
>-Wextra -Wswitch-default -Wunsafe-loop-optimizations -Wcast-align -Wlogical-op -Wpacked-bitfield-compat -Wnested-externs -Wredundant-decls -Winline
## JPL ##
coming soon ...

77
docs/configuration.txt Normal file
View File

@@ -0,0 +1,77 @@
/** \addtogroup group_configuration
* @{ */
//--------------------------------------------------------------------+
// COMMON CONFIGURATION
//--------------------------------------------------------------------+
/// \brief tell the stack which mode (host/device/otg) the usb controller0 will be operated on. Possible value is
/// from \ref group_mode. Note the hardware usb controller must support the selected mode.
#define CFG_TUSB_RHPORT0_MODE
/** USB controller in MCU often has limited access to specific RAM section. The Stack will use this macro to place internal variables
into the USB RAM section as follows. if your mcu's usb controller has no such limit, define CFG_TUSB_MEM_SECTION as empty macro.
@code
CFG_TUSB_MEM_SECTION uint8_t usb_xfer_buffer[10];
@endcode
*/
#define CFG_TUSB_MEM_SECTION
#define CFG_TUSB_MCU ///< Select one of the supported MCU, the value must be from \ref group_mcu
#define CFG_TUSB_OS ///< Select one of the supported RTOS, the value must be from \ref group_supported_os.
#define CFG_TUD_TASK_PRIO ///< If \ref CFG_TUSB_OS is configured to use a real RTOS (other than OPT_OS_NONE). This determines the priority of the usb stack task.
//--------------------------------------------------------------------+
// HOST CONFIGURATION
//--------------------------------------------------------------------+
/** \defgroup CFG_TUSB_HOST Host Options
* @{ */
/** \brief Maximum number of device host stack can manage
* \n If hub class is not enabled, set this equal to number of controllers in host mode
* \n If hub class is enabled, make sure hub is also counted */
#define CFG_TUSB_HOST_DEVICE_MAX
/// \brief Buffer size used for getting device configuration descriptor. You may want to increase this from default (256)
/// to support lengthy composite device especially with Audio or Video class
#define CFG_TUSB_HOST_ENUM_BUFFER_SIZE
/** \defgroup config_host_class Class Driver
* \brief For each Class Driver a value of 1 means enable, value of 0 mean disable
* @{ */
#define CFG_TUH_HUB ///< Enable Hub Class
#define CFG_TUSB_HOST_HID_KEYBOARD ///< Enable HID Class for Keyboard
#define CFG_TUSB_HOST_HID_MOUSE ///< Enable HID Class for Mouse
#define CFG_TUSB_HOST_HID_GENERIC ///< Enable HID Class for Generic (not supported yet)
#define CFG_TUSB_HOST_MSC ///< Enable Mass Storage Class (SCSI subclass only)
#define CFG_TUSB_HOST_CDC ///< Enable Virtual Serial (Communication Device Class)
/** @} */
/** @} */ // group Host
//--------------------------------------------------------------------+
// DEVICE CONFIGURATION
//--------------------------------------------------------------------+
/** \defgroup CFG_TUSB_DEVICE Device Options
* @{ */
#define CFG_TUD_ENDOINT0_SIZE ///< Max packet size of Cotnrol Endpoint, default is 64
/// Application MUST define this variable and initialize its pointers's member to all required USB descriptors including
/// Device Descriptor, Configuration Descriptor, String Descriptors, HID Report Descriptors etc ...
tud_desc_init_t tusbd_descriptor_pointers;
/** \defgroup config_device_class Class Driver
* \brief For each Class Driver a value of 1 means enable, value of 0 mean disable
* @{ */
#define CFG_TUD_HID_KEYBOARD ///< Enable HID Class for Keyboard
#define CFG_TUD_HID_MOUSE ///< Enable HID Class for Mouse
#define CFG_TUD_HID_GENERIC ///< Enable HID Class for Generic (not supported yet)
#define CFG_TUD_MSC ///< Enable Mass Storage Class (SCSI subclass only)
#define CFG_TUD_CDC ///< Enable Virtual Serial (Communication Device Class)
/** @} */
/** @} */ // group Device
/** @} */

63
docs/getting_started.md Normal file
View File

@@ -0,0 +1,63 @@
# Getting Started #
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents**
- [Download](#download)
- [Add tinyusb to your project](#add-tinyusb-to-your-project)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Download
tinyusb uses github as online repository https://github.com/hathach/tinyusb since it is the best place for open source project.
If you are using Linux, you already know how to what to do. But If Windows is your OS, I would suggest to install [git](http://git-scm.com/) and front-end gui such as [tortoisegit](http://code.google.com/p/tortoisegit) to begin with.
After downloading/cloning, the code base is composed of
Folder | Description
----- | -------------
doxygen | Documentation
examples| Folder where test examples are kept with Makefile and Segger Embedded build support
hw/bsp | Source files of supported boards
hw/mcu | Low level mcu core & peripheral drivers (e.g CMSIS )
lib | Source files from 3rd party such as freeRTOS, fatfs etc ...
src | All sources files for tinyusb stack itself.
tests | Unit tests for the stack
tools | Files used internally
*examples* is the folder where all the application & project files are located. There are demos for both device and hosts. For each, there are different projects for each of supported RTOS. Click to have more information on how to [build](../examples/readme.md) and run [device](../examples/device/readme.md) demos.
## Add tinyusb to your project
It is relatively simple to incorporate tinyusb to your (existing) project
1. Copy or `git submodule` this repo into your project in a subfolder. Let's say it is *your_project/tinyusb*
2. Add all the .c in the src folder to your project settings (uvproj, ewp, makefile)
3. Add *your_project/tinysb* to your include path. Also make sure your current include path also contains the configuration file tusb_config.h. Or you could simply put the tusb_config.h into the tinyusb folder as well.
4. Make sure all required macros are all defined properly in tusb_config.h (configure file in demo application is sufficient, but you need to add a few more such as CFG_TUSB_MCU, CFG_TUSB_OS, CFG_TUD_TASK_PRIO since they are passed by IDE/compiler to maintain a unique configure for all demo projects).
5. If you use the device stack, make sure you have created/modified usb descriptors for your own need. Ultimately you need to fill out required pointers in tusbd_descriptor_pointers for that stack to work.
6. Add tusb_init() call to your reset initialization code.
7. Implement all enabled classes's callbacks.
8. If you don't use any RTOSes at all, you need to continuously and/or periodically call tusb_task() function. Most of the callbacks and functionality are handled and invoke within the call of that task runner.
~~~{.c}
int main(void)
{
your_init_code();
tusb_init(); // initialize tinyusb stack
while(1) // the mainloop
{
your_application_code();
tusb_task(); // handle tinyusb event, task etc ...
}
}
~~~
[//]: # (\subpage md_boards_readme)
[//]: # (\subpage md_doxygen_started_demo)
[//]: # (\subpage md_tools_readme)

22
docs/group_def.txt Normal file
View File

@@ -0,0 +1,22 @@
// define all the modules group to have the desired ordering since doxygen order module group by
// the order of files it is feed
/// \defgroup group_demo Demos
/// \defgroup group_class Application - Class Driver API
/// \defgroup group_application_api Application - Stack API
/// \brief Non-Class driver API
/// \defgroup group_configuration Configuration tusb_config.h
/// \defgroup group_usbd USB Device Core (USBD)
/// \defgroup group_usbh USB Host Core (USBH)
/// \defgroup group_osal OS Abstraction Layer (OSAL)
/// \defgroup group_usb_definitions USB Definitions
/// \defgroup Group_Common Common Files

58
docs/header.html Normal file
View File

@@ -0,0 +1,58 @@
<!-- HTML header for doxygen 1.8.6-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen $doxygenversion"/>
<!--BEGIN PROJECT_NAME--><title>$projectname: $title</title><!--END PROJECT_NAME-->
<!--BEGIN !PROJECT_NAME--><title>$title</title><!--END !PROJECT_NAME-->
<link href="$relpath^tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="$relpath^jquery.js"></script>
<script type="text/javascript" src="$relpath^dynsections.js"></script>
$treeview
$search
$mathjax
<link href="$relpath^$stylesheet" rel="stylesheet" type="text/css" />
$extrastylesheet
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<!--BEGIN TITLEAREA-->
<div id="titlearea">
<table width="100%" cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<!--BEGIN PROJECT_LOGO-->
<td id="projectlogo"><img alt="Logo" src="$relpath^$projectlogo"/></td>
<!--END PROJECT_LOGO-->
<!--BEGIN PROJECT_NAME-->
<td style="padding-left: 0.5em;">
<div id="projectname">$projectname
<!--BEGIN PROJECT_NUMBER-->&#160;<span id="projectnumber">$projectnumber</span><!--END PROJECT_NUMBER-->
</div>
<!--BEGIN PROJECT_BRIEF--><div id="projectbrief">$projectbrief</div><!--END PROJECT_BRIEF-->
</td>
<td align="right">
<a href="https://pledgie.com/campaigns/24694"><img border="0" src="https://pledgie.com/campaigns/24694.png?skin_name=chrome" alt="Click here to lend your support to tinyusb donation and make a donation at pledgie.com"></a>
</td>
<!--END PROJECT_NAME-->
<!--BEGIN !PROJECT_NAME-->
<!--BEGIN PROJECT_BRIEF-->
<td style="padding-left: 0.5em;">
<div id="projectbrief">$projectbrief</div>
</td>
<!--END PROJECT_BRIEF-->
<!--END !PROJECT_NAME-->
<!--BEGIN DISABLE_INDEX-->
<!--BEGIN SEARCHENGINE-->
<td>$searchbox</td>
<!--END SEARCHENGINE-->
<!--END DISABLE_INDEX-->
</tr>
</tbody>
</table>
</div>
<!--END TITLEAREA-->
<!-- end header part -->

167
docs/porting.md Normal file
View File

@@ -0,0 +1,167 @@
# Porting
TinyUSB is designed to be a universal USB protocol stack for low-cost 32 bit microcontrollers. It
handles most of the high level USB protocol and relies on the microcontroller's USB peripheral for
data transactions on different endpoints. Porting is the process of adding low-level support for
the rest of the common stack. Once the low-level is implemented, it is very easy to add USB support
for the microcontroller to other projects, especially those already using TinyUSB such as CircuitPython.
Below are instructions on how to get the cdc_msc_hid device example running on a new microcontroller. Doing so includes adding the common code necessary for other uses while minimizing other extra code. Whenever you see a phrase or word in <> it should be replaced.
## Register defs
The first step to adding support is including the register definitions and startup code for the
microcontroller in TinyUSB. We write the TinyUSB implementation against these structs instead of higher level functions to keep the code small and to prevent function name collisions in linking of larger projects. For ARM microcontrollers this is the CMSIS definitions. They should be
placed in the `hw/mcu/<vendor>/<chip_family>` directory.
Once this is done, create a directory in `hw/bsp/<your board name>` for the specific board you are using to test the code. (Duplicating an existing board's directory is the best way to get started.) The board should be a readily available development board so that others can also test.
## Build
Now that those directories are in place, we can start our iteration process to get the example building successfully. To build, run from the root of TinyUSB:
`make -C examples/device/cdc_msc_hid BOARD=<board>`
Unless, you've read ahead, this will fail miserably. Now, lets get it to fail less by updating the files in the board directory. The code in the board's directory is responsible for setting up the microcontroller's clocks and pins so that USB works. TinyUSB itself only operates on the USB peripheral. The board directory also includes information what files are needed to build the example.
One of the first things to change is the `-DCFG_TUSB_MCU` cflag in the `board.mk` file. This is used to tell TinyUSB what platform is being built. So, add an entry to `src/tusb_option.h` and update the CFLAG to match.
Also, add an entry for the board in `hw/bsp/board.h`. The CFLAG is auto-added.
Update `board.mk`'s VENDOR and CHIP_FAMILY values when creating the directory for the struct files. Duplicate one of the other sources from `src/portable` into `src/portable/<vendor>/<chip_family>` and delete all of the implementation internals. We'll cover what everything there does later. For now, get it compiling.
## Implementation
At this point you should get an error due to an implementation issue and hopefully the build is setup for the new MCU. You will still need to modify the `board.mk` to include specific CFLAGS, the linker script, linker flags, source files, include directories. All file paths are relative to the top of the TinyUSB repo.
### Board Support (BSP)
The board support code is only used for self-contained examples and testing. It is not used when TinyUSB is part of a larger project. Its responsible for getting the MCU started and the USB peripheral clocked. It also optionally provides LED definitions that are used to blink an LED to show that the code is running.
It is located in `hw/bsp/<board name>/board_<board name>.c`.
#### board_init
`board_init` is responsible for starting the MCU, setting up the USB clock and USB pins. It is also responsible for initializing LED pins.
One useful clock debugging technique is to set up a PWM output at a known value such as 500hz based on the USB clock so that you can verify it is correct with a logic probe or oscilloscope.
Setup your USB in a crystal-less mode when available. That makes the code easier to port across boards.
#### board_led_control
Feel free to skip this until you want to verify your demo code is running. To implement, set the pin corresponding to the led to output a value that lights the LED when `state` is true.
### OS Abstraction Layer (OSAL)
The OS Abstraction Layer is responsible for providing basic data structures for TinyUSB that may allow for concurrency when used with an RTOS. Without an RTOS it simply handles concurrency issues between the main code and interrupts.
The code is almost entirely agnostic of MCU and lives in `src/osal`.
#### tusb_hal_millis
The OPT_OS_NONE option is the only option which requires an MCU specific function. It needs `tusb_hal_millis` to measure the passage of time. On ARM this is commonly done with SysTick. The function returns the elapsed number of milliseconds since startup.
`tusb_hal_millis` is also provided in `hw/bsp/<board name>/board_<board name>.c` because it may vary with MCU use.
### Device API
After the USB device is setup, the USB device code works by processing events on the main thread (by calling `tusb_task`). These events are queued by the USB interrupt handler. So, there are three parts to the device low-level API: device setup, endpoint setup and interrupt processing.
All of the code for the low-level device API is in `src/portable/<vendor>/<chip family>/dcd_<chip family>.c`.
#### Device Setup
##### dcd_init
Initializes the USB peripheral for device mode and enables it.
#### dcd_int_enable / dcd_int_disable
Enables or disables the USB device interrupt(s). May be used to prevent concurrency issues when mutating data structures shared between main code and the interrupt handler.
##### dcd_set_address
Called when the device is given a new bus address.
If your peripheral automatically changes address during enumeration (like the nrf52) you may leave this empty and also no queue an event for the corresponding SETUP packet.
##### dcd_set_config
Called when the device received SET_CONFIG request, you can leave this empty if your peripheral does not require any specific action.
#### Special events
You must let TinyUSB know when certain events occur so that it can continue its work. There are a few methods you can call to queue events for TinyUSB to process.
##### dcd_event_bus_signal
There are a number of events that your peripheral may communicate about the state of the bus. Here is an overview of what they are. Events in **BOLD** must be provided for TinyUSB to work.
* **DCD_EVENT_RESET** - Triggered when the host resets the bus causing the peripheral to reset. Do any other internal reset you need from the interrupt handler such as resetting the control endpoint.
* DCD_EVENT_SOF - Signals the start of a new USB frame.
Calls to this look like:
dcd_event_bus_signal(0, DCD_EVENT_BUS_RESET, true);
The first `0` is the USB peripheral number. Statically saying 0 is common for single USB device MCUs.
The `true` indicates the call is from an interrupt handler and will always be the case when porting in this way.
##### dcd_setup_received
SETUP packets are a special type of transaction that can occur at any time on the control endpoint, numbered `0`. Since they are unique, most peripherals have special handling for them. Their data is always 8 bytes in length as well.
Calls to this look like:
dcd_event_setup_received(0, setup, true);
As before with `dcd_event_bus_signal` the first argument is the USB peripheral number and the third is true to signal its being called from an interrup handler. The middle argument is byte array of length 8 with the contents of the SETUP packet. It can be stack allocated because it is copied into the queue.
#### Endpoints
Endpoints are the core of the USB data transfer process. They come in a few forms such as control, isochronous, bulk, and interrupt. We won't cover the details here except with some caveats in open below. In general, data is transferred by setting up a buffer of a given length to be transferred on a given endpoint address and then waiting for an interrupt to signal that the transfer is finished. Further details below.
Endpoints within USB have an address which encodes both the number and direction of an endpoint. TinyUSB provides `edpt_number` and `edpt_dir` to unpack this data from the address. Here is a snippet that does it.
uint8_t epnum = edpt_number(ep_addr);
uint8_t dir = edpt_dir(ep_addr);
##### dcd_edpt_open
Opening an endpoint is done for all non-control endpoints once the host picks a configuration that the device should use. At this point, the endpoint should be enabled in the peripheral and configured to match the endpoint descriptor. Pay special attention to the direction of the endpoint you can get from the helper methods above. It will likely change what registers you are setting.
Also make sure to enable endpoint specific interrupts.
##### dcd_edpt_xfer
`dcd_edpt_xfer` is responsible for configuring the peripheral to send or receive data from the host. "xfer" is short for "transfer". **This is one of the core methods you must implement for TinyUSB to work (one other is the interrupt handler).** Data from the host is the OUT direction and data to the host is IN. In other words, direction is relative to the host.
`dcd_edpt_xfer` is used for all endpoints including the control endpoint 0. Make sure to handle the zero-length packet STATUS packet on endpoint 0 correctly. It may be a special transaction to the peripheral.
Besides that, all other transactions are relatively straight-forward. The endpoint address provides the endpoint number and direction which usually determines where to write the buffer info. The buffer and its length are usually written to a specific location in memory and the peripheral is told the data is valid. (Maybe by writing a 1 to a register or setting a counter register to 0 for OUT or length for IN.)
TODO: can we promise the buffer is word aligned?
One potential pitfall is that the buffer may be longer than the maximum endpoint size of one USB packet. Some peripherals can handle transmitting multiple USB packets for a provided buffer (like the SAMD21). Others (like the nRF52) may need each USB packet queued individually. To make this work you'll need to track some state for yourself and queue up an intermediate USB packet from the interrupt handler.
Once the transaction is going, the interrupt handler will notify TinyUSB of transfer completion.
TODO: who handles zero-length data packets?
##### dcd_xfer_complete
Once a transfer completes you must call dcd_xfer_complete from the USB interrupt handler to let TinyUSB know that a transaction has completed. Here is a sample call:
dcd_event_xfer_complete(0, ep_addr, xfer->actual_len, XFER_RESULT_SUCCESS, true);
The arguments are:
* the USB peripheral number
* the endpoint address
* the actual length of the transfer. (OUT transfers may be smaller than the buffer given in `dcd_edpt_xfer`)
* the result of the transfer. Failure isn't handled yet.
* `true` to note the call is from an interrupt handler.
##### dcd_edpt_stall / dcd_edpt_stalled / dcd_edpt_clear_stall
Stalling is one way an endpoint can indicate failure such as when an unsupported command is transmitted. The trio of `dcd_edpt_stall`, `dcd_edpt_stalled`, `dcd_edpt_clear_stall` help manage the stall state of all endpoints.
## Woohoo!
At this point you should have everything working! ;-) Of course, you may not write perfect code. Here are some tips and tricks for debugging.
Use [WireShark](https://www.wireshark.org/) or [a Beagle](https://www.totalphase.com/protocols/usb/) to sniff the USB traffic. When things aren't working its likely very early in the USB enumeration process. Figuring out where can help clue in where the issue is. For example:
* If the host sends a SETUP packet and its not ACKed then your USB peripheral probably isn't started correctly.
* If the peripheral is started correctly but it still didn't work, then verify your usb clock is correct. (You did output a PWM based on it right? ;-) )
* If the SETUP packet is ACKed but nothing is sent back then you interrupt handler isn't queueing the setup packet correctly. (Also, if you are using your own code instead of an example `tusb_task` may not be called.) If thats OK, the `dcd_xfer_complete` may not be setting up the next transaction correctly.

48
docs/started_demo.md Normal file
View File

@@ -0,0 +1,48 @@
# Demos #
For simplicity and user's convenience, there are only 2 basic application demos which are *Device* and *Host* respectively. Each application demo, however, has a few projects, each for its supported RTOS. For instance, in addition to the *src* folder, you will also find in the /demo/device
- device\_os\_none for no RTOS
- device\_freertos for freeRTOS
- device\_cmsis_rtx for ARM CMSIS with RTX implemenation
To be able to have the same application code running across RTOSes, the application make use of the "internal" **OSAL layer**. Thus this makes the application code a bit weird and over-complicated than it should be in some (many) cases. This is absolutely not necessary in product development. User can just use the native API function of supported RTOS or a state machine or blocking wait in case of none OS. For example, instead of the blinking task in application
~~~{.c}
OSAL_TASK_FUNCTION( led_blinking_task , p_task_para)
{
OSAL_TASK_LOOP_BEGIN
static uint32_t led_on_mask = 0;
osal_task_delay(led_blink_interval_ms);
board_leds(led_on_mask, 1 - led_on_mask);
led_on_mask = 1 - led_on_mask; // toggle
OSAL_TASK_LOOP_END
}
~~~
can be written in FreeRTOS's native API
~~~{.c}
void led_blinking_task( void * p_task_para )
{
while(1)
{
static uint32_t led_on_mask = 0;
// FreeRTOS API's vTaskDelay is used in place of osal_task_delay. Note it takes input parameter in tick
vTaskDelay( (led_blink_interval_ms * CFG_TUSB_TICKS_HZ) / 1000);
board_leds(led_on_mask, 1 - led_on_mask);
led_on_mask = 1 - led_on_mask; // toggle
}
}
~~~
[//]: # (\subpage md_demos_readme)
[//]: # (\subpage md_demos_device_readme)
[//]: # (\subpage md_demos_host_readme)