Firmware Description

Due to the precise and stringent timing requirements, and the hard real-time nature of the application, the firmware design for the two microcontrollers required a particular care and the use of some unconventional programming techniques. Both firmware were written in ANSI C language, so easing and accelerating the development and debug process, but the most time critical routines were written in assembly language. The GCC tool chain was used for both firmware develop-ments. A more detailed description of the firmware structure and operation is provided in the following paragraphs.

12.4.1 AVR Firmware

The AVR firmware tasks and structure are shown in Fig.12.3. The firmware was designed trying to exploit the AVR core features. In particular, the absence of an instruction pipeline avoid jump penalties, so the use of conditional operations is convenient; interrupt latencies are very small, so interrupt can be used without significantly perturbing the main tasks; registers and port operation timings are deterministic and very fast (requiring only 1 or 2 clock cycles), allowing fast internal data movement and efficient external bit banging operations, useful for interface handling, especially when coupled with read-modify-writing or bit instructions. At system boot, after the preliminary peripheral configuration, the CompactFlash card is initialised and checked. If it is correctly inserted and ready, the stored system configuration is read, decoded and actuated by sending acqui-sition parameters to the ARM. Then the data write loop is entered, accomplishing the task of reading data from the FIFO and writing them to the CompactFlash. In order to satisfy the main constraint of a continuous writing throughput greater than the acquisition one, this routine was optimised and coded in assembly language

178 G. Fertitta et al.

and the fastest strategy for driving the CompactFlash was used. Speeding up memory write operations is not an easy and obvious task, in fact there are two main delays imposed by the CompactFlash: one at the reception of the command block and the other while executing the command once all arguments (data) have been transferred.

CompactFlash employs ATA block command set [14] and this requires to send an 8 byte block for each write command, hence in order to minimise these delays either command number has to be minimised, or argument dimension (data) have to be maximized for each command.

Since the standard command set allows different possibilities to perform write operations and cards of different brands may implement a different command subset or may handle in a different way standard commands, a number of commands and command combinations were tested. In particular the following tests were

Fig. 12.3 Flow chart of the AVR firmware

12 An Embedded Datalogger with a Fast Acquisition Rate 179

performed: ‘‘Write Sector(s)’’ command with one sector only, ‘‘Write Sector(s)’’

command with up to 256 sectors, ‘‘Write Multiple Sectors’’, ‘‘Write Sector(s) w/o Erase’’ with and without pre-formatting. Different card models or brands gave slightly different results, but for most of the tested cards best performances were obtained by using the ‘‘Write Sector(s)’’ command with 256 sectors. This allowed to write blocks of 2569512 bytes for each command sent. The assembly coded routine achieved a raw data throughput of more than 4 MB/s, this allowed to tolerate card delays and latencies, and to prevent the FIFO to overflow. Data were sequen-tially stored in the card, as they were read from the FIFO. Session information such as channels configuration, acquisition rate, start sector, length, etc. were also updated at the end of the recording session in a specific area used as a directory. More recording sessions then are possible in the same CompactFlash card. In the imple-mented version no explicit file system was used, either for efficiency reasons, either for the limits of the most common file systems in handling very large files (in FAT32 for example maximum file length is 4 GB) [15]. The data write was handled by the firmware main loop while external events such as triggers, CAN data reception and decoding has been handled instead by a small interrupt service routine. To this purpose a relatively slow timer, with a period of about 1 ms, controlled the firmware operation by setting some global flags. The interrupt provided reception and transmission of CAN frames, starting and stopping the acquisition if programmed conditions are met (triggers, CAN messages or pushbutton).

12.4.2 ARM Firmware

The ARM7TDMI has radically different characteristics compared to the AVR core; in particular it features an instruction pipeline, long interrupt delays and quite long access times for memory or peripheral. Moreover the execution of code from internal flash memory is slower than the execution from RAM. These facts make

Fig. 12.4 Operation timings in case of FIFO full event

180 G. Fertitta et al.

Fig. 12.5 Flowchart of ARM firmware

12 An Embedded Datalogger with a Fast Acquisition Rate 181

the use of branches and conditional statements, as well as interrupts very ineffi-cient. The datalogger acquisition parameters are highly configurable, in fact each channel can be selected or not, configured as single-ended, pseudo-differential or differential, and in these last cases it can be coupled with another channel; hence an high number of conditional statements would be needed in each acquisition scan. All these conditions would introduce a considerable delay and would make impossible to meet the acquisition rate constraints of 1 Msps. Since the configu-ration is decided at start-up only and never changes after, the optimal solution in terms of computational efficiency would be to store in the flash a specific code segment, without any branch, for each possible channels configuration. This solution however would produce a very large code. For this reason a quite unconventional programming technique was used: the main acquisition routine (scan loop) code is generated on the fly at start-up according to the acquisition configuration received from the AVR. This is implemented by storing in the microcontroller code memory (flash) a set of code fragments implementing all the required elementary operations. These fragments are selected and assembled in the internal RAM according the received configuration so to form the main scan routine (see Fig.12.5b). In this case the routine only contains the exact sequence of operations needed for the specified configuration, without any jump due to conditional instructions. This code is executed from RAM and used to serve the ARM fast interrupt (FIQ, Fig.12.5c), triggered by a timer programmed according to the desired acquisition rate. The routine basically sets the next analog channel, starts A/D conversions, reads the converted data, formats and writes them to the FIFO. If the FIFO is found to be full (this condition is unlikely, but may happen if the CompactFlash card used is particularly slow) the acquisition is temporarily suspended as shown in Fig.12.4.

The other interrupt service routine is used to handle the UART messages from the AVR. Even if this routine may perturb the acquisition timings due to its high latency, it is called when the AVR sends messages to the ARM, that is at boot time or on start or stop conditions only.