Embedded ARM OS options?

[bd139]

Currently working on a prototype for a medium complexity mixed mode analogue and digital device. This is based around the PSoC 6 / Cortex M4. I have considerably underestimated the complexity of trying to build something with an event loop on a single thread as I have several peripherals and subsystems to control at the same time. Three of these are isolated. I hit a wall trying to add a serial port to it so I can control the device from a host machine. How do I talk to all the functions? Architectural fail. Start again.

This brings me into the world of operating systems. Are there any "easy to roll", "very light weight" and "license free" tiny operating systems for ARM Cortex M4? All I need to do is run about 10-12 "tasks" which have static memory allocation and are event based (interrupt or timer driven). These will communicate via shared memory or FIFO if the OS allows that abstraction. Ergo I really need a preemptable scheduler with safe communication primitives. Real time guarantees aren't required for this; it's noddy user interface functions. I can possibly build something using setjmp in C and manual preemption wrapped in a header library (I have done this in the distant past) but I'd like to avoid that mess and go for a clean abstraction.

Before anyone suggests it, Linux is way too heavy. There is no budget to import something commercial.

Edit: just a note, kicking it back down to another core is a possibility. It's all hanging off a PSoC 4 board at the moment. I'm actually doing most of the work in C on a Linux VM at the moment just to see how it fits together. There is no actual target device yet

[chickenHeadKnob]

I'm not a PSOC person but I believe FreeRtos has been ported to the psoc5. It will do everything you need (and more but only is you need it)

[andersm]

There's more RTOSes for ARM than stars in the sky. ARM have their own CMSIS-RTX (based on Keil's RTX, Apache license). FreeRTOS is popular (modified GPL), though its API is butt-ugly IMO.

[bd139]

Thanks will have a look at these. I've looked at FreeRTOS already and it's a possibility but I agree the API is ugly.

PSoC to me here is just a standard ARM core with some funky shit around the edges that make me not have to add a few opamps to the BOM on this

[jeremy]

The good thing about freertos is that it is ridiculously battle tested and stable (IMO), and can also be 100% statically allocated if need be. It also doesn’t force you to use a whole bunch of libraries you don’t need, and doesn’t force you to use a specific build tool (I’m looking at you, mbed...)

You can also run it on a PC for testing.

I’ve seen better APIs, but I’m not sure I’d go so far as saying the freertos one is “ugly”.

Edit: also interesting you are using the PSoC 6, I wasn’t aware they were really on the market yet other than dev kits.

[bd139]

Not using yet. Awaiting dev kit availability. The target design will likely be PSoC 6 but I'm using a PSoC 4 kit at the moment hooked up into the rig. All the software is running on a desktop machine poking it. I'm really awaiting the final pricing of PSoC 6 ICs before I commit to it.

[Berni]

Yep freeRTOS is the way to go. Its free, very well tested and doesn't bring a bunch of crap you probably don't need.

As for the API being ugly that's likely due to one of these high reliability coding standards it tries to conform to. Somehow things like this are supposed to prevent programmers from making silly bug or at least make it less often. In reality it probably just makes code harder to read.

[bd139]

Fair points. Thanks all. Will look at FreeRTOS in depth.

I'll do a hello world on Linux then I will attempt to get it to target my PSoC dev board and see where I get to. I have an encoder and Si570 synthesizer hooked up so if I can get it to set that by end of March and read/set it via serial port / SCPI i'll be happy

[enz]

If you are looking for a simple, but stable, RTOS and don't mind C++, than scmRTOS (https://github.com/scmrtos) could be an attractive alternative. Comes with an MIT license.

I have used it in a couple of projects with a Cortex-M0 and it did work very well and was easy to use.

It doesn't come with a lot of features, nor with a HAL. But this is an advantage in my opinion.

Best regards,
Martin

[andersm]

Correction to what I wrote above: after Amazon bought FreeRTOS, its license was changed to MIT from the previous GPL with linking exception.

[mac.6]

freeRTOS, as it's basically ported everywhere, works quite fine (minus some quirks between ports), and is not anymore encumbered with GPL as v10 is now MIT.

[bd139]

Thanks for the further replies everyone - much appreciated.

[mikerj]

Another vote for FreeRTOS here.  It might not be the perfect RTOS but it's mature and reliable and so widely used that any issues you come across are likely to have been solved before.

Setting the appropriate interrupt priority threshold for RTOS and non-RTOS calling interrupts made my head hurt a bit the first time I used it due to the upside down Cortex priority levels, but once you understand how that works it's pretty straight forward.

[Howardlong]

Correction to what I wrote above: after Amazon bought FreeRTOS, its license was changed to MIT from the previous GPL with linking exception.

Amazon buying FreeRTOS, how did I miss that? I sincerely hope Richard Barry has made a good few quid out of that deal, he deserves it for the quality engineering and dedication he’s put into it over the years, and particularly because it’s been, well, free for most of us. I often wondered what his business model was, ie, were there enough companies buying the paid-for options, for example.

At least Amazon is hardware agnostic in this space, or at least I’d imagine they are. It would’ve been frustrating had one of the microcontroller manufacturers bought it, and the innevitable loss of ongoing support that would go with that.

I agree that the API is a bit of a mindset thing: it’s not that it’s messy, it’s just a bit of a hill to climb.

[bd139]

Climbing hard now

I picked another target to play with that I have already floating around that works out of box (pic24+mplab)

[andyturk]

ARM have their own CMSIS-RTX (based on Keil's RTX, Apache license). FreeRTOS is popular (modified GPL), though its API is butt-ugly IMO.

Another vote for CMSIS-RTX. It's actively being maintained by ARM and has a generous license.

The downside is that you'll have to "port" it to your platform, as it's a generic RTOS. That's not especially difficult (IMO), but it is a speed bump.

[krho]

I just found µOS++ IIIe today it's also generous MIT license.

[ShowKemp]

Hi,

I'm assuming you were using PSoC Creator to develop the application (for the PSoC), for PSoC6 you can add FreeRTOS very easily [1], but it's the FreeRTOS version 9 (i haven't seen if they updated to v10 tho). You can see more projects for the PSoC6 on the same blog, here [2].

I did a port of FreRTOS 9 and 10 for the PSoC4200 devices, you can see it here [3].

Hope it helps.

[1] https://iotexpert.com/2017/05/30/psoc-6-freertos-first-example/
[2] https://iotexpert.com/category/devices/psoc-6/
[3] https://github.com/C47D/FreeRTOS9_49-42xx

[bd139]

Thanks for that - appreciated. Will have a look through.

Big failure though; I just blew up my PSoC, kitprog and the USB port it was attached to  - forgot the power supply I had wired up wasn't floating.

[Berni]

Climbing hard now

I picked another target to play with that I have already floating around that works out of box (pic24+mplab)

By the way 16bit PICs have a bit of a gotcha when it comes to memory and OSes. There normal addressing modes can only access up to a certain amount of RAM. The memory above that magic number needs a special addressing mode that is only used for this extended memory(Yeah oldschool x86 all over again) so only this lower part of RAM is easily usable by freeRTOS, the upper part is best statically allocated. But the limit is reasonably high so most PICs don't have enough RAM to run into it.

[bd139]

Yeah that's not a problem for this. It doesn't need dynamic allocation or any heap really. There's one command buffer and a bunch of configuration and state variables that are global and that's it. In the current incarnation it's all in a big for loop with one procedure for each task and the task when it gets called checks for state change in the globals it knows about and then reacts, or changes the variable based on panel controls etc. Interrupts only mutate the global state at the moment. Makes serial handling difficult to add so adding FreeRTOS here makes stuff easier with queues so I can deliver events instead of watching state.

Inputs for this are: rotary encoder, 5 buttons, 5 ADC inputs (multiplexed), serial port, 2 GP digital lines.
Outputs are: serial port, 3 DAC outputs, one synthesizer IC (I2C), one 44780 LCD, 6 GP digital lines.

uC just controls state or listens to it via serial port and reports it on the display. No intelligence going on.

[NorthGuy]

Makes serial handling difficult to add ...

What is the exact problem with the serial? You can use DMA or interrupts, which are much less imposing than RTOS.

[bd139]

It's more a matter of scale and management. This thing is starting to have to handle a lot of interrupts.

[NorthGuy]

It's more a matter of scale and management. This thing is starting to have to handle a lot of interrupts.

RTOS will only add more interrupts

RTOS takes resources and gives you back convenience. So, if the problem is in your inability to organize things, RTOS may help. But if it's too tight without RTOS, RTOS will only make things worse.

[bd139]

Definitely agree. RTOS gives me the abstractions and the ability to scale this design up if I want, which is what I'm after. If I had to rewrite it later on, I'd be burning a lot of time which I don't have.