1. I’m running on STM32 with 120MHz CPU clock what is acceptable range of configTICK_RATE_HZ for this case. I mean what is the max rate what will keep OS run time relatively small compared to processes run time.
2. What is an average process switch time? Based on this parameter I can answer question 1 as well.
3. I have an alphanumeric LCD on board and it’s working fine. But this type of LCD requires delays of about 100us after each character write. Currently I run with configTICK_RATE_HZ = 1000 and to implement 100us delay I busy loop.
Do you have any suggestion on implementing sub TICK_RATE_HZ delays better then loop?
1. I’m running on STM32 with 120MHz CPU clock what is acceptable range of configTICK_RATE_HZ for this case. I mean what is the max rate what will keep OS run time relatively small compared to processes run time.
Most applications use a tick of 10 to 100ms. I would not recommend going faster than 1ms.
2. What is an average process switch time? Based on this parameter I can answer question 1 as well.
You have the hardware and compiler with your compiler settings in front of you so I suggest you just measure it. All context switches are performed by the PendSV handler, so you can time how long that takes to execute. If you are using FreeRTOS V7.3.0 then you can also define configUSE_PORT_OPTIMISED_TASK_SELECTION to 1 to save a few extra cycles at the cost of being limited to 32 different priority levels.
3. I have an alphanumeric LCD on board and it’s working fine. But this type of LCD requires delays of about 100us after each character write. Currently I run with configTICK_RATE_HZ = 1000 and to implement 100us delay I busy loop.
Do you have any suggestion on implementing sub TICK_RATE_HZ delays better then loop?
If it is a small display that only holds a few characters you might be better off just using a delay of 1ms as it won’t be noticeable. If you have a large display, or are scrolling characters then the additional time would be noticeable.
We are also using the stm32 and several of the subsystems require usec timing. We run freertos at 1msec and use the chips HW timers for the usec timings. Set up the timer to interrupt at the time out value - in your case 100usec - and in the handler post a message to the LCD task - or have the LCD code block on a semaphore released in the interrupt handler. Use the macro portEND_ISR_SWITCHING (true) - I think that’s the macro - I don’t have the code in front of me at the moment. Returning true will ensure or LCD task executes immediately (assuming it’s the highest priority task).
We’ve examined this implementation on a scope and it’s pretty much dead on.
Before this approach we actually ran the OS at 100usec - clearly too fast but it was a quick way to maintain the 100usec timings of the system while we converted it from a loop to FreeRtos. At 120MHz, the stm ran just fine. We then changed to 1msec and used HW timers (about 5 timers being used in this manner) and now the CPU spends most of its time doing nothing.
I was thinking about running CPU timer and busy loop with taskYIELD checking the timer value advance. If no other process is ready to run I will catch delay period exactly at time otherwise I will be late but will let other process to run. Considering that LCD task priority is low it’ s quite OK.