Allow the use of non-static allocation for FreeRTOS mutexes & queues

[pete-pjb]

Allow the use of non-static allocation for FreeRTOS mutexes & queues

Added some conditional code to the file src/osal/osal_freertos.h to check the FreeRTOS configuration option configSUPPORT_STATIC_ALLOCATION and if it is set to '0' We use the non-static variants of the queues, mutexes and associated creation functions.

[pete-pjb]

Hi @hathach ,

It seems one of the CI tests is failing (Build ARM / build-arm (rp2040) (pull_request)) , I have looked at the 'Details', there seems to be no clue as to why? If I need to change something, please let me know.

Kind Regards,

Pete

[hathach]

it is network/bandwidth issue, happen quite often now and then. Just re-run it.

[pete-pjb]

Hi @Hatach ,

I have also added another 'FreeRTOS' related commit to this pull request to eliminate the need to repeatedly call the tuh_task() when using FreeRTOS. You can just start tuh_task() as a normal task from FreeRTOS like this:

xTaskCreate( (TaskFunction_t)tuh_task, "USB", THREAD_STACKSIZE, NULL, USB_PRIORITY, NULL );

This eliminates the very small overhead incurred when calling the function continuously in a loop from another FreeRTOS task which is not necessary whilst the tuh_task_ext() is being executed in it's own loop and blocking using the OS specific calls... I hope that makes sense.

Let me know your thoughts...

Kind Regards,

Pete

[pete-pjb]

Hi @hathach ,

I have also added another commit here, I added the CFG_TUSB_MEM_SECTION macro to the declaration of struct _ctrl_xfer in usbh.c, this is required for my port also.

I hope that is okay.

Kind Regards,

Pete

[hathach]

thank you for the PR, though it is better to revert some of your recent changes.

[hathach]

thank you for your PR. I have pulled and tested with existing examples on actual hardware. It worked great, I also clean up and put more update to existing examples to allow it to run with configSUPPORT_STATIC_ALLOCATION=0