Controller Board System Allows For Easy Evaluation Of General-Purpose Converters

A critical task when designing a system using an analog-to-digital converter is the actual choice of the converter to be used. Constraints such as power, price, and size­ along with system requirements of resolution and performance parameters will narrow the choice. However, the designer may still be left with a number of converters which at first glance will perform in the application. One option is to simply to choose a converter based on data-sheet information; but the prudent engineer will actually want to see how the part performs under the conditions required by the application. At issue, though, is how to spend as little time as possible on the evaluation, since much of it will be spent evaluating converters that will be eliminated from consideration.

Evaluating converters is not an easy task. Hardware design work and careful PCB layout are required to allow the part to achieve its specified analog performance. Even if the hardware problem is solved by use of a standard evaluation board, software routines will be required to control the part and read back the data. In today’s diverse market, the wide variety of available converters, especially those from different manufacturers, are housed in proprietary pinouts and generally require different software routines for control and access.

Given this background, any tools that enable the designer to evaluate the converter more easily are welcome. Such tools speed up the process of selecting the converter by saving the designer the time and effort needed to develop a system just to evaluate the part. Besides having the converter chosen more quickly and easily, the design process should be further speeded up with a quick and easy means of testing the part in the application. To be useful, the test system should effectively be self-contained, run on a platform readily available to the designer, and fulfill two distinct functions: provide a quick means of demonstrating the performance of the converter, and provide a development platform for evaluation of the converter in the user’s application.

Those were the design goals for an evaluation system for medium- and high-speed general purpose analog-to-digital converters, using a standard PC as the platform for evaluating the devices. The PC has two ports for external communications­ a serial RS-232 port and a parallel printer port. Because neither port can operate at the speeds required to run an ADC at throughput rates in excess of 10,000s of samples per second, direct connection between the PC and the ADC is not possible if the ADC is to be operated at specified throughput rates.

Thus, to facilitate controlling the ADC and running it at specified speeds, additional processing power is required external to the PC. A memory buffer area is also required to store the data, gathered at the higher throughput rates, before it is uploaded to the PC at the lower rates compatible with its porting speed. One approach is to build evaluation boards with processing power and memory. But this has the disadvantage of requiring a processor on every evaluation board; and the evaluation board becomes less flexible for use as a development board.

The approach adopted by ADI’s General-Purpose-Converter Applications Group in Limerick was to simplify the evaluation boards and move the memory, processing power and PC communications to a separate controller board. This controller board, labeled EVAL-CONTROL BOARD, provides the link between the RS-232 port of the PC and the evaluation board for the device of interest. It provides a means of controlling a converter’s (daughter) board and operating a converter at its maximum throughput rate, while demonstrating the results on a PC. The Eval-Control Board is capable of being used with a suite of daughter evaluation boards, each geared to the specific needs of a particular converter or family. The user buys one Eval-Control Board and can connect daughter evaluation boards to this controller board via a standard 96-lead connector. The system configuration is shown in Figure 1.

All daughter evaluation boards that are compatible with the Eval-Control Board have designations that end with the letters CB. To date, there are 10 daughter ADC evaluation boards available for use with the controller board; their performance range is from the 12-bit, 600-ksps AD7892 to the 16-bit 200-ksps AD976A.*

In keeping with the requirement that the setup be self-contained, a standard 12-V ac transformer with 1-A current capacity is available to power the system. From it, the Eval-Control Board then generates all the power required for itself and the daughter board (Figure 2). The board’s functions are based on an Analog Devices ADSP-2111 digital signal processor (DSP). The ADSP-2111 features two high-speed serial links, a 2K x 24 internal program-memory RAM and a 1K x 16 internal data-memory RAM. The processor controls the sampling rate and the data acquisition from the evaluation board. For serial interfaces, it is capable of taking data at a bit rate of 8 MHz; for parallel interfaces, it has a word rate of 3.2 MHz.

Communication between the Eval-Control Board and the PC is controlled by an 8051 microcontroller. The UART port on the 8051 connects to the COM-1 serial port of the PC, and information is transferred via a standard RS-232 cable. The 8051 is connected to the host interface port (HIP) of the ADSP-2111. The software for the appropriate daughter evaluation board is downloaded to the ADSP-2111 via the 8051. Similarly, when the ADSP-2111 has acquired and processed the data samples, they are transferred back to the PC for analysis via the 8051. The Eval-Control Board’s 8K x 16 bit RAM allows as many as 4000 samples to be stored before they are transferred up to the PC for processing. It also includes a 14-bit single-chip DAC and ADC (AD7869). Thus it can acquire analog data, and generate analog output signals if the user so wishes.

The evaluation software, which runs under DOS 4.0 or higher, allows the user to control the operation of the daughter board, which contains the device under test. The samples are gathered at rates up to the maximum throughput rate of the converter, and then uploaded to the PC for display and analysis. The front-end PC software has a number of screen displays; examples of these are shown in Figure 3.

The software runs with a series of function keys, hot keys and on-screen buttons. With it, the user can select sample rate, number of samples to be taken, analog input range, mode of operation and control of on-chip registers. The software can also perform a window function on the captured data, carry out a fast Fourier transform (FFT), compute signal-to-noise ratio, and display the results. It can also display the spread of codes for a dc input and compute the mean and standard deviation of the distribution. The software allows the captured data to be stored to a file, from which it can be exported for processing by other software packages. Data can be taken from a file (rather then captured from the evaluation board) and processed off line.

The Eval-Control Board thus fulfills its requirement of demonstrating nominal performance using the complete set of software routines for the above functions. Once the designer has moved to the evaluation phase, these routines can be adapted to evaluate the device under application-specific conditions. Here the Eval-Control Board can operate as a true development platform. To adapt and develop the software for this purpose, it is first necessary to understand how the software for the Eval-Control Board works.

Software

The software comes in two main parts. The first, written in C code, runs on the PC; the second is the DSP code­ it runs on the evaluation control board and is based on the ADSP-21xx code. We consider here as an example a 12-bit ADC with a parallel data bus. Before examining the 21xx code, one should understand what happens when the user selects commands from the PC software.

Each daughter evaluation board requires its own software routines; they are stored on the PC and downloaded to the Eval-Control Board whenever that specific evaluation board is to be used. The board-specific software files are called host-interface-port (HIP) files. When the user selects the program to be loaded, the HIP file for that program is loaded to the Eval-Control Board over the serial port of the PC. After a program has been loaded, the DSP program causes it to wait until it gets a command before doing any further operations. When the user selects an operation from the PC, a four-byte code is sent to the DSP via the serial port. The code is pre- and post-formatted with an “S” and “E” character respectively. These allow the software to interpret what function is required to be carried out (e.g., take samples, write to a register etc.) When a command is sent to the Eval-Control Board the “S” and “ E” bytes are stripped by the microcontroller and the 4 bytes are loaded into data memory (DM) addresses 0x3FE1, 0x3FE2, 0x3FE3 and 0x3FE4, as diagrammed here.

The microcontroller also writes a value of 0x03 to adö3ess 0x3FE0 to indicate that data has been received. These addresses are called the HIP registers. There is also a HIP status register at address 0x3FE6. This register is checked to see if any new data has been written to the HIP registers, by either the DSP or the PC. The four-byte code sent to the DSP can be seen if the command line option -e+ is added to the program name running on the PC. For instance, if the program being used is AD7892.EXE, the command line is AD7892.EXE -e+.

The first step in writing code for an application is to write all the initial setup routines for the DSP­ the interrupt vector addresses, the serial port configurations and initialization of any flags that may be needed. (That part of the code, which depends on the specific application, will not be shown in this article.) Once the DSP has been set up, the program should wait for commands to be sent to it from the user. This is done using the Wait_Confirm subroutine as shown below and ALU input registers AX0 and AY1. AR is the ALU output register.

wait_confirm:
AX0=DM(0x3fe6); {load HIP status register into AX0}
AY1=0x0001; {load AY1 to check HIP against register 1}
AR=AX0 AND AY1; {Has anything been written?}
IF EQ JUMP wait_confirm; {If not then repeat the loop}
RTS; {return when the commands are received}

This routine simply monitors the HSR6, HIP Status Register (0x3FE6) and doesn’t return until the LSB of the register is a 1, indicating that something has been written to the HDR1 register. This diagram identifies the contents of the four data bytes:

Once the data is received, the timer register can be loaded. The manipulation of the data to rebuild the 2 bytes into one 16 bit word (by shifting the high byte 8 bits left and combining), and store it in data memory, is shown here:

AX0=DM(0X3fe2); SI=AX0; SE=8; SR=LSHIFT SI(LO);
AX0=DM(0X3fe3); AY1=0X00ff; AR=AX0 AND AY1;
AX0=AR; AY1=SR0; AR=AX0 OR AY1;
AY0=AR;AR=AY0-1;
DM(Tcount_Reg)=AR; DM(Tperiod_Reg)=AR;

Finally, the address of the parallel port (in this case the edge connector), and the start address of the memory location where the data is to be put, need to be set up. This is done using the ADSP-2111’s pair of data-address generators (DAGs). DAGs consist of three registers, identified as I (Base/index address of the memory block), M (incremental step to next location), and the L (the length of the memory block; The L block is required for return to start of a loop involving a circular buffer; in this example it will be set to zero). The code looks like this.

I0=0; M0=1; L0=0; {address of memory locations for data}
I1=0x2000; M1=0; L1=0; {address of parallel port }

A loop can now be set up which will read in a data sample every time an interrupt occurs. Since reading samples takes but a fraction of the time of the whole operation (i.e., reading and uploading the data) it is possible to fill the memory with data and only select a portion to upload.

AY1=1; AR=8191; {set sample increment and number of samples req’d}
MSTAT=0x20; IMASK=0x01; {start the timer and unmask the interrupt}
luup: IDLE; {wait for the interrupt to occur}
luup1: AR=AR ­ AY1; {decrease the count}
IF NE JUMP luup; {repeat until finished}

In this example the code is simplified to use only the timer interrupt. This can be done by waiting for the timer, starting from a preset time, to expire­ thus causing an interrupt. Data can then be read from the data bus and, after a short delay (if required), start the next conversion. The code below shows how the timer interrupt vector address should look when it appears in the vector table. The interrupt service routine is also shown.

timer_int: jump ISR;RTI;RTI;RTI; {interrupt vector}
ISR: AX0=DM(I1,M1); {read data}
DM(I0,M0)=AX0; {Write to memory}
RESET FL0; SET FL0; {Convst}
RTI;

When using this technique the first data value to be returned must be ignored, because it will have been read in before the conversions were started; hence it is not valid. Once all the data has been read in, it is time to upload the data to the PC. After turning off the interrupts and resetting the DAGs controlling the data memory, one can check to determine how many samples are required to be uploaded, using this code:

The data from the 12-bit ADC should be sign-extended to fit the 16-bit-wide data registers. This can be done by examining the data and, if the MSB is a 1, OR the data with 0xF000 to set the highest 4 bits to 1 as shown here.

The data is now properly formatted and can be transferred to the PC via the host interface port. This is done by calling the OUT_HIP routine as part of a loop:

Once the required number of samples has been sent to the PC, the program should return to the start of the main loop and wait for further instructions.

The last few routines are the standard set; they will rarely need to be changed when modifying the Eval-Control Board’s DSP code to meet application-specific conditions. All the routines shown above have been used in the HIP files that control the various evaluation (daughter) boards that interface to the PC via the Eval-Control Board. They are shown here to give an indication of how existing programs are modified for additional functionality.

Authors

Mike Byrne

Ken Kavanagh

Ken Kavanagh is an applications engineer in ADI's Precision DAC Group. Currently responsible for providing application support for the nanoDAC® and denseDAC® portfolios, Ken has worked in applications since 1994. He earned a BEng from the University of Limerick in 1999.