ARM mbed – An operating system for IoT devices

by pjmlp • 12 years ago

43 38 12 years ago

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...

joezydeco• 12 years ago

Yup. Kind of hard to tell my customers that their IoT module is secure when I can't control the toolchain.

jvermillard4• 12 years ago

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

zwieback3• 12 years ago

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.

noselasd• 12 years ago

Can't you just tell it to use gcc, as described at http://developer.mbed.org/handbook/mbed-tools ?

justincormack3• 12 years ago

Well, see this thread for problems people encountered http://developer.mbed.org/forum/mbed/topic/2336/

higherpurpose• 12 years ago

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?

zokier• 12 years ago

You mean like https://github.com/mbedmicro/mbed ?

jvermillard4• 12 years ago

a bigchunk of the announced new parts are not going to be opensourced (like the server and some part of the IP stack)

jvermillard4• 12 years ago

more details: http://www.javaworld.com/article/2692491/mobile-java/arms-mb...

jvermillard4• 12 years ago

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.

zwieback3• 12 years ago

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.

KaiserPro• 12 years ago

They are aiming it at large scale rollouts. They are sort of pitching it in the same way that Amazon does its cloud computing.

bsder• 12 years ago

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.

dmritard96• 12 years ago

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.

n0rm• 12 years ago

range constrained if you are working with power constrained devices

Could you elaborate on that? Why does the narrow frequency drain power?

freehunter• 12 years ago

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.

pinkyand5• 12 years ago

Nothing is binding it to those protocols.

For example it's already supporting this:

http://developer.mbed.org/users/dudmuck/code/SX1232/

simpsond• 12 years ago

I realize linux might be too heavy for many applications, but for any powered device, let's please make linux the default.

zwieback3• 12 years ago

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.

pinkyand5• 12 years ago

Linux also means higher hardware costs and bigger size and worse peripheral selection. Those are critical parameters in this market.

fragmede• 12 years ago

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.

WallWextra• 12 years ago

I'd really rather not have my toaster running, e.g., bash, since a toaster will never get firmware upgrades.

mindslight3• 12 years ago

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).

swah• 12 years ago

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.

tmuir• 12 years ago

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.

monocasa• 12 years ago

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.

Sanddancer• 12 years ago

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.

justincormack3• 12 years ago

Linux is just too big. And we need variety to explore new ideas.

fra• 12 years ago

Linux doesn't run without an MMU (cortex M only has an MPU). Furthermore, I don't think one size fits all. Putting a server OS on an embedded system is nuts and will hurt you across the board (power consumption, performance, ... etc.).

unmole• 12 years ago

Clearly you've not heard of uCLinux.

pinkyand5• 12 years ago

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.

angersock• 12 years ago

...can we just have BEAM-on-Cortex?

ARM mbed – An operating system for IoT devices

Related Stories