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] [August 2014 Threads] FreeRTOS Semaphore overhead timePosted by kilombo on August 27, 2014 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
FreeRTOS Semaphore overhead timePosted by rtel on August 27, 2014 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.
FreeRTOS Semaphore overhead timePosted by kilombo on August 28, 2014 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.
FreeRTOS Semaphore overhead timePosted by davedoors on August 28, 2014 I just tried the same and got 7.6uS, but with a faster clock.
FreeRTOS Semaphore overhead timePosted by kilombo on September 1, 2014 Hello Dave,
How fast is your clock?
Itay,
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|