RP2040 + FreeRTOS + TinyUSB: Possible? Sensible?

[mablinov]

Hi all,

I'd like to use FreeRTOS for my application, which is running on the RP2040. However, the TinyUSB support for the RP2040 seems to be hardwired to only use the pico-sdk support utilities via OPT_OS_PICO (line 57):

tinyusb/hw/bsp/rp2040/family.cmake

Lines 55 to 59 in be21413

	target_compile_definitions(tinyusb_common_base INTERFACE
	CFG_TUSB_MCU=OPT_MCU_RP2040
	CFG_TUSB_OS=OPT_OS_PICO
	#CFG_TUSB_DEBUG=${TINYUSB_DEBUG_LEVEL}
	)

Ofcourse its trivial to change from OPT_OS_PICO to OPT_OS_FREERTOS, but it means that I now have to carry a non-standard version of the library, or carry around a patch that gets applied to the library before building.

Would it be possible to make this option configurable?

[hathach]

FreeRTOS is already working well with rp2040, I just don't follow this to make tinyusb's example to work with it yet. I think it needs to use a specific port for freeRTOS or something. @kilograham would you mind give a brief update on freeRTOS with rp2040, I think it is probably a good time to update freertos example to work with rp2040

[rppicomidi]

@hathach The FreeRTOS demo for the Pico/RP2040 is here. Follow the Raspberry Pi Pico link. I was starting to look at this too. Is there a project already started on this?

[hathach]

thank you, I also figured it out, https://github.com/raspberrypi/picoprobe seems to use freeRTOS. I will peek at project setting, and update tinyusb freertos examples to support rp2040 later on.

[rapzak]

thank you, I also figured it out, https://github.com/raspberrypi/picoprobe seems to use freeRTOS. I will peek at project setting, and update tinyusb freertos examples to support rp2040 later on.

Hi,
In my fast sneak peak into that project i did not find where the CFG_TUSB_OSwas set, other than in tinyusb config to Freertos.

However i would like give you the best positive feedback for your great library share with us... Thank you.

/Kasper

[rapzak]

Hi,
I also had the same issue - had to go back to the "pico-sdk\lib\tinyusb\hw\bsp\rp2040\family.cmake" file to set the "OPT_OS_FREERTOS"
But actually i do see this more of a pico SDK issue, than a TinyUSB...
But still could be great if you can adress it :)

/Kasper

[rapzak]

raspberrypi/pico-sdk#1326

[rppicomidi]

@hathach As I understand it, the picoprobe code does not change the TINYUSB_OPT_OS variable. It just wraps the tud_task() in a FreeRTOS task with a trivial delay to let lower priority tasks run. It doesn't take advantage of blocking queues as provided by osal_freertos.h

An alternate solution: the tinyusb RP2040 family.cmake should work with pico-sdk rp2_common.cmake to create a second set of libraries: tinyusb_device_freertos, tinyusb_host_freertos, and tinyusb_board_freertos. RP2040 pico-sdk programs that require FreeRTOS would add those libraries instead of tinyusb_device, tinyusb_host and tinyusb_board.

I believe this solution can be implemented and is more consistent with what was done for the CYW43 arch drivers in the pico-sdk to support the Pico W Wi-Fi/Bluetooth chip. @hathach if you think this is a worthwhile solution, I can work on a pull-request.

[hathach]

oh, I didn't look at the detail implementation of picoprobe and miss that. Yeah I think it should be better to use OPT_OS_FREERTOS. I am not really good at CMake but your suggestion make sense, though we surely need more opinion from rpi team since they understand rp2040 build system better than me.

[kilograham]

1. I'm certainly curious about where using CFG_TUSB_OS=OPT_OS_PICO falls down on FreeRTOS (I'm not arguing for using it, I'm just curious what the negative effects are)
2. Yes, perhaps setting the CFG_TUSB_OS on tinyusb_common_base was not the right answer.
   The issue was partly that all the examples (and also likely people's tusb_config,h) have

   #ifndef CFG_TUSB_OS
   #define CFG_TUSB_OS                 OPT_OS_NONE 
   #endif
   

   which made it hard to insert a default
3. Yes we could add a CMake var TINYUSB_ OS or whatever to change the value we set on tinyusb_common_base but that isn't great either, as it is project wide.
4. We could extend 3. to use CMake target variables, but again that starts to get messy/complicated
5. We want to be backwards compatible with people using the CMake libraries today

The order of the config headers in TinyUSB makes it hard to inject an MCU override before the user tusb_config.h, but perhaps we could do something like

#ifdef CFG_TUSB_OS_DEFAULT
#define CFG_TUSB_OS CFG_TUSB_OS_DEFAULT
#endif

Perhaps this should be called CFG_TUSB_OS_FORCE or CFG_TUSB_OS_OVERRIDE

But to avoid just recreating the same problem with a differently named variable, we can have tinyusb_common_base set CFG_TUSB_OS_DEFAULT=PICO_TUSB_OS_DEFAULT and have PICO_TUSB_OS_DEFAULT defaulted in tusb_mcu.h

anyway, @hathach probably has some better ideas ;-)

[hathach]

I'm certainly curious about where using CFG_TUSB_OS=OPT_OS_PICO falls down on FreeRTOS (I'm not arguing for using it, I'm just curious what the negative effects are)

osal_freertos use freeRTOS queue API which allow the tud/tuh_task() give up its MCU when there is no events. osal_queue_receive() will put usbd/usbh task to NOT_READY state
https://github.com/hathach/tinyusb/blob/master/src/device/usbd.c#L487

This is important since USB task (or any low level irq-driven peripherals) typically has higher priority than application task (Since UI/app would need usb event proccessed in order to have its own data). Otherwise we will need to introduce delay to give up MCU like picoprobe does

• https://github.com/raspberrypi/picoprobe/blob/master/src/main.c#L63

I am not saying it is bad, it is just not optimal, with high enough priority CPU will end up looping over usb task doingg nothing. and also consume more power since it wakes cpu reguarly when there is no USB event.

[hathach]

@kilograham for the solution, to be honest, you are much better with CMake than me, I am literally only type make BOARD= for most of my workflow. Though since we are building tinyusb as library, it is necessary to know the OS to generate correct code much like those libmath with different float api. That is the solution that @rppicomidi suggest. Again, since you understand rp2040 cmake build system better than me, I will leave the decision for you, I am sure you will come up with the best approach.

[rppicomidi]

@kilograham I proposed this solution: see pull request #1993. Does that seem like it is on the right track?

[rppicomidi]

I would like to discuss @hathach's and @kilograham's last comments.

The way I read the code, the tusb_config.h setting for CFG_TUSB_OS is pretty much ignored by the pico-sdk build system. The only way to set CFG_TUSB_OS is in the project's CMakeLists.txt. You do so by setting CFG_TUSB_OS before the call to pico_sdk_init(). That can work for a stand-alone project, but not for current code.

For example, the pico-examples project pulls in the tinyusb/examples directory. That directory includes both FreeRTOS and non-FreeRTOS examples. However, because the pico-examples directory CMakeLists.txt calls pico_sdk_init(), before including any tinyusb example projects, there is no way to set CFG_TUSB_OS at the subproject level.

To track the details, pico_sdk_init() pulls in the pico-sdk subdirectory, whose CMakeLists.txt includes the pico-sdk/src directory, whose CMakeLists.txt eventually pulls in the rp2_common subdirectory, whose CMakeLists.txt file eventually pull in the tinyusb subdirectory, whose CMakeLists.txt includes family_support.cmake, which needs CFG_TUSB_OS to be set or it sets to OPT_OS_PICO. That precludes setting CFG_TUSB_OS in the individual projects in the pico-examples directory.

For maximum backward compatibility, I propose leaving the pico-sdk code alone and inventing _freertos variants of the tinyusb libraries. As pull request #1993 demonstrates, this approach allows you to build both OPT_OS_PICO and OPT_OS_FREERTOS examples from the same code base.

[hathach]

I agree that having _freertos version would help compiling all pico examples with mixed of noos + freertos if pico-sdk compile tinyusb as a lib. Though since I don't understand much of the cmake build used by pico-sdk, I will leave this to @kilograham and pi team to see which approach is best.

Meanwhile, I may probably update tinyusb examples/bsp to add support for freeRTOS for rp2040. though this is not an issue since tinyusb exmaples usually build with sources instead of pre-built lib, I can just add and set(RTOS) to tinyusb examples top CMakeList (I hope)