RTOS options

It's all about the code!
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

RTOS options

Post by AndreyB »

ChibiOS/RT was chosen pretty randomly and even while I am totally happy with it, I guess we should look at other options.

One of the other options is http://erika.tuxfamily.org/drupal/ - this one brags about being certified by someone and it has some connection with Magneti Marelli which has some connection with Fiat.

Another keyword is http://en.wikipedia.org/wiki/OSEK

So far I am trying to figure out any differences :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: RTOS options

Post by AndreyB »

While googling for asnwers I have found this thread - http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=1455 - and it has mentioned that SPC5-STUDIO by ST somehow uses ChibiOS.

Anyway, SPC56 is a totally different story and no free compiler there AFAIK.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: RTOS options

Post by roflcopter »

Have you ever looked into the Keil RTOS developed by ARM? I was doing some reading about different ones and I'm not sure if it would be any better, but it looks quite comparable to the Chibi setup.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: RTOS options

Post by AndreyB »

roflcopter wrote:Have you ever looked into the Keil RTOS developed by ARM?
RTX seems to be free and seems to be compilable with free GCC compiler, but I have no idea if there any advantages or disadvantages.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
roflcopter
Posts: 39
Joined: Tue Oct 29, 2013 12:41 am

Re: RTOS options

Post by roflcopter »

It really seems to accomplish the same things as the ChibiOS/RT system, but with a bit more base level functionality. I tend to like the stuff that's actually backed by the manufacture, just for less chance of it disappearing out from underneath you like some open-source projects do, but the base level functionality can be both a good thing or bad. It introduces a lot more places for issues to be created but also allows for more concise and direct code.
davidbuzz
Posts: 8
Joined: Thu Jan 02, 2014 7:01 am

Re: RTOS options

Post by davidbuzz »

http://nuttx.org/ is used as the Underlying OS and HAL in the ( fuly open source) http://ardupilot.com/. The latest two commercial hardware releases ( called "px4" and "pixhawk") both use a stm32f4 ( https://pixhawk.ethz.ch/px4/en/start ). I'm one of the (lesser) software devs messing with the open-source code that these all run on. :-) If it's code you are interested, then its pretty much all found here: https://github.com/diydrones/ ( including the stuff to autonomously fly planes, copters, drive cars and boats, etc, all automagically, with GPS navigation. )

Just thought you might all be interrested. :-)
User avatar
acab
provoker
provoker
Posts: 263
Joined: Wed Dec 18, 2013 7:27 pm
Location: Minsk, BY

Re: RTOS options

Post by acab »

you want to change RTOS?!
blundar
contributor
contributor
Posts: 141
Joined: Tue Jan 07, 2014 4:38 am
Location: Cincinnati, Ohio
Github Username: blundar
Slack: Dave B.
Contact:

Re: RTOS options

Post by blundar »

I've been really impressed with Chibi so far for STM32... Lot of momentum there, and it seems to not be going anywhere. I looked into the ERIKA and OSEK but they're more RTOS and less STM32HAL, so I guess it would depend on how much work you felt like doing. Over.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: RTOS options

Post by AndreyB »

ChibiOS is amazing but question is how much it depends on Giovanni personally.

Also they are promising to separate HAL from kernel in 3.0 so one would be able to use ChibiHAL with another kernel, like ERICA
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
jedediah_frey
contributor
contributor
Posts: 51
Joined: Tue Nov 05, 2013 1:43 pm

Re: RTOS options

Post by jedediah_frey »

russian wrote:ChibiOS is amazing but question is how much it depends on Giovanni personally.
Given the integration with the SPC5 series and how STMicro has included it with SPC5-STUDIO I would not be surprised if Giovanni was partially employed by them.
Also they are promising to separate HAL from kernel in 3.0 so one would be able to use ChibiHAL with another kernel, like ERICA
Where ever you go I would suggest a free RTOS that supports the SPC5. eTPU has some very nice features like being able to have angle based events. While you are able to get away with using brute MHz for timing adding a TPU drops a lot of CPU load by externalizing timing events.
blundar
contributor
contributor
Posts: 141
Joined: Tue Jan 07, 2014 4:38 am
Location: Cincinnati, Ohio
Github Username: blundar
Slack: Dave B.
Contact:

Re: RTOS options

Post by blundar »

Ya, all the major MCUs used today by OEMs (SH, tricore, MPC56, etc.) have bad ass TPU units designed to offload a lot of the timing sensitive stuff. The TPU is almost as much silicon as the MCU in some of the newer Renesas designs.

The TMS570 looks promising too, but the price on it is pretty damn high.
http://www.ti.com/lsds/ti/arm/hercules_arm_cortex_r_safety_microcontrollers/arm_cortex_r4/tms570ls/overview.page

All of the "real" automotive chips are oriented towards those buying hundreds of thousands if not millions of units. :(
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: RTOS options

Post by abecedarian »

Redhat is taking GCC and it's being expanded to include MSP430 and other processors.

Just a thought.
You can lead the horticulture but you can't make them think.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: RTOS options

Post by AndreyB »

http://en.wikipedia.org/wiki/MQX was recommended to me but I am not sure about licensing.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
J L
Posts: 1
Joined: Fri Mar 07, 2014 9:39 pm

Re: RTOS options

Post by J L »

It's not about the RTOS, it's about the project code. The PX4 code base has years of code already done & is built to be extensible to other projects. At the minimum, you get all the autopilot stuff for free including PWM output & a variety of sensor input. It works on the discovery board.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: RTOS options

Post by AndreyB »

J L wrote:The PX4 code ... autopilot stuff for free including PWM output & a variety of sensor input.
Let's begin from the beginning - what is PX4? :) Is it http://copter.ardupilot.com/ ?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
mobyfab
Posts: 139
Joined: Tue Oct 29, 2013 10:09 am
Location: Versailles, France

Re: RTOS options

Post by mobyfab »

blundar wrote:Ya, all the major MCUs used today by OEMs (SH, tricore, MPC56, etc.) have bad ass TPU units designed to offload a lot of the timing sensitive stuff. The TPU is almost as much silicon as the MCU in some of the newer Renesas designs.

The TMS570 looks promising too, but the price on it is pretty damn high.
http://www.ti.com/lsds/ti/arm/hercules_arm_cortex_r_safety_microcontrollers/arm_cortex_r4/tms570ls/overview.page

All of the "real" automotive chips are oriented towards those buying hundreds of thousands if not millions of units. :(
There is very little documentation on the N2HT, I remember asking TI a year ago, they were still writing it... And you will need their proprietary assembler.
Also the Cortex R4 is not as good as the M4 performance wise.

You could use another chip to have the role of the TPU, such as an F0 with 11 timers :)
It's cheaper, a lot more flexible, and easier. Only downside is it takes more space on the PCB.

It's probably better to stick with general purpose MCUs.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: RTOS options

Post by kb1gtt »

One of the reasons why I feel it's important to have an OS that allows for portability to other ARM based processors, is that we are currently experiencing a revolution in processing. More and more peripherals are being integrated into a single chip. While soft cores have been very common for a long time with FPGA's, we are starting to see very powerful hard ARM processors with an FPGA fabric attached. Often you can get a multicore ARM with this FPGA fabric. This means there are many new options just around the corner, and we'll likely see an obsolescence of the TPU style of processing. We'll start to see dedicated hardware for these relatively simple and time dependent tasks. Then we'll see the hard-core deal with administrative level tasks and high level decisions. See Xlnx's zynq chips found here.

http://www.xilinx.com/products/silicon-devices/soc/zynq-7000/

Any how, using an ARM based OS is critical in allowing portability to these features that are just around the corner. I generally think any ARM will do, then the performance critical stuff will be dedicated hardware.
Welcome to the friendlier side of internet crazy :)
seank
Posts: 1
Joined: Thu Mar 13, 2014 11:40 pm

Re: RTOS options

Post by seank »

Yep, those Zynq chips are pretty impressive. I think you can get into one for about $50 and that's at digikey pricing. I might go to a hands on lab for the Zynq next month. You could be right about TPU type processors being a thing of the past, but that won't happen over night. Did the Zynq have MCU like peripherals?

-sean
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: RTOS options

Post by kb1gtt »

When you have control over the hardware like that, things change a fair bit. When you say MCU peripherals I assume you mean ADC's and DAC's. As the FPGA fabric allow a massive pile of PWM's and various timers and such. As well you can have do some things that you can't do with an MCU, like a dedicated crank angle schedule Independent of the MCU. Even independent of the MCU clock signal. You have many UART's, SPI's, I2C, and other things like that.

As for ADC's you can get external chips like quickfilter which do ADC with DSP near brick wall filtering to SPI stream. As well DAC's are easy with an low pass filtered PWM connected to an op-amp. So I see it as having all the items you really need and want for engine control.
Welcome to the friendlier side of internet crazy :)
Nobody
Posts: 98
Joined: Wed May 28, 2014 9:12 pm

Re: RTOS options

Post by Nobody »

Has anybody looked at OSEK variants, of which there are many?

I decided on MPC56xxx family long before joining this site, so that is etched in stone. I have looked at ChibiOS as there is support for MPC56 family but not complete, eMIOS is not 100% and don’t think TPU will ever get there (too many variables). Having said that, the little that I have tested with it, looks good so far.

Code as it sits now is bare metal or OS-less, which is fine for testing purposes because system is interrupt driven for most part. Looking to add OS, but don’t want to switch down the line. At this point I’m biased towards ERIKA (another OSEK), which already supports MPC56 dual core (locked step or decoupled). As far as drivers (TPU functions included), I already have what I need so that is really not relevant here. Another thing that OSEK has going for it is Alarm functionality in OS. Although alarming is not that hard to implement, doing it correctly can be another story.

So has anybody used ChibiOS and OSEK extensively and if so what feedback do you have?
Last edited by Nobody on Thu Sep 04, 2014 10:02 pm, edited 1 time in total.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: RTOS options

Post by kb1gtt »

Have you found a compiler for the ETPU's for MPC56xxx ? With out it it doesn't really matter what you use. The FS provided code is garbage and needs to be re-written to be useful. Sensor Jitter is a very significant issue with the FS provided cam/crank angle decoder. The key issue with the MPC56xxx stuff is the lack of a low cost compiler and development environment. Expect to pay in excess of $4k to get a basic development platform. As well why do you like this chip? There are many multi-core chips out there with low latency IRQ's.
Welcome to the friendlier side of internet crazy :)
Nobody
Posts: 98
Joined: Wed May 28, 2014 9:12 pm

Re: RTOS options

Post by Nobody »

As mentioned my MPU selection is etched in stone… So what does the MPC56xx have going for it?

Overall specs:
* -40 to 125, or -40 to 150 degree C temperature range (depending on which one is specified).
* 5V I/O both analog and digital.
* Up to 56 timed I/O pins with 24 bit resolution (not 16 bit like most).
* Simple EEPROM emulation with free driver.
* Flash and SRAM have ECC with single-bit correction, double-bit detection.
* If you watch your signal injection current, chip will ride though some nasty transients without latchup.
* It’s designed for harsh environmental and electrical conditions, which is reflected at silicone level.

ADC:
* 0 - 5V input (no voltage dividers needed).
* Differential or single ended inputs, with a programmable gain amp (PGA - 1x, 2x 4x).
* Configurable strong or weak pull-up/pull-down resistors (5k, 100k 200k).
* Knock detection with programmable decimation filter with almost no CPU overhead.

TPU:
* 32 I/O channels.
* Enables angle based control.
* Many functions sets for varying applications.
* Effectively offloads considerable CPU overhead.
* Too many features to get into, but I/O can be defined for many functions, so PCB/hardware design can be generic.

eMIOS:
* 24 I/O channels.
* Can be independent timers or reference to bus A, B or C (some limits apply).
* Configurable input filtering (how many counts before input is valid).
* Lots of flexibility with independent interrupts.

Above lists a few of the reasons I like this chip, it’s like a swiss army knife for powertrain applications.

Now with respect to your “Garbage” comment, you do realize there are millions of cars on the road with the exact same function set you and I can get - no complier needed.

You can indeed throw some serious noise/jitter at the crank/cam function… The function is very robust, but must understand how to configure/use it (hint - read up on windowing). GIGO, garbage in = garbage out, applies for both software and hardware. The learning curve on TPU varies, some find easy others daunting, or in between.

I suspect you’ll have your opinion as will I on the TPU, which is fine.

As far as why dual core, MPC56xx can be used in SIL 3 safety applications in which locked step operation is required to conform to standards. I am not needing it now, but wanted a MPU line that covers my current and possible future needs with TPU included.
Last edited by Nobody on Thu Sep 04, 2014 9:55 pm, edited 1 time in total.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: RTOS options

Post by kb1gtt »

I have first hand experience with a single cyl engine 36-1 wheel. It failed badly especially at low RPM, yes windowing and following the datasheet was taken into account. The issue appears to be that real world jitter will toss that window way off. I'm not saying it's a bad choice of chip. I'm saying it's not cost effective to low budget applications. If you can amortize your compiler expenses across 1k units, the end costs aren't bad. However we are low volume and low budget. We can use an existing platform that comes with a compiler and all the pieces you need, for very low $. With other tools being so effective and so easy to use, I just don't see the benefit of using such a chip. Are there particular system features it offers that we don't already have? Also have you heard of o5e? It's a good platform, but has issues that are very hard to get around due to the crank angle decoder. It also has some management issues, but that's minor and can be resolved if required.
Welcome to the friendlier side of internet crazy :)
Nobody
Posts: 98
Joined: Wed May 28, 2014 9:12 pm

Re: RTOS options

Post by Nobody »

Yes, I found o5e by accident about 4 months ago. With all due respect no comment…

EDIT-

As mentioned earlier, millions of cars on the road with same function set would contradict or invalidate statements. Also to knowledge a single cylinder function does not exist.

So let’s agree to disagree :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: RTOS options

Post by kb1gtt »

If we go multi-core, we should consider xmos. $149 starter kit found here. http://www.digikey.com/product-detail/en/XK-SK-L2-ST/880-1041-ND/3622821

That's 16 cores, nS delay time, lots of slices that allow you to make a prototype quickly.
Welcome to the friendlier side of internet crazy :)
Nobody
Posts: 98
Joined: Wed May 28, 2014 9:12 pm

Re: RTOS options

Post by Nobody »

Well AUTOSAR compliant OSEK up and running on two MPUs MPC5634M (80 MHz) and MPC5644A (150 MHz dual issue core). Can’t say it was fun, but not that bad at all, everything playing nicely even TPU with Extended Tasks.

Alarm management is actually fairly flexible, you can setup xxx events per unit of time as an example, for like a stall detection, normal thresholds types, windows, self-clearing…

For those that are contemplating OSEK I’d say go for it, enough info can be found that porting isn’t that bad. OSEKTime can be useful for things like servo motion control, but an engine is predominantly event driven, so don't see much benefit here.
Last edited by Nobody on Thu Sep 04, 2014 9:56 pm, edited 1 time in total.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: RTOS options

Post by AndreyB »

Nobody wrote:Well AUTOSAR compliant OSEK up and running on two MPUs MPC5634M (80 MHz)
Arctic Core is a dual license (GPL/commercial) AUTOSAR implementation with OSEK implementation.
http://www.arccore.com/products/

Would you be available to provide a HelloWorld project suitable for my SPC563M-DISP board? Something to start with would be a huge help.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Nobody
Posts: 98
Joined: Wed May 28, 2014 9:12 pm

Re: RTOS options

Post by Nobody »

I did not use Arctic Core because they contradict themselves on License terms. Having already developed drivers over time and happy with them, I just wanted OS with minimal HAL implementation required (main timers and counters)… The version I’m using is cross between OSEK and TurboOSEK (latest OSEK version but TurboOSEK like port). All I’m doing here is converting a bare metal application to OS based, in reality it did very well as bare metal… It had critical routines scheduled and rest was event driven.

The board (ST) you referenced, SPC5 studio already has uOSEK port and examples. The reason I did not go with that was again licensing… Can only be used with “ST” MPU, but Freescale says TPU binaries can only be used with “FSL” MPU LOL. I use allot of FSL drivers for things like Flash write/erase, even EEPROM emulation, obviously TPU binaries, BAM utility to allow end user to reflash MPU… I’ve pretty much decided that FSL is preferred part and will only use ST if a shortage is present. Also can get better prices from FSL direct too (MPUs).

Just a note - choose your preferred toolchain/OS and stick with it… FSL and ST use different JTAG interface, which you’ll have to buy. I might be willing to sell off my ST stuff as I haven’t touched it more than 4 times this year.
Last edited by Nobody on Thu Sep 04, 2014 10:01 pm, edited 3 times in total.
Nobody
Posts: 98
Joined: Wed May 28, 2014 9:12 pm

Re: RTOS options

Post by Nobody »

Image
Not sure if you found this?
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: RTOS options

Post by AndreyB »

russian wrote:Anyway, SPC56 is a totally different story and no free compiler there AFAIK.
Now it looks like finally (?) there is a free compiler for SPC56. I have these boards, I just do not have time to play with them :(
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply