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

seperate tusb_task() to tud_task() and tuh_task()

Browse Source 
tusb_task() still exists for backward compatible
This commit is contained in:
hathach
2018-12-13 14:51:37 +07:00
parent af1ffe4675
commit 1c49c479ca
13 changed files with 64 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/getting_started.md
View File

@@ -41,7 +41,7 @@ It is relatively simple to incorporate tinyusb to your (existing) project
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.
8. If you don't use any RTOSes at all, you need to continuously and/or periodically call tud_task()/tuh_task() function. Most of the callbacks and functionality are handled and invoke within the call of that task runner.
~~~{.c}
int main(void)
@@ -53,7 +53,8 @@ int main(void)
{
your_application_code();
tusb_task(); // handle tinyusb event, task etc ...
tud_task(); // tinyusb device task
tuh_task(); // tinyusb host task
}
}
~~~

4
docs/porting.md
View File

@@ -61,7 +61,7 @@ The OPT_OS_NONE option is the only option which requires an MCU specific functio
### 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.
After the USB device is setup, the USB device code works by processing events on the main thread (by calling `tud_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`.
@@ -164,4 +164,4 @@ At this point you should have everything working! ;-) Of course, you may not wri
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.
* 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 `tud_task` may not be called.) If thats OK, the `dcd_xfer_complete` may not be setting up the next transaction correctly.