Mutex in ISR
I know this had to have been discussed before, but searching the forum fails me….
PIC32 and FreeRTOS application. I have a hardware interrupt (INT0) which increments a long variable everytime it fires. I have a task that runs every 100ms which reads and clears that variable.
I thought I could use xSemaphoreTake and xSemaphoreGive in the ISR, but that crashes the program. Then I looked at xSemaphoreGiveFromISR, but that doesnt work either.
So how do expert FreeRTOS developers create exclusion between the task and ISR. I have the “Using the FreeRTOS Kernel… PIC32 edition”, but the example doesnt seem to fit.
thanks!
Mutex in ISR
The “FromISR” versions should certainly work, but check your FreeRTOSConfig.h to make sure that configMAXSYSCALLINTERRUPT_PRIORITY is set at least as high as the priority level of your interrupt handler.
Mutex in ISR
You can also turn off interrupts for a very short time to read variable…
volatile long myVarable
long myNewVarable
task…
taskDISABLEINTERRUPTS ();
myNewVarable = myVarable;
taskENABLEINTERRUPTS ();
On Fri, May 29, 2015 at 2:48 PM, Robert H. Oujesky roujesky@users.sf.net
wrote:
I know this had to have been discussed before, but searching the forum fails me…. PIC32 and FreeRTOS application. I have a hardware interrupt (INT0) which increments a long variable everytime it fires. I have a task that runs every 100ms which reads and clears that variable. I thought I could use xSemaphoreTake and xSemaphoreGive but that crashes the program. Then I looked at xSemaphoreGiveFromISR, but that doesnt work either. So how do expert FreeRTOS developers create exclusion between the task and ISR. I have the “Using the FreeRTOS Kernel… PIC32 edition”, but the example doesnt seem to fit.— ~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ Tom Lafleurthanks!
Mutex in ISRhttps://sourceforge.net/p/freertos/discussion/382005/thread/9442dd83/?limit=25#a831
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Mutex in ISR
I would vote for Tom’s solution:
~~~~~
uint32_t ulTickCount = 0ul;
void atask( void *pvParameters
{
for( ;; )
{
/* Reading a 32-bit variable in 32-bit memory
should be safe. */
if( ulTickCount != 0ul )
{
taskDISABLEINTERRUPTS ();
ulTickCount–;
taskENABLE_INTERRUPTS ();
}
}
}
void an_isr()
{
/* The task has protected itself against possible
interrupts. We’re not expecting a nested interrupt
that also accesses ‘ulTickCount’. */
ulTickCount++;
}
~~~~~
Programmers dislike disabling interrupts, but in the above case I see no better solution. As you’ll know the compiler will create at least 3 instructions for a de- or increment in memory:
~~~~~
ulTickCount–;
ldr r2, [r3] // Load from memory
sub r0, r2, #1 // Decrease with 1
str r0, [r3] // Store in memory
~~~~~
Getting an interrupt in-between these instructions would be fatal,
ulTickCount
gets corrupted.
About xSemaphoreGive
:
When you are sharing resources/objects among tasks, a semaphore or a mutex can be very useful. Before using the resource you take
the semaphore, when ready you give
the semaphore:
~~~~~
if( xSemaphoreTake( xUSARTAccessSemaphore, ( TickType_t ) 10 ) )
{
vUSARTWrite( pcMessage, xLength );
xSemaphoreGive( xUSARTAccessSemaphore );
}
~~~~~
About xSemaphoreGiveFromISR
:
Sometime a resource becomes available when an interrupt fires, for instance when data is received or sent.
Suppose a USART receives characters and an ISR stores them into buffers. xSemaphoreGiveFromISR
is called as soon as one buffer is full:
~~~~~
void anisr()
{
BaseTypet xHigherPriorityTaskWoken = psFALSE;
/* Read a character from the register: */
ucUSARTBUffer[ xUSARTIndex ][ xUSARTHead ] = UDR0;
if( ++xUSARTHead == USART_BUF_LENGTH )
{
xUSARTHead = 0;
if( ++xUSARTIndex == USART_BUF_COUNT )
{
xUSARTIndex = 0;
}
/* As noticed above: the priority of this ISR should not
be higher than configMAX_SYSCALL_INTERRUPT_PRIORITY. */
xSemaphoreGiveFromISR( xUSARTSemaphore, &xHigherPriorityTaskWoken );
}
portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
~~~~~
Regards,
Hein
Mutex in ISR
My first modification would be to use taskENTERCRITICAL/taskEXITCRITICAL if the interrupt has a priority below configMAXSYSCALLINTERRUPT_PRIORITY (as would be required to call any FreeRTOSAPI). This typically only disables those interrupts and not higher priority interrupts, it also nests properly incase your code that needs protection might be in a function called within a bigger critical section.