chris_koerber wrote on Tuesday, July 04, 2006:

Good day,

My colleagues and I are currently thinking about dumping our homebrew non-multitasking scheduler of our AT91SAM7sS design which happened to become rather complex during the lasts weeks.

FreeRTOS seems to be the perfect replacement. However, I have the impression that the AT91SAM7 port is relativly new and thus not very well documented (at least I couldn’t find any documentation).

Because of this I’d like to ask some questions here, any input is highly appreciated:

1. Does the AT91SAM7-GCC port work with the GNUARM toolchain?

2. What is the source of the “Tick-Interrupt”? Sorry I couldn’t phrase it better, this subject is actually a bit too low level for my taste. What I mean is this: On our board resides a real time clock, is this a possible source for this interrupt or will FreeRTOS automatically rely on the the MCU built-in signal?

best regrads,


rtel wrote on Tuesday, July 04, 2006:

The SAM7S port was created using IAR tools.  The SAM7X port with Rowley/GCC.  A command line GCC (rather than Rowley IDE) makefile was also provided for the SAM7X demo a little later.  This was created using GNUARM.  There is little specific documentation for the command line GCC version as 95% of it is common with the Rowley port documentation.  See here:

The X and S are very similar and compatible, just the peripherals are different (I think), so using the X demo on an S part should just be a matter of cutting out the unwanted bits (Ethernet driver mainly).  Several people have done this.  I have a project written using GNUARM that includes an SD card driver also, so people are using this successfully.

The Tick is generated by the PIT (periodic interrupt timer), which according to the datasheet is provided exactly for this purpose.

Hope this answers your questions.


nobody wrote on Tuesday, July 04, 2006:

Thank you Richard,

this sounds promising.
Please let me get back to the tick issue once more:

What our application basically does, is sampling a sensor with 200Hz, performing some signal processing for 1 millisecond and than disabling ALL interrupts and switching to low clock cycle, thus nearly shutting it down for 4 milliseconds (in order to preserve battery charge). The only way to get back from this state is  by a signal from the real time clock via an advanced interrupt controler.

So my thoughts circle around the question whether there was a way to interface FreeRTOS with this signal.

best regards,


rtel wrote on Tuesday, July 04, 2006:

Take a look at the function prvSetupTimerInterrupt() in FreeRTOS\Source\portable\GCC\ARM7_AT91SAM7S\portable.c.  This is the function that installs the tick handler on the PIT interrupt (as well as configuring the PIT frequency).

You can generate the tick from any interrupt source capable of providing a periodic interrupt.  So you could modify prvSetupTimerInterrupt() to use your external clock through an IRQ rather than using the clock on the processor.  The kernel does not care where the interrpt comes from as long as it gets it at regular intervals.

You might want to consider using the idle task hook to place the CPU into power down mode.  This way whenever there is no processing to perform (all tasks are blocked other than the idle task, assuming no other tasks share the same priority as the idle task) then the CPU will sleep automatically sleep until the next interrupt.


nobody wrote on Tuesday, July 04, 2006:

Reading through the online documentation gave me the impression that our power down functionality could be embedded into an idle task hook, right?

nobody wrote on Tuesday, July 04, 2006:

I missed your last post, Richard.

Thanks a lot for the starter, great help.