Greetings,

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.

Thanks, Woody

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.

"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.

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?

All ideas are considered...

Regards.