Pages: 1 [2] 3 4 ... 13   Go Down
Author Topic: DuinOS: small and simple rtos  (Read 37956 times)
0 Members and 1 Guest are viewing this topic.
Chennai, India
Offline Offline
God Member
*****
Karma: 0
Posts: 752
Peace!!!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Julian,

Welcome to the community!

Looks like great work! This will help a lot!

Cheers,
pracas
Logged

Be The Change...

Argentina
Offline Offline
Full Member
***
Karma: 0
Posts: 186
Sé feliz
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Argentina
Offline Offline
Full Member
***
Karma: 0
Posts: 186
Sé feliz
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

DuinOS v0.1 Alpha is here now:

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

Regards,
Julián
Logged

USA
Offline Offline
Newbie
*
Karma: 0
Posts: 36
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Argentina
Offline Offline
Full Member
***
Karma: 0
Posts: 186
Sé feliz
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Regards,
Julián
« Last Edit: November 02, 2009, 05:00:42 pm by juliandasilva » Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 2
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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..
Logged

Argentina
Offline Offline
Full Member
***
Karma: 0
Posts: 186
Sé feliz
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

USA
Offline Offline
Newbie
*
Karma: 0
Posts: 36
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

In my own opinion I feel the declareTaskLoop macro is ill-conceived. Writing
 
Code:
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:
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:
taskLoopType greenLed
which to me makes it easier to understand what that line represents and perhaps less confusing even for beginning Arduino users.
« Last Edit: November 02, 2009, 11:36:52 pm by chumbud » Logged

Argentina
Offline Offline
Full Member
***
Karma: 0
Posts: 186
Sé feliz
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi, thanks.

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

Code:
#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
Logged

USA
Offline Offline
Newbie
*
Karma: 0
Posts: 36
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?
Logged

Argentina
Offline Offline
Full Member
***
Karma: 0
Posts: 186
Sé feliz
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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:
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
Logged

USA
Offline Offline
Newbie
*
Karma: 0
Posts: 36
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Argentina
Offline Offline
Full Member
***
Karma: 0
Posts: 186
Sé feliz
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Chennai, India
Offline Offline
God Member
*****
Karma: 0
Posts: 752
Peace!!!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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 smiley-wink) perhaps a scan input and give output at the same time will help.

cheers,
pracas
Logged

Be The Change...

0
Offline Offline
Newbie
*
Karma: 0
Posts: 30
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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).
« Last Edit: November 20, 2009, 01:26:43 pm by gwen » Logged

Pages: 1 [2] 3 4 ... 13   Go Up
Jump to: