MSP430FR5994: Announcing PRTOS - a full featured preemptive RTOS for the MSP430 family

Hello Nicholas,

having:

CCS8.2,
tirtos_msp43x_2_20_00_06,
compiler TI v16.9.9.LTS,
XDCtools 3.32.0.06

and the following defaults:

I have obtained the following MSP5994 benchloop example project results:

Benchloop Started

Computing the Min, Max, Avg cycles for each [BIOS API]

5  5  5   Hwi_restore()
3  3  3   Hwi_disable()
113  113  113   Hwi_dispatcher_prolog
133  133  133   Hwi_dispatcher_epilog
247  247  247   Hwi_dispatcher
609  609  609   Hardware_Interrupt_to_Blocked_Task
402  402  402   Hardware_Interrupt_to_Software_Interrupt
71  71  71   Swi_enable()
18  18  18   Swi_disable()
28  28  28   Post_Software_Interrupt_Again
149  149  149   Post_Software_Interrupt_without_Context_Switch
343  343  343   Post_Software_Interrupt_with_Context_Switch
1  7741  6173   Create_a_New_Task_without_Context_Switch
231  231  231   Set_a_Task_Priority_without_a_Context_Switch
322  322  322   Task_yield()
55  55  55   Post_Semaphore_No_Waiting_Task
260  260  260   Post_Semaphore_No_Task_Switch
382  382  382   Post_Semaphore_with_Task_Switch
70  70  70   Pend_on_Semaphore_No_Context_Switch
414  414  414   Pend_on_Semaphore_with_Task_Switch
18  18  18   Clock_getTicks()

Benchloop Complete

Could you post equal or similar test results for PRTOS?

I very appreciate small PRTOS footprint you have presented.

Tomasz Kocon wrote:

>  I have obtained the following MSP5994 [I am assuming ti RTOS] benchloop example project results:
>  Computing the Min, Max, Avg cycles for each [BIOS API]
>  5  5  5   Hwi_restore()
>  3  3  3   Hwi_disable()
>  113  113  113   Hwi_dispatcher_prolog ...
>  Could you post equal or similar test results for PRTOS?

Every RTOS implementation is different.  Although all, hopefully, meet the same needs they all have a different view of what an RTOS is, how to implement it and what API to wrap around it.  I haven't made a count of the number of RTOS offerings on the web but I would guess there are at least 100.  The one-and-only true RTOS is usually the one a person imprinted on because it was the first one they learned - like the first language they learned at their mother's' knee.

PRTOS is very different from ti's RTOS in almost every respect with the exception that it is possible to use either one to design a given product.

A comparison of the two based on the above would be meaningless.  The ti API calls you list have no counterpart in PRTOS, and the API calls in PRTOS have no counterpart in ti's offering. - it would be like comparing apples to peaches.  That doesn't illegitamize either offering - either the RTOS or the fruit.

One very big difference is that PRTOS is a naked kernel.  ti's implementation is surrounded by a cloud of communications drivers.  If you need some of those drivers you might be better off with ti's offering.  If your product is naked or uses a communications protocol not present in ti's offering you might be better off with PRTOS.

If you are starting out just learning about RTOS then the PRTOS model is much simpler and the documentation clearer.  Of course, if you are already a ti maven that comparison would be reversed.  I encourage those that may be intrigued to download the PRTOS documentation - its only a 40 page PDF - and see for themselves -- sourceforge.net/.../.

An even simpler learning platform is the CoRTOS  cooperative RTOS - also available on Sourceforge at sourceforge.net/.../

> I very appreciate small PRTOS footprint you have presented.

Thank you very much.  FWIW the basic PRTOS kernel compiles to ~1.3kB -- with all the options turned on the size is ~4kB (varies, of course, with optimization levels and all that).

Hello Nicholas,

I am not a ti maven.
I am a freelancer.

Answering to your statement: The ti API calls you list have no counterpart in PRTOS, and the API calls in PRTOS have no counterpart in ti's offering. - it would be like comparing apples to peaches.
You have already compared apples to peaches talking about PRTOS footprint and linking it to TI-RTOS.
No matter.
I am impressed by a so small footprint and congratulate to guys who did it.
I was looking for pros/cons.

4 days happened, still this thread is silent.
Doing a great announcement I would avoid statements like this:
PRTOS presently supports the MSP430 and AVR architectures.

V102 is released on Sourceforge

This version adds semaphores and makes minor updates to the documentation.

Mitch Ridgeway wrote:

> This looks awesome!

Err, no, not awesome.  Just yet-another RTOS kernel.   Going to the moon, now that was awesome.  I mean, if the word keeps getting devalued what are people going to say when something really awesome comes along?

On the Mars Pathfinder spacecraft mission, the prioritized semaphores have melted a lot - I mean, their users assumptions.

Your semaphores are welcome!

Version 1.03 is available on Sourceforge sourceforge.net/.../

This expands on the semaphores section in the manual, adds more semaphore demo/test programs and fixes a bug with initializing resource owning tasks.

Take enough morning showers and you end up with a new software release.