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.

References:

More From The Blog

IR35, Here it Comes Again…

IR35, Here it Comes Again…

IR35, Here it Comes Again...In 2021 the reform to IR35 Off-Payroll rules is to be rolled out to the private sector. As before the reform will only affect companies that do not meet the following attributes: an annual turnover below £10m fewer than 50 employees or a...

Solving the Resource Conundrum

Solving the Resource Conundrum

Solving the Resource ConundrumPicture this. One minute all is fine and dandy, you have access to all the resources you could possibly need, then bam an unexpected challenge arises. Suddenly you find yourself lacking the capacity to meet the new need. What are your...

Quality – An Aid to Produce Consistent Rubbish

Quality – An Aid to Produce Consistent Rubbish

Quality - An Aid to Produce Consistent RubbishAnother year has passed, and myself and a colleague have hosted a BSI auditor for our annual ISO9001/TickITplus check-up, and in fact this was more than the regular check, in that it was our 3-year re-certification audit,...

The Hazards of Legacy Systems

The Hazards of Legacy Systems

The Hazards of Legacy SystemsBeing the owner of a software system with a dedicated customer base sounds like the kind of position one would like to find themselves in. At least until it gets superseded and you have to face dealing with a legacy system. Many developers...

How to Test Without Access to The Test Environment

How to Test Without Access to The Test Environment

How to Test Without Access to The Test EnvironmentIn many of our previous articles, we have expressed the importance of achieving a high standard of testing. Potentially blocking this achievement, several factors can come together to affect the quality of your...

The Technical Workshop – How To Make Them Work For You

The Technical Workshop – How To Make Them Work For You

The Technical Workshop - How To Make Them Work For YouAnyone experienced in product design will understand just how valuable a facilitated workshop can be. Bringing together a project's key stakeholders into a single space allows for the exploration of diverse...

Developing Software for Safety Related Systems

Developing Software for Safety Related Systems

Developing Software for Safety Related SystemsSoftware systems should always be both robust and reliable, however the moment you introduce a safety element, this need for reliability increases significantly. The level of safety required is governed by the severity and...

How to Choose an Outsourcing Partner

How to Choose an Outsourcing Partner

How to Choose an Outsourcing PartnerHaving recognised a need to outsource, and worked your way through the initial preparations, you are now in a strong position to seek out a suitable partner. Choosing an outsourcing partner is no trivial affair, so taking the time...