Julian,

Welcome to the community!

Looks like great work! This will help a lot!

Cheers,
pracas

DuinOS v0.1 Alpha is here now:

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

Regards,
Julián

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

Regards,
Julián

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

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

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

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

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