Introductory guide to software development for reliable embedded systems

start_here_label
We receive many enquiries from people who are looking for information about the development of software for reliable embedded systems.

Some of these enquiries come from people who are about to join our TTa or TTb training courses, from professional programmers who are about to develop their first safety-related embedded system, and from staff and students at universities and colleges around the world.

In response, we’ve created this ‘8-step guide’ for people who want to learn how to program reliable, real-time embedded systems.

Starting from scratch, the material presented here proceeds to a level at which we discuss the development of safety-related embedded systems (up to ‘SIL 2’ level and equivalent).

youtube_logo_100

The page includes links to two free books (PDF format) and to our free introductory training course on “Embedded C”, which is distributed via YouTube®.

[This page was last updated: 2017-02-24] empty_space


empty_space

Four categories of modern embedded system

empty_space
Four different categories of software development for modern embedded systems can be identified:

  • Completely ‘bare metal’ designs, that usually involve a number of interrupt services routines and a main program loop. Typically used in introductory textbooks and code examples. Usually used in practice only for very small / simple products.
  • Systems based on a conventional ‘RTOS’. Sometimes treated as the ‘default design solution’ and (in our experience) often used inappropriately (e.g. when a Task Scheduler would be more appropriate – see below).
  • Systems based on a larger conventional OS, such as Linux.
  • Systems based on a ‘Task Scheduler’. Highly deterministic. Easy to model and monitor. Used for a wide range of products (from small to very large). Often used in safety-related designs.

Our focus in this guide will be on designs based on a Task Scheduler: these form an appropriate foundation for many safe and reliable systems in a wide range of sectors.

If you want to obtain a more general understanding of the techniques used to develop other forms of embedded system, we suggest you start with some Google (or equivalent) searches for ‘bare-metal embedded system’, ‘RTOS guide’, and ’embedded Linux’.

empty_space


empty_space

1. Learn how to program in C for a “desktop” computer

C in a nutshell cover

Let’s start at the beginning.

Before you can start to develop software for embedded systems, you need to learn how to program.

While it is not impossible to begin programming using an embedded board, most people find it much easier to learn how to program on a desktop computer before they start to deal with the complexities of cross-compilation, debugging over a JTAG link, etc.

We therefore recommend that you learn how to program a desktop computer, in C, before you start trying to program an embedded processor.

To explain why we recommend learning C, we make the following observations:

  • Computers (such as microcontroller, microprocessor or DSP chips) only accept instructions in “machine code” (“object code”).
  • Machine code is, by definition, in the language of the computer, rather than that of the programmer. Interpretation of the code by the programmer is difficult and error prone.
  • All software, whether in assembly, C, C++, Java or Ada must ultimately be translated into machine code in order to be executed by the computer.
  • There is no point in creating ‘perfect’ source code, if we then make use of a poor translator program (such as an assembler or compiler) and thereby generate executable code that does not operate as we intended.
  • When compared to “desktop” processors, embedded processors tend to have limited processor power and very limited memory available: the language used must be efficient.
  • To program embedded systems, we need low-level access to the hardware: this means, at least, being able to read from and write to particular memory locations (using ‘pointers’ or an equivalent mechanism).

Of course, not all of the issues involved in language selection are purely technical:

  • No software company remains in business for very long if it generates new code, from scratch, for every project. The language used must support the creation of flexible libraries, making it easy to re-use (well-tested) code components in a range of projects. It must also be possible to adapt complete code systems to work with a new or updated processor with minimal difficulty.
  • Staff members change and existing personnel have limited memory spans. At the same time, systems evolve and processors are updated. Many embedded systems have a long lifespan. During this time, their code will often have to be maintained. Good code must therefore be easy to understand now, and in five years time (and not just by those who first wrote it).
  • The language chosen should be in common use. This will ensure that you can continue to recruit experienced developers who have knowledge of the language. It will also mean that your existing developers will have access to sources of information (such as books, training courses, WWW sites) which give examples of good design and programming practice.

Even this short list immediately raises the paradox of programming language selection. From one point of view, only machine code is safe, since every other language involves a translator, and any code you create is only as safe as the code written by the manufacturers of the translator. On the other hand, real code needs to be maintained and re-used in new projects, possibly on different hardware: few people would argue that machine code is easy to understand, debug or to port.

Inevitably, therefore, we need to make compromises; there is no perfect solution. All we can really say is that we require a language that is efficient, high-level, gives low-level access to hardware, and is well defined. In addition – of course – the language must be available for the platforms we wish to use. Against all of these points, C scores well.

We can summarise C’s features as follows:

  • It is a ‘mid-level’ language, with ‘high-level’ features (such as support for functions and modules), and ‘low-level’ features (such as good access to hardware via pointers);
  • It is very efficient;
  • It is popular and well understood;
  • Even desktop developers who have used only Java or C++ can soon understand C syntax;
  • Good, well-proven compilers are available for every embedded processor (8-bit to 32-bit or more);
  • Experienced staff are available;
  • Books, training courses, code samples and WWW sites discussing the use of the language are all widely available.

Overall, C’s strengths for embedded system development greatly outweigh its weakness. It may not be an ideal language for developing embedded systems, but is unlikely that a perfect language will ever be created.

empty_space

“Can you recommend a book on ‘desktop C’?”

empty_space

We’ve found “C in a Nutshell” by Peter Prinz and Tony Crawford to be a useful guide to “desktop C”.

empty_space


empty_space

2. Learn the basics of “embedded C”

empty_space

embedded_c_cover_border

When you are familiar with desktop C, we suggest that you begin to explore embedded systems using a simple processor. For example, the 8051 microcontroller is a popular “starter” processor which is still used in many “real” systems.

If you decide to start with the 8051 microcontroller, “Embedded C” provides a gentle introduction to the programming of embedded systems (using 8051 microcontrollers).

Please note that Embedded C is a self-contained “teach yourself” program: the package includes both a compiler and processor simulator (on CD), which means that you can run all of the examples in the book (and learn a great deal about the programming of embedded systems in C) without buying — or building — any hardware.

Further information is available.

empty_space

Code examples from “Embedded C”

empty_space
Copies of the code examples from Embedded C are available for download here (zip file).

empty_space

Course notes for “Embedded C”

empty_space

A set of course notes based on “Embedded C” are available here.

These notes are intended for use in a 10-week introductory module on embedded systems.

empty_space

empty_space

Teaching slides for “Embedded C”

empty_space

If you wish to use “Embedded C” in a university or college course, a complete set of Powerpoint slides (10 files, zipped) is available. These would be suitable for use in an introductory course on embedded systems. These files were created by Dr. Jimmy To, a faculty member at the Hong Kong Polytechnic University.

empty_space


empty_space

3. Download and read ‘PTTES’

empty_space

PTTES cover

Building on the foundations presented in “Embedded C”, “Patterns for Time-Triggered Embedded Systems” is a 1000-page book which illustrates how you can create a range of reliable embedded systems.

In total, PTTES contains details of more than 70 useful “design patterns”, complete with guidelines to help you apply these techniques in your own projects: full source code for all of the patterns is also included.

Following an agreement with the original publishers and the author, PTTES is now distributed by SafeTTy Systems Ltd.

You can now download the complete book and code examples from our PTTES page.

empty_space


empty_space

4. View some of our training videos on YouTube®

empty_space

You can view a series of four lectures (in total around 7 hours of training) from our TTa training course via our YouTube® channel.

empty_space

Session 1: An introduction to “Embedded C”

empty_space
The material in Session 1 provides a foundation for the remainder of the course. We discuss what is meant by the phrases “embedded system” and “deeply embedded system”. We discuss the history of current embedded processors. We introduce the 8051 microcontroller (our hardware target in Session 1 and Session 2). We explain why ‘C’ is the programming language used to develop most embedded systems. We talk about the differences between developing code for “desktop” and “embedded” processors, including key differences in the software architectures used. We discuss task-oriented software engineering. We consider what is meant by real-time embedded systems. We discuss the creation of loop delays and contrast these with hardware delays. We discuss “sandwich” delays. We discuss the need for (and implementation of) timeout mechanisms. We introduce the concept of “balanced code”.

empty_space
empty_space

Session 2: Real-time “Embedded C”

empty_space
In Session 2, we explore real-time constraints in more detail. We consider and discuss concepts such as worst-case execution time (WCET), best-case execution time (BCET), task jitter and CPU loading. We look at interrupt handling and interrupt response time. We introduce time-triggered (TT) system architectures. We introduce – and explore the operation of – a first simple “TT embedded operating system”. We look at the concept of system state and explore ways of implementing state-transition diagrams (“statecharts”).

empty_space
empty_space

Session 3: Working with modern hardware platforms

empty_space
In the first two sessions on this course, we focus on software development, and we work with a simple processor (8051) simulator to test the resulting code. In Session 3, we move into the 21st century. We begin by considering a modern (32-bit) ARM® microcontroller and provide an introduction to some of the challenges and opportunities offered by this new platform. We then discuss key debugging techniques (including the use of JTAG) and the issue of timing analysis. To ensure that your skills are transferrable, we consider other hardware targets, starting with a “Field Programmable Gate Array” (FPGA) platform. FPGAs are already a popular implementation platform for developers of embedded systems (and some people believe that they will be the platform of choice for the majority of new systems within the next few years). We consider “soft” processor running on FPGAs. We also consider x86 (“embedded PC”) hardware. Finally, we introduce a more advanced TT software architecture that can be employed with any of these platforms.

empty_space

empty_space

Session 4: Multi-tasking systems

empty_space
In Session 4, we explore some of the challenges involved in designing and implementing systems in which more than one task must run simultaneously. We look first at ways in which we can approximate multi-tasking systems using a single CPU and a real-time operating system (RTOS) which supports task pre-emption. Our coverage includes a discussion about the challenges of priority inversion (PI), and consideration of some practical solutions to PI problems through the use of “time triggered hybrid” (TTH) and similar system architectures. We then move on to consider some of the challenges involved in creating distributed embedded systems: that is, systems involving multiple processors connected in some form of network using (for example) a bus or star topology. We consider key design issues, including ways in which we can synchronise the timing of tasks that are running on different nodes. Our focus is on systems that employ the popular Controller Area Network (CAN) protocol.

empty_space
empty_space

You can find further information about course TTa here.

empty_space


empty_space

5. Download a complete set of course notes to match the TTa training videos

empty_space

Course TTa is concerned with the design and implementation of reliable embedded systems using the “C” programming language.

You can download a copy of the TTa course notes (PDF file) to go with the training videos.

The TTa course notes are 232 pages long. They consist of copies of all of the Powerpoint® slides from the four seminars in the course.

Some additional information about the course is also included, along with detailed suggestions for further reading.

You can download a copy of the course notes here.

You can find out more about the related SafeTTy Certified™ programme here.

empty_space


empty_space

6. Learn a little more about time-triggered architectures

empty_space

If you want to create reliable embedded systems, then it pays to learn a little more about time-triggered software (and system) architectures.

Time-triggered (TT) architectures have been used for many years in industries such as aerospace and defence, because they have been found to provide significant benefits (including high system reliability and greatly reduced testing costs). Until recently, use of TT architectures has been less common outside these sectors — but this situation is now changing rapidly, as developers in many different organisations experience the benefits of a time-triggered solution.

We provide an introduction to TT architectures on this page, and make some suggestions for ways in which you can determine whether a TT approach may offer benefits for your own organisation.


empty_space

7. Download and read ‘ERES1’ (PDF)


If you are interested in the development of safety-related embedded systems, we offer the following books (in PDF form) for free download on our site:

Pont, M.J. (2014) The Engineering of Reliable Embedded Systems, SafeTTy Systems. ISBN: 978-0-9930355-0-0.

    First book in the ‘ERES’ series. Enables developers to create TT software for products that can – where required – meet ‘SIL 2’ (and equivalent) requirements in industrial [IEC 61508], automotive [ISO 26262], aerospace [DO-178C], medical [IEC 62304], houshold [IEC 60730] and related sectors. Code examples target the NXP® LPC1769 MCU.

    Full PDF copies of this book can be downloaded (free of charge) from the ERES page.

empty_space


empty_space

8. Read our “Design Guide for Developers of Reliable Embedded Systems”

Design Guuide logo
Having reached the end of our introductory guide, you are now ready to read our “Design Guide for Developers of Reliable Embedded Systems”.

The material presented in this professional guide has evolved from experience gained in a very wide range of projects over a period of many years, and has been found to be effective. Various organisations have also used the approach described in the guide as the basis of their own set of in-house design guidelines.

Throughout the guide, it is assumed [i] that you are building a safety-related embedded system, and [ii] that your system will be based on a time-triggered (TT) system architecture.

You will find the guide here.