I’m porting an application/product from FreeRTOS to Particle and it is mostly up and running, but I’m hitting a wall with my queue-based processes. The application has several threads that use FreeRTOS queues to communicate, but the queue functions have not been exposed through the dynalib. It works great using monolithic build, but it won’t build for modular.
Any ideas/suggestions? What are the chances the queue functions could be exposed?
I am also really missing the ability to get the current task handle, as in xTaskGetCurrentTaskHandle().
The quick answer is that the more APIs are exposed directly to the user from the RTOS the harder it will be to switch to a different RTOS if this were needed. That’s one reason we haven’t simply exposed every FreeRTOS method to the user app.
If we expose a simple enough API for queues, it should be possible to abstract away the details specific to FreeRTOS.
If you are building locally, you can use this PR - https://github.com/spark/firmware/pull/1019. Access to queues will be available in 0.6.0, with a high level Wiring API in 0.7.0.
Cool. I ported the application using the os_ API, so that’s basically best case for my situation.