Today I presented at the Embedded Systems Conference in Shenzhen – the topic of my session was “The next generation of Embedded Operating Systems and Tools” – the talk starts by looking at the hardware and software trends – the general move from single core to multi-core and distributed cores (distributed embedded systems, good examples being industrial control, home automation), and the developer trends to higher levels of abstraction from the hardware – this can be clearly seen in the move from writing everything in assembler (which is where I got started on 8-bit systems), through to C/C++, and perhaps even higher level languages such as C# or Java – the move to higher level languages allows developers to be more productive and get to market quicker.
An example of application developers being abstracted from the underlying hardware can be seen in the typical code use to write bytes of data out of a serial port – a C/C++ developer writing an application on Windows CE/XPE/Desktop would call CreateFile on “COM1”, call WriteFile to write their data, and CloseHandle when done – the developer doesn’t need to know how the underlying serial port is exposed at the hardware level – introducing appropriate development frameworks (.NET, MFC) allows a developer to focus on their “added value” application rather than the hardware implementation or operating system “plumbing”.
The introduction of multi-core hardware also introduces the issue of concurrency, which can be hard for software developers to deal with, and perhaps requires a shift in thinking about how a typical application is built. Add to that the level of device experience that end users are now expecting and the life of the developer becomes quite challenging. Some of these challenges can be resolved by using the appropriate tools and technologies – for example, having graphic designers use Microsoft Expression to build a great user experience without caring about the underlying application code, and then have software developers “code behind” the user experience – or using the appropriate application development stack (.NET, CCR/DSS, MFC, COM, Win32) to accelerate development – for example, using the CCR/DSS runtime that ships with Microsoft Robotics Studio to build distributed applications.
Of course the level of software complexity within an embedded device depends on your position in the overall system stack – more time and effort is typically placed the further down the stack you go, for example, writing the drivers and BSPs can take longer than an application running on the device, and also requires developers with a different skill set.
So what about the title of the blog? – Do Embedded Systems add value? – according to the image below (taken on the Shenzhen metro system) the answer is of course “Yes!”.