Deriving real-time performance from a non-real-time system

Deriving real-time performance from a non-real-time system

Before this can be tackled, the first step is to quantify the real-time performance that is needed and from that determine the level of processing power needed. Real-time means guaranteeing that work will be completed within a certain time period. That time period could be seconds or minutes but as long as the work requested is completed within a given time period, the system is a real-time one. The key time critical function is sampling the data. The time frame for processing this is determined by the interval between the samples which in turn depends on the sampling rate. This in turn also determines the minimum processing needed to perform these tasks.

The display software imposes several constraints: its maxi-mum sampling rate is 30Hz and the data file should be less than 350 kbytes in size. Each sample contains 8 bytes and each second generates 240 bytes of data. This means that a 350 kbytes file would contain about 1493 seconds or over 24 minutes of data. This is more than enough as the longest sessions that the car experiences are about 15—24 minutes. It was decided to not limit the sampling data and if longer periods were needed, the sampling rate would be reduced or the resulting data file sub-sampled to reduce its size at the expense of timing resolution. The serial data link is fixed at 19.2 kbaud. As a rough rule of thumb, dividing the baud rate by 10 gives the maximum number of bytes that can be transferred. This works out at just under 2 kbytes per second. This is eight times the required data rate for the 30 Hz sampling rate. This indicates that the serial link is more than capable of supplying the required data and perhaps more importantly, indicates the level or CPU per-formance needed. A fast 386 or entry level 486 is quite capable of transferring 2 kbytes of data per second over a serial link. Indeed faster rates are often achieved with higher serial link speeds during file transfer. Bearing in mind that all the data logger has to do in real-time is receive some data and store it, then almost any laptop with a higher speed 386 or entry level 486 should be capable of meeting the processing load.

Another way of looking at the same problem is to consider how many instructions the processor can execute between the samples. A 30 MHz 386 with a data sampling rate of 30 Hz can provide 1 MHz of CPU processing per sample. If it takes 10 clocks per instruction (a very conservative figure), that means that 100,000 instructions can be executed between samples. This is several orders of magnitude higher than the number of instructions actually needed to perform the task. Again, this is good informa-tion to help back-up the conclusion that CPU performance was not going to be an issue.

Choosing the hardware

The next task was to choose the hardware that was needed. Always a difficult problem but this turned out to be quite simple. Simple microcontrollers were ruled out because of their limited functionality. They have small amounts of memory that would restrict the amount of data that could be sampled and stored. This constrained both the data sampling rate and the total time that the sampling could take place. In addition, the data had to be trans-ferred to the laptop for display and in addition, writing the display and analysis software would have been a major undertaking.

The next hardware candidate was a single board computer. These have more memory and often have disk drive support so that the data could be transferred using a floppy disk. A serial port could also be used. They have a downside in that they require external power which is not something that is easy to provide cleanly from a car system, let alone a competition car. Then there was the level of software support. This needed to be a quick development because it had to be in place for the start of the car’s testing dates so that its information could be used to set up the car prior to the start of the season.

The next candidate was a laptop PC itself. This seems to be a bit extreme but has several advantages that make it very attrac-tive:

•                                                                         It has a built-in battery independent of the car’s power supplies and systems.

•                                                                         It can be used to immediately display the data as well as storing it on disk or removable media like a PC memory card.

•                                                                         It can be used as the development equipment and thus allow the software to be changed in the pit lane if needed.

•                                                                         There is a wealth of software available.

•                                                                         Low cost. This may sound strange but second-user laptops are inexpensive and the project does not require the latest all-singing all-dancing hardware. A fast 486 or entry-level Pentium is more than capable of meeting the processing needs.

•                                                                         Allows migration to low cost PC-based single board com-puter if needed.

The disadvantage is that they can be a little fragile and the environment inside a competition car can be a little extreme with a lot of physical shocks and jolts. However, this is similar to the treatment that is handed out to a laptop used by a road warrior. My own experience is that laptops are pretty well indestructible providing they are not dropped on to hard surfaces from great height. By placing the unit in a padded jacket, it would probably be fine. The only way to find out would be to try it! If there were problems then a single board PC in an industrial case could be used instead.