Sampling the data- Real-time without a RTOS

Sampling the data

The data is requested and received via a serial port that connects the PC to the engine management unit (EMU) in the car. The EMU collates the wheel speeds, current engine revs and other information and outputs this as a series of bytes with each byte representing the current value for the parameter. This value is subsequently multiplied by a factor to derive the actual value that is shown by the display software. These factors are provided within the header of the file that contains the data. This topic will be returned to later in this chapter.

When a sample is needed, a request character is sent and by return, the data sample is sent back. The EMU does not use any handshaking and will send the data sample as fast as the serial port will allow it – essentially as fast as the baud rate will let it. This poses yet another interesting challenge as the PC system must be configured so that none of this data is lost or mixed up. If this happens, the values can go out of sequence and because the position signifies which parameter the byte represents, the data can easily be corrupted. Again this is a topic that will be returned to later on as this problem was to appear in field trials for a different reason.

The first design decision is over whether to use an interrupt-based approach or poll the serial port to get the data. The data arrives in a regularly defined and constant packet size and so there is no need to continually poll the port. Once the request has been sent, the software need only poll or process an interrupt six times to receive the six bytes of data. On initial inspection, there is little to choose between the two approaches: the interrupt method requires some low level code to intercept the associated interrupt and redirect it to the new service routine. Polling relies on being able to process each character fast enough that it is always ready for the next character. For a fast processor this is not a problem but for a slower one it could well be and this takes the design back to being system dependent. The modern serial ports are designed to run at very fast baud rates e.g. 115000 kbaud and to do this have FIFO buffers built into them. These FIFOs can be exploited by a polling design in that they take away some of the tight timing. The buffers enable the serial port to accept and store the incoming data as fast as it is sent but do not rely on the polling software to run at the same speed. Providing the polling software can empty the FIFO so that it never overflows, there is no problem. By designing the software so that the polling software always retrieves its six bytes of data before issuing a new request, the system can ensure that this overflow does not take place. With the large 8 to 16 byte FIFOs being used today, they can actually buffer multiple samples before a problem is encountered. With the polling software easier to write and debug, this was the method chosen.