# CMSIS and sub millisecond delays

We are running FreeRTOS with CMSIS. Is it possible, using CMSIS on STM32F3 Discovery board, to have periodic tasks running with periods less than 1 millisecond resolution? We want to run tasks at 400 Hz, meaning the period should be 2.5 milliseconds. All functions pertaining to delays in CMSIS that i've found have millisecond resolution. Should we reconsider using CMSIS for our purposes?

EDIT 2: A straight forward question now, hehe. Could someone show me an example of how to setup a task to run periodically with a rate of 400 Hz with FreeRTOS, possibly using CMSIS but not limited to it, on STM32F3 Discovery board?

EDIT: I will try to explain in more detail. The task is a PID controller that should run as fast as possible, but no faster than 432 Hz. So 400 Hz seemed like a round number. This means that 2 ms is a too short period. And the difference in task frequency between 2 ms and, say, 4 ms is quite dramatically. I don't quite know how much jitter we can accept, though. But it should probably not be in the millisecond range.

It seems more and more like we have to make use of the native FreeRTOS calls for the timing of tasks.

We would happily trade CPU utilization for greater timing accuracy since we won't probably make use of a great deal of the cycles in non-OS activity.

• Periods less than or periods greater than 1ms? – Andy aka Dec 2 '14 at 15:08
• Well, less than. But in this specific case the period is greater than 1 ms. since it is 2.5 milliseconds. osDelay takes integer number of milliseconds as parameter as i understand it. We would need the resolution of this parameter to be in the microsecond range. – mickey Dec 2 '14 at 15:31
• How you might go about solving this depends an awful lot on how accurate your 2.5ms period has to be. I suggest that you clarify that in your question. – markt Dec 3 '14 at 6:13
• If I may, this doesn'the seem like a great task for an RTOS. You need to be closer to the metal – Scott Seidman Dec 4 '14 at 11:37
• Ah, ok. Using an RTOS in our design is a demand by our teacher, as is the requirement of running tasks at 400 Hz. Furthermore, the class of last year supposedly managed to meet these requirements. – mickey Dec 4 '14 at 20:13

The granularity is probably a limitation from FreeRTOS, not from CMSIS itself.

Since you require a task every 2.5ms you might want to setup a timer to trigger every 2.5ms (Interrupt). Do what you have to do inside your interrupt (but keep it short) and get out as fast as possible. Usually there is hardware available for specific tasks, so if you can tell us something about your task at hand, there might be a better solution.

• But FreeRTOS have functions for delays where you can specify the length in ticks rather than millis, so it seems that it is not a limitation of FreeRTOS? – mickey Dec 2 '14 at 17:11
• Maybe I chose the word "limitation" wrong. It was a design decision which set the default system tick rate to 1ms (this is done commonly). How exact do you need to keep your deadlines? Because the 1ms tick is just a signal which lets another thread do its work and not a reliable time delay source. – Tom L. Dec 2 '14 at 17:13

I found the solution eventually! What I did was to change the constant 'configTICK_RATE_HZ' in 'FreeRTOSConfig.h' to something so that 400 Hz could be expressed as an integer multiple of the tick rate, and then used the function 'vTaskDelayUntil'. I.e. 'configTICK_RATE_HZ 4000' and 'vTaskDelayUntil(&firstWake, 10)'.

Be sure to set 'INCLUDE_vTaskDelayUntil 1' in the same file as well!

They warn about using values greater than 1000, but it seems to work for us. The CMSIS functions `osDelay*' cannot be used anymore though.

You are correct that FreeRTOS specifies all timings in ticks (as can be seen by the name of the parameters in functions such as vTaskDelay(), although vTaskDelayUntil() is better suited to periodic tasks). The pdMS_TO_TICKS() macro is used to convert milliseconds to ticks. When using FreeRTOS by itself therefore the limitation is actually one of processing power. Setting sub millisecond ticks is indeed possible and lots of people do it, but naturally you will experience a greater percentage of your CPU time going to processing interrupts.

If the CMSIS APIs don't allow sub millisecond times to be specified then there is nothing to stop you calling the native API too. Restricting times to be multiples of ms would appear to be somewhat limiting as it assumes your tick is an exact multiple of ms.

• Ok, could you provide an example of how to set sub millisecond ticks? FreeRTOS API style or CMSIS doesn't matter.. – mickey Dec 4 '14 at 10:53