time resolutions in freeRTOS in general

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:
  1. When a low priority task is running and a higher task is ready , the time sheculer switches it in .
  2. The time when an interrupt is triggerd by pins and the moment the isr is switched in.
  3. The time when an interrupt is triggerd by task and the moment the isr is switched in.
  4. The time duration needed by a task to delete itself (exclude the idle cleaning up time).
  5. 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.
  6. time duration for a task to switch to suspend state.
  7. time duration for a task to take/write a unit from/to a queue.
I am kind of confident about the very first three. But not sure about the last four because in the tutorial guide, there is a sentence “FreeRTOS API calls always specify time in multiples of tick periods, which are often referred to simply as ‘ticks’.” So does that mean functions like vTaskDelete() vTaskSuspend have to happen after integernumber of tick period? Or any task with this kind of functions have bind to this peace? If a task has the highest priority and has a loop so it has to apply some delay between loop to not starve other tasks, then the loop frequency can go beyond 1000/portTICKPERIODMS (<100 in my case)? I guess to set the tick period at this is reasonable to avoid a lot overheads just want to make sure the understanding is correct. Some estimation and the order of each of the time duration in the list will be very helpful for people to design their high efficient freeRTOS program.

time resolutions in freeRTOS in general

​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…

time resolutions in freeRTOS in general

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.

time resolutions in freeRTOS in general

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.

time resolutions in freeRTOS in general

Yes. the 328 is just for a test drive. I will use more powerful mcu.

time resolutions in freeRTOS in general

very clean explanation, yes, preemption is on.

time resolutions in freeRTOS in general

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?

time resolutions in freeRTOS in general

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.

time resolutions in freeRTOS in general

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.

time resolutions in freeRTOS in general

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.

time resolutions in freeRTOS in general

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.