which ARM rtos? - Page 1
Forum section: electronics / general

author: ralphd
author_rank: Frequent Contributor
timestamp: October 02, 2015, 01:36:20 pm
content: 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?

author: andyturk
author_rank: Frequent Contributor
timestamp: October 02, 2015, 03:57:13 pm
content: https://github.com/ChibiOS/ChibiOS/blob/master/os/nil/src/nil.c

author: jnz
author_rank: Frequent Contributor
timestamp: October 02, 2015, 05:26:30 pm
content: 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.

author: ralphd
author_rank: Frequent Contributor
timestamp: October 02, 2015, 05:47:08 pm
content: Quote from: jnz on October 02, 2015, 05:26:30 pmLooking 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-osI forgot to mention that I'm only interested in open-source, so Keil is out.

author: ralphd
author_rank: Frequent Contributor
timestamp: October 02, 2015, 06:11:33 pm
content: Quote from: andyturk on October 02, 2015, 03:57:13 pmChibiOS/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.

author: jnz
author_rank: Frequent Contributor
timestamp: October 02, 2015, 06:21:27 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: October 02, 2015, 06:28:10 pm
content: 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: October 02, 2015, 07:06:28 pm
content: 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.

author: ralphd
author_rank: Frequent Contributor
timestamp: October 02, 2015, 07:30:42 pm
content: Quote from: AndyC_772 on October 02, 2015, 07:06:28 pmI 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.

author: jnz
author_rank: Frequent Contributor
timestamp: October 02, 2015, 08:14:38 pm
content: Quote from: ralphd on October 02, 2015, 07:30:42 pmI 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.

author: Rasz
author_rank: Super Contributor
timestamp: October 02, 2015, 08:36:12 pm
content: http://dmitryfrank.com/projects/tneo

author: ralphd
author_rank: Frequent Contributor
timestamp: October 02, 2015, 10:32:51 pm
content: Quote from: Rasz on October 02, 2015, 08:36:12 pmInteresting, 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.

author: ralphd
author_rank: Frequent Contributor
timestamp: October 02, 2015, 10:40:02 pm
content: Quote from: jnz on October 02, 2015, 05:26:30 pmI think I'll do some reading on CMSIS-RTOS, and how compatible freertos is or is not.

author: ralphd
author_rank: Frequent Contributor
timestamp: October 02, 2015, 10:49:38 pm
content: 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-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.

author: nctnico
author_rank: Super Contributor
timestamp: October 03, 2015, 08:08:09 am
content: Quote from: ralphd on October 02, 2015, 07:30:42 pmWhy 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!

author: andersm
author_rank: Super Contributor
timestamp: October 03, 2015, 08:42:26 am
content: Quote from: nctnico on October 02, 2015, 06:28:10 pmCMSIS-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).

author: ralphd
author_rank: Frequent Contributor
timestamp: October 03, 2015, 03:43:09 pm
content: Thanks, that clears up some of the confusion.If I understand it correctly, mbed OS is not based on CMSIS-RTOS.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 03, 2015, 03:50:59 pm
content: Are you looking for an RTOS with or without peripheral abstraction?Quote from: ralphd on October 02, 2015, 06:11:33 pmThe kernel itself is made for ARM Cortex. That means that if you choose the compatible ARM instruction set, it'll run onalltargets.For the HAL (Hardware Abstraction Layer) things are different.

author: richardman
author_rank: Frequent Contributor
timestamp: October 06, 2015, 06:57:55 am
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: October 08, 2015, 05:18:29 am
content: Quote from: jnz on October 02, 2015, 06:21:27 pmyuck.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.

author: ralphd
author_rank: Frequent Contributor
timestamp: October 09, 2015, 09:28:55 pm
content: Someone on HaD pointed out that the Keil compiler/IDE is free for STM32F0.http://www2.keil.com/stmicroelectronics-stm32/mdk

author: Jeroen3
author_rank: Super Contributor
timestamp: October 10, 2015, 11:32:29 am
content: Too bad their debugger is not.

author: d21d3q
author_rank: Newbie
timestamp: February 20, 2017, 12:06:15 pm
content: Why so few ppl mention here freertos?

author: Jeroen3
author_rank: Super Contributor
timestamp: February 20, 2017, 12:11:42 pm
content: Because, contrary to the name, its not free. Only the pure kernel is.

author: voltsandjolts
author_rank: Unknown
timestamp: February 20, 2017, 12:45:45 pm
content: Quote from: Jeroen3 on February 20, 2017, 12:11:42 pmThat needs some clarification.FreeRTOS + TCP + FAT are available for Free under the GPL license.

author: voltsandjolts
author_rank: Unknown
timestamp: February 20, 2017, 12:55:40 pm
content: Quote from: Jeroen3 on October 10, 2015, 11:32:29 amI don't understand your statement, the debugger seems to work fine for me on free Keil STM32L0?

author: Jeroen3
author_rank: Super Contributor
timestamp: February 20, 2017, 02:05:19 pm
content: Either some messages have been removed or I was referencing the to the price of the Ulink 2.Looong time ago though2015-10-10, 12:32:29FreeRTOS 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.

author: krho
author_rank: Regular Contributor
timestamp: February 20, 2017, 04:59:18 pm
content: Quote from: voltsandjolts on February 20, 2017, 12:45:45 pmSorry, 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.

author: voltsandjolts
author_rank: Unknown
timestamp: February 20, 2017, 05:17:03 pm
content: Sorry but GPL is free for commercial use. There are many companies making money from GPL software.Edit: Removed unecessary quote of previous post.

author: Jeroen3
author_rank: Super Contributor
timestamp: February 20, 2017, 06:04:42 pm
content: Only gpl3 is incompatible. Gpl2, lgpl or gpl with linking exception are perfectly suitable for mcu use.

author: voltsandjolts
author_rank: Unknown
timestamp: February 20, 2017, 06:24:49 pm
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: February 20, 2017, 06:45:36 pm
content: Of which the incompatible part is the Tivoization clause that forces you to provide ways to change the firmware.

author: voltsandjolts
author_rank: Unknown
timestamp: February 20, 2017, 07:06:30 pm
content: 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?

author: ehughes
author_rank: Frequent Contributor
timestamp: February 20, 2017, 07:13:48 pm
content: 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.

author: mac.6
author_rank: Regular Contributor
timestamp: February 20, 2017, 09:08:10 pm
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: February 20, 2017, 09:10:47 pm
content: No, if you use say, polarssl, and user want openssl, user should be able to do that.To do so, user needs all code.

author: julianhigginson
author_rank: Frequent Contributor
timestamp: February 21, 2017, 05:54:11 am
content: 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.htmlChibiOS 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:startI 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/

author: krho
author_rank: Regular Contributor
timestamp: February 21, 2017, 06:15:08 am
content: Quote from: voltsandjolts on February 20, 2017, 05:17:03 pmYeah 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.

author: Kalvin
author_rank: Super Contributor
timestamp: February 21, 2017, 01:08:59 pm
content: 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/

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: February 21, 2017, 06:01:53 pm
content: Quote from: voltsandjolts on February 20, 2017, 05:17:03 pmThat 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.

author: voltsandjolts
author_rank: Unknown
timestamp: February 21, 2017, 06:31:22 pm
content: Quote from: Sal Ammoniac on February 21, 2017, 06:01:53 pmThat 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: February 21, 2017, 09:49:30 pm
content: Quote from: voltsandjolts on February 21, 2017, 06:31:22 pmYou'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 (thisisthe 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.

author: voltsandjolts
author_rank: Unknown
timestamp: February 21, 2017, 10:09:46 pm
content: No I wasn't thinking of embedded Linux (which can run on MMU-less microcontrollers), thanks for pointing that out.I was thinking ofhttps://github.com/CANopenNode/CANopenNode

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: February 21, 2017, 10:41:28 pm
content: Quote from: voltsandjolts on February 21, 2017, 10:09:46 pm...which uses the GPL "linking exception". The GPL normally doesn't allow that for statically linked code.

author: westfw
author_rank: Super Contributor
timestamp: February 21, 2017, 11:21:22 pm
content: QuoteIf you want to use GPL'ed code (OS, static libraries, etc) in highly proprietary embedded code, then your staff should include a lawyer. :-(

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: February 22, 2017, 01:30:36 am
content: Quote from: westfw on February 21, 2017, 11:21:22 pmLots of companies prohibit any use of GPL'd code for just this reason.

author: voltsandjolts
author_rank: Unknown
timestamp: February 22, 2017, 08:25:37 am
content: ...and lots of companies do use GPL'd code.

author: mac.6
author_rank: Regular Contributor
timestamp: February 22, 2017, 10:24:11 am
content: Quote from: voltsandjolts on February 22, 2017, 08:25:37 amEspecially 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.

author: voltsandjolts
author_rank: Unknown
timestamp: February 22, 2017, 10:42:45 am
content: 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.

author: mac.6
author_rank: Regular Contributor
timestamp: February 22, 2017, 11:00:56 am
content: 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...

author: Marco
author_rank: Super Contributor
timestamp: February 22, 2017, 11:28:10 am
content: Quote from: Jeroen3 on February 20, 2017, 06:45:36 pmForcing 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.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: February 22, 2017, 02:34:06 pm
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: February 23, 2017, 07:32:38 am
content: Quote from: Marco on February 22, 2017, 11:28:10 amI 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.