Go Down

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


Some yes, and some no:

- OneWire and Servo are not tested now, but no work has been done there as far as I know (is it correct?)

- printf has been replaced by Yannick56 in the v0.3, with the mprintf from Paula's library (http://www.out--there.com/blog/the-devil-is-in-the-details-atmega-startup-to-freertos/)

- WiShield: Don't know.

- Tone: Must be working since the DuinOS v0.2 released by CHERTS.

Thanks Yannick! Very great work!



So I tested with the 2560 and OR must have done something wrong or there must be something wrong where the RTOS doesn't support the board:  #error "Device is not supported by DuinOS", is one of many.

Any ideas Yannick?




Can you reply to my  personal message in this forum ?

>So I tested with the 2560
Do you test with the latest source code (commit r27) in SVN here http://code.google.com/p/duinos/source/list ?

>#error "Device is not supported by DuinOS"
This message is at the end of the file FreeRTOSConfig.h here :



Hello DuinOS users,

I have updated DuinOS 0.2 source code for a DuinOS 0.3 release.

You can find the changes here in the readme.txt file :

or in the commit list here :

To get the latest source code, use the svn command here

Please test and report bugs or things that don't work in this forum.



thank you for this release
I  want just to know if this version 3.0 accepts: micros(), delayMicroseconds() and pulseIn(), because I use them to measure distance with an ultrasonic sensor.



>thank you for this release
It is not a release.
It's for testing by users before a release
and to know if some arduino card works or not.

If you want to test, then follow the part
"Install for DuinOS 0.3 Dev SVN for testing only "

>I  want just to know if this version 3.0 accepts: micros(), >delayMicroseconds() and pulseIn(),
Maybe, if it is in Arduino IDE 0021 API or FreeRTOS 6.1.0 API.
You need to test it.

Note : in the next days, I will try to replace Timer1A by Timer 0 OVF used by DuinOS kernel to improve compatibility with Arduino standard libs ( Here, I think about Servo lib).


thank you very much I'll do it soon


Hi Guys!

I've been trying to work with a servo and I tried the basic SWEEP example but I keep receiving the following error message :
core.a(port.c.o): In function `__vector_11':
E:\ARDUINOsoft\arduino-0021_duinOSv0.3\arduino-0021\hardware\arduino\cores\arduino.DuinOS\DuinOS/port.c:478: multiple definition of `__vector_11'
Servo_renamed\Servo.cpp.o:E:\ARDUINOsoft\arduino-0021_duinOSv0.3\arduino-0021\libraries\Servo_renamed/Servo.cpp:103: first defined here

The example works perfectly fine if I don't use DuinOS.

Can you please help me??  Thank you in advance!


Dec 29, 2010, 03:15 pm Last Edit: Dec 29, 2010, 03:17 pm by yannick56 Reason: 1
>I've been trying to work with a servo and I tried the basic SWEEP
> The example works perfectly fine if I don't use DuinOS.
> Can you please help me??  Thank you in advance!

Yes, you must have this error because in the file      DuinOS_v0.3_Alpha_dev_svn20101222.zip, DuinOS use Timer 1 for its kernel.
Timer 1 is 16 bits.
But Servo lib need Timer1.
And you use the Servo Lib that is not patched to not use Timer 1.

Then use patched Servo lib (from Arduino IDE 0021) with Timer1 disabled because DuinOS uses the timer 1 for its kernel,
if you have a card with AtMega 128, 1280, 1281, 2560, 2561, 32U4, AT90USB646, AT90USB1286.
This patched Servo lib with Timer disabled is in the file DuinOS_v0.3_Alpha_dev_svn20101222.zip.
And for the other cards, I have added ServoTimer2 lib to replace Servo for AtMega 88,168,328,644 - use the 8 bits Timer2 to manage up to 8 servos
 ServoTimer2 lib website : http://code.google.com/p/tricopter/source/browse/trunk/arduino/#arduino%2Flibraries%2FServoTimer2

Or you can get the latest DuinOS souce code here
where I have replaced Timer1 by Timer0 for the timer used by DuinOS kernel.


I have tested micros(), delayMicroseconds() and pulseIn() with blinking LEDs, with a very simple examples on an Arduino Mega (1280), it seems to be working fine :)


I've tested semaphores being set via interrupts on Arduino v22.

Note the hardware directory is a little different but seems to compile, load, and run correctly.

Does it makes sense for someone to put a regression test outline on the Google project site?  The thought here is if we have various parties checking off a known set of previously supported features, we can move the process along.  

Also, if there were a list of unresolved and untested subsystems, those interested could work on those as needed and contribute to the project.


Go Up