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!

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.

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.

thanks!

Mutex in ISR

https://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/

~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~

Tom Lafleur

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

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.