Merge pull request #25 from hathach/devlocal

remove OSAL_TASK_DEF, osal_task_create

3 files changed, 6 insertions, 6 deletions

diff --git a/docs/configuration.txt b/docs/configuration.txt
index 49061a4a0..7850827f6 100644
--- a/docs/configuration.txt
+++ b/docs/configuration.txt
@@ -20,7 +20,6 @@
 
 #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
diff --git a/docs/getting_started.md b/docs/getting_started.md
index 6d6091c03..723e6d862 100644
--- a/docs/getting_started.md
+++ b/docs/getting_started.md
@@ -37,11 +37,11 @@ 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).
+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 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.
+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
   }
 }
 ~~~
diff --git a/docs/porting.md b/docs/porting.md
index 040112d9c..f5af82800 100644
--- a/docs/porting.md
+++ b/docs/porting.md
@@ -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.