Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 10, 2016, 03:29:09 15:29


Login with username, password and session length


Pages: [1] 2  All
Print
Author Topic: If you were going to start over tomorrow... Which RTOS?  (Read 3748 times)
0 Members and 1 Guest are viewing this topic.
jnz
Newbie
*
Offline Offline

Posts: 18

Thank You
-Given: 3
-Receive: 0


« on: September 24, 2014, 07:27:34 19:27 »

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.
Logged
dennis78
Junior Member
**
Offline Offline

Posts: 75

Thank You
-Given: 119
-Receive: 129


« Reply #1 on: September 24, 2014, 07:36:45 19:36 »

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.
« Last Edit: September 24, 2014, 09:04:55 21:04 by dennis78 » Logged
jnz
Newbie
*
Offline Offline

Posts: 18

Thank You
-Given: 3
-Receive: 0


« Reply #2 on: September 24, 2014, 11:22:55 23:22 »

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 Wink
Logged
Signal
Active Member
***
Offline Offline

Posts: 102

Thank You
-Given: 47
-Receive: 33


« Reply #3 on: September 25, 2014, 01:01:12 01:01 »

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

Give a right name to a right game and play it right
Gallymimu
Hero Member
*****
Offline Offline

Posts: 579

Thank You
-Given: 101
-Receive: 151


« Reply #4 on: September 25, 2014, 06:54:04 06:54 »

I'm with dennis.  RTOSes suck Smiley

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...
Logged
dotm
Active Member
***
Offline Offline

Posts: 149

Thank You
-Given: 61
-Receive: 47


C15H15NO2S


« Reply #5 on: September 25, 2014, 09:54:00 09:54 »

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
Logged
metal
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2018

Thank You
-Given: 514
-Receive: 477


Top Topic Starter


« Reply #6 on: September 25, 2014, 01:44:00 13:44 »

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

nothing to say..
dotm
Active Member
***
Offline Offline

Posts: 149

Thank You
-Given: 61
-Receive: 47


C15H15NO2S


« Reply #7 on: September 25, 2014, 07:29:23 19:29 »

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.
Logged
jnz
Newbie
*
Offline Offline

Posts: 18

Thank You
-Given: 3
-Receive: 0


« Reply #8 on: September 25, 2014, 08:12:45 20:12 »

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 Smiley

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

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

I lol'ed. Thanks Cheesy

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.
Logged
dotm
Active Member
***
Offline Offline

Posts: 149

Thank You
-Given: 61
-Receive: 47


C15H15NO2S


« Reply #9 on: September 25, 2014, 08:33:46 20:33 »

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.
Logged
Ichan
Hero Member
*****
Offline Offline

Posts: 840

Thank You
-Given: 312
-Receive: 387



WWW
« Reply #10 on: September 25, 2014, 11:37:36 23:37 »

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
Logged

There is Gray, not only Black or White.
Signal
Active Member
***
Offline Offline

Posts: 102

Thank You
-Given: 47
-Receive: 33


« Reply #11 on: September 26, 2014, 12:36:39 00:36 »

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

Give a right name to a right game and play it right
dotm
Active Member
***
Offline Offline

Posts: 149

Thank You
-Given: 61
-Receive: 47


C15H15NO2S


« Reply #12 on: September 26, 2014, 06:40:10 06:40 »

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.
Logged
Ichan
Hero Member
*****
Offline Offline

Posts: 840

Thank You
-Given: 312
-Receive: 387



WWW
« Reply #13 on: September 26, 2014, 08:46:22 08:46 »

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  Wink

-ichan
Logged

There is Gray, not only Black or White.
dotm
Active Member
***
Offline Offline

Posts: 149

Thank You
-Given: 61
-Receive: 47


C15H15NO2S


« Reply #14 on: September 26, 2014, 11:44:24 11:44 »

Not a pipe, a ring it is  Wink

Funny! Dont you care about the order of your outgoing data?
Logged
Ichan
Hero Member
*****
Offline Offline

Posts: 840

Thank You
-Given: 312
-Receive: 387



WWW
« Reply #15 on: September 26, 2014, 11:51:13 11:51 »

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
Logged

There is Gray, not only Black or White.
Sideshow Bob
Senior Member
****
Offline Offline

Posts: 457

Thank You
-Given: 160
-Receive: 495



« Reply #16 on: September 26, 2014, 11:56:04 11:56 »

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

I really am ruggedly handsome, aren't I?
jnz
Newbie
*
Offline Offline

Posts: 18

Thank You
-Given: 3
-Receive: 0


« Reply #17 on: September 26, 2014, 07:22:13 19:22 »

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

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.
Logged
Signal
Active Member
***
Offline Offline

Posts: 102

Thank You
-Given: 47
-Receive: 33


« Reply #18 on: September 26, 2014, 08:40:46 20:40 »

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

Give a right name to a right game and play it right
Ichan
Hero Member
*****
Offline Offline

Posts: 840

Thank You
-Given: 312
-Receive: 387



WWW
« Reply #19 on: September 26, 2014, 10:21:42 22:21 »

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

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

Would like to know your findings.

-ichan
Logged

There is Gray, not only Black or White.
Vineyards
Active Member
***
Offline Offline

Posts: 130

Thank You
-Given: 36
-Receive: 25


« Reply #20 on: September 27, 2014, 08:46:12 08:46 »

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?
Logged
metal
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2018

Thank You
-Given: 514
-Receive: 477


Top Topic Starter


« Reply #21 on: September 27, 2014, 11:47:55 11:47 »

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

nothing to say..
nPn
Newbie
*
 Warned
Offline Offline

Posts: 10

Thank You
-Given: 6
-Receive: 2


« Reply #22 on: October 23, 2014, 10:29:08 22:29 »

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.
Logged
xeontory
Newbie
*
Offline Offline

Posts: 23

Thank You
-Given: 9
-Receive: 32


« Reply #23 on: September 28, 2016, 11:06:26 23:06 »

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.
Logged
Gallymimu
Hero Member
*****
Offline Offline

Posts: 579

Thank You
-Given: 101
-Receive: 151


« Reply #24 on: September 29, 2016, 05:44:47 05:44 »

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!
Logged
Pages: [1] 2  All
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC