question on when to use freeRTOS

anonymous wrote on Saturday, September 08, 2012:


I am new to RTOs. I am trying to use freeRTOS on a motor control application. The thing is, that my application works fine for two, maybe three minutes and then it just crashes. I am using a 10 Kb heap size on a dsPIC33FJ128MC802.

I am starting to think that maybe this is not the best application to use freeRTOS with. It has a modulation algorithm (Space vector modulation) which is computer intensive and it must be executed at least every 333usec. So, this means having a tick rate of at least 3kHz, which is not recomended, however, i do not know another way of having a faster task.

I have checked my stack size and I think it is more than enough, I know i am not having a stack overflow problem (already used the vApplicationStackOverflowHook to discard that). Maybe this question seems kind of obvious for the rest of you but i am feeling really puzzled. SO any help and suggestions are more than welcome.

richard_damon wrote on Saturday, September 08, 2012:

My first feeling is that this sort of crash, if not based on an out of heap problem, is likely due to an interrupt issue. One key thing to look at is that no interrupt that uses a FreeRTOS API can have an interrupt above the maxSYSCALL priority (which defaults to 1), and can only call API functions with _FromISR at the end of their name, breaking this rule will give  a chance at causing corruption which may eventually crash your processor.

As to processing speed, a first question is do you REALLY need to update that often, or do you just need to update quickly after an event happens. If the later, have your control loop wait on a semaphore, and an interrupt set up on that condition which gives the semaphore (if your application is a BLDC motor with hall sensor feedback, set up a change interrupt on the hall sensor). If you are doing sensorless control with a ADC converter on the undriven winding, then the ADC completion interrupt can be your trigger.

If it is something else, one possibility that is usually available is to setup a special high speed counter to interrupt at the needed rate to give the semaphore, and a slower tic rate for other task switching. If this really is a hard real time requirement, it may even make sense to not task switch at all, but do the calculation in the interrupt, this assumes that other interrupts can be delayed by this calculation.

anonymous wrote on Saturday, September 08, 2012:

Hello Richard:

First of all thank you for your reply. In this particular case i wanto to update tahat often in order to have a large resolution on my generated waveform.
I have one question about the semaphore option. Lets assume that i have a tick rate of 1 kHz, and that the semaphore triggering interrupt is being generated at a 6 kHz frequency. What happens on that particular case? My task will be held blocked until the next tick?

If it is something else, one possibility that is usually available is to setup a special high speed counter to interrupt at the needed rate to give the semaphore, and a slower tic rate for other task switching.

this particular solution sound very interesting and I would love to try it. Do you know where i can see any example of this? I does not import if iit is for another port. I just want to get an idea of how to implement it.

Thank you!

richard_damon wrote on Sunday, September 09, 2012:

If you enable preemption, and your high speed interrupt that gives the semaphore calls PortYield per the Port Documentation, then the waiting task will start right away assuming it is the highest priority waiting task. Task switching is NOT held till the next tick, ticks just control timeouts and the sharing of time between ready tasks of equal priority. Normally the controlling factor for the speed of timer ticks has been what is the need accuracy of timeouts or delays.

Since you are using a MC series part, this is probably a PWM application, and these parts have the ability to interrupt on a division of the PWM frequency, which is probably the best source for this interrupt. I don’t know of any sample ports that do this, and I am not able to share the code that I have written that does this due to contractual restrictions.

One thing to look at, is if the processing needed per update can be made short enough, you may be able to do the fast part of the updates in the interrupt itself. One thing that can help here is a pre-computed table based on angle, so that the update can be pretty quick.

anonymous wrote on Tuesday, September 11, 2012:

Thank you for your reply. I will star readin to implement the interrupt as you say.
Another question. Besides the freertos api is there any other good reference to stick to?
It is always good to know more than one reliable source.

richard_damon wrote on Wednesday, September 12, 2012:

I have mostly used the API Documentation, and some of just looking at the code. There are some book the Richard Barry has on FreeRTOS that might be another good reference.