DuinOS: small and simple rtos

[pracas]

Julian,

Welcome to the community!

Looks like great work! This will help a lot!

Cheers,
pracas

[juliandasilva]

Thank you! we hope this will be online today or tomorrow (very first Alpha version).
Regards,
Julián
http://robotgroup.com.ar

[juliandasilva]

DuinOS v0.1 Alpha is here now:

http://robotgroup.com.ar/noticias/20091102/duinos-sistema-operativo-multitarea-para-arduino

Regards,
Julián

[chumbud]

Downloaded DuinOS and can't use it out of the box without modifying the DuinOS.h file.  The path specified in there is a Windows path so you'll get a compile error on any unix variant OS.

[juliandasilva]

Many thanks! We fixed it. We did not test it on Linux, so any comment is welcome.

Regards,
Julián

[Folknology]

Hi I changed the DuinOS.h file section '/* Scheduler include files. */'

from
#include "DuinOS\FreeRTOS.h"
#include "DuinOS\task.h"

to
#include "DuinOS/FreeRTOS.h"
#include "DuinOS/task.h"

To make it work on Mac OSX

Then it compiled and uploaded, now playing with it thanks Julian

Very Cool that you used FreeRTOS been meaning to play with it for some time, this is a perfect excuse..

[juliandasilva]

Thanks for your words!!
I already made that modification in the current zip file.
Regards,
Julián

[chumbud]

In my own opinion I feel the declareTaskLoop macro is ill-conceived. Writing

Code: [Select]

declareTaskLoop(greenLed) looks like you are calling a function to declare it and/or initialize it.  I know it is simply a macro that is replaced with

Code: [Select]

extern xTaskHandle greenLed which I agree looks too complicated for a typical Arduino programmer but when you are reading through code what declareTaskLoop is doing is not at all obvious and seems counter-intuitive.  I would rather see a typedef/define so that the code would then be:

Code: [Select]

taskLoopType greenLed
which to me makes it easier to understand what that line represents and perhaps less confusing even for beginning Arduino users.

[juliandasilva]

Hi, thanks.

Are you suggesting to replace the macro with something like the following?

Code: [Select]

#define taskLoopType extern xTaskHandle

It works too (I have compiled it, changing the example too).

The macro is only for forward declarations when needed, I expect that most sketches will never use it, but right now I'm not sure which is more easy to understand.  I like both!

Good question to decide as a community...

Regards,
Julián

[chumbud]

Yes, I was suggesting using that macro.  The current way looks like a method call and not a variable definition.

Have you done any testing on memory usage with tasks?  Specifically, do you know how much base memory the creation of a task uses?

[juliandasilva]

Hi Chumbud,

Regarding the macro, I think the change may be done in the next version. I agree with you about the sintax and that the function-call look isn't the best.

About the memory, now every task uses a space for it's CTB and for it's stack.  The current default stack is defined with the configMINIMAL_STACK_SIZE in the FreeRTOS.h file.
Now it takes 85 bytes, but can be reduced very easy.

About the CTB this is the struct, from the task.c file:

Code: [Select]


typedef struct tskTaskControlBlock
{
     volatile portSTACK_TYPE      *pxTopOfStack;            /*< Points to the location of the last item placed on the tasks stack.  THIS MUST BE THE FIRST MEMBER OF THE STRUCT. */
     xListItem                        xGenericListItem;      /*< List item used to place the TCB in ready and blocked queues. */
     xListItem                        xEventListItem;            /*< List item used to place the TCB in event lists. */
     unsigned portBASE_TYPE      uxPriority;                  /*< The priority of the task where 0 is the lowest priority. */
     portSTACK_TYPE                  *pxStack;                  /*< Points to the start of the stack. */
     signed portCHAR                  pcTaskName[ configMAX_TASK_NAME_LEN ];/*< Descriptive name given to the task when created.  Facilitates debugging only. */

     #if ( portSTACK_GROWTH > 0 )
           portSTACK_TYPE *pxEndOfStack;                  /*< Used for stack overflow checking on architectures where the stack grows up from low memory. */
     #endif

     #if ( portCRITICAL_NESTING_IN_TCB == 1 )
           unsigned portBASE_TYPE uxCriticalNesting;
     #endif

     #if ( configUSE_TRACE_FACILITY == 1 )
           unsigned portBASE_TYPE      uxTCBNumber;      /*< This is used for tracing the scheduler and making debugging easier only. */
     #endif

     #if ( configUSE_MUTEXES == 1 )
           unsigned portBASE_TYPE uxBasePriority;      /*< The priority last assigned to the task - used by the priority inheritance mechanism. */
     #endif

     #if ( configUSE_APPLICATION_TASK_TAG == 1 )
           pdTASK_HOOK_CODE pxTaskTag;
     #endif

     #if ( configGENERATE_RUN_TIME_STATS == 1 )
           unsigned portLONG ulRunTimeCounter                   /*< Used for calculating how much CPU time each task is utilising. */
     #endif

} tskTCB;


I know all this is too much memory for the small m168, but works well in the 328.  We will try to fine tune and optimize all these things to fit better even in the 168.

As always, any comment is welcome.

Regards,
Julián

[chumbud]

I think it is not worth trying to accommodate the atmega168 too much since the 328 has pretty much replaced the 168 as far as the arduino community.   I think all the 168 arduino boards for sale have been replaced with 328 chips.

How much alteration did you have to do compared to the "standard" FreeRTOS to get it to work on the 8 bit avr's? What I see is these files needed to be altered:

portmacro./h
port.c
FreeRTOSConfig.h

and macro definitions that aren't necessary in: DuinOS.h

Does that cover it?


I think it will just take some time for the general Arduino community to catch on to the significance of the FreeRTOS port your group has done.

[juliandasilva]

Hi, the m168 is not our main target, but the OS is already running on it (yes, but with some constraints).  About the files, those you mentioned cover it.  The initial work migrating the OS to most modern AVRs (than the 323) was made by the people at www.micropendous.org.

The macros at DuinOS.h are optional, but we think this is a more "Arduino-like" sintax. Of course you can always work with handles instead of names, and use the standard FreeRTOS API.

Regarding the evolution of the system, we are trying to do some optimizations and running more tests, in order to have the rtos working better with our robots. We think once we have more examples and better documentation (perhaps some videos too), this small os may be useful for many applications.  In our specific case, the people who uses NXC, NQC, or small embedded versions of Java for robotics can use multitasking, and they really use it. So we want the same functiontality for Arduino and Arduino-compabible robots.

Regards,
Julián
http://robotgroup.com.ar

[pracas]

I think it is not worth trying to accommodate the atmega168 too much since the 328 has pretty much replaced the 168 as far as the arduino community.   I think all the 168 arduino boards for sale have been replaced with 328 chips.

:-[Well not really. Its still hard to get Atmega328 here in india(Well looks the arduino guys here are the only ones to use Atmega168 and that is available only directly from ATMEL dealers and they don't have stock of 328 unless we place a order)

Putting it simply, All efforts to accommodate 168 would be appreciated and this would reach more people than making it possible only on 328.

Can someone come out with a simpler example(than the more complex led blink ) perhaps a scan input and give output at the same time will help.

cheers,
pracas

[gwen]

Hi  julian,


Wow, Really cool, just the tool I have been looking for.. I have a modified version(added serial print lines to each routine so I didnt have to wire up leds) of the example working on one of my adafruit 328p chips right now and I am writing an app to demo it more extensively later today.

However my main project is moving to a sanguino within 24 to 48hours.. any chances of getting my grubby hands on the 644 port of DuinOS?


     again many thanx for giving this back to the community .. it really rocks

  gwen
ps the arduino community has mostly moved to the 328 and more capable chips the 168 prolly is just too small for rtos AND the arduino cruft combined(with regards to the above poster).