add rt-thread software package support

[tfx2001]

Hi,

This PR based on #637 by supporting RT-Thread RTOS. TinyUSB has been registered to the RT-Thread software packages center. Developers can use TinyUSB more easily by installing the TinyUSB package in package manager center.

This PR includes two SConscript files. RT-Thread uses Scons to organize files rather than CMake or Makefile, so it will not cause any conflicts with existing Makefiles. Meanwhile, this PR also contains some drivers for interfacing with the RT-Thread device framework.

However, there is a problem that the added files contain headers (those will be used in RT-Thread side) that do not exist in this repository, which will cause errors at the CI. Is it possible to exclude the osal/rt-thread folder?

I would be grateful if you consider about this PR. Thanks ahead.

Frank

https://www.rt-thread.io

[hathach]

Thanks for your PR to improve the rt-thread port. I am not familiar with SConscript, but I will give a try whenever I could. However, there is a few changes I would like to make

• the rt-thread/README.md is very helpful, but it should be added to the docs/ instead https://github.com/hathach/tinyusb/tree/master/docs/reference
• all the *.c and tusb_congifg.h under rt-thread must be removed. These are application specific files in the usb stack point of view and shouldn't be placed under tinysb/src.
• The rule of thum is for osal, it should contains only the thin OS adapter API for the stack to function and application does not need to use any of these implementation

[tfx2001]

RT-Thread is not just a kernel. RT-Thread contents a device driver framework layer which will provide a uniform API for users. These *.c files port for device driver framework rather than a specific application.

If it's not appropriate to place them in osal/rt-thread, where should I place them?

[hathach]

RT-Thread is not just a kernel. RT-Thread contents a device driver framework layer which will provide a uniform API for users. These *.c files port for device driver framework rather than a specific application.
If it's not appropriate to place them in osal/rt-thread, where should I place them?

yes, and device driver framework should be placed on top of the usb stack not inside it. I am not familiar enough with rt-thread to give suggestion.

[tfx2001]

Thank you for your patience in explaining. So I move them out of the tinyusb/src and make a new folder sys/rt-thread to place them. Please review.

[hathach]

Thank you for your patience in explaining. So I move them out of the tinyusb/src and make a new folder sys/rt-thread to place them. Please review.

No problems, however this is still not correct way to add these, in fact we cannot put these in this repo. Sorry if I am not making it clear enough. Files such as descriptors, msc device which implement callbacks are application scope. Although you tried to make it easier for rt-thread user, those still belongs to application and cannot be put anywhere within this repo. There is no way these files can satisfy ALL the application from ALL users, there will be always changes/customized to fit per application special need. If you want to demonstrate how to use tinyusb with rt-thread, you could add an specific example cdc_msc_rtthread (similar as freertos one).

Sum up; these files aren't accepted anywhere except served as example within this repo. If you want to build an framework to help/generate descriptors, implement callbacks, you should do it in your own (or rt-thread's) separated repo. Checkout pico-sdk https://github.com/raspberrypi/pico-sdk/tree/master/src/rp2_common/pico_stdio_usb and esp idf https://github.com/espressif/esp-idf/tree/master/components/tinyusb for reference on how they implement integration.

[tfx2001]

OK, I'll put these files under my own repo and use TinyUSB as a submodule.

[hathach]

Thank you for your effort