EEVblog Electronics Community Forum

Electronics => Microcontrollers => Topic started by: ralphd on October 02, 2015, 01:36:20 pm

Title: which ARM rtos?
Post by: ralphd on October 02, 2015, 01:36:20 pm
I've decided to get into ARM development, but not vendor specific.  Looking at freertos, it seems to support a number of ARM MCUs.  I also read about mbed OS, which at least sounds like it will work on lower-end devices than freertos.
I'm thinking of starting with a 32K or even 16K stm32f030, which I think is too small for freertos.  Anyone know about mbed OS?
Title: Re: which ARM rtos?
Post by: andyturk on October 02, 2015, 03:57:13 pm
https://github.com/ChibiOS/ChibiOS/blob/master/os/nil/src/nil.c
Title: Re: which ARM rtos?
Post by: jnz on October 02, 2015, 05:26:30 pm
I don't like much about mbed. It's like too much like Arduino for me to consider for a serious project.

I've been using Keil's RTX. Which like FreeRTOS (can be?) it's a CMSIS RTOS. So the idea is you could plug in any RTOS under the CMSIS layer. I've been very happy with it so far while staying under 32K rom.
Title: Re: which ARM rtos?
Post by: ralphd on October 02, 2015, 05:47:08 pm
I don't like much about mbed. It's like too much like Arduino for me to consider for a serious project.

I've been using Keil's RTX. Which like FreeRTOS (can be?) it's a CMSIS RTOS. So the idea is you could plug in any RTOS under the CMSIS layer. I've been very happy with it so far while staying under 32K rom.

Looking at the mbed library API, it does look arduino-ish.  Looking at the source I see the mbed OS uses the same DigitalIO API.
https://github.com/ARMmbed/mbed-os

I forgot to mention that I'm only interested in open-source, so Keil is out.

Title: Re: which ARM rtos?
Post by: ralphd on October 02, 2015, 06:11:33 pm
https://github.com/ChibiOS/ChibiOS/blob/master/os/nil/src/nil.c

ChibiOS/RT looks more interesting than nil, since the comparison page says it is CMSIS-RTOS compatible.  The docs say 2-6KB for RT vs ~1KB for nil.
I wish they had a clear list of supported MCUs.  The release notes have lots of references to STM32F parts, but I don't see any LPC parts listed.
Title: Re: which ARM rtos?
Post by: jnz on October 02, 2015, 06:21:27 pm
Keil's RTX is free now, although I can't remember if it's open source or not. It didn't used to be free. :-//

All I know is that I've been using RTX since June, and while I know I'm not pushing it hard, I've been very pleased with the performance and it's been bug free. I've even done things I was sure were going to mess it up (100% thread loads and some weird messaging/signaling) and it just chugged right through.

So either way, whichever you pick, I'd definitely select a CMSIS RTOS as it's not a lot of overhead but would make switching to other options infinitely easier.
Title: Re: which ARM rtos?
Post by: nctnico on October 02, 2015, 06:28:10 pm
In general CMSIS is a very thin layer (basically the systick timer and interrupt controller) so any RTOS written for an ARM Cortex Mx series is likely to be CMSIS based even if it doesn't specifically says so.
Title: Re: which ARM rtos?
Post by: AndyC_772 on October 02, 2015, 07:06:28 pm
Unless you have a good commercial reason to do so, I'd skip the ARM chips with the smallest memory. Go for a device with at least 256k; the incremental cost is tiny, and you'll find your code size does tend to be larger than it would be on an 8-bit device.
Title: Re: which ARM rtos?
Post by: ralphd on October 02, 2015, 07:30:42 pm
Unless you have a good commercial reason to do so, I'd skip the ARM chips with the smallest memory. Go for a device with at least 256k; the incremental cost is tiny, and you'll find your code size does tend to be larger than it would be on an 8-bit device.
I can get 10pcs of f030k6 (32K flash) for $6.
The few 256K parts I've seen have been around $2 or more.  Can you point to any in the $1 range?

I already have lots of Unix/C experience, so more complex projects I'd just go with an embedded linux solution such as openwrt and run it on a $7 wifi router stick.
Title: Re: which ARM rtos?
Post by: jnz on October 02, 2015, 08:14:38 pm
Unless you have a good commercial reason to do so, I'd skip the ARM chips with the smallest memory. Go for a device with at least 256k; the incremental cost is tiny, and you'll find your code size does tend to be larger than it would be on an 8-bit device.
I can get 10pcs of f030k6 (32K flash) for $6.
The few 256K parts I've seen have been around $2 or more.  Can you point to any in the $1 range?

I already have lots of Unix/C experience, so more complex projects I'd just go with an embedded linux solution such as openwrt and run it on a $7 wifi router stick.

I agree with Andy, stepping up in core is usually noticeably more expensive but stepping up in memory is (for me in the USA) only tiny increases. I'm also basing any prices on 1k units, so there is that.

The issue was for me, I wanted to use the smallest physical packages (32/36/48pin) and memory is just more limited in those. I've tossed up my hands on my latest project however, I'm just going to use a 512k 100pin STM32F4 because I don't want to have to think about external nor/nand for temporarily storing bootloader/application flashes.
Title: Re: which ARM rtos?
Post by: Rasz on October 02, 2015, 08:36:12 pm
http://dmitryfrank.com/projects/tneo (http://dmitryfrank.com/projects/tneo)
Title: Re: which ARM rtos?
Post by: ralphd on October 02, 2015, 10:32:51 pm
http://dmitryfrank.com/projects/tneo (http://dmitryfrank.com/projects/tneo)
Interesting, but I'd like to go with an RTOS that has some traction in commercial products.  If I learn something like freertos, I might be able to pick up some contract work related to it.
Title: Re: which ARM rtos?
Post by: ralphd on October 02, 2015, 10:40:02 pm
I don't like much about mbed. It's like too much like Arduino for me to consider for a serious project.

I've been using Keil's RTX. Which like FreeRTOS (can be?) it's a CMSIS RTOS. So the idea is you could plug in any RTOS under the CMSIS layer. I've been very happy with it so far while staying under 32K rom.
I think I'll do some reading on CMSIS-RTOS, and how compatible freertos is or is not.
Title: Re: which ARM rtos?
Post by: ralphd on October 02, 2015, 10:49:38 pm
Seems like the main FreeRTOS guy doesn't think much of CMSIS-RTOS.
http://www.embedded.com/electronics-blogs/industry-comment/4237614/Who-wins-when-Cortex-M-adds-RTOS-abstraction-layer- (http://www.embedded.com/electronics-blogs/industry-comment/4237614/Who-wins-when-Cortex-M-adds-RTOS-abstraction-layer-)
He makes false assumptions though, like assuming an os abstraction layer always adds overhead.  When it is just function name mappings, that can be done in a header file with no overhead.
Title: Re: which ARM rtos?
Post by: nctnico on October 03, 2015, 08:08:09 am
Unless you have a good commercial reason to do so, I'd skip the ARM chips with the smallest memory. Go for a device with at least 256k; the incremental cost is tiny, and you'll find your code size does tend to be larger than it would be on an 8-bit device.
I can get 10pcs of f030k6 (32K flash) for $6.
The few 256K parts I've seen have been around $2 or more.  Can you point to any in the $1 range?
Why make life hard for yourself for a few dollars? Just start with a big device. It will have more cool peripherals to play with and you don't run into memory problems just as things start to get fun!
Title: Re: which ARM rtos?
Post by: andersm on October 03, 2015, 08:42:26 am
In general CMSIS is a very thin layer (basically the systick timer and interrupt controller) so any RTOS written for an ARM Cortex Mx series is likely to be CMSIS based even if it doesn't specifically says so.
CMSIS-RTOS is an attempt at a standardised API for RTOSes, like eg. ┬ÁITRON. If you download ARM's CMSIS distribution it includes the CMSIS-RTX implementation, which is actually Keil's BSD-licensed RTX kernel with an API wrapper. CMSIS-RTOS offers all the basic services you'd expect, but perhaps to not limit implementations it eg. offers only seven levels of task priorities (-3 to +3).
Title: Re: which ARM rtos?
Post by: ralphd on October 03, 2015, 03:43:09 pm
Thanks, that clears up some of the confusion.
If I understand it correctly, mbed OS is not based on CMSIS-RTOS.
Title: Re: which ARM rtos?
Post by: Jeroen3 on October 03, 2015, 03:50:59 pm
Are you looking for an RTOS with or without peripheral abstraction?

https://github.com/ChibiOS/ChibiOS/blob/master/os/nil/src/nil.c

ChibiOS/RT looks more interesting than nil, since the comparison page says it is CMSIS-RTOS compatible.  The docs say 2-6KB for RT vs ~1KB for nil.
I wish they had a clear list of supported MCUs.  The release notes have lots of references to STM32F parts, but I don't see any LPC parts listed.
The kernel itself is made for ARM Cortex. That means that if you choose the compatible ARM instruction set, it'll run on all targets.
For the HAL (Hardware Abstraction Layer) things are different.
Title: Re: which ARM rtos?
Post by: richardman on October 06, 2015, 06:57:55 am
IMHO, one problem with the existing RTOS is that "everything talks about IoT, but no one is doing anything about it".

There are two classes of microcontrollers: the "big" ones where they handle the kitchen sink tasks, and the little ones where they handle sensor data.

Show me an RTOS that scales both ends and make communication easy between all the systems, without using just TCP/IP or the like.
Title: Re: which ARM rtos?
Post by: andyturk on October 08, 2015, 05:18:29 am
Keil's RTX is free now, although I can't remember if it's open source or not. It didn't used to be free. :-//
yuck.

I selected CMSIS-RTOS RTX for a commercial project and have been using it for a year. It works well enough, but the code makes me hold my nose at times. ChibiOS is a much cleaner implementation IMO, but the licensing is more complicated.
Title: Re: which ARM rtos?
Post by: ralphd on October 09, 2015, 09:28:55 pm
Someone on HaD pointed out that the Keil compiler/IDE is free for STM32F0.
http://www2.keil.com/stmicroelectronics-stm32/mdk (http://www2.keil.com/stmicroelectronics-stm32/mdk)
Title: Re: which ARM rtos?
Post by: Jeroen3 on October 10, 2015, 11:32:29 am
Too bad their debugger is not.
Title: Re: which ARM rtos?
Post by: d21d3q on February 20, 2017, 12:06:15 pm
Why so few ppl mention here freertos?
Title: Re: which ARM rtos?
Post by: Jeroen3 on February 20, 2017, 12:11:42 pm
Because, contrary to the name, its not free. Only the pure kernel is.
Title: Re: which ARM rtos?
Post by: voltsandjolts on February 20, 2017, 12:45:45 pm
Because, contrary to the name, its not free. Only the pure kernel is.

That needs some clarification.
FreeRTOS + TCP + FAT are available for Free under the GPL license.
Title: Re: which ARM rtos?
Post by: voltsandjolts on February 20, 2017, 12:55:40 pm
Too bad their debugger is not.

I don't understand your statement, the debugger seems to work fine for me on free Keil STM32L0?
Title: Re: which ARM rtos?
Post by: Jeroen3 on February 20, 2017, 02:05:19 pm
Either some messages have been removed or I was referencing the to the price of the Ulink 2.
Looong time ago though 2015-10-10, 12:32:29

FreeRTOS did not always have this gpl. I recall it being purely source and for manuals you'd had to pay.
Also a looong time ago.
Title: Re: which ARM rtos?
Post by: krho on February 20, 2017, 04:59:18 pm
Because, contrary to the name, its not free. Only the pure kernel is.

That needs some clarification.
FreeRTOS + TCP + FAT are available for Free under the GPL license.

Sorry, but GPL is not free, at least for commercial use. Yeah, I know they have the linking exception now.

GPL and LGPL just don't work for micro controllers.
Title: Re: which ARM rtos?
Post by: voltsandjolts on February 20, 2017, 05:17:03 pm
Sorry but GPL is free for commercial use. There are many companies making money from GPL software.

Edit: Removed unecessary quote of previous post.
Title: Re: which ARM rtos?
Post by: Jeroen3 on February 20, 2017, 06:04:42 pm
Only gpl3 is incompatible. Gpl2, lgpl or gpl with linking exception are perfectly suitable for mcu use.
Title: Re: which ARM rtos?
Post by: voltsandjolts on February 20, 2017, 06:24:49 pm
Just to clarify, when Jeroen3 says 'incompatible' he means incompatible with closed source applications.
Edit: See Jeroen's own clarification below.
Anyone is free to use GPLv3 software/firmware commercially as long as they abide by the license.
Title: Re: which ARM rtos?
Post by: Jeroen3 on February 20, 2017, 06:45:36 pm
Of which the incompatible part is the Tivoization clause that forces you to provide ways to change the firmware.
Title: Re: which ARM rtos?
Post by: voltsandjolts on February 20, 2017, 07:06:30 pm
Which is just a JTAG port, right? Or does it have to be some other way that doesn't require hardware such as an ISP programmer?
Title: Re: which ARM rtos?
Post by: ehughes on February 20, 2017, 07:13:48 pm
I have  had success with FreeRTOS. It is easy to port, etc.  Lots of documentation.     


You may consider if you really need an RTOS for a 32Kb part.    I can't think of any application that small that would require a scheduler.     Since ARM cortex IRQs can be fully nested,   you can get any real time behavior needed without the overhead of an RTOS.   I am not sure it is buying you anything.   RTOS's are helpful once you get lots of high level "blocking" components (TCP stacks,  USB Host Stacks, etc) but you are going to burn up that 32Kb pretty quickly. 


Title: Re: which ARM rtos?
Post by: mac.6 on February 20, 2017, 09:08:10 pm
If you want a bare RTOS that works fine and is easy to port, FreeRTOS is a good choice. It's GPL with a linking clause so can be used in a closed source product if you provide rtos sources.Some vendor bundle it with their BSP/SDK (NXP, ST) with various improvements (like low power tick timer in sleep mode).
On the other hand if you want a full framework you can go with other like chibiOS (full GPL, so no closed source afaik), zephyr (still very young and evolve quickly) or nuttx. The inconvenience of these frameworks is that you need to embed everything in their build system and use their drivers. So if you plan to use vendor SDK, it's not the perfect choice and can requires a lot of work.
Title: Re: which ARM rtos?
Post by: Jeroen3 on February 20, 2017, 09:10:47 pm
No, if you use say, polarssl, and user want openssl, user should be able to do that.
To do so, user needs all code.
Title: Re: which ARM rtos?
Post by: julianhigginson on February 21, 2017, 05:54:11 am
FreeRTOS doesn't look like it places that much of a restriction on a commercial product. And it seems to be very solid. I've had no issues with it when I've used it. Also if you get into it, it's nice to know you can go to openRTOS for a proper commercial license and support if needed, and even to safeRTOS if you need that.
http://www.freertos.org/a00114.html (http://www.freertos.org/a00114.html)

ChibiOS looks like it could work for commercial products with their free commercial licence, except you can only sell 500 units before going full commercial license, and you have to advertise ChibiOS on your product materials, and they get your details and can advertise your product as part of their own marketing... not sure under which circumstance this would be too horrible for a commercial product. (well OK, it would suck in the event of ChibiOS having some really bad vulnerability discovered)
http://chibios.org/dokuwiki/doku.php?id=chibios:licensing:start (http://chibios.org/dokuwiki/doku.php?id=chibios:licensing:start)
I keep meaning to try ChibiOS because I hear good stuff about it - but the free commercial license keeps putting me off.

Also there's micrium's uc/OS offering which was just opened up on a free tier, so you can now register to use as a hobbyist or a startup at no cost - I think it's actually a better deal than free commercial ChibiOS. I used UC/OS-II a while ago for a large project, and it was actually a very good solid product.
https://www.micrium.com/makers/about/ (https://www.micrium.com/makers/about/)

Title: Re: which ARM rtos?
Post by: krho on February 21, 2017, 06:15:08 am
Sorry but GPL is free for commercial use. There are many companies making money from GPL software.

Yeah it is. If you want to open source ALL of your proprietary source code. But you don't right. Because this might give your competition the boost they need.

Before anyone attacks me. I'm all for open source and GPL and contributing back I have also released the email client in 2003 but that's different.
Also I'm perfectly fine with GPL/LGPL with linking exception, however I don't like the V3 from any of it. Because it just doesn't work in micro-controllers.
Title: Re: which ARM rtos?
Post by: Kalvin on February 21, 2017, 01:08:59 pm
Nuttx is quite well supported by many stm32-based devices and eval boards, quite easy to port, has extensive protocol stacks, has device drivers for various peripherals and devices, it is suitable also for the IoT, and it is released under the permissive BSD license:

http://nuttx.org/ (http://nuttx.org/)
Title: Re: which ARM rtos?
Post by: Sal Ammoniac on February 21, 2017, 06:01:53 pm
Sorry but GPL is free for commercial use. There are many companies making money from GPL software.

That depends on your definition of "free". If by "free" you mean you can do anything you want with it, including use it in products where you don't release your proprietary source code, then it's not free.

The BSD and MIT licenses, in my opinion, are more free than the GPL.
Title: Re: which ARM rtos?
Post by: voltsandjolts on February 21, 2017, 06:31:22 pm
That depends on your definition of "free". If by "free" you mean you can do anything you want with it, including use it in products where you don't release your proprietary source code, then it's not free.
That is incorrect.
There are many commercial products available using a mixture of GPL code and closed source proprietary code.
You probably knew that but for other people reading this, these kind of statements are misleading.
The situation is more complex than you can sum up in a simple one liner. If anyone is unclear on these issues they should refer to the appropriate license, not to people blowing hot air on a forum.
Title: Re: which ARM rtos?
Post by: Sal Ammoniac on February 21, 2017, 09:49:30 pm
That depends on your definition of "free". If by "free" you mean you can do anything you want with it, including use it in products where you don't release your proprietary source code, then it's not free.
That is incorrect.
There are many commercial products available using a mixture of GPL code and closed source proprietary code.
You probably knew that but for other people reading this, these kind of statements are misleading.
The situation is more complex than you can sum up in a simple one liner. If anyone is unclear on these issues they should refer to the appropriate license, not to people blowing hot air on a forum.


You're probably thinking of cases like when a proprietary programs are run under a GPL'd OS -- that's allowed. I'm thinking of a common case where proprietary code is combined with GPL'd code into firmware for a microcontroller (this is the Microcontroller forum...) Or dynamic linking--again, not something typically done with firmware.

Personally, I'd rather not deal with GPL'd code. If I have to use 3rd party code at all (only under extreme circumstances) I'd rather it be BSD or MIT licensed.
Title: Re: which ARM rtos?
Post by: voltsandjolts on February 21, 2017, 10:09:46 pm
No I wasn't thinking of embedded Linux (which can run on MMU-less microcontrollers), thanks for pointing that out.
I was thinking of https://github.com/CANopenNode/CANopenNode (https://github.com/CANopenNode/CANopenNode)
Title: Re: which ARM rtos?
Post by: Sal Ammoniac on February 21, 2017, 10:41:28 pm
I was thinking of https://github.com/CANopenNode/CANopenNode (https://github.com/CANopenNode/CANopenNode)

...which uses the GPL "linking exception". The GPL normally doesn't allow that for statically linked code.
Title: Re: which ARM rtos?
Post by: westfw on February 21, 2017, 11:21:22 pm
Quote
The situation is more complex than you can sum up in a simple one liner.
If you want to use GPL'ed code (OS, static libraries, etc) in highly proprietary embedded code, then your staff should include a lawyer. :-(
Title: Re: which ARM rtos?
Post by: Sal Ammoniac on February 22, 2017, 01:30:36 am
Quote
The situation is more complex than you can sum up in a simple one liner.
If you want to use GPL'ed code (OS, static libraries, etc) in highly proprietary embedded code, then your staff should include a lawyer. :-(


Lots of companies prohibit any use of GPL'd code for just this reason.
Title: Re: which ARM rtos?
Post by: voltsandjolts on February 22, 2017, 08:25:37 am
...and lots of companies do use GPL'd code.

 
Title: Re: which ARM rtos?
Post by: mac.6 on February 22, 2017, 10:24:11 am
...and lots of companies do missuse GPL'd code.

Especially Chinese ones.

No big name companies I worked for were using GPL unless mandatory (like linux kernel work). And it won't gonna change soon, if ever.
Title: Re: which ARM rtos?
Post by: voltsandjolts on February 22, 2017, 10:42:45 am
Using GPL Linux is not mandatory.
Those companies chose to use Linux rather than VxWorks..etc..etc.
So your (non)argument actually further validates the use of GPL in a commercial environment.

Edit:
My replies here make it look like I'm on a GPL rant and I don't mean to be, I'm not a GPL fanboy as such.
I admire the success of the Linux kernel and I'd attribute much of that to the GPL. The BSD kernel hasn't anything like the same level of activity.
I just think smaller embedded projects could benefit in the same way, persuade users to contribute back to the free code they have been given while keeping proprietary code closed via linking exemptions.
Personally, I like the FreeRTOS licensing model.
I'll stop posting in this thread now, sorry for diverting slightly off topic.
Title: Re: which ARM rtos?
Post by: mac.6 on February 22, 2017, 11:00:56 am
When you work inside linux kernel, like to support some of your chips, then you are bound to the GPL, unless you do really dirty things like binary linked modules...
Title: Re: which ARM rtos?
Post by: Marco on February 22, 2017, 11:28:10 am
Of which the incompatible part is the Tivoization clause that forces you to provide ways to change the firmware.

Forcing this on developers is not a bad thing with IoT. This is an industry in which people still program internet facing code in C after all.
Title: Re: which ARM rtos?
Post by: donotdespisethesnake on February 22, 2017, 02:34:06 pm
This discussion is confusing, because there are at least 4 different types of licenses that might be called "GPL", and many meanings to the word "free". The advice I would give depends on the type of company, a "traditional" engineering company probably couldn't cope, other companies who already contribute to Open Source projects might have no problems.

As someone with a foot in both camps, I would be wary about including any GPL code in a proprietary microcontroller program. I'm not saying it can't or shouldn't be done, it just requires careful checking of the actual license and how that would impact the product, e.g. if it says "GPLv2" or "GPLv2 or later", there is a significant difference. Even if I am satisfied myself it is OK, I would still want to run it past legal dept. Everyone including management needs to be on board with the idea of using GPL code, and what requirements and responsibilities that entails, if there is *any* risk that proprietary code might need to be published. I don't want to be doing a hurried rewrite because someone misunderstood, nor find myself on the block for pushing "company code" to a public repo because the GPL requires it.

Even BSD code could be problematic, if it requires notices in the product manual for example.

tldr; Open Source code can bring a big advantage in development time to proprietary products, but be very aware of all the implications first.



Title: Re: which ARM rtos?
Post by: Jeroen3 on February 23, 2017, 07:32:38 am
Of which the incompatible part is the Tivoization clause that forces you to provide ways to change the firmware.

Forcing this on developers is not a bad thing with IoT. This is an industry in which people still program internet facing code in C after all.
I completely agree, as end-user. But my employer does not want the core features of the products to be available as source code or assembly bin. This means JTAG lock.