Go Down

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


thanks Julián, but it looks like those tests are comparative performance results on different platforms but do not directly indicate the time to do a single task switch (unless I missed something). Are there any results of tests with a scope or logic analyzer to  specifically measure the task switching overhead?


Hi, I believe there are the values you are asking for. The page does not let me to copy the exactly link, so I'm quoting here the results from http://www.freertos.org/PC:

Scheduler tick function: 41.8[ch956]s, (56.2[ch956]s), [52.8[ch956]s].

with an ATMega323 @ 8 MHz and compiled with an old 2003 WinAVR.

I'm running tests with a digital osciloscope, but will publish when they are finished (because I ask to the FreeRTOS people to do so, due to the original license specific clause about publishing benchmarks).



Hi Julian,

    do you have a bugtracker setup for DuinOS yet?
So we can track issues with various support libs that will need refactoring(fixing) to work with DuinOS.



It may also be nice if a list/wiki were setup to indicate compatible libraries.


Dec 01, 2009, 08:39 pm Last Edit: Dec 01, 2009, 08:50 pm by gwen Reason: 1
hey chumbud,
   I found I was able to get I2C writes working fairly reliably but my results with i2c reads are all over the map.. sometimes my rtc1307 code works sometimes it doesnt(currently doesnt and I didnt svn the sketch that had it working momentarily..(does arduino gui even support this?))
typically now its failing on the second read sequence.

so i2c reads should be added to the noncompatible list.. ie its a big one on the second i2c read the rtos dies(or so it seems as non of my canary tasks are making any noise/updates anymore).

   yes would be nice to have wiki and a bugtracker.

ps we could just add a wiki section onto the arduino playground at http://www.arduino.cc/playground/Main/GeneralCodeLibrary and probably should create a DuinOS Section to that wiki.. just found out my admittedly limited login privs dont allow me to edit the code snippets section.Can one of the admins take care of this? or grant me the necessary privs.


Have you tried to run Duinos with the WiShield yet?
There is a conflict with pin 10 and maybe more than that.

I understand from the first post that Duinos/freertos uses timer 1 which has something to do with digital pins 9 and 10. Does it need any other pins or interrupts to operate?

The WiShield uses the SPI system and pin 10 is used for slave select. I don't know if it goes deeper than that. WiShield can use either digital pin 2 or 8 for an interrupt pin. SO it needs digital pins 2,10,11,12,13 or 8,10,11,12,13.

Do you know of any other conficts that I should be looking for?



DuinOS does not use any pins per-se.  What it does use is timer1 which means you can't use the PWM feature on pins 9 and 10.  You can still use pins 9 and 10 though.


Any ideas where I should start then?

Let me say that Duinos is working just great. I have been working with multiple tasks on a ATmega328 and loving it. I may need to work with semaphores soon, but so far it does everything that I need.

I also have a WiShield program that works. It is the WebServer demo that came with the board.

So I tried to put the two together. I added one task to the WebServer program. Now the task does not run and the WiFi does not work either.

After reading your comment I can be pretty sure that the problem is with pin 10. WiShield pulls the pin low to select the slave device which is the ZeroG2100 device. The pin does not go low to select the device when Duinos code is added.

I am looking through the WiShield code to see if I can configure it to use a different pin for slave select.

I'll let you know if I find an answer.



I noticed the WiShield is also using pin 9, did you try removing the "LED jumper cap"?


Here is what I tried today. I run a multi-task Duinos sketch using pins 9 and 10 as digital outputs. No problem. The tasks keep running and the lights keep blinking.

So, the problem must be deeper than this.

I will have to start digging through the WiShield library to see if there are some variable names or function names that are crossing.


Here is another indication that there is a conflict in the two code sets, WiShield vs Duinos/freeRtos

WiShield comes with a sample sketch named SimpleWebServer. When I compile it to the ATmega328 board it works just fine. When I compile it to ATmega328 + Duinos board it does not work.

Doesn't that point the problem to a code conflict?

I've already found one that I think is a problem. The WiShield code defines a 'timer struct'. There is also 'timer struct' in the Duinos version of the Arduino code. Which one gets linked?

The variable 'queue' is also a suspect.

I am going to bring this up to the WiShield authors and see if they can create variables that are unique. I would suggest that the Duinos authors see if they can do the same, though the problem is likely to be in the FreeRtos code and would be much more difficult to accomplish.


The simplest answer is that you are running out of RAM.  Either check how much static RAM your sketch is using if you know how to do that or simply change the heap space used by FreeRTOS for the 328 chip.  Change the #define for configTOTAL_HEAP_SIZE for the ATmega328P located in the FreeRTOSConfig.h file (around line 205) which is currently set to 1200 to a much smaller value like 200.


Suppose I change configTOTAL_HEAP_SIZE to 200. What does that do?

Is there a way to estimate how much I\is needed for each task?


I'll try a few values out and see what happens.


Dec 04, 2009, 03:55 am Last Edit: Dec 04, 2009, 03:58 am by chumbud Reason: 1
The FreeRTOS port for the 8 bit Atmega chips is using a heap for memory management.  This heap is statically created at compile time to the size of that #define.  This number is just an arbitrary value and depending on your application you could easily run out of free memory if that value is set too high.  When you create a new task, queue, etc in FreeRTOS it uses memory from that statically created heap.  There are some API's in FreeRTOS to check how much memory is being used in the heap.  To find out if the heap is too large because you have a lot of static variables in other parts of your app and you are using more memory then the chip has is by following the directions here.

For example, using the default heap size for the ATmega168 and using Serial print routines will exceed the memory available in the chip and cause the application to crash or not work at all.This is because of the extra static variables used in the libraries used for serial print output.


That should keep me busy for a few days.

Go Up