What was your first Arduino program? Probably an LED blinker — that seems to be the “hello world” of microcontrolllers. You probably moved on to things a little more complicated pretty quickly. At some point, things get harder because the Arduino lacks an operating system.
There are operating systems that will run on the Arduino. They aren’t full-featured like Windows or Linux, but they allow you to run multiple tasks that are both isolated from each other (to some degree) and have a way to cooperate (that is, synchronize, share data and resources, and so on). One such operating system is ChibiOS. It will run on AVR- and ARM-based devices. You can find documentation about the entire project on the home page along with other ports.
The problem with adopting a new operating system is always getting started. [ItKindaWorks] has started a video series on using ChibiOS and has posted three installments so far (see below; one is about getting started, the other two cover messaging, mutexes, and priorities).
If you want to follow along with the videos, the code is available on GitHub. We aren’t sure if he’s planning more videos, but these will be more than enough to get you started.
According to the ChibiOS project, they are better than many common similar operating systems because of their static design (you can put the processor to sleep without causing problems). They also support true threads instead of simple tasks, meaning that you can dynamically create and destroy threads and synchronize threads easily.
If you are building sophisticated software that needs multiple things occurring at once, having an operating system can make life a lot easier. We’ve seen examples of using ChibiOS ranging from motor control to MIDI players. There are quite a few choices other than ChibiOS, too, if you look around.
Good stuff, Al. Thanks.
I’m a big fan of ChibiOS. I recently decided I’d do a quick survey of all the RTOSes that will run on an arduino (328P at least) and I quickly settled on ChibiOS as the best available. It’s fairly mature, it’s not too big, and it’s flexible (major example: you can use cooperative multitasking or pre-emptive). I’ve been reworking all my code to run either in ChibiOS or on bare metal and so far it’s gone well.
There already IS an Arduino with an operating system. It’s the Yun and it has a full Linux system/processor running side by side, co-operating with it’s impressive arduino controller. I have been working with the Yun for two years now and the system is unbelievably powerful. Why get involved with a special use OS LIKE ChibIOS that historically speaking is sure to go by the wayside in months or years? Yuns are no longer being promoted but they will be freely available into the indefinite future.
Sure, and I’m guessing the Yun’s power consumption is also the same as the vanilla Arduino too, right? No. And no shit it’s powerful, it’s running a full fucking Linux OS! What did you expect?
ChibiOS is wonderfully stable at this point, and hell, even if it falls by the wayside (hint: it probably won’t given its current adoption), it’s still super useful in its current state. It’s honestly the first thing I get running on any new microcontroller, simply because it’s powerful and stable and fits in tiny freaking spaces.
Please shove your “my Yun is holier than thou’s OS” crap and realize that some of us here have no interest in putting what amounts to a desktop OS, with its large size and resource needs, into something that simply needs to blink some LEDs, read some sensors, and drive some motors.
Wow, you could try and react like a normal person instead of cussing and putting people down. If you like chibiOS so much maybe you should marry it. :)
Some of us grew up in a generation where the use of “fucking”, etc doesn’t mean much. It’s basically the equivalent of a comma.
I’ve heard that there are some parts in New York that even nuns use the word as part of polite conversation.
“‘fget about it”…
Agree with Shifto … Hackaday is more supportive environment for learning and for encouraging more people to take up this wonderful hobby when folks treat others with respectful attitudes.
Linux is a general-purpose OS. It’s got lots of power for networked hardware and is designed to achieve 100% utilization. It can’t run several processes that need to happen at predictable intervals many times a second.
A Real Time Operating System is mostly just a very fancy process scheduler. It can take many tasks and ensure they run with different timing without stepping on eachother. They tend to be unable to deliver these guarantees at 100% load, but below about 69% load they can work perfectly. Think of an RTOS as a way run a multitasked computer where everything is a time critical interrupt.
So if you’ve got something happening on an Arduino and it’s just too many interrupts to keep track of, instead of a lack of processing speed or memory that limits you then a Real Time Operating System is exactly what’s needed.
” It will run on AVR- and ARM-based devices.”
Check twice about AVR…
AVR cannot execute code from RAM.
It doesn’t have to. All of the threads can run from flash, with the “OS” being a separate thread that does context switching.
My real question is how they’re handling heap fragmentation, with dynamic allocation/destruction on an AVR…(no memory management unit on all but one linux-compatible chip in the family)
You have a lot of choices there (ok, like 3-4), and the basic two are either fully static, or just use an incrementing counter. The more powerful memory managers handle fragmentation, allocation, and the like IIRC.
Dynamic memory allocation can fail and garbage collection are non-deterministic so you wouldn’t normally use those where you dealing with a RTOS (vs your regular OS).
Thanks for posting this. I played around with ChibiOS a few years ago and had trouble with the learning curve. Looks like it’s time for a second look.
Hey, ItKindaWorks here! I totally am planning on releasing more videos, I had one planned for this week however last weekend my data storage array failed (taking all of my video work along with it – yes yes I know it’s my own fault for putting my data in one place, redundant or not I should have separate backups) and I’ve been working to bring it back up. But I have more videos in the pipeline once I get that sorted out!! But just as a teaser I’m going to be talking about using asynchronous messages (aka mailboxes in ChibiOS). I also want to do some less technical videos and get to some more semantical videos of ways that I’ve laid out projects and how I do things differently when working with an RTOS vs non-threaded programs.
Thanks so much for putting in all this work. I find videos to be the best way to first get acquainted with new technical areas and I’ll definitely be watching yours.
Looking forward for them!
FreeRTOS seems to be more of the standard for embedded systems.
ChibiOS has the fastest context switch time on Cortex-M based microcontrollers. And the HAL is amazingly powerful. I don’t know what you mean by ‘the standard’, but ChibiOS was designed for embedded systems from the ground-up. Most RTOS’s are written for embedded applications anyway. If you’re running an RTOS on your desktop computer or A59 processor, then you’re just using that device poorly.
Having used a number of RTOS’s both free and paid, I would say that at this level of microcontroller, FreeRTOS (or it’s derivatives safeRTOS and openRTOS) will work quite well and is generally considered one of the standard goto RTOSs, are very easy to learn, and used in a number of military applications. RTOS’s like ThreadX (Which I personally believe is garbage), VXworx, uC are good for a faster group of processors.. But Chibios while being one of the newer kids on the block looks promising, I just hope the documentation improves.
At this level of microcontroller, an MMU-less 8 bit core with limited memory, why the hell are you using an RTOS?
Code portability, maybe?
Standard in the same way linux is now the standard Unix OS.
There are many commercial devices using FreeRTOS, so if you are going to learn a RTOS, its a good one to go with if you want to work in the field.
It is a matter of understanding the API, terminology and idiosyncrasies. The concepts are transferable. I learned multitasking from my CS OS day. Played with AmigaOS and Win32 threading and messaging. Learning ChibiOS was pretty easy for me.
As far as I am concerned, ChibiOS has better license terms and community.
Dude…
http://rtos.com/products/threadx/ARMThumb
“Pre-certified by TUV and UL to IEC 61508 SIL 4, IEC 62304 Class C, ISO 26262 ASIL D, UL/IEC 60730, UL/IEC 60335, UL 1998, and EN 50128 SW-SIL 4”
Go and look up what those standards cover.
Unless you have that level of development tool “relics” then no, no it’s not the standard in embedded systems.
I was looking for an OS for a realtime control application and looked at FreeRTOS among others. The problem I had with FreeRTOS was that even though it was open source all the documentation and tutorials were not free. So I thought of FreeRTOS as “royalty free”. But professional support was available.
I ended up going with a modified bare metal program.
If these tutorials had been available then I would have gone with ChibiOS instead. (I didn’t like the Chibi Dev environment requiring a seperate 32 bit Eclipse install)
Arduino and other microcontrollers/boards are often used precisely because they do NOT have an OS, therefore timing can be easily measured and is predictable and repeatable. OSes have their use, but low level precise timing (for example) is not one of them. I had a number of applications where I actually counted the cycles of a micro (68hc11, PIC, etc). If I had a dollar for every instance I heard “We will do precise timing on a PC” and then it was proven to be a total failure, I would be rich.
To help you know your RTOS from your elbow.. http://www.factorydirect.ca/Categories/847/Computers___Notebooks/Notebooks/Apple_Macbooks
dammit, wrong link in paste buffer, https://en.wikipedia.org/wiki/Real-time_operating_system
That all depends on your demands. From the link that you provided:
“Processing time requirements (including any OS delay) are measured in tenths of seconds or shorter increments of time.”
If your requirements are in the milliseconds or high microseconds, then a RTOS might be just fine. If you need nanoseconds, any OS might be too much of a burden.
It is having some upper bound on OS calls/events that makes it a RTOS – not the actual performance.
Things you found in a regular multitasking OS like virtual memory, swapping, garbage collection makes them non-real time as they are non-deterministic.
Even the fastest are just not predictable in timing when interrupts (or multiple interrupts) arrive.
You can even have jitters without interrupts on modern chips. e.g. Cache misses
I have also seen multiplexed I/O pins having sub cycle difference depending on the peripheral you select due to propagation delay, clock to output delays.
At some point, you got to ask yourself if your system level design is flawed if you have such tight dependency of jitters. That going to be bottleneck for more complex designs with much larger software or newer technologies (e.g. caches, prefetch, wait states). I guess you can stay with PIC16xx54 forever as it doesn’t have interrupt and any surprises.
It’s not necessarily a design flaw for your system to depend on exact timing. Sometimes it’s easier/cheaper/better to use a dedicated microcontroller to generate precisely timed signals than to use a specialized chip, but if you do so, then this rules out things like having other signals interrupting that microcontroller. I’ve seen plenty of designs that use an ARM for the heavy work and an AVR or PIC for low-level hardware interface. That’s not a flaw; it’s just sensible application of technology. Now, if you’re trying to multitask a $1 microcontroller while still using it for time-critical processing, you should probably step back and consider whether there’s a better way.
You cost should also include the NRE and software maintenance cost of constraining your design. If you have to spend a lot of time debugging a timing issue, then that should also factor into the schedule and costing.
If there are tight constraints, I would look into better peripherals (e.g. timer capture/compare, DMA) If all else failed, I would use CPLD/FPGA.
I have used ARM chip with 100% C code running in FLASH with wait states using IRQ to trigger DMA in an application that have zero tolerance on jitter. Yes, it can be done.
The only thing that the Arduino software framework is predictable is that it is slow and badly written. God help you if a badly written “script” peripheral library code decided to use polling I/O in a busy loop.
Chibios at least have better written non-blocking device driver. With threads, messaging, mutex etc, it is easier to come up with software component framework that would work together instead of getting into each other’s way.
It may be badly written and slow, but it is predictable. I’m finding that interrupt driven systems are a nightmare from a timing standpoint.
Wha?
What would be your non-nightmare?
polling?
Polling is fine for one or two tasks, and waiting for a condition to be met to exit. You might be surprised to learn that Apple 1 used polling for keyboard reads, according to Wozniak book I read.
Most 8-bits used polling (well, directly reading the I/O port) for the keyboard. But they didn’t run operating systems. They had BIOS-type functions, but they’re really just libraries for standard functions. Anything running on an 8-bit had full ownership of the system. No OS at all, by the standards we’re using here.
If I understand correctly, you can no longer program in the Arduino environment if you want to use ChibiOS. And once you move away from the vast Arduino ecosystem of hardware support and libraries, I see no reason to stick with the dated AVR microcontrollers used in (most of) the Arduino boards. Modern microcontrollers are vastly more capable with more memory, higher clock speeds, more flash and more sophisticated peripherals. The introduction video for ChibiStudio even shows them using a Nucleo board (which is basically ST’s attempt at making an Arduino-like board).
ESP32 port, anyone? :)
I agree, it might actually be useful on a esp32 – there is no way that is useful on a UNO etc as they are already incredibly RAM constrained and are used for real time control anyway – both things that you don’t really want an OS for…And it is actually easier to write no OS software, particularly as you don’t have that many pins to control…
Or the Intel Quark platform which could really use a better RTOS.
How do you decide if you should just add more AVRs to your board vs multitasking on one chip with all the overheads that creates? Are there any rues of thumb?
As far as I am concerned, if you have to plunk down more than one chip side by side, then you should consider moving to a more capable one or different platform as you are hitting against some constraints – may it be framework, hardware, your skills or just your way of thinking.
ARM chips are probably the best platform. If you ever need a much faster part, more I/O, a lot more memory, more powerful peripherals (DMA, multiple high speed ADC), it is a matter of switching to a different series or even to different vendors. Most of the stuff you have learned about your tool chain remains the same.
I don’t know about you, but I have no loyalty or obligation to stick to a particular vendor’s part. If there is a better part for the job, I’ll learn to use it. Life is about learning new things. The moment you stop learning in this field is the moment your skills are obsoleted.
Funny, just here the other day I read that modern cars have upwards of 400 uP in them for various purposes, guess they don’t share your views.
They are not exactly side by side. The uC in cars are in different modules/subsystems and may sometimes be bundled with manufactured parts by other vendors.
The wiring inside a car isn’t exactly simple, so the situation is very different on the same board/breadboard like your typical users randomly stock piling on Arduinos.
It’s usually electrically identical whether you have a 3m bus between the processors and short wires to the sensors and actuators, or short bus between the processors all on one board and 3m wires to the sensors and actuators. The only consideration being that two low current bus wires are cheaper than 6 higher current motor/sensor wires at a 3m length.
I still would ague that your average Arduino user do not put into much effort on design nor engineering. 99% of the time, the user can’t incorporate two different scripts into one design or can’t think of any other way of attacking a problem.
Automotive engineering is another level over regular products, so they are willing to trade off the complexity and fault handling having to deal with complexity of dealing with their system.
http://blog.caranddriver.com/it-takes-a-lot-of-wiring-to-keep-a-modern-vehicle-moving-witness-this-bentleys-harness/
RW:
Might want to read automotive electronic requirement specifications before commenting further.
“It’s usually electrically identical whether you have a 3m bus between the processors and short wires to the sensors and actuators, or short bus between the processors all on one board and 3m wires to the sensors and actuators. The only consideration being that two low current bus wires are cheaper than 6 higher current motor/sensor wires at a 3m length.”
Wow…
By that, I mean the circuit diagram looks identical, whether there’s 1cm between the parts or 300. There are of course other considerations as to why you’d do it one way and not the other.