doc update

docs/getting_started.md

@@ -17,11 +17,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 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.
+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 boards).
+5. If you use the device stack, make sure you have created/modified usb descriptors for your own need. Ultimately you need to implement all **tud_descriptor_** callbacks 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 tud_task()/tuh_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. All of the callbacks and functionality are handled and invoke within the call of that task runner.
 
 ~~~{.c}
 int main(void)

docs/porting.md

@@ -6,7 +6,7 @@ data transactions on different endpoints. Porting is the process of adding low-l
 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.
+Below are instructions on how to get the cdc_msc 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
 
@@ -19,7 +19,7 @@ Once this is done, create a directory in `hw/bsp/<your board name>` for the spec
 ## 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>`
+`make -C examples/device/cdc_msc 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.
 

examples/readme.md

@@ -15,22 +15,26 @@ TinyUSB examples includes external repos aka submodules to provide low-level MCU
 $ git submodule update --init --recursive
 ```
 
-It will takes a bit of time due to the number of supported MCUs, luckily we only need to do this once.
+It will takes a bit of time due to the number of supported MCUs, luckily we only need to do this once. Or if you only want to test with a specific mcu, you could only update its driver submodule 
 
 ## Build
 
-[Here is the list of supported Boards](docs/boards.md) that should work out of the box with provided examples. 
- 
-To build example, go to its folder project then type `make BOARD=[our_board] all` e.g
+[Here is the list of supported Boards](docs/boards.md) that should work out of the box with provided examples (hopefully).
+To build example, first change directory to example folder. 
+
+```
+$ cd examples/device/cdc_msc
+```
+
+Then compile with `make BOARD=[your_board] all`, for example
 
 ```
-$ cd examples/device/cdc_msc_hid
 $ make BOARD=feather_nrf52840_express all
 ```
 
 ## Flash
 
-`flash` target will use the on-board debugger (jlink/cmsisdap/stlink/dfu) to flash the binary. We should install those debugger/programmer software in advance. Futhermore, since external jlink can be used with most of the board, there is also `flash-jlink` target for out convenience.
+`flash` target will use the on-board debugger (jlink/cmsisdap/stlink/dfu) to flash the binary. We should install those debugger/programmer software in advance. Furthermore, since external jlink can be used with most of the board, there is also `flash-jlink` target for your convenience.
 
 ```
 $ make BOARD=feather_nrf52840_express flash

tools/build_all.py

@@ -94,10 +94,7 @@ for example in all_examples:
             if build_result.returncode != 0:
                 print(build_result.stdout.decode("utf-8"))
 
-# FreeRTOS example
-# example = 'cdc_msc_hid_freertos'
-# board = 'pca10056'
-# build_example(example, board)
+
 
 total_time = time.monotonic() - total_time
 print(build_separator)