Unless you’ve spent the last 10 years sunbathing in Aruba you would have heard that ARM is well and truly in the software business. After all, it was way back in 2005 when ARM acquired compiler-maker Keil, lauding the virtues of a full-stack solution – i.e. software + silicon – as part of a broader strategy that included explicit aims to deal the death blow to the indomitable 8051, amongst others. Recall, it was ARM’s own slide deck that foretold the Cortex M3 as the answer to an ‘Intel-inside my <everything>’ …and shortly thereafter? Intel EOL’d their 8051-play, leaving it to third-parties, while doubling-down on x86 as their hope for a new, 32-bit world…ahh how exciting to watch titans do their thing!
And as it were, ARM’s strategy of dominating the so-called “small” embedded CPU market with Cortex M had teeth, as they are – if not the dominant force in embedded these days – pretty damn close to the defacto standard for serious development. So much so, that they’d prompted giants like TI to expand their portfolio, acquiring Luminary Micro and bringing the M3 on board (pun) despite success with the MSP430 and Code Composer. And along with that rise in silicon starts, ARM has made no secret of continuing the strategy of not just fighting the fight on the silicon fr0nt, but also delivering on the promise to add more software to the mix — the best and probably most comprehensive case being MBED.
Now if you’re not familiar at all with MBED, it’s been developed largely by ARM (along with their partners, including the semiconductor manufacturers) and is most-recently (relatively new phenomenon) being billed as a full-stack operating system “for the Internet of Things” (previously they didn’t take an IoT position but since adding comm’s support and the relevant IoT protocols (MQTT, CoAP, etc) they’ve since re-badged this to make it alluring to IoT developers). And though this may at first turn some folks off – being tied to IoT – it’s important to keep things in perspective and understand that to say something is an OS for IoT is like saying something is an OS for automotive…You know there will be extensions specific to the domain (in this case comms, protocols, etc) but that doesn’t mean the underlying resources are any less useful when trying to chat-up some lonely UART or read an accelerometer over SPI. And what’s not to love about IoT?…a bunch of comm’s, sensors, and actuators…sounds like dirty work I’d rather not do myself if I didn’t have to.
And MBED is more than just an operating system or an SDK or a collection of drivers (sure, it’s all of these) but moreover, this is ARM’s attempt at simplifying the whole development workflow, including offering a free, online compiler and as we’ll see, a collection of hardware resources to really build the stack from top to bottom, bits and atoms, soup to nuts.
Online compiler, you say?
Indeed the notion of an online compiler can be, how you say? unnerving? But MBED and the folks at ARM aren’t amateurs by any measure and just as you can use all of the MBED libraries online (where they are always current, well managed, revision controlled, and easy to implement) you can also checkout the complete MBED source collection from Github and build projects in your compiler of choice (Keil & IAR are of course super easy and with a little effort, support in GCC / Eclipse is a no-brainer).
The target for the online EDE appears to be that web-savvy generation of startup entrepreneurs, hackers, makers, and the like, *not* currently entrenched in traditional workflows or with traditional notions of developing embedded software. But of course, like anything running in the browser, there are some trade-offs when developing with real hardware connected to the PC via USB ports and such.
Firstly, there’s limited ability to debug (UART anyone?) and – when you really need it – there’s nothing like the ability to examine registers, step code, evaluate variables, set breakpoints, add watches, profiling, etc. Though again, if we’re talking about web developers who until recently have survived almost exclusively on console.log(), you might be forgiven for asking ‘do they even know what they’re missing?’ Whether this methodology is misdirected or worse still, could result in catastrophic system failures may remain to be seen, but judging by the numbers of products these days who owe at least some part of their development lifecycle to early wins on Arduino and the like (Kickstarter anyone?) one can argue that it can’t be all bad.
Another major trade-off of course is at least the perception of IP security. One can’t imagine source code being saved in “the cloud” if that code holds the keys to a product’s differentiation, however MBED appears to be banking on it (at least for the online compiler workflow). They’re also banking on your contributing content back into the community via that same mechanism. And perhaps this too is a sign of the times, where if we accept that the developers at the heart of new products are coming from a place never having known life without the world wide web; that the very notion of differentiation exists because of one’s ability to get there first and build that community of developer-followers faster and more effectively than the next guy.
One component of the MBED flow though perhaps not as popular (at least not yet) as say, Arduino, is the dedicated MBED hardware and just how that hardware is shared with users, or what that might mean to engineers looking to move fast and build $@)#. What began as a few development boards (now plenty, for sure) is now replete with a collection of hardware designs & source files in a Cadsoft Eagle format, BOMs, etc. specifically intended to show you how to implement the devices supported thru the SW stack. To quote the MBED site:
“The Component Database hosts reusable libraries for different hardware, middleware and IoT services that you can use with ARM Microcontrollers. These components can be used as building blocks for quickly developing prototypes and products.”
No programmer required
MBED boards follow a “no programmer required” model…Or rather, a model exists wherein when you’re ready to program your target you simply connect to the device via USB and it’ll appear as a USB Composite Device, including a mass-storage device and virtual serial port. The compiler’s output file is then dropped onto the waiting storage device where it’s “consumed” and used to flash the eager CPU. The virtual serial port is used for serial communications between the PC and the development hardware.
This model is a refreshing departure from the need to break out the J-Link, sort thru pinouts, configure targets, etc. every time you want work with a new development board, though it does come with it’s own set of drawbacks, not the least of which is the limited debugging capability discussed earlier. Alas, MBED / ARM have a solution there, in the form of the CMSIS-DAP (DAP = Debug Access Port) interface which is accessible thru traditional “offline” compiler / debuggers including Keil and IAR. When using the DAP interface with Eclipse / GCC / GDB, have a look at OpenOCD and pyOCD (python based) which both setup a GDB server (TCP socket) and provide the ability to add breakpoints, step code, examine registers, etc.
‘Love it when a plan comes together’
Given the various components of MBED and the overall ARM portfolio it seems they DO indeed have a plan to rule (at least the embedded) world, and that plan is all about getting the full stack solution to users both old and new, skilled & unskilled. The larger challenge ahead is in getting those users to adopt a modular methodology that extends thru from the hardware, to where they’re writing applications. And to empower those same users with resources and a story good enough for a Firmware Engineer to be able to reach across the aisle and share a schematic with their resident Hardware Engineer. Then again, if they do this right – meaning truly raising the abstraction – this may not matter at all, as they might both find themselves “outmoded concepts”.