rtos and high speed interrupts

freppac wrote on Wednesday, July 30, 2008:

Hi

Im planning on using freertos for an UAV project on the at91SAM7 uC. Im fairly new to RTOS and completely new to FreeRTOS , so I have a question that might be a bit stupid :slight_smile:

The thing is that I need to generate several servo control signals (a pwm signal between 1-2ms with an update rate of at least 50Hz) and to generate these signals I need to set up a fast running timer/counter interrupt (my guess is that 100kHz interrupt freq is enough to obtain a good resolution)
How would this affect FreeRTOS performance, or is it even possible to do something like this with an RTOS?

rtel wrote on Wednesday, July 30, 2008:

This depends on the port you are using.  Here are some examples:

1) Cortex M3

Cortex M3 ports allow interrupts above the kernel interrupt priority (this feature is extended even further in the next release) so these interrupts are never held up by the kernel activity at all.  The demos applications run a high frequency timer interrupt at 20KHz then measure the jitter in the interrupts execution - which comes out between 80ns and 160ns depending on the frequency at which the CPU is running.  This jitter is totally an effect of the interrupt tail chaining (a feature that allows you to short cut interrupt entry) and nothing to do with the kernel.  I have not tried a 100KHz interrupt, but at any frequency if the interrupt is above the kernel priority then it will not get delayed by the kernel so its just a matter of whether or not the processor can operate that quickly.

2) PIC32

Likewise on the PIC32 you can run interrupts above the kernel interrupt priority.  Although the measured jitter is a little longer when defining normal interrupts you have the option of using the level 7 priority and therefore the shadow registers which should give you super fast and accurate interrupt entry as the context need not be saved.

3) ARM7

On the ARM7 you can use the FIQ interrupt, but make sure that the critical section entry code only disables IRQ interrupts, not FIQ interrupts.

etc.

The best thing to do is buy an inexpensive eval board and give it a try.

Regards.

desertfx5 wrote on Wednesday, July 30, 2008:

Just curious why the hardware PWM channels won’t work.  A 100 kHz interrupt tick will burn a lot of processor time RTOS or no RTOS, especially on an ARM7 which has relatively poor IRQ latency.

incrediball wrote on Wednesday, July 30, 2008:

It is certainly possible. As David said, the best way would be to use the PWM output(s) and then you only need to update it at 50Hz. However bit banging an output at 100kHz is also possible. I wrote about high speed interrupts on the AT91SAM7S several months ago in http://sourceforge.net/forum/forum.php?thread_id=2005665&forum_id=382005 . Perhaps that might give you a few clues.

freppac wrote on Friday, August 01, 2008:

Hi and thanks for your answers!

Well the basic reason why i cant use the pwm outputs is that i need to control a lot of servos, and I think that the sam7s only has 4 pwm outputs right?

but I probably will solve this by using another smaller uc for servo output generation. I think that this will probably be a better solution, so that the main processr will not be overloade by just generating servo signals.

sr-embedded wrote on Friday, October 21, 2011:

Hi I too have a similar question.I am using FreeRTOS on a dsPIC.I had read on the free RTOS website that there are specific macros to manage interrupt nesting and allows interrupts above a user-definable priority level to remain unaffected by the activity of the kernel. Using FreeRTOS will not introduce any additional timing jitter or latency for these interrupts.
I have a similar  high speed adc interrupt.
Could some one point out which macros control this behavior or it depends on a particular port?

davedoors wrote on Friday, October 21, 2011:

They are documented on the documentation page for the dsPIC port on the FreeRTOS web site. Look at the port specific configuration section http://www.freertos.org/portpic24_dspic.html