Go Down

Topic: DuinOS: small and simple rtos (Read 51 times) previous topic - next topic


We have developed an alpha version of a small preemptive full open source rtos for Arduino, based on open source software, but with a new very simple syntax.

We hope it will be available for download next week.

It has been adapted to fit even in a mega168 (with some limitations), and we are working to have it running on the 328, the 644 and the new 1284. In our (very) initial tests, it's compatible with most standard Arduino code, so it could be added as a library to any application, just taking into account the following:

- The loop() is now a task, so it's speed may be different.
- The timer 1 is used by the kernel (so no pwm in pins 9 and 10).
- The delayMicroseconds() is allowed, but not welcome in DuinOS based sketches.

Here is a small example of use (it's running on a 168), with two LEDs blinking, where the red LED is "modulated" by two separated tasks:


#include <DuinOS.h>

DuinOS TwoLEDsBlinking

Blinks two LEDs with different freqs.

The circuit: ##Pins:
* LED connected from digital pin 14 to Vcc.
* LED connected from digital pin 15 to Vcc.

* Note: On most Comm.ProgUSB boards, there are already two LEDs on the board
connected to pins 14 and 15, so you don't need any extra components for this example.

Created 2009.10.26 (yyyy.mm.dd)
by Julián da Silva Gillig

Based on the original Blink code by David Cuartielles

int ledPinRed =  14;
int ledPinGreen =  15;
boolean redLED_isOn = false;

 redLED_isOn = false;
 redLED_isOn = true;

 static unsigned char counter = 0;

 digitalWrite(ledPinGreen, LOW);  // set the LED on
 digitalWrite(ledPinGreen, HIGH);  // set the LED off

 if (counter >= 29)
   suspend();      //After a while, the tasks suspends itself (forever)

// The setup() method runs once, when the sketch starts

void setup()  
 // Initialize the digital pins as outputs:
 pinMode(ledPinRed, OUTPUT);
 pinMode(ledPinGreen, OUTPUT);
 createTaskLoop(redLED, LOW_PRIORITY);
 createTaskLoop(greenLED, NORMAL_PRIORITY);

 //A task can be suspended by it's name

// This is the main loop() method, wich runs over and over again,
// as long as the Arduino has power. Is a LOW_PRIORITY loopTask:

void loop()                    
 if (redLED_isOn)
   digitalWrite(ledPinRed, HIGH);  // set the LED off
   delay(25);                      // The OS can be tested reducing these delays, and seeing how both LEDs work together...
   digitalWrite(ledPinRed, LOW);   // set the LED on
   digitalWrite(ledPinRed, HIGH);  //  LED is off
   //If nextTask is not called, the application will not hang, because the OS is preemptive. BUT, the current task
   //will consume a lot of computational resources (due to it's lack of a delay() in this branch), the application will
   //turn slower, and the other tasks may be affected by this, loossing precision in their timing:

We are new to the Arduino community, so any comments are welcome!


Mike Murdock


DuinOS looks like it will be very useful.  I can see where it will make complex programs easier to read, and being able to control task priorities will be helpful.

Will you be able to control the priority of the loop() task?  What's the OS footprint in code and RAM?




Hi Mike, thanks for your comments.
Yes, you can control everything if you want, (the main loop priority is just a value in a header). More: you can change priorities at runtime (but not in the m168, due it's small RAM).
About the footprint, this is de avrsize output for the mega168 (with the size optimizations flag):

Program:    5260 bytes (32.1% Full)
(.text + .data + .bootloader)
Data:        900 bytes (87.9% Full)
(.data + .bss + .noinit)

I know it lets small RAM to the user, but in a 328, a 1280 or a 644 it's much better.



I can see where it will make complex programs easier to read

That's odd; I looked at this code and thought it was probably making something simple a lot more complex to read.


Hi Andy, you are right about this small example. But it's just an small example. We are making this to be used in robots (among other things), and with a lot of sensors, some DC motors and communications, we think it may help. Specially if using subsumption, or a computer intensive PID, or when some class of arbiter is needed to control behavior.
Another use is when using graphic displays, with drawing primitives.

Go Up