If you were going to start over tomorrow... Which RTOS?

[jnz]

Some of you have been around the block. What's the one that if you had to be locked into, pay or open source, that you'd choose?

I'm looking at ThreadX, FreeRTOS, OSEK-by-whoever, Salvo, and about 100 others, but their sites and videos don't really give an impression of how the community support is, how often they break with updates, stability, quality of trace tools, etc.

I have some money, not a ton, but if I can try and avoid picking the "wrong" OS out the gate, that would be really helpful.

Currently using Pic18F and moving to maybe Cortex M0/M3/M4 depending on projects.

[dennis78]

First question is do you really need RTOS? I think "small" MCU's don't need RTOS. Good organized standard "while(1){...}" application will be enough in most cases. If you need somethnig stronger go to linux board with strong ARM processor or similar system... It is my opinion.

[jnz]

Uh, yes. I very much need an RTOS. I didn't think that was really up for questioning.

I'm currently programming CAN diagnostic client and server both on two different busses. It's a TON of work to control access to buffers and hardware (sure could use semphores and mutexes!), I've got arrays of buffers that are constantly in need of polling their states, I've devised relative timers, absolute 16bit timers with rollover protection, and simple decrement timers that activate tasks/ops when they reach zero, and on top of all of this I need to add USB soon. I'm looking at chip migration which means a lot of code will have to be tossed out. For this specific application, I've basically re-made a lot of features an OS has in limited and application specific ways.

I need an RTOS. I'm spending time fixing or adjusting aspects of a stack for a no-copy transition for each comm message that ranges 3 different protocols (each has to have a stack, update loops, polling), instead of spending time doing what I do, which is make features for the end user.

Features I can sell. Well coded state machines mean garbage on a retail box.

So... Back to RTOSes

[Signal]

jnz, I am just curious, do you have a reason to reject PIC32 in favor of Cortex while currently using PIC18? Have you tried Microchip's Harmony?

[Gallymimu]

I'm with dennis.  RTOSes suck

we did user interface, encrypted daisy chained bootloader, LCD, streaming SPI, streaming UART, SD card, 10x ADC 4x DAC, and SMPS control spread across 3 dspic and pic32s all driven with DMA and 2 threads just in an event driven super loop.  We simply used shadow registers for our 1kbyte data buffers that were being fed from all the different inputs and outputs.  Once we kept the data structure centralized and protected everything else was pretty easy.

hmm... probably should have used an RTOS...

[dotm]

We simply used shadow registers for our 1kbyte data buffers that were being fed from all the different inputs and outputs.  Once we kept the data structure centralized and protected everything else was pretty easy.

hmm... probably should have used an RTOS...

This sounds exactly like you did a lot of hard work to get things done that are normally part of rtos routine programming.
I'd say when using arm cortex m3 or m4 devices it is never a bad idea to start with an rtos. If you dont need it you will have one thread at the end and you can then remove the rtos with ease. With keil, you can insert an rtos with two mouse clicks

[metal]

From what I read on different forums, it seems people who use STM32 use chibios, some use keil RTX, others who use GCC usually use FreeRTOS. I think the way chibios handles things is different from RTX. So, if you are going to use an RTOS, you need to stick with it for a long time, otherwise it will be a nightmare for you to move between them.

[dotm]

So, if you are going to use an RTOS, you need to stick with it for a long time, otherwise it will be a nightmare for you to move between them.

Chibios is planning to include a CMISIS-RTOS wrapper for v3.0. After that you can freely switch from chibios to rtx to abassi-rtos and freertos whenever you like without having to change a single line of code.

[jnz]

jnz, I am just curious, do you have a reason to reject PIC32 in favor of Cortex while currently using PIC18? Have you tried Microchip's Harmony?

There are reasons. I was telling someone else a second ago... Microchip has got to be the LAZIEST hardware developer I've ever seen. Their CAN implementations are sub-par at best, esp considering their transceivers are damn near out of spec. Their chips have had exceptionally little innovation in the 12 years I've been working with them. They're struggling to catch up to everyone else it seems. Their tools are absolutely the worst out there - I can define something in MPLABX 2.20 (latest) and one line below that if I hover over the same object it I get "NOT RECOGNIZED", thanks Microchip, super useful right there! No. I'm done. Fuck microchip. Seriously. I probably made the wrong choice with them so many years ago, at least for automotive work that is. They do make an excellent hobby chip.

I have a seriously hard time considering Microchip over anything in the Cortex fam.

Posted on: September 25, 2014, 08:10:13 20:10 - Automerged

I'm with dennis.  RTOSes suck

<... a ton of work ...>

hmm... probably should have used an RTOS...

I lol'ed. Thanks

The thing is, at my company, it's just me. I'm a team of 1 person. So keeping up with an excellently coded state machine where I must account for everything is really wearing on me. I'm also probably not that great a coder, so there that.

The idea is that an RTOS should allow me to pay a penalty for absolute performance, but maybe get back to writing for the actual application instead of foundation layers.

[dotm]

The idea is that an RTOS should allow me to pay a penalty for absolute performance

In my opinion you will gain performance. Look at a usart putchar function as an example:
Normally you would poll for the output buffer empty flag then write the char into the buffer.
With an rtos you expand the polling loop with an osThreadYield() allowing the other tasks to complete their work while polling.
Implementing a state machine with absolutely no polling is very hard. By considering collaborative multitasking  everytime you wait for a ressource you will be astonished how often you're in the idle task.

[Ichan]

Normally you would poll for the output buffer empty flag then write the char into the buffer.

No, with buffered interrupt driven uart routine.

Implementing a state machine with absolutely no polling is very hard.

Not that hard, by implementing system tick to "slice" tasks - well then it started to become an rtos.

This fourteen years old AN from microchip is good, IMO - but alas the sample code is in ASM.

http://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en011105

I have a seriously hard time considering Microchip over anything in the Cortex fam.

Hard to agree, Microchip is very strong on peripherals. I do use STM32F4 and now with Kinetis but many times i started to think with Cortex in mind and then switched back to dsPic. For example their full featured 32 bit QEI module is hard to find on others, so the internal rail-to-rail op-amp and smps / motor control pwm.

-ichan

[Signal]

This fourteen years old AN from microchip is good, IMO - but alas the sample code is in ASM.

The seventeen years old AN

[dotm]

No, with buffered interrupt driven uart routine.

Not very convenient if you consider that you have to write your own pipe and your own ressource lock for that pipe and you will need the run the pipe pop function within the isr and also stuff like disable irq on last char.

My solution is printf, putchar with yield and check flag. 5 lines code , no buffer, limitless output length.
For input my irq handler is even smaller. Just pass the char trough my nice ready-to-use message queue to the usart input function.

It seems that if someone tries to code functionality that matches the performance of an rtos, it often ends in an rtos-like implementation. I for myself do not want to re-invent the weel.

[Ichan]

Not very convenient if you consider that you have to write your own pipe and your own ressource lock for that pipe and you will need the run the pipe pop function within the isr and also stuff like disable irq on last char.

Not a pipe, a ring it is 

-ichan

[dotm]

Not a pipe, a ring it is 

Funny! Dont you care about the order of your outgoing data?

[Ichan]

Funny! Dont you care about the order of your outgoing data?

Read some about Ring Buffer, sure there will be some pointers to the data (head, tail, current).

-ichan

[Sideshow Bob]

In my opinion you will gain performance. Look at a usart putchar function as an example:
Normally you would poll for the output buffer empty flag then write the char into the buffer.
With an rtos you expand the polling loop with an osThreadYield() allowing the other tasks to complete their work while polling.
Implementing a state machine with absolutely no polling is very hard. By considering collaborative multitasking  everytime you wait for a ressource you will be astonished how often you're in the idle task.

Your post reminded me of one thing. The RTOS label may be quite misleading as I see it, what is Real-Time really? I like more to use the term deterministic OS.

[jnz]

Hard to agree, Microchip is very strong on peripherals. I do use STM32F4 and now with Kinetis but many times i started to think with Cortex in mind and then switched back to dsPic.

You clearly haven't tried Microchip's CAN peripheral.

I'll give you that in motor control and DAC, microchips are robust, hearty little chips, but they are just so behind the times in EVERYTHING else.

[Signal]

You clearly haven't tried Microchip's CAN peripheral. ;)

It would be great if you could share with us the knowledge about observed defects in Microchip's CAN peripheral. Maybe not here but in a separate thread.

[Ichan]

You clearly haven't tried Microchip's CAN peripheral.

How can you be so sure? I did, not in automotive environment, but no problem. 

Would like to know your findings.

-ichan

[Vineyards]

I have never considered an RTOS. Would it be useful for developing multi parameter industrial measurement and control equipment? If so in what ways can it help?

[metal]

behind means that the protocol has been updated, and the HW/SW combinations are no longer compliant!?
This is different from saying that the feature set is behind..

[nPn]

Hard to agree, Microchip is very strong on peripherals. I do use STM32F4 and now with Kinetis but many times i started to think with Cortex in mind and then switched back to dsPic. For example their full featured 32 bit QEI module is hard to find on others, so the internal rail-to-rail op-amp and smps / motor control pwm.

I agree with dsPIC having great peripherals, esp. input capture, QEI, timer, PWM are more separate than on STM32, where all that are in timers. But I think STM has more functionality overall, like DMAing to almost anything and the timers have lots of connections to everything else, ex. you can slave a timer reset-and-start to another timer getting an quadrature encoder edge on its hardware majority filtered inputs...

Back to rtos, I like chibios because the IO drivers work well with the shceduling. ex. you do UART transfer from thread and it deschedules the thread until the transfer completes.

[xeontory]

If you want to use RTOS for IoT devices, Contiki 3.0 is another good choice. You can get a kickstart from github projects done in contiki. Find their features here: http://www.contiki-os.org/

A lot of MCU manufacturers including Texas Instruments, Atmel, Microchip, Freescale supports porting contiki to their hardware: http://www.contiki-os.org/hardware.html

There is a simulator named Cooja where you can simulate the wireless mesh networking in visual map.

[Gallymimu]

If you want to use RTOS for IoT devices, Contiki 3.0 is another good choice. You can get a kickstart from github projects done in contiki. Find their features here: http://www.contiki-os.org/

A lot of MCU manufacturers including Texas Instruments, Atmel, Microchip, Freescale supports porting contiki to their hardware: http://www.contiki-os.org/hardware.html

There is a simulator named Cooja where you can simulate the wireless mesh networking in visual map.

GEEZ, why are you resurrecting a thread 2 years old!