First of all I would like to note that I am quite new at the RTOS business. I am using FreeRTOS on my STM32L151VC arm processor. I am using binary-semaphore to sync between an interrupt and some task (The semaphore state that the DMA has finished its action). Now, The time passed between the command of xSemaphoreGiveFromISR() to the required task being on and running again is about 50[us]. That seems too long to me, isn’t it? I would like to state, that for this test I have used only 1 task (and IDLE task), my cpu clk is 24[MHz]. I have looked on FreeRTOS web-sites for some answer and didn’t find any. I only found a statement that this action should take less than 1[us]. I am using IAR embedded workbench. I measure the time pasted with oscilloscope (Pulling up a GPIO before the command is issued and lowering it when the task begin to run). On IAR I am using high level of optimization and right after the command of xSemaphoreGiveFromISR() I am using portYIELDFROMISR() (For shorter switch time to task). My question is, has anyone encountered a similar problem? Anyone knows how to solve this time overhead problem? Is 50[us] a normal time? Thanks for all the helpers.. Itay

I’m not sure what time you would expect, some questions: Do you have stack overflow detection turned on? If so that will consume a good portion of the time as it checks for a pattern being written over at the end of the stack (as well as some other things, but that is the bit that takes time). Do you have configASSERT() defined? That too will add run time as there is quite a lot of interrupt priority checking done in the assert statements. On that processor and at that speed you could take out some of the memory barrier instructions, which will prevent the pipline from being wiped out in several places. Do you have configUSEPORTOPTIMISEDTASKSELECTION defined to 1 in FreeRTOSConfig.h? If not your task selection will use a generic C algorithm, instead of a single instruction to select the priority of the next task from a bitmap. 24MHz, by today’s standards at least, is somewhat slow. Do you have wait states on your flash memory – if so I would not have thought they would be necessary at that speed (if indeed wait states are even an option if this is internal flash). Regards.

First, thank you for the quick answer. I adjusted the freeRTOS.h file like you said and the result is really good! now, the time it takes to switch to the working task is 28[us]. The project I am currently, working on, is for a low power application, therefore I would rather the program will spend most of the time in low power mode. That is why I am trying to cut all the unnecessary overhead-time. You mentioned in your answer “memory barrier instructions”, can you please expand on that, if you have time. I am not sure what kind of instruction are we talking about. Thanks again for your help.

I just tried the same and got 7.6uS, but with a faster clock.

Hello Dave, How fast is your clock? Itay,