Using freeRTOS & Pololu AVR Library with Orangutan SVP

I’m building a project based on the Orangutan SVP (ordered but not yet received) and, as I think it will become quite complex and multilayered, I’d like to base it on the freeRTOS system.

I’ve some experience using freeRTOS on the Arduino platform, so I expect that freeRTOS will work without too much issue. In fact there are several ports already available for the ATmega1284.

I’m planning to use the Orangutan SVP because 328p based platforms don’t have sufficient analogue inputs available. The SVP is a welcome upgrade.

As background, freeRTOS uses Timer1 for its “tick” function, also the “tick” function generates task swapping.

My questions are mainly around the use of the Pololu AVR Library with freeRTOS.

  1. Are there any sections in the Library that depend on the use of Timer1? If so, is there any restriction (based on special option only available with Timer1) that would prevent recoding the Library to use either Timer0 or Timer2?
    (I think that the answer is yes: OrangutanServos and OrangutanBuzzer. And no: just change them to Timer0. But, I just want to be sure I’m not missing anything).

  2. Are there any sections in the Library that are not re-entrant? I mean, if any function was interrupted and swapped out during execution there would be a problem with re-starting the function properly?

  3. I couldn’t find any reference to freeRTOS in this forum, so I was wondering whether there’s anyone who can speak of their experience in putting freeRTOS on to Orangutans?


I can give you some answers right now, but I think other people here will probably have things to add.

  1. Timer0 is totally free on the SVP, so you could try to use that one. But it is only an 8-bit timer, so the buzzer and servo code will not work without quite a few changes.

  2. Definitely. Re-entrance was not a concern at all when writing the library, and most of the sections contain functions that manipulate global or static variables. The QTR sensors library uses malloc(), and I have no idea how the various parts of the code that manipulate timers and interrupts would react to being swapped out. There are probably many places where we made assumptions that the code would execute within a reasonable amount of time (e.g. before a timer overflow) so I can see lots of problems.

  3. I have not heard of anyone doing it, but it sounds exciting, and I would be very interested to hear how it goes. What are you hoping to get from freeRTOS?


Thanks. Sounds like there could be a lot to do.

One alternative is to use a mod to freeRTOS to get it to use Timer0. Haven’t tried it, but the existing mod looks solid. With that in place, I wouldn’t have to modify the Pololu AVR Library for Timer1, nor cut the trace for the buzzer on the SVP (existing PWM implies Timer1). However, this wouldn’t help with re-entrance issues.

I think the QTR sensors code wouldn’t worry me, as I’m not planning to use it. But, will have to look in detail at other code it sounds.

I’ve an overview of the project here.
Wifi Dogbot - Post 3 - Pin Outs
WiFi Sniffer Dog

But as with most things, changes occur ahead of the documentation. I’ve found the BlackWidow WiFi doesn’t have an RFMON mode in the driver, so can’t sniff SSIDs effectively. Also, there are not enough analog pins available to cover the sensors I’m planning. Hence, I’ve purchased a SVP through LittleBird in Australia (still to deliver), and the project is heading in the direction of being a “hide&seek” DogBot.

For the “hide&seek” DogBot, I plan to mount a server sensor head with a thermopile 8 pixel sensor, with IR & Ultrasound rangefinders. This should allow the DogBot to seek out small hot targets (small children) and bark when it finds them. Other behaviours are possible, based on the same platform.

I’m planning (have done some testing) with freeRTOS, because it handles the different time constraints of many layers of code, without me needing to conscientiously time or manage each function. There will be a lot of pieces to manage, so I hope that having this platform will allow me to do sensor information acquisition, mapping, navigation, target tracking, sound, LCD, etc, pretty much as independent applications delivering services to each other.

If it all works out well, then I may also mount the system on an outdoor platform. At the moment things are going well, but I expect it will take a few months (year) to get everything going. But, that’s part of the fun.


Ok, based on some help from … tos/port.c
and some changes to the Timer0 Prescaler, I’ve created the attached port file.

It seems to work for me, in that it can successfully run the freeRTOS demo provided with the distribution found in ~/freeRTOS_604/demo/AVR_ATMega323_WinAVR

Comments would be appreciated.

Also BTW, I’ve changed the crystal on my Arduino to 22.118400MHz. A much nicer frequency for UART and other I/O activities. Any chance Pololu can source some of these in SMD for addition to (out of spec) SVPs?

Phillip (4.84 KB)


We typically get parts at least a reel at a time, so unless you’re looking for a few thousand units, we’re probably not a good source. By the way, the SVP (and all of our products) use resonators, and I haven’t seen any crystals that would match that footprint. You would also need to add the external capacitors for the crystal.

- Jan

I finally bothered to read the datasheet (RTFM) and noticed that there is an extra 16 bit timer on the 1284p that is not available on the 328p, being Timer3. And, I’m guessing that no-one is using Timer3 for anything, anywhere, ever.

So, I switched all the port.c code to Timer3, and it pretty much all works again.

Note to self… RTFM… before hacking about.


1 Like


If it helps you feel any better, I’ve read the (a?) datasheet and I had no idea there was an extra timer on the 1284P. There is a single datasheet here for the ATmega164A/164PA/324A/324PA/644A/644PA/1284/1284P family and it has no mention of any Timer3 (it even claims “one 16-bit timer”), so this news comes as an extremely pleasant surprise! For anyone who wants to see the version of the datasheet that includes Timer3, see the following pdf: … oc8059.pdf

- Ben

I changed PulseIn to use Timer3 via a conditional compile and now can use the PulseIn library with either the Servo or Buzzer libraries in the same app.

I must say, the code is easy to modify, thanks!


I’m glad the library was so easy to modify. Note that we just released a new version of the library (100326) that totally redoes how the PulseIn library works. It now uses the new tick counter run by OrangutanTime and updated by Timer 2. This has a number of benefits:

  1. You can use the buzzer or output servo pulses while using the OrangutanPulseIn library.
  2. You can time pulses as long as 28 minutes with 0.4us resolution (you don’t have to trade pulse length for resolution anymore).
  3. The reading is all interrupt-driven now; there is no need for calling a pulse_update() routine in your main loop.

Code written using the original OrangutanPulseIn will no longer compile using this latest version of the library, but it should be very easy to update it so it works again.

- Ben

The freeRTOS project is progressing.
Dogbot - Post 4 - Hardware & freeRTOS Complete

That robot looks great! It looks like you really have a lot packed onto that little chassis.

- Jan

So some time has passed and I’ve had some success with different aspects of my robot.

I’m using a test bed based on an Arduino Duemilianova and Nerdkits display. I’ve hooked the display up as if it was a 3Pi or Orangutan SV-328 and am using Pololu libraries to write to it. Also, I’ve been working on the actual SVP based robot, so both of which are working well.

In testing freeRTOS I’ve been able to configure it based on a choice from some settings in the FreeRTOSConfig.h file to define 328p or not, and also in the make file (for each app) to determine whether 1284p Pololu or 328p Arduino is to be used.

328p is used for the Duemilianova and requires Timer0, which implies no motor library code.
1284p is used for the SVP and uses Timer3, which has no limitations on any known libraries.

//#define ARDUINO_328P // Define this to use the Arduino & Timer0 
// Otherwise use Pololu & Timer3

# MCU name
#MCU = atmega328p      # Arduino
MCU = atmega1284p     # Pololu

#AVRDUDE_PROGRAMMER = stk500v1       # Arduino
AVRDUDE_PROGRAMMER = avrisp2        # Pololu

#AVRDUDE_PORT = /dev/ttyUSB0        # Arduino
AVRDUDE_PORT = /dev/ttyACM0        # Pololu

#AVRDUDE_SPEED = 57600              # Arduino
AVRDUDE_SPEED = 115200             # Pololu

Actually, it is pretty easy to get things working, and swap between the two systems. Currently I’m focussed on getting the i2c bus working to allow the SRT10 sonar and thermopile to work. Also I’ve done some work on the analog sensing. Both are working fine now. Next steps are a PID motor control with quadrature, and z-axis yaw sensor.

One of the nicest things about freeRTOS is not needing to care about timing. Using queues, it is possible to block processes (without tying up resources) until they should run, and using semaphores it is possible to control or limit access to resources (LCD, ADC, I2C Bus, etc) without having to go to critical code.

Some freeRTOS and application code attached, more as a “back up” than anything else.
[deleted as a new version available]

[ Added some more discussion here: DogBot - Post 5 ]


I’m glad you’re having so much success with RTOS and AVRs!

Here’s a little tip that might make your development easier: Instead of having a line in FreeRTOSConfig.h that says “#define ARDUINO_328P” which you have to comment out whenever you switch to using a different platform, you could use a command-line compiler option to define the ARDUINO_328P macro. I think the right avr-gcc option is “-DARDUINO_328P”. You would include this option in the Makefiles for your 328P projects and not include it in the makefiles for your 1284P projects.

But there’s another way you could do it which would not require you to modify your Makefiles. You can use the preprocessor macros defined by the compiler itself from the -mmcu argument to determine whether or not to define ARDUINO_328P.

#if !(defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega1284PA__))
  #define ARDUINO_328P



Took your advice and made some changes to the FreeRTOSConfig.h file.
Updated source attached, with some other minor changes. (438 KB)
Still haven’t had time to finish the odometry and motor PID.
Been playing with the new Freetronics 2010… with link back to Pololu SVP.


Hi Feilipu,

I used FreeROTS with the Orangutan X2 awhile back for my thesis project.

Haven’t looked at it much since then but you’ve just inspired me to get back into it. Thanks for posting up the modifications. As you said before, I definitely find an RTOS much simpler from a timing point of view when you have to manage a number of concurrent tasks.

Time to start buying parts again :slight_smile:

Thanks Lumos,

Hope you can post your thesis and code at some stage.

My Dogbot is sort of on hold at the moment. I got distracted into making a retrograde (hands rewind back to original position) clock and using this as a project to understand hardware based PWM properly.
So I wrote a set of little functions to manage the Timer1 or Timer0 PWM hardware, depending upon which timer was being used for the freeRTOS Tick.

As part of this work, I wrote some more extensions to freeRTOSconfig.h file configurations to allow you to use either Timer0 or Timer1 as the Tick timer on the 328p. Though, in hindsight, I think there is no reason to use the more functional Timer1 as the Tick timer at all.

I sort of ran into a wall with Dogbot, in that I wasn’t getting sensible values from the SVP quadrature encoder functions, so the PID couldn’t ever work properly.

100% certain my hardware is right, as the SVP demo code can see the quadrature outputs properly. Need to dig into whether it is a conflict between freeRTOS and the Orangutan libraries, or whether its just bad programming. Will know more once the clock is up on the wall in the next week or so.

One thing to look out for with serial comms and RTOS is that if your comms task is not the highest priority you may end up with some problems if the buffer fills before you have a chance to read it or if the other device depends on some fairly tight timing constraints (or delays) you’ll get some unpredictable behaviour. Although that being said it seems there’s only 5 bytes for the encoder counts + status so I would think it should be okay.

Can also be quite handy to test things before the scheduler takes over just to make sure they work independently. Keep us updated on how the project goes!

When you are retrieving information from the SVP’s auxiliary processor, there should be no issue with the priority of the task. The communication is done over SPI, which means that the master (the AVR ATmega324p/1284p) has total control over when the slave sends the information. It should be fine if the master is a little slow in requesting bytes from the slave because some other task pre-empted the encoder reading task.

The auxiliary processor requires you to have a minimum delay of a few microseconds between SPI bytes so it has time to prepare the next byte, but there is no maximum delay.


Ahh, of course, thanks David.

I’d forgotten about the SPI master/slave setup, the delays are an issue for UART serial comms like a GPS where it’s just streaming data at you that you can miss.
In that case I’m not quite sure what the issue could be, let us know when you work it out.

Been spending some time on a time wasting (its a pun) diversion, building a clock, to learn how to use hardware PWM to drive servos. The reason to use hardware PWM is to allow the servos to work in the background, without interrupting the freeRTOS tick unnecessarily.

The post is here.

As part of that I needed to move one of the OrangutanLCD configured data lines to free both Timer 1 PWM pins to drive two servos. I’ve updated the OrangutanLCD.h file to free Arduino Pins 9 & 10 by moving DB4 onto Pin 11.

The file from the Pololu library is here:


Once the change is made, you’ll need to recompile and reinstall the library as described.

The changes to OrangutanLCD.h are here:

#define LCD_DB4                PORTB3        // Was PORTB1. Use PORTB3 to avoid the Timer1 pins. 
#define LCD_DB5                PORTB4        // PB4 
#define LCD_DB6                PORTB5        // PB5 
#define LCD_DB7                PORTD7        // PD7

//    PortB:     7 6 5 4 3 2 1 0 
//  LCD Data:      2 1 0            Use DB3 to avoid Timer1 pins. 
//  LCD Data:      2 1     0 
//  PortD:     7 6 5 4 3 2 1 0 
//  LCD Data:  3

#define LCD_PORTB_MASK            ((1 << LCD_DB4) | (1 << LCD_DB5) | (1 << LCD_DB6))
#define LCD_PORTD_MASK            (1 << LCD_DB7) 
#define LCD_PORTB_DATA(data)    ((data & 0x07) << 3)  // Modified the data mask to avoid using DB1 
#define LCD_PORTD_DATA(data)    ((data & 0x08) << 4)

I’ve updated the FreeRTOSConfig.h file to allow different timers to be used to drive PWM.
Also, added the use of internal pull up resistors on the I2C SCL and SDA lines.

Also, out of interest, I’ve compiled the Pololu Libraries on a PS3, which uses the PowerPC architecture. Off an Ubuntu 10.4 Lucid platform, it is all surprisingly easy. Here’s a link to the process, though it is exactly the same as with any x86 Ubuntu platform. (158 KB)