ARM mbed – An operating system for IoT devices
mbed.org
mbed.org
Anybody who cares already has an open-source chain to work with.
This is trying to capture the folks who aren't capable enough to use the open-source toolchain and not rich enough to use the ARM-proprietary toolchain.
This enables both low power systems(since both threads and scheduler are always asleep unless there's a new event - unlike traditional rtos, where usually the scheduler needs to wake up periodically quit often to check which process's turn is now and give it to him).
And since threads are run to completion, you only need a single stack(instead of stack per task), which saves a lot of ram, which is critical in those kinds of systems, both in terms of price and in terms of sleep power(since even in sleep you need to power the ram and the smaller the ram the better) which usually is the biggest component in total power consumption.
I didn't see anything that restricts the mbed SDK to the use of the ARM toolchain.
Could you elaborate on that? Why does the narrow frequency drain power?
For example it's already supporting this:
Yes.
> bigger size
If you're comparing something like a bare ATTiny to a Raspberry Pi, sure, but the size difference between a standard Arduino and the Pi isn't great.
> worse peripheral selection
Um, compared to what?
mbed, a new operating system, will have to have drivers written for everything it supports - which is likely much shorter list than for Linux.
It certainly beats the current standard of manufacturers dropping firmware support after 5 short years, and older devices being left completely high and dry for the sheer majority of people that don't update appliances based on fashion.
Until you solve this mindset problem(god knows how), GPLv3 isn't a workable solution.
Right now I've got a dishwasher that pukes on every second cycle. I know it's a software problem, yet their solution is to replace the whole controller board, taking months to diagnose and order a new one. Luckily I don't own it, so I'm only paying for this circus with my time.
The quip about GPL3 was meant as one possible example, although it does line up incentives pretty well. Users should be wary of devices that have worked quite well with mechanical timers/thermostats/etc being replaced with an essentially infinitely complex microcontroller, and the solution for taming that complexity to be the manufacturer retaining indefinite control.
But solving that is much, much bigger than just open-sourcing embedded code.
Also
>>Oh I'm well aware. Version control with something other than zip files isn't compatible with the mindset of embedded developers :P
That's one thing the mbed default IDE(web ide) does well - it gets people to use version control.
I don't get it.
Finally, for many tasks, your code will end up being more complicated. Because power consumption tends to be crucial in a lot of designs, you want to spend as much time as possible sleeping, waking up only to handle whatever event you received. As such, most microcontroller frameworks have excellent support for event/interrupt-centric programming, where a device will only wake up long enough to handle the input at hand before going back to sleep. Linux just doesn't have the apis needed to support this sort of behavior well, which means you either need a proper real-time microkernel under Linux to handle your i/o, or you're going to be stuck putting all of your operations in kernel space, negating the point of Linux.
In short, stating Linux should be the default is short-sighted and neglects a lot of what is going on in the systems that mbed is focusing on. Trying to wedge it in, or even think of wedging it in, is going to make your device more expensive, and less useful, than using the right tool for the job from the get-go. All the world does not need to be Linux.