Working at Etteplan: What is embedded systems programming?


My previous blog entry brought up the fact that not all programming is about cloud and mobile and highlighted especially embedded systems as an area of programming that is not drawing as much attention as some others. This entry will go deeper into that subject, describing what embedded systems programming is about. The topic is wide, but this entry will focus on some points regarding how embedded systems differ from those other areas of programming and how that affects what a programmer needs to understand and consider.


With and without frameworks


One simple and quite apparent difference is in the use of various software frameworks. When programming for cloud or mobile devices, those programs have a lot in common beneath the surface. For example, when a user clicks or touches a button and the software reacts to that, the looks of the button and the reaction depend on the application, but noticing that the user clicked or pushed the button is the same for most applications and may actually require more code than the look and the reaction. There is usually no point in writing code that exists just to enable the application specific functionality again and again for each program. Instead, there are frameworks available that offer that common functionality ready, and the programmer only needs to add the code specific to their application. Simply put, the framework generates a code file containing a function that is called when the user has pressed a button, and the programmer just adds the application code there, with no need to understand how exactly that function gets called.

Embedded systems programming is different. The code is usually not written on a framework, but instead, programs are written “from scratch”. One reason for that is that those frameworks usually concentrate on creating graphical interfaces - interfaces with buttons, menus and other elements that can be pushed for example by touching the screen. In embedded systems, user interfaces are often not graphical, and such frameworks would simply be useless. User interface often means just a few buttons and leds and maybe a small display showing some text or numbers. There are fewer things that could be supported via a framework, and a framework that would support a reasonable amount of functionality might also be too heavy for the hardware. The latter point will be touched in more depth in the next paragraph.


Perspectives to hardware


Another difference is related to the amount of hardware resources available for the programmer, which can often be simplified to mean the processor’s processing power or simply speed, or perhaps the amount of memory. For developers of mobile applications and especially cloud software, those resources usually appear infinite, and they are also abstracted away by frameworks and operating systems so that the programmers can concentrate on writing the functionality that the user sees. Embedded systems programmers, on the other hand, need to be more aware of the hardware and its limitations. When writing mobile or cloud software, how software does what it does is not that significant, but in embedded systems programming, it usually is significant, because the details of the implementation may have a big effect on what the feature requires from the hardware. The tasks that embedded systems are built for are usually quite simple in the sense that they don’t require a lot of hardware resources, but on the other hand, the limits of the resources force the programmer to think what is possible and what is not.

The use of frameworks and the need to consider the hardware resources can be seen related to each other at least one way. Outside embedded systems programming, at least some part of the hardware resources are spent on making the programmers’ job easier, while in embedded systems programming, there are usually no resources available for that and the programmers need to put more effort on maximizing the efficient use of the resources. One might ask why the hardware resources are kept so limited, and the answer is the costs. Copying software is free, but manufacturing copies of hardware costs money and because the price depends on the amount of resources, the resources are minimized. One might also ask why mobile devices and the servers running the cloud software have so much more resources available. One reason for that is that they are meant to serve a variety of different purposes with varying requirements, while an embedded system is usually designed to serve just one well defined purpose, which makes it possible and more reasonable to optimize.


What are embedded systems?


What are those embedded systems in practice, then? Well, they exist in a wide variety of forms. A smart watch, the electronics of a modern car, the user interface of a microwave oven, an electronic door lock system, a digital camera, a bar code scanner, a payment card terminal – they are all embedded systems. Furthermore, that list is limited to consumer products, but it could be extended to industrial or medical applications too, for example. Embedded systems are devices that contain a microprocessor but don’t look like computers in traditional sense, and making that microprocessor do something useful is called embedded systems programming.


Antti Gärding

Embedded software architect