ARM mbed – An operating system for IoT devices(mbed.org)
mbed.org
ARM mbed – An operating system for IoT devices
https://mbed.org/technology/os/
6 comments
Anyone else think ARM missed an opportunity to make this open source? Is the fear that the platform would "fork" in very bad (far out) ways, real?
[deleted]
Why should ARM?
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.
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.
Yeah, it's not really clear what they gain by keeping it closed and the fragmentation fear seems unwarranted. If it were open source people might be more likely to port it to non-ARM platforms but I doubt that's the main motivation.
They are aiming it at large scale rollouts. They are sort of pitching it in the same way that Amazon does its cloud computing.
[deleted]
You mean like https://github.com/mbedmicro/mbed ?
a bigchunk of the announced new parts are not going to be opensourced (like the server and some part of the IP stack)
yes it's kinda broken when you know all the existing alternatives: contiki OS, RIOT OS, openwsn, and for LWM2M eclipse wakaama
and (shameless plug:) Leshan in place of the mbed server.
Technically ,the nice thing about this is that they use an event based model. Your system is divided into event-manager threads which communicate with each other using events(and of course interrupts create events). When they are activated by an event , they do their stuff rapidly - and go to sleep. Only a single thread is allowed at a time. There are also event priorities to manage a case of multiple events happening at the same time, and a scheduler to manage that.
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.
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.
mbed seems to insist you use ARM's online toolchain, and appears to be very difficult to just use with gcc or llvm in your machine. So no thanks...
Yup. Kind of hard to tell my customers that their IoT module is secure when I can't control the toolchain.
you can export the project to use gcc, it's packing you a zip with make files and linker scripts
example:
https://github.com/jvermillard/Wakaama-mbed
I think that's just to get people who aren't used to setting up embedded systems toolchains an easy start a la Arduino.
I didn't see anything that restricts the mbed SDK to the use of the ARM toolchain.
I didn't see anything that restricts the mbed SDK to the use of the ARM toolchain.
Can't you just tell it to use gcc, as described at http://developer.mbed.org/handbook/mbed-tools ?
Well, see this thread for problems people encountered http://developer.mbed.org/forum/mbed/topic/2336/
Nothing inherently binding this to 2.4ghz, but it is the band for bluetooth, wifi zigbee/thread etc. Not in love with that as the bet for much of IoT because its pretty range constrained if you are working with power constrained devices...For higher bandwidth applications it makes lots of sense but for sensors and actuators where I am only moving a few bytes at a given time, I would rather have lower power and better range... and yes, they did miss an opportunity to make it open.
Nothing is binding it to those protocols.
For example it's already supporting this:
http://developer.mbed.org/users/dudmuck/code/SX1232/
For example it's already supporting this:
http://developer.mbed.org/users/dudmuck/code/SX1232/
> range constrained if you are working with power constrained devices
Could you elaborate on that? Why does the narrow frequency drain power?
Could you elaborate on that? Why does the narrow frequency drain power?
Lower frequencies offer longer range, which is nice compared to 2.4Ghz. Which means that 2.4Ghz is also going to have more attenuation, so you need a higher TX power draw to account for that. Basically, to get the same range, 2.4Ghz is going to need more power than 900Mhz would, but 2.4Ghz offers better transmission speed.
I realize linux might be too heavy for many applications, but for any powered device, let's please make linux the default.
Linux as the default for the sort of devices mbed is focusing on is, plain and simple, not feasible by any shape of the imagination. The first constraint is memory; the microcontroller world is full of very powerful chips that can only address a few kilobytes of memory. Using a chip capable of running any sort of Linux kernel means limiting yourself to chips that cost at least 5-10 times more than other chips, plus the added cost of RAM, plus the design costs associated with the extra chips and discrete components, etc. Second, you are limiting what you can do with the chip; Linux, for example, has no support for being an SPI slave device, so if that's part of your design requirements, you now have to start writing your own kernel drivers for something that's almost always built into other OSes/frameworks for microcontrollers.
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.
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.
Linux won't run on most Cortex-Ms that this is for. These devices have 192KB of RAM on the high end and no MMU.
Linux also means higher hardware costs and bigger size and worse peripheral selection. Those are critical parameters in this market.
> higher hardware costs
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.
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.
Generally, that's the way it's going but there are still many situations where a lightweight real-time kernel like uC/OS or ThreadX, etc. is preferable.
I'd really rather not have my toaster running, e.g., bash, since a toaster will never get firmware upgrades.
Rather than encouraging proprietary blobs that will have their own bugs and never get updated (if they're even publicly disclosed), we're better off solving the firmware update problem (eg GPL3).
The GPLv3 model, i.e the need to release all your source, isn't compatible with the mindset of embedded product manufacturers, which are highly afraid of copying.
Until you solve this mindset problem(god knows how), GPLv3 isn't a workable solution.
Until you solve this mindset problem(god knows how), GPLv3 isn't a workable solution.
Oh I'm well aware. Version control with something other than zip files isn't compatible with the mindset of embedded developers :P
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.
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.
Sure there's a huge problem with the quality and the reliability of appliances.Basically everything's shit, or there's are high end products which are a bad deal, economically.
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.
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.
This only solves the problem in theory, not in practice. The vast majority of users aren't going to bitbake their own toaster firmware to fix bugs (nor will they even suspect the latest Linux bug might impact their toaster).
So then you build auto-updating frameworks on top. If you don't start off with the option to DIY, you cannot possibly end up with a functioning market for repair service.
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.
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.
I agree this has to be considered. I see this pattern some times: wow, this small device is really fun to work. Now I want to hook a camera (usb) and process the data (opencv) to do something. And I realize I should've been using arm + linux.
Linux is just too big. And we need variety to explore new ideas.
[deleted]
Maybe some people like reinventing the wheel with every piece of code they write Or, they like having a pool of only a couple hundred people that can help with problems, instead of a couple hundred thousand. Or they don't like the freedom to program in fifty different languages. Or they don't like a thoroughly tested, mature, code base. Perhaps they don't like when their code runs on multiple different processor architectures. Maybe they hate the abundance of freely available communication protocols, file systems, and graphical frontends. Maybe they're overwhelmed by the ease of searching for solutions to common problems because of linux's ubiquity.
I don't get it.
I don't get it.
...can we just have BEAM-on-Cortex?