# Mbed OS efficiency

I'm planning on using the mbed in a motion control project, where certain threads need to run at a specific, high frequency.

Using the mbed library, I could use Ticket to calculate the time spent within a thread, and then subtract that from the desired wait time, and then feed the result into the thread::wait method to ensure a consistent frequency. However, would this be efficient at high frequencies (1500hz with some heavy calculations in the thread)?

In such cases, would it be better to take advantage of the lower level CMSIS libraries?

I realise this question is quite vague, but any comments, advice, etc would be a great help.

## 2 Answers

If you set a Ticker it will already set a hardware timer, and the callback will run in an ISR with highest priority. You can then bounce the event back to a thread which runs at a lower / higher priority depending on the event (e.g. via Semaphore, Queue or EventQueue).

The rest of your threads can have a priority (e.g. osPriorityRealtime which I think is the highest in Mbed OS 5) and you can balance things here. If you pause the thread (Thread::wait) it'll yield back to lower priority threads.

If you need precise timing then you should set up a hardware timer to generate an interrupt at 1500Hz. The interrupt service routine can then call your important thread, or set a global variable that tells the multitasking kernel to run the thread.

• And drop the RTOS idea entirely. Fast and precise timing is best done at the bare metal programming model. – Michael Karas Jul 11 '18 at 20:00
• Not exactly. If you're going to use a hardware timer for a particular task, you should use it to directly run the code. If you're going to use a RTOS kernel to run the task, then you should use the RTOS timing mechanism, not an external one. – Chris Stratton Jul 11 '18 at 20:33
• @ChrisStratton I wasn't assuming any particular capabilities in the multitasking kernel...it could be just a superloop without built-in timing capability. If you run all of the code in the ISR you risk blocking other tasks; generally the ISR should be as short as possible. I will admit that it's not at all clear what the OP is trying to do at 1500Hz and what the other threads need to do. – Elliot Alderson Jul 11 '18 at 20:44
• @ElliotAlderson a superloop is not a multitasking kernel. The question was specifically about an RTOS with a scheduler, if that is going to be utilized, then its designed timing mechanism should be used. In contrast, if you're going to use a superloop approach, don't use an RTOS kernel. – Chris Stratton Jul 11 '18 at 21:13