@gedare @c-mauderer @JoelSherrill
Thanks for the guidance on rtems_message_queue_construct(), noted.
I’ve started working on my proposal. Should the proposal focus only on the device stack for now, or is there an expectation to include the host stack as well?For the first working deliverable, is a USB CDC example on STM32F4 Black Pill sufficient, or should I target a more complex device class?Is a 12-week timeline for osal_rtems.h+CDC device example+test suite a realistic scope?
@gedare @c-mauderer
Quick update while I work on the proposal:
My GSoC 2026 tracking page has been merged: tracking/2026: add Moksh Panicker (!182) · Merge requests · RTEMS / Programs / Google Summer of Code · GitLab
I’m currently drafting the proposal based on the work done so far. I’m still looking forward to your feedback on the scope questions above, particularly whether to include the host stack, and whether cdc on STM32F411 is the right first deliverable.
Thanks
I’m a bit confused by your questions. The main work to be done should be to provide the OSAL. The host/device stacks should already be there and work with the target hardware you use. Otherwise, you should pick a different target hardware, to reduce the uncertainty in the project scope.
You’ll have to determine based on your board how you could test it. I would strongly recommend running the baremetal or FreeRTOS versions of TinyUSB as part of scoping out your project. This will help you to be sure that hardware availability and support will not be blockers in your effort.
Thanks for clearing that up makes a lot more sense now. So the OSAL is really the core of the project and the stacks just work once that’s in place.
I’ve already been running TinyUSB baremetal on my STM32F411 Black Pill CDC+MSC enumerated fine, /dev/ttyACM0 showed up no issues. I’ll run the FreeRTOS version next on the same board like you suggested and include both in the proposal.
1 Like
Alright, so I ran the FreeRTOS version on the Black Pill as suggested.
Baremetal cdc+msc came in at 24KB flash, ~9.5KB RAM. FreeRTOS version was 30KB(5.79%) flash, 16KB(12.53%) RAM, same enumeration, /dev/ttyACM0 working fine on both. So FreeRTOS adds roughly 6KB flash and 6.5KB RAM, which I think is nothing on a 512KB/128KB chip.
Hardware isn’t a blocker. I’ll put both results in the proposal.
Sounds good, I think you should be pretty well set then to work on your proposal. Add it to your tracking page if you haven’t already. I try to look at all the proposals at least once, and I try to match potential mentors to review proposals as well.
1 Like
@gedare @c-mauderer @JoelSherrill
I’ve added a draft of my GSoC proposal to the tracking page.
Happy to receive any feedback before the final submission.
@gedare @c-mauderer @Dhrulian1 @JoelSherrill
I’ve added my GSoC 2026 proposal draft for “Port TinyUSB to RTEMS” to the tracking page and linked the Google Drive document from my entry. I’d really appreciate any feedback or suggestions for improvement before I submit on the GSoC website.
Also, could you please let me know if any mentors have been (or could be) matched to this project so I can coordinate with them on refining the scope and timeline?
@gedare @c-mauderer
While I was studying the FreeRTOS osal for my tinyusb port, I noticed it has a dedicated spinlock section that handles single-core and multi-core MCUs differently, taskENTER_CRITICAL() for single-core and portMUX_TYPE spinlocks for multi-core (Espressif).
For the RTEMS OSAL, I’m planning to use rtems_interrupt_local_disable/enable for single-core targets. For SMP-capable RTEMS targets, should I use rtems_interrupt_lock_acquire instead?
Also, is it safe to ignore the multi-core path for now since my initial target (STM32F411) is single-core, or should the OSAL handle both from the start?
Sorry, I missed that message. If possible, I would suggest to keep multicore in mind during the port.
For SMP applications, the rtems_interrupt_lock_... is the correct mechanism. You can use that for non-SMP applications too. On non-SMP configurations, it falls back to the same mechanism that is used by rtems_interrupt_disable or rtems_interrupt_local_disable. If you check the definition, you will find the following:
#define rtems_interrupt_lock_acquire( _lock, _lock_context ) \
_ISR_lock_ISR_disable_and_acquire( _lock, _lock_context )
and
#if defined( RTEMS_SMP )
#define _ISR_lock_ISR_disable_and_acquire( _lock, _context ) \
_SMP_lock_ISR_disable_and_acquire( \
&( _lock )->Lock, \
&( _context )->Lock_context \
)
#else
#define _ISR_lock_ISR_disable_and_acquire( _lock, _context ) \
_ISR_Local_disable( ( _context )->isr_level )
#endif
Like mentioned, the _ISR_Local_disable is the same function, that is used by the rtems_interrupt(_local)_disable. So for non-SMP systems, it doesn’t matter. I didn’t check how taskENTER_CRITICAL() and portMUX_TYPE are used in tinyusb. But if possible, I would just create one implementation that covers SMP and non-SMP applications using the RTEMS ISR locks.
1 Like
Thanks for the clarification. So the approach will be to use rtems_interrupt_lock_acquire / rtems_interrupt_lock_release uniformly across the osal spinlock implementation. The automatic fallback to _ISR_Local_disable on non-SMP builds means one clean implementation covers all RTEMS configurations. I’ll design the osal with this in mind from the start.