Real Time Timing

dmwilliams66 wrote on Monday, April 03, 2006:


I’m getting into programming some of my critical code in FreeRTOS with the Atmel ARM 7 based SAM7X on my own board.

Some casual experimentation has resulted in some surprising results.  When the standard demo web server is running, timing interrupts (i.e. those caused by the Timer) can be delayed by as much as 100ms - quite a lot for an RTOS!

I’m looking into this deeper, but as it stands it is difficult to contemplate running anything really RT.

Some discussion in this forum has hinted at the possibility of fixing this with nested interrupts, but would this really work?  What if the long time periods are really code running as critical sections?  Then there are no interrupts at all, presumably.  So isn’t this whole thing a bit of a problem?

Could someone tell me if it’s stupid to try to fix this by using the FIQ interrupt and excluding fast interrupts from the Critical section and IQR enable disable macros?

There will be no need to context switch during my IRQ’s.

Thanks for any help.


dmwilliams66 wrote on Tuesday, April 04, 2006:

That was 10ms not 100ms as I earlier stated.  Sorry about that.  Still seems long!

rtel wrote on Tuesday, April 04, 2006:

The SAM7X demo does very little in the ISR’s as the DMA on the SAM7X fills and clears the buffers automatically, and most processing is done at the task level with interrupt enabled.

The WEB server demo creates a table of all the tasks running in the system for display on the ‘home’ page.  This table uses a lot of string handling functions *and* walks the stack of each task to find the respective stack high water marks for display.  This function can therefor take a long time to complete and executes with interrupt disabled.  I suspect that this is the source of your measurement.

From the site: "The RTOS CGI file generates a table containing information on each task executing within the demo.  This table is interesting for demonstration purposes, but as it is necessary to leave interrupts disabled for an extended period during its creation it is not recommended for use in applications with strict real time requirements".

Try removing this to see if things improve.


dmwilliams66 wrote on Tuesday, April 04, 2006:

Thanks for the quick reply, Richard.  Commenting out the call to vTaskList( ) does indeed improve things - now the longest delay I’m getting is around 2.25ms.  Much better.

However I still need access to a much more accurate interrupt, since I need 50us resolution.  I think this should be possible. 

I’ve spent a long evening banging my head up against the FIQ handler with ARM doc, ATMEL doc, and whatever GCC information I could scrounge.

My theory was that I could make the Timer0 interrupt a FIQ interrupt and then remove the FIQ disable from the critical section code permitting the FIQ’s to function even while the other code does its thing. Clearly I am in far over my head since converting the Timer0 handler to a fast forcing interrupt works, but only for a little while.  The whole thing ends up in the DAbort handler.  I suspect something in the interaction between IRQ code and FIQ code - stack etc. stuff.   I’ve given all the tasks at least another 100 bytes of stack in case it’s a stack overflow.

I read that GCC isn’t too good at IRQ / FIQ preambles.

Anyone have any ideas (or better still some code)?



nobody wrote on Tuesday, April 04, 2006:

I think the FIQ interrupting critical sections will cause a problem if the FIQ and critical section are both accessing the data structures used by the kernel.

Can you make the FIQ perform the action for which you need the fast response time without the FIQ handler accessing above mentioned data structures or calling API functions?  Maybe the FIQ could effectively be your highest priority task?

dmwilliams66 wrote on Tuesday, April 04, 2006:

Yes, the data the FIQ handler needs to play with are independent of the Kernel data. 

nobody wrote on Tuesday, April 04, 2006:

Hi David,

what do you mean with timing interrupts can be delayed by as much as 2,5ms?
The ISR get’s called within 10’s of us with my STR7.
Don’t know about a resolution of 50us, that depends
on the processer clock and more.
Anyway, interrupt reaction has nothing to do with FreeRTOS?
Sure you mean something different e.g. reactivation time of a task that gets runable from within a ISR?

dmwilliams66 wrote on Tuesday, April 04, 2006:


Since I’m dealing with servo’s and stepper motors, I need hard realtime processor responses.

To test out the response time of FreeRTOS I created a regular interrupt (using Timer0) which interrupts 100’s of times a second.  Helpfully, the hardware clears the counter used at the point of the interrupt, so since I know how long each counter increment takes (approx 1/24,000,000s), if I examine the value of the counter in my interrupt handler, I can see how long it took to get to the interrupt.

There are two mechanisms that might cause this time to exceed the normal IRQ dispatch time.  One is that there are other interrupts that occur.  FreeRTOS only serves one interrupt at a time. The other is that FreeRTOS regularly switches IRQ’s off while it does critical OS-related things.

What I find is that while the average interrupt latency is around 100/24000000 = 4uS (which is excellent), the maximum latency can be as much as   2819/24000000 = 120us even with the (vTaskList( ) commented out) which is almost three times the resolution I need. (Note that this more careful finding is much better than the 2.5ms I said earlier)

Note that this is not a flaw with FreeRTOS.  Sub 1ms responses are excellent for most purposes.  There is however a class of problem that requires much more accurate timing.  Hence my interest in creating a FIQ-based interrupt scheme orthogonal to the rest of the OS.

So - does anyone have FreeRTOS + GCC-based FIQ Handler experience on the SAM7 processors?


dmwilliams66 wrote on Wednesday, April 05, 2006:

OK.  I got the Fast Forcing Timer interrupt to work.  I mostly had it right, but I wasn’t setting the FIQ stack up correctly.

I created a Timer interrupt, setting the Fast Forced flag so it came in as an FIQ.  The FIQ mode has its own stack, etc. so it can run independently of the rest of user / irq mode.  The stock FreeRTOS ARM implementation sets and clears both the IRQ and the FIQ, I modified this to only modify the IRQ flag.  Now the FIQ is enabled at all times permitting the Timer0 interrupt to interrupt FreeRTOS any time - including during vTaskList calls.

Now I can get interrupts with latency of maximum 4us - all the time.

Care will need to be taken to protect any data modified by these routines with very short Disable FIQ / Enable FIQ segments, and naturally no kernel  data can be touched.

I hope this is useful to someone else needing hard real time performance from FreeRTOS/ARM

nobody wrote on Wednesday, April 05, 2006:

>I hope this is useful to someone else needing hard real time performance from FreeRTOS/ARM

definitely, thanks.

nobody wrote on Wednesday, April 05, 2006:

Cool.  How are you interfacing the servo to the sam7x?  Do you have a resolver/encoder input and pwm output?

dmwilliams66 wrote on Wednesday, April 05, 2006:

The servos I mentioned are hobby servos (need a pulse of length between 1ms and 2ms to specify position).   These are now working great - the nice quick interrupts permit me to easily get the 1000 levels between  1ms and 2ms.

The other thing I needed the quick timing for was to control stepper motors.  Most seem to run no faster than 1000 steps per second or so, but most controllers advertise that they can do much more.  Also, I want to be able to adjust the PWM output at some period in the middle of the step (to reduce current consumption) so I need fine grained timing to do that.

nobody wrote on Thursday, April 13, 2006:

Hey Guys,

Are you saying that FreeRTOS supports hard real-time?

John W.

dmwilliams66 wrote on Thursday, April 13, 2006:

The mechanism I outline in this thread does give hard-real time responses.  It relies on the ARM’s FIQ which is a separately maskable interrupt from the normal IRQ.  You can get very quick responses - as fast as the processor is capable of - but because it’s unclear what FreeRTOS is doing when its interrupted, you can’t safely manipulate any of the FreeRTOS structures.  As such, it couldn’t really be said to be part of FreeRTOS.  In my application, I have some data that I protect with Enable / Disable FIQ calls which permits me to communicate with this “system on the side”.  I now get maximum delays of about 4us from IRQ event to my RT code running.

Richard has spoken about a more elegant scheme where we change the way interrupts are handled on the ARM port slightly so that the regular ARM interrupts themselves can be interrupted by higher priority IRQ’s.  This would go a long way towards make FreeRTOS a more real time OS, but would still exhibit the problem that any task anywhere could disable IRQ’s for potentially unbounded lengths of time.  So all tasks would need to co-operate - and the OS would need to be examined very carefully to find out what the longest IRQ diabled period is and reduce it if necessary. Ultimately the slowest responses possible from this kind of system would be in the low 100’s of microseconds, I suspect based on my research.

I chose to do the “system on the side” because the solution I chose needed to work regardless of what else was going on in the system.  I am creating an environment for other people to use, so I didn’t want to impose any restrictions on them.  It also turned out to be a lot easier!  I’m not a super ARM coder by any means.

It is interesting to note that these two kinds of solutions (“system on the side” and the more integrated one) are also the same two solutions commonly used to improve Linux’s realtime abilities.  Linux’s pre-emptable kernel gets you a long way towards lower response times, but if you really want response times in the microseconds, you need to do something like the “system on the side”.

nobody wrote on Friday, April 14, 2006:


Thanks for the response.  This is very interesting.
As you know hard vs. soft is very difficult - if FreeRTOS could do hard - that of course is a boon for FreeRTOS.

John W.