Embedded Development – The Software Side
A couple of weeks ago, we kicked off our new blog series with a quick introduction to embedded systems. As foretold in the final lines, this week we will be shifting our attention onto the software side of things.
Compared to software juggernauts such as Cloud computing and Artificial Intelligence, Embedded development always feels just a little more niche. Sitting outside of the skill set of the everyday programmer. However, this needn’t be the case. While there are certainly some key differences, which we shall get onto in a minute, for the most part, embedded programming is just plain programming.
The differences begin to creep in when the hardware elements are taken into account. For example, there will almost always be a restriction on the amount of memory available, a factor that must be taken into account when writing code. Typically, as memory is quite an expensive commodity, this is largely a result of reducing production costs. For most embedded systems, it is generally a good idea to allocate memory on startup and avoid Dynamic memory allocation. By working in this manner, you define the amount of memory available to the software, ensuring there will be enough as a safety precaution.
Continuing on the theme of hardware limitations, the CPU’s and microcontrollers that are utilised by embedded systems often require specialised compilers and tools. The downside is that these compilers have an unfortunate tendency of reducing the selection of programming languages available. Once again, the reason behind this reduction stems mostly from attempts at minimising cost. For each new type of CPU or microcontroller, manufacturers will need to develop corresponding tools and compilers. Rather than catering for all available languages, narrowing the list to a few essential choices keeps the associated cost low. With an abundance of libraries and toolsets, traditionally, C and C++ are the languages of choice when it comes to embedded development.
Before we move on from the topic of hardware, we need to mention dedicated hardware. As embedded systems are designed to perform specific tasks, it isn’t unusual for developers to utilise dedicated hardware to help manage power and size restrictions. While there are obvious benefits to this approach, specialised tools are often required to develop on these platforms. As technology continues to advance, with the introduction and increased availability of more efficient hardware making it easier to introduce operating systems, our dependence on these tools is waning.
Speaking of operating systems, we couldn’t discuss embedded software without mentioning possibly the biggest lynchpin in the ‘what is embedded’ debate. Unlike desktop applications, it is common practice to develop embedded systems without the need for an operating system. Deciding on whether to adopt a bare metal approach or employ a commercial operating system, such as Embedded Linux or Nucleus, will impact how you go about development. Bare metal allows for faster execution speeds and a reduction of system power consumption, but can also complicate the debugging process and engineers will have to write almost all of the systems device drivers. On the flip side, even refined operating systems designed specifically for embedded purposes, require storage space, RAM and demand some level of processing power. All factors that drive up the cost of hardware.
A type of embedded system that should be introduced at this point is real-time. These systems can mostly be defined by their ability to make calculations and decisions at specified time intervals. By introducing real-time elements into embedded developments, you introduce timing constraints that need to be carefully managed. Bare metal allows developers to take more control over the timing of tasks and decisions, however scheduling all of the tasks a device will need to complete can be rather complex. On the other hand, standard operating systems can schedule tasks, but it can be very difficult to meet the demanding timing requirements of certain real-world signals. This is because they have to run so many other tasks, it quickly becomes impossible to guarantee that a required task will run at the exact time required. Specialised real-time operating systems (RTOS’s) still schedule tasks like a standard OS, but they can allow for quicker and more accurate timings.
All of the factors outlined in this article define the big design decisions that must be considered throughout an embedded development project. In the next edition in this series, we will be looking at the type of skillset you want in an embedded engineer.