Choosing the software environment

Real-time without a RTOS

This chapter describes the design and development of a real-time data logger that is used to collate information from various data logging sources in a race car. It brings together many of the topics discussed in previous chapters into a real world project. The project’s goal was to design a real-time data logger. Its function was to fetch data samples from the various systems in the car and store them locally for display once the car has finished competing. The car is fitted with several computer based control systems, including a engine management unit (EMU) and traction control system that would provide a snapshot of the current input data (all four wheel speeds, engine revs and traction control intervention) when prompted. The EMU communicates using a serial port at 19.2 kbaud. The system comes with some basic data logging software that would run on a PC laptop but this was not very reliable at time stamping. The timing would depend on the performance of the laptop that received the data which made ‘before and after’ comparisons very difficult to make. What was needed was an embedded system that could periodically request a data sample and then store it in a format that the standard display software could use. Simple: well, as with most designs, the reality was slightly different.

Choosing the software environment

So where do you start with a project like this? Most design-ers will often start by defining the hardware and then rely on the software to either cope or fit with the hardware selection. This is often adopted because of the so-called flexibility that software offers. It’s only software, it be changed, rewritten, and so on. While there is some truth in this, it should be understood that many software components such as the operating system and compiler cannot be modified and that it can be as fixed as hardware. In practice, these decisions have to be taken in conjunction and the design based on a system approach that takes into account both hardware and software issues. However, you have to start some-where and in this case, the software environment was given the highest priority.

The first question to be answered was that of which operat-ing system. In practice there were three candidates: a real-time operating system of some kind, MS-DOS or Windows. The design was definitely a real-time one with a deadline to meet to maintain the correct sampling. It probably needed to provide access to the hardware directly due to the slightly different use that the parallel ports in particular were going to be put to. It also needed to be simple and stable. For most engineers, the immediate reaction would be to use a real-time OS. The challenge here is that these are expensive (compared to a copy of MS-DOS or Windows) and it would be difficult to use the target system directly for the devel-opment. MS-DOS was easily available and permitted easy access to hardware and could be both the target and development environment. Windows was ruled out because of its size, lack of direct hardware access and its complexity. A data logger did not need to display different backgrounds for a start. In addition, Windows does impose a huge overhead on the hardware re-sources which again was not attractive.

The decision was taken to use MS-DOS. The Borland C compiler for MS-DOS can be downloaded from Borland’s website free of charge and is a fast compact compiler. It might be old but it is more than adequate for the job. This complemented the idea of using the laptop target system for both the actual implementa-tion as well as the final target. The compiler also provides exten-sive library support for low-level direct access to hardware and BIOS routines. These would provide a rich source of function with which to control the data logging without the need for assembler programs.

Does this decision mean that MS-DOS is a real-time operat-ing system? Well it all depends. It is possible to design real-time systems without the need for a real-time operating system, pro-viding the system designer understands the constraints imposed on the design when doing this. With MS-DOS, this invariably means a single thread of execution with a single task running and performing all the work. This may have procedure calls and so on and be a structured modular program but there is only one thread of execution running. If the design required multiple threads then this can be difficult in MS-DOS as it does not support this function-ality. This doesn’t mean it cannot be done but it requires the ‘multitasking’ to be embedded into the single task. In effect the multitasking support is taken out of the operating system and built into the program. This can quickly get very complex and cumbersome to write and maintain and this is where the true multitasking operating system can come to the fore. As soon as this step is taken, there is usually an increased need for a real-time operating system. Windows is multitasking but it is not real-time. It can do real-time work providing the rest of the software running in the system co-operates and shares processing time with the other tasks and threads running in the system. If this co-operation is not maintained, the system can appear to hang up because another that is not co-operating and hogging the CPU blocks the waiting task that needs to meet a deadline. The operating system is powerless in this situation to do anything about this. With a real-time operating system, the waiting task can pre-empt the hogging task if it has a high enough priority.

Given that MS-DOS was to be used, how were the real-time aspects of the design to be implemented, such as the data sampling scheduling and perhaps more importantly, how the system would respond when no data was received? This would be the next set of design decisions to be made.