FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [January 2015 Threads] Yet another portENTER_CRITICAL() questionPosted by nburkitt on January 30, 2015 I've run into a problem caused by my calling from an ISR a function that, ultimately, calls portENTERCRITICAL(), or more to the point, portEXITCRITICAL(), with the well-discussed effect that interrupts get enabled while still in the ISR. Fine, I understand the problem.
My solution, for which I guess I'm seeking validation, was simply to increment uxCriticalNesting from within the FreeRTOS interrupthandler, after its original value has been saved. When interrupthandler finally unwinds, it restores uxCriticalNesting to its original value, and no one is the wiser, except that my code doesn't crash.
It seems to me that this is a legitimate use of uxCriticalNesting, and I can't see any drawbacks, but then I didn't write the Microblaze port, and I don't like second-guessing published code.
Am I all wet? Do I just not understand the point of uxCriticalNesting? I appreciate any thoughts on the subject.
Thanks,
-Nick
FreeRTOS V8.1.2
Xilinx Spartan 6
MicroBlaze 8.50a
Xilinx EDK 14.5
Yet another portENTER_CRITICAL() questionPosted by richard_damon on January 30, 2015 One issue that I can think of is that if your port allows for interrupts to nest, you still might need to use a critical section, only they are written differently in the interrupt context.
Yet another portENTER_CRITICAL() questionPosted by rtel on January 30, 2015 The Microblaze port does not (not yet, anyway) support interrupt nesting.
What Nick is doing is technically breaching two of the API usage
restrictions - whether that actually matters or not depends on the the
API function being called and the situation in which it is being called.
What is being called from the ISR? If it is anything that could
potentially result in a yield being attempted then it will be very
dangerous on the Microblaze (less so on other ports).
Regards.
Yet another portENTER_CRITICAL() questionPosted by markwrichardson on January 30, 2015 I remember thinking about this a while back while getting my port running on a Zilog eZ80. I use nested interrupts.
I came up with something that sounds similar
~~~~~~
void vPortEnterCritical( void )
{
portDISABLE_INTERRUPTS();
uxCriticalNesting++;
}
void vPortExitCritical( void )
{
uxCriticalNesting--;
if( uxCriticalNesting == 0 )
{
portENABLE_INTERRUPTS();
}
}
~~~~~~
I'm interested in hearing the same thoughts.
FreeRTOS V8.0.0
Zilog eZ80F91
ZDSII 5.1.1
Yet another portENTER_CRITICAL() questionPosted by nburkitt on January 31, 2015 To be clear, the only functions being called are mine, and the only FreeRTOS API members being referenced are the critical section macros*. It seems that my solution should be safe, but only as a special case where nested interrupts are not possible. :-/
Rather than using uxCriticalNesting as an interrupt detector, I've added a dedicated flag that is incremented upon entry to interrupthandler() and decremented upon exit. Testing its value in the trace macro functions, and in portENTERCRITICAL should help protect me from myself.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|