A rudimentary software architecture:Super loop

Super loop
Context

● You are developing an embedded application using one or more members of the 8051 family of microcontroller.

● You are designing an appropriate software foundation for your application.

Problem

What is the minimum software environment you need to create an embedded C program?

Background

Solution

One key difference between embedded systems and desktop computer systems is that the vast majority of embedded systems are required to run only one program. This program will start running when the microcontroller is powered up and will stop run- ning when the power is removed.

A software architecture that is frequently used to generate the required behaviour is illustrated in Listings 9.1 to 9.3.

A rudimentary software  architecture-0161

A rudimentary software  architecture-0162

A rudimentary software  architecture-0163

Listings 9.1 to 9.3 illustrate a simple embedded architecture, capable of running a single task (the function X()). After performing some system initialization (through the function Init_System()), the application runs the task ‘X’ repeatedly, until power is removed from the system.

Crucially, the ‘Super Loop’, or ‘endless loop’, is required because we have no operating system to return to: our application will keep looping until the system power is removed.

Hardware resource implications

SUPER LOOP has no significant hardware resource implications. It uses no timers, ports or other facilities. It requires only a few bytes of program code. It is impossible to create, in C, a working environment requiring fewer system resources.

Reliability and safety implications

Applications based on SUPER LOOP can be both reliable and safe, because the overall architecture is very simple and easy to understand and no aspect of the underlying hardware is hidden from the original developer or from the person who subsequently has to maintain the system. If, by contrast, you are programming for Windows or a similarly complex desktop environment (including Linux or Unix), you are not in complete control: if someone else wrote poor code in a library, it may crash your pro- gram. With a ‘super looping’ application, there is nobody else to blame. This can be particularly attractive in safety-related applications.

Please note, however, that just because an application is based on a Super Loop does not mean that it is safe. Indeed, in general, a Super Loop does not provide the facilities needed in an embedded application: in particular, it does not provide a mecha- nism for calling functions at predetermined time intervals. As we discussed in Chapter 1, these are key characteristics of most embedded applications: if you need such facili- ties, a scheduler (see Chapter 13) is almost always a more reliable environment.

Portability

Any ‘C’ compiler intended for embedded applications will compile a Super Loop program: the loop is based entirely on ISO/ANSI ‘C’. The code is therefore inherently portable.

Overall strengths and weaknesses

The main strength of Super Loop systems is their simplicity. This makes them (comparatively) easy to build, debug, test and maintain.

Super Loops are highly efficient: they have minimal hardware resource implications.

Super Loops are highly portable.

If your application requires accurate timing (for example, you need to acquire data precisely every 2 ms), then this framework will not provide the accuracy or flexibility you require.

The basic Super Loop operates at ‘full power’ (normal operating mode) at all times. This may not be necessary in all applications, and can have a dramatic impact on system power consumption. Again, a scheduler can address this problem.

Related patterns and alternative solutions

In most circumstances, a scheduler will be a more appropriate choice: see Chapter 13.

Example: Central-heating controller

Suppose we wish to develop a microcontroller-based control system to be used as part of the central-heating system in a building. The simplest version of this system might consist of a gas-fired boiler (which we wish to control), a sensor (measuring room temperature), a temperature dial (through which the desired temperature is specified) and the control system itself (Figure 9.1).

We assume that the boiler, temperature sensor and temperature dial are connected to the system via appropriate ports. We further assume that the control system is to be implemented in ‘C’.

A rudimentary software  architecture-0164

A rudimentary software  architecture-0165

A rudimentary software  architecture-0166

Leave a comment

Your email address will not be published. Required fields are marked *