- When a low priority task is running and a higher task is ready , the time sheculer switches it in .
- The time when an interrupt is triggerd by pins and the moment the isr is switched in.
- The time when an interrupt is triggerd by task and the moment the isr is switched in.
- The time duration needed by a task to delete itself (exclude the idle cleaning up time).
- The time duration a mutex/semaphore is taken/given. I meant the extra time to take/give the mutex/semaphore, not include the task switching part.
- time duration for a task to switch to suspend state.
- time duration for a task to take/write a unit from/to a queue.
when i use ATmega328P based arduino uno, I found that the “portTICKPERIODMS” in default is 16. So I assume the “tick period” or the “time slice” is for the switching frequency between tasks have equal priority. And all the events in the following list are in general faster than this duration:
As a general rule, the ATmega328P is a bad choice for running FreeRTOS as it has extremely limited resources in flash and especially in its available free ram memory. You may want to consider using an Atmel M0 processor like the ATSAMD21ZG18 series, about the same cost with lots more resources for running FreeRTOS… In my option, if your building less that a few thousand of something the cost of a 32bit processor is far less in total cost that using any 8 or 16 bit processor… Development time is less, and trying to squeeze code in a small processor is just a waste of development time… again, just my 2bits…
The Tick period defines the resolution for delays and timeouts. It also defines the base inveral for task switching when multiple tasks of the same priority switch between themselves. It does not affect the time for the system to perform most other actions. Note that this pretty much assumes preemption is turned on. If preemption is turned off, then task switching doesn’t happen except at defined FreeRTOS calls, so things like your item 1, as then the higher priority task doesn’t get started automatically, but needs to wait for the lower priority task to make a FreeRTOS call that allows the scheduler to be run.
I’m not sure I’m following the question, if this is a question. In FreeRTOS time is measured in ticks, and ticks are specified using unsigned integers. Therefore, you cannot specify fractions of a tick, and the resolution you are able to achieve is subject to normal integer rounding. With regards to your list, and all subject to the compiler being used, frequency the chip is running at, the FreeRTOSConfig.h settings, and the compiler optimisation for actual values: 1, 4, 5 and 6 – fast enough for you not to be concerned about it in all but extreme cases. 2 and 3 – Something the hardware does, not the software. 7 – Depends on the amount of data read from the queue. If you want to save a lot of data its best to queue a pointer to the data.
Yes. the 328 is just for a test drive. I will use more powerful mcu.
very clean explanation, yes, preemption is on.
I see. So 2 and 3 will in general be faster than other items because they are handled by the hardware. In general the question was ask if there is some kind of benchmark test of freeRTOS on some typical and popular mcu about all thoses timings. Kind like Bill in this thread did–measuring the time for a semaphore giving: https://forum.pjrc.com/threads/46733-Support-for-FreeRTOS?highlight=freertos The question left is the portTICKPERIODMS is 16, it is quite slow. if I have a super high priority task with a loop, to avoid starving other tasks I need to put an explicit delay in it anyway, then it has to be at least 16 millisec… I guess this 16 ms for such a mcu is reasonable and it can be set faster, but will have higher overhead due to more frequent interruption. So is there a better way to have a fast loop (50uS interval is okay) without starving low priority tasks?
There are two basic things I find that determine what frequency the tick needs to be. The first is what rate do I need a purely time based activation of a task to be. The second is how accurate do I need timeout values to be (which rarely needs to be very precise). There is also always the option of having a second timer interrupt operating checking at a higher rate than the tick if something needs to be done to avoid an artificially fast tick rate. The concept of a “super high priority task” having the possibility of starving the rest of the system sounds to me like something isn’t defined right, or you are on the wrong platform. One thing to note, ‘High Priority’ does not mean Very Important, but more implies Short Timelines which normally implies Quick. If your high priority task is really just polling, looking for something, that indicates a design issue, You really want this to be based on an interrupt (polling loops are the anti-thesis of real time design). As to benchmarks, the biggest issue with doing benchmarks is that with the wide range of systems FreeRTOS runs on, it is easy for a benchmark to be misleading if it isn’t on a very similar setup, and there are too many of them to really perform.
50us is very fast. If feasible (depends what it is doing) you could have a second timer at that speed and perform the actions you need in the ISR itself.
Yes. I meant in order to avoid starving other tasks I need a delay in the high priorty loop to slow it down. Oh, great there is a way to implyment a second and fast timer and I guess to have the isr handle the high priority code. Is this method included in the tutorial pdf or easy to find out? So I guess after implementing this, the trace is like: timer1 duration:—— timer2 duration:– –interrupt&isr–interrupt&isr–interrupt&isr–interrupt&isr–interrupt&isr– ——lowPTask——lowPTask——lowPTask——lowPTask——lowPTask—— This information is important! The reason I request a benchmark is that I think people can have better idea what mcu they need for certain tasks. And also I plan to share the experience of freeRTOS with people in a presentation in a seminar in some research institute soon. It will make a lot experiment easier. But that is okay.
It is not in the tutorial guide as it is outside of FreeRTOS – just configuring a timer on on the device to generate an interrupt as you would in any other MCU application. It is device specific as to which timers are available for this purpose.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.