Hardware Architecture

The most challenging constraint in designing the datalogger hardware was the quite high data throughput that had to be handled. Considering a maximum aggregate sampling rate of about 1 Msps (100 Ksps per each of the 10 channels), and a 12 bit resolution of converted analog data plus 4 bit of digital data, an overall continuous data stream of 2 MB/s has to be expected. Such a throughput may represent a significant issue for a small real-time embedded system: firstly the CPU has to control and continuously handle the data acquisition process, so a very little and constrained processing time is left for other tasks such as interfacing and data storage; secondly other tasks, namely storage, become very critical since they have to be performed faster than the data acquisition task, otherwise there will be an increasing data accumulation, leading to a final data loss.

12 An Embedded Datalogger with a Fast Acquisition Rate 175

In the sampling phase the CPU has to scan all the selected channels while skipping the unselected ones, properly setting them so to handle single-end and differential channels, and transferring the converted data. Since the aggregate maximum sampling frequency is 1 MHz, this process has to be completed in less than 1ls, so to reserve an adequate spare processor time for other tasks. The proposed system employs a 32 bit ARM7TDMI [7] based microcontroller from Analog Devices endowed with a 12 bit A/D converter operating up to 1 Msps, and 12 multiplexed input channels [8]. All the peripherals (A/D converter, GPIO, timers, etc.) are mapped into the ARM memory space and are connected to the same bus. This solution guarantees an adequate data throughput and processing capability. On the other hand however, even if the CPU is capable of operating at 41.7 MHz, delivering about 41 MIPS, it was not possible to meet all the con-straints due to the interrupt latencies and the large number of clock cycles required to access all the memory mapped registers. As an example, when executing code from RAM, about 20 ARM instructions only can be executed in 1ls, and the interrupt latency can be as long as 24 clock cycles. For this reason a multi-processor architecture was adopted, as showed in Fig.12.2. The second micro-controller was a low cost 8 bit ATMega16 AVR micro from Atmel [9], working at 16 MHz. The AVR microcontroller was chosen for its computational efficiency (about 1 MIPS/MHz), for the very low latency in instruction execution, jump, interrupt and I/O operations. This choice allowed to completely fulfil all the requirements at a very little cost. A special care in designing task partitioning was however required, as explained hereafter. As shown in Fig.12.2 the ARM microcontroller was used to handle the data acquisition process, while the AVR

Fig. 12.2 System architecture of the datalogger

176 G. Fertitta et al.

was used as a master, controlling and coordinating the system operations, handling the interfacing tasks and data storage with the flash card. The two CPUs need to communicate only during boot phase and at the end of each recording section, so only a bi-directional asynchronous serial link was used to this end. High speed data transfer is instead obtained through a double port FIFO memory.

As already mentioned an essential requirement for proper system operations is that the storage throughput is greater than the data acquisition one. This second problem is closely related not only to the processing time available for this task, but also to the storage medium used. At first a 2 MB/s throughput may seem quite reasonable for any of the currently available storage media (see Table12.1), but actually this is not the case. Flash media devices specifications in fact are given only for peak, burst or average data transfers [10–12], if real data write throughput is considered, a substantial worst performance is obtained.

This is due to high flash cards latencies in executing commands, in particular write commands. These delays are usually unpredictable, depending on the spe-cific card brand and integrated flash controller, on the previous memory content and finally on the particular address location and data block size. Even if average delays are quite tolerable (being in the order of 100ls), very long delays, as long as 100 ms, can be occasionally obtained from certain cards. This poses a very important constraint on the choice of the storage media. In order to tolerate these unpredictable delays an asynchronous 16 KB FIFO buffer was used. The FIFO buffer allowed the two CPU to operate in a completely asynchronous and inde-pendent fashion. The acquisition task timings are in fact governed by the pro-grammed acquisition rate, the storage tasks by external events or signals (communication bus, storage card response, pushbutton etc.). FIFO status signals (FIFO full and FIFO empty) provides an automatic handshake for coordinating the two part of the system. The choice on the specific flash media to use was done considering the maximum throughput, the maximum capacity, the availability of open specifications and the availability of industrial grade components. This analysis led to the choice of CompactFlash cards [13]. The card was interfaced using the 8 bit IDE mode, considering that the overall throughput is limited by the above mentioned delays rather than the bus capacity.

At system boot the AVR checks for the flash card, reads the previously stored configuration, decodes it and configures the system, also sending the configuration data containing the selected channels and sample rate to the ARM. The acquisition starts according to the programmed trigger: manual click on the pushbutton,

Table 12.1 Flash media

12 An Embedded Datalogger with a Fast Acquisition Rate 177

external trigger or reception of a specific CAN command. Once the acquisition is started, the ARM keeps scanning and reading the analog and digital channel values and writing data to the FIFO, while the AVR handles data write to the Com-pactFlash memory, check for external events (pushbutton click, command on the CAN bus), and sends a low frequency replica of selected channel data to the CAN bus for external logging or monitoring purposes.

The use of the CAN bus is particularly suited for this application, since it employs a broadcast scheme to transmit packets. By exploiting this feature it is possible to send commands to all the loggers on the bus at the same time, also obtaining an easy synchronization and control method. When a stop condition is verified (stop command, memory full, etc.), the AVR CPU issues a halt to the ARM microcontroller, so stopping the data acquisition.