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