critical sections in cr queue implementation

pabigot wrote on Thursday, July 26, 2012:

While implementing optimized critical section macros for the MSP430 port, I notice that xQueueCRSend and xQueueCRReceive use portDISABLE_INTERRUPTS()/portENABLE_INTERRUPTS() instead of portENTER_CRITICAL/portLEAVE_CRITICAL to implement a critical section (at least, in V7.1.1).

An unusual but valid design for MSP430 programs is to leave interrupts disabled at all times except when in low power mode.  The new macros I’ve implemented restore the interruptibility state to what it was when the first critical section was entered, rather than unconditionally enabling interrupts, so FreeRTOS can be used with applications that follow this design.

Explicitly enabling interrupts in xQueueCRSend and xQueueCRReceive breaks this feature for MSP430 programs that use coroutines.

Since taskENTER_CRITICAL is defined in terms of portENTER_CRITICAL, I believe it should be possible to assume the port-named versions are available, and to use them (if the intent was to avoid “task*” invocations in coroutine support).  Is there a reason why the existing critical section approach is required for these functions?


rtel wrote on Thursday, July 26, 2012:

I don’t really recall, although the co-routines run at the lowest priority and are co-operative, so the critical section nesting is not as necessary.

I would be interested in seeing your code, as I’m sure would others, so please post it up to the FreeRTOS Interactive site once it is complete.


pabigot wrote on Thursday, July 26, 2012:

Since the blocking coroutine calls are leaf functions and must be invoked from the coroutine function itself I would not expect a fully coroutine-based application to involve nesting, but I also wouldn’t want interrupts enabled for me after the call completes if they were disabled before the call.  Refining “critical section” so that doesn’t happen would seem to make things more clear.

I’m working on a generalization of freertos-mspgcc (already on github at  The new version will provide FreeRTOS support for all MSP430 chips in a single port, leveraging an external library for peripheral/MCU-specific functionality and reducing the dependency on mspgcc (IAR and CCS should, at least theoretically, be supported as well).  I’m optimistically hoping to have some compelling examples implemented in an initial public release in about a week, and will post an announcement when that happens.

rtel wrote on Thursday, July 26, 2012:

The official FreeRTOS MSPGCC port has issues with the latest MSPGCC versions, and this is noted in the “Known Issues” list on the download page.  Could you please post a link to your github repository in the FreeRTOS Interactive site, then I will add a link to the FreeRTOS Interactive post in the Known Issues list so people know where to go for up to date versions.  Thanks!