Here at Katalix, embedded Linux has been our core business for 10 years. Over that time we've seen a lot of developments in the embedded software industry. With the re-launch of our website, it seemed like a good time to reflect a little on the changes we've seen.
When I first started working with embedded Linux, it was an option. Barely an option, and it raised eyebrows with some developers, but an option. Vendor support for Linux was rare, but occasionally a chipset manufacturer would let you have their "platform independent" driver code, and you could implement a passable new Linux driver based on that.
Real-Time OSes like VxWorks ruled the roost, and developers seemed to genuinely like working with physical memory allocation ("more deterministic, you see?"). Of course that came at the cost of having to really understand the memory requirements of every task, and a walking pointer exceeding its bounds could take out the whole system in the blink of an eye. Perhaps I'm spoiled and lazy with memory now, but thanks to the Linux memory model it's been a long time since I've had to really worry about such things. You could perhaps bemoan this as a lack of rigour, but what it's really done is free us up to concentrate on the features and functionality of the product.
A few years ago, it was possible for a small team to develop all of the functionality required of an embedded device from scratch. Perhaps with the exception of OS supplied features like an IP stack, and key bits you might buy in on top, like a USB stack. For all but the smallest of devices, that's just not the case any more. We expect so much more from our devices now, that it's no longer feasible to develop the whole product in-house. It's widely accepted that open source software and embedded Linux are the ideal foundation for embedded developments.
Cheap Linux development boards have proliferated - thanks in part to the burgeoning maker movement and vendors realising that there is a significant hobbyist market. We were recently engaged in the early phase of a project with tight deadlines, where a microcontroller was being specified. After a bit of research, we managed to find the Carambola board with Linux support with a lower unit cost than the proposed microcontroller board. In this case, embedded Linux represented a clear development time saving - it would be possible to develop the entire system on a PC, then simply recompile for use on the embedded system. For those who require a more full-featured board there are alternatives such as the phenomenally popular Raspberry Pi, and the Beagle boards. It's never been cheaper or easier to scratch that itch and have a go at developing an embedded Linux product - and canny OEMs can leverage these cheap resources for prototyping, and even production runs.
As a result of Moore's Law, we're seeing more desktop technologies making their way into embedded products. Not so long ago, it would have been unthinkable to include D-Bus or a python interpreter in an embedded product. As each year passes, embedded Linux systems gain more and more features once only found in desktop systems. In addition to that the factors which once drove the deployment of embedded-only tools like uClibc and BusyBox (RAM and FLASH constraints), become less important as the price of memory falls and its capacity increases. I don't believe that these tools will go away completely, but it's certainly becoming increasingly common to see full-fat glibc in place of uClibc. Likewise, the idea of a Java VM in an embedded deployment was once greeted with derision, but now not only is it possible, it's at the very core of the Android apps ecosystem.
It used to be an uphill struggle to encourage adoption of embedded Linux, but looking around me now, it's everywhere. As Tim Bird said at the 2013 ELCE conference in Edinburgh, "We [Linux enthusiasts] used to joke about 'world domination' - we don't any more". Chipset vendors now supply Linux (or Android) support as a default, where previously they would have provided RTOS board support packages. We now spend less time developing drivers and board support, and more time helping customers get their userspace code flying.
It's great to be able to report that the Linux ecosystem is thriving, and we look forward to the exciting projects and industry developments of the next 10 years.