Prop RTOS?

icepuck

In the Feb issue of Nut's & Volts write up of the 32-bit micro experimenter was interesting. The part with the demos using the http://www.freertos.org/ RTOS is what was got me thinking about the prop.
After looking on the freertos web site for supported chips and not seeing any thing for prop got me thinking again.
If an os can be done with one 32-bit cpu(or core) why couldn't this be done on the 8 core prop?
I'm I the only person to think of this?
-dan

localroger

The usual reason for using a Real Time Operating System is that you have a complex interrupt system and you need to make sure that lots of them are handled in a timely manner, which can get complicated when interrupts interrupt other interrupt code. The propeller doesn't have interrupts at all, or enough Cog RAM to do much useful with them if it did, and it goes on the theory of dedicating cogs to tasks that need real-time response. So in essence, any propeller OS is a RTOS because the RT function is established by using different dedicated cogs for each time-critical function.

RossH

I agree with Roger. Most of the functionality provided by FreeRTOS comes "built in" to the hardware of the Propeller.

On the Propeller, all you need to do what other chips need an O/S like FreeRTOS to do is a suitable C compiler, such as ... (insert drum-roll here) ... Catalina!

Ross.

pjv

Hi All;

I feel compelled to add a comment here;

The multi-threading scheduler I have developed (but not yet released for use) performs the principal functions of an RTOS. It resides in any number of Cogs, and the kernel consumes about 60 instructions (longs) in those Cogs where it is loaded. It takes care of all the timing and scheduling issues typically found in a full RTOS, but in co-operation with each concurrent thread of assembler (only) code to be executed in the Cog.... so this is called a Co-Operative RTOS. What this means is that the threads must be writtenin a form where no thread can any perform any blocking type timing or looping functions.... the kernel must (and will) take care of that.

Each thread runs a bit of code, say a dozen or so instructions, and the releases back to the kernel which will dispatch the next-up thread to run a small section of its code. In this manner all active (some may be temporarily suspended) threads are interleaved according to their timing requirements. With an 80 MHz clock, all timing is set to 1 uSec resolution, with a typical (special faster cases could be created) minimum timing of 2 uSec. Up to 144 separate (trivial LED flashing) threads can be run in a single Cog, but typical real-world applications are somewhere in the 8 to 16 threads range, depending on speed requirements.

This means that mutiple channels of full duplex 38400 serial comms, I2C, stepper motors, sigma-delta ADC, LCDs, button input, mouse input etc. can all reside and operate simultaneousy in any one Cog, thereby greatly expanding any Cog's usefulness, and hence the Prop's total capability.

Some Beta testing has recently been happening, and for the past year that I have used this kernel, it has been absolutely rock solid.

So my take on a Prop RTOS is, that it already exists, is extremely useful, and greatly enhances any Cog which more traditionally was used as a rather simple driver. In fact as yet I have not needed to ever launch a second Cog....... a waste, I know, but my computational needs are growing, and soon expect to explore the multiple Cog realm.

All in assembler only, which for me is not a problem as I don't use Spin.

Cheers,

Peter (pjv)

groggory

Are you this guy?

http://www.parallax.com/PropRTOS/tabid/852/Default.aspx

2009-2010 Honorable mention in the Propeller contest?