I create an array of semaphore (in my case is two elements).
xSemaphoreHandle sig_Pulse[NUMBER_CHANNEL];
and then initiate and take it
vSemaphoreCreateBinary(sig_Pulse[CHANNEL1]);
xSemaphoreTake(sig_Pulse[CHANNEL1],0);
but the problem is that when the interrupt sending semaphore
xSemaphoreGiveFromISR(sig_Pulse[CHANNEL1], &higher_priority_task_woken);
portEND_SWITCHING_ISR(higher_priority_task_woken);
it not enable the other task, which is waiting for this semaphore
xSemaphoreTake(sig_Pulse[channel],portMAX_DELAY);
but if I use the normal way with if…else then it work correctly
if (channel == 0)
{
xSemaphoreTake(sig_Pulse1,portMAX_DELAY);
}
else
{
xSemaphoreTake(sig_Pulse2,portMAX_DELAY);
}
This is both semaphore in 1 array.
CHANNEL1 and CHANNEL2 are only the predefined keyword for number 0 and 1 and NUMBER_CHANNEL is equal to 2.
My board is sam3u4e-ek with atmel studio 6.2 beta compiler. and the kernel is free rtos 7.3.0
please tell me where the problems is???
hello Dave,
This is both semaphore in 1 array.
CHANNEL1 and CHANNEL2 are only the predefined keyword for number 0 and 1.
and NUMBER_CHANNEL is equal to 2.
I just put together and tried the following tiny application that gives two semaphores that reside in an array in the tick hook (which is called from an interrupt) and everything executed in the expected sequence. I’m not sure what your problem is, but maybe it is not the way you are using the semaphores, but how your interrupt priorities are defined (which is what probably 95% of support requests on Cortex-M devices, especially STM32 parts, turn out to be). If you were using FreeRTOS V8.0.0 (or maybe even V7.6.0) then you could defined configASSERT() and it would automatically call assert if you had the interrupt priorities wrong.
voidvTask1( voidpvParameters )
{ for( ;; )
{ / Wait for the semaphore, and increment the counter when it is received. /
xSemaphoreTake( xSemaphores[ 0 ], portMAX_DELAY );
ulTask1++;
}
} /-----------------------------------------------------------*/
voidvTask2( voidpvParameters )
{ for( ;; )
{ / Wait for the semaphore, and increment the counter when it is received. */
xSemaphoreTake( xSemaphores[ 1 ], portMAX_DELAY );
ulTask2++;
}
}
thank you Real Time Engineers ltd very much for the fast support.
I do define the same configASSERT() and set my hardware interrupt priority as configMAX_SYSCALL_INTERRUPT_PRIORITY as already mentioned in Freertos page. But the error triggered hardfault problem instead of configASSERT().
Could you add the “portEND_SWITCHING_ISR” or taskyield() to the function to check that again?
It is really weird because there must not be any difference between the 2 independent semaphore and those in an array. I would change to version 8.0 to check that again.
Thank you very much.
yes I do check it, and it does correctly (with warning in compiler) but the task take it correctly.
(if it goes wrong then the 2 separate semaphore will going wrong too but it actually does right).
I do define the same configASSERT() and set my hardware interrupt priority as
You would need to be using FreeRTOS V7.6.0 or later for that to catch a priority misconfigurtion.
Could you add the “portEND_SWITCHING_ISR” or taskyield() to the function to check that
again?
If the problem is related to the access of the semaphore then that would not make any difference, but I tried it all the same and it didn’t change the behaviour or my test application.
In your case I can only assume either an interrupt priority problem, a problem indexing into the array, or a problem creating the semaphores in the first place - although I understand you have checked those already.
But the error triggered hardfault problem instead of configASSERT().
That has to be the biggest clue as to what the issue is. I would recommend stepping through the code until you see the hardfault occur, then look at what was being accessed immediately before the hardware (what triggered the hard fault). The following link may also help - but just stepping through the code would be easier:
But the error triggered hardfault problem instead of configASSERT().
I'm sorry about this, I misremembered. I already fix this problem (before I post this quesion).
I change the OS to version 8.0.0 and it does not make any difference at all. (I already change the to xSemaphoreCreateBinary() instead of vSemaphoreCreateBinary() too)
I mean the two separate semaphore does work as normal but the semaphore in array does not work, no assert trigger found.
The problem is that it does send semaphore but the other task can not take it and thus nothing work.
the waiting task, named Calculate1, does in ready status at the time the semaphore give but cannot take it. The waiting command is:
xSemaphoreTake(sig_Calculate[channel],portMAX_DELAY);
I observe the semaphore via the function vQueueAddToRegistry().
Create a small a project as you can that still exhibits the problem, check it builds correctly on any machine (it does not rely on any absolute paths to tools, source files, linker scripts, etc), zip it up and send it to the ‘business contact’ email address on the http://www.freertos.org/contact web page.
I recheck my project and realize that the semaphore does send and receive but the problem is that it seem the array of semaphore make the “semaphore get” slower. And thus missing more than half of the semaphore give.
it seem the array of semaphore make the “semaphore get” slower
How could it do that? Inside the function it just has a pointer to a semaphore, if the semaphore is stored in the same kind or RAM (rather than external RAM in one case and internal RAM in the other) it can’t make any difference to the speed.
Sounds like you should be using a counting semaphore.
thanks all for your support. Things now running as expected. The array of semaphore run as the two separate semaphore now. The reason is that some mistake in my code (I still dont know where), when I re-code it, step by step, everything goes right. Problem solved!