Macro to declare Status Reg for Critical Sections

woody242 wrote on Friday, July 24, 2015:


We are working on Zync processor and wanted to implement critical sections that could be common between ISRs and App code. The need is due to reuse of some code that used to run on uCOS-II and worked and we prefer not to have two copies one for ISR and one for APP code.

Curious why FreeRTOS does not provide a MACRO to declare a status register variable. For space critical apps this could be empty so no hit on space. We noticed when we pull in the trace code that the trace code provides three macros and is implemented this way for A9 port. IF the critical section macros are implemented properly the trace method would be nice but it must be implemented with critical nesting for it to be guaranteed to work in app code.

Is there any chance a future revision of freeRTOS might provide this macro in any function where critical sections are done to give port developers the flexibility to implement critical nesting and interrupts this way.

We are considering making this change locally but this is obviously not desirable.


edwards3 wrote on Friday, July 24, 2015:

I think on an A9 you can call ulPortSetInterruptMask() and vPortClearInterruptMask() from tasks and interrupts. vPortClearInterruptMask() takes the value returned by ulPortSetInterruptMask() as its parameter.

rtel wrote on Sunday, July 26, 2015:

“in the beginning” FreeRTOS was only used on really tiny processors and didn’t support interrupt nesting so the critical nesting method was chosen to be simple and use no stack (back then stack was the limiting factor). Later ports ports were to larger parts, and interrupt nesting was supported, so the interrupt safe method was introduced - but only for ports that support interrupt nesting.

Somewhere, in the forum, or on a ticket in SourceForge, there is an implementation provided by somebody that allows both methods to be replaced by a single method while maintaining backward compatibility. It uses macros and block scope variables though, which is technically against the coding standard (block scope variables), but it would be nice to incorporate something like it into the code.

woody242 wrote on Monday, July 27, 2015:

Thanks, I’ll take a look. Seems like the coding standard violation could be avoided if a macro to declare a function scope variable was added. Do you think this might be considered in a future release?

rtel wrote on Monday, July 27, 2015:

All ideas are considered…