The migration of technology to the digital world has increased the types of digital applications. Digital I/O applications include monitoring and control applications, video testing, chip verification, and pattern recognition. Just as there are many types of digital I/O applications, there are many different types of digital I/O data acquisition devices that can be used.
The type of digital I/O device required for your application will depend on how data needs to be transferred between the DAQ device and the external (peripheral) device. Data transfers can be broken into two main categories -- static (nonlatched) and block (latched) transfers. Latched data transfers can be further subdivided into two categories -- two-way handshaking and pattern generation. Two-way handshaking can also be broken into two subcategories -- synchronous and asynchronous. This application note explains these transfer modes in some detail.
Figure 1. Digital I/O Applications
2. Static I/O
Static data transfers, also called unstrobed or nonlatched, do not require status and control signals, in a way very similar to single point analog input or output. Because no hardware timing is employed, transfer speeds are completely software/computer dependent. As a result, nonlatched I/O is normally used for low-speed applications, such as monitoring and controlling alarms, motors, and enunciators. All National Instruments DAQ devices with digital I/O lines are capable of performing nonlatched data transfers.
The most common digital I/O interface chip used is the 8255 programmable peripheral Interface (PPI). This PPI has three 8-bit digital ports (A, B, and C). When you configure a port that is part of an 8255 PPI, the 8255 PPI goes through a configuration phase, where all the ports within the same PPI chip get reset to logic low, regardless of the data direction. The data direction on other ports, however, is maintained. The Lab/1200 Family, DIO-24/96, and MIO-16D devices all use the 8255 PPI. Each line in a port on an 8255 PPI has to be configured for the same direction; that is, all the lines in Port A have to be configured for either input or output.
Port C on the 8255 can be configured as two 4-bit (nibble) ports, but this functionality is not accessible through the NI-DAQ driver software. The registers on the 8255 must be accessed directly to implement this feature of the 8255 PPI. See the Appendix for more information.
Devices that use the DAQ-STC chip (most E Series devices) can perform only static (unstrobed) digital I/O operations. With the DAQ-STC chip you can configure each line in a digital port for any input/output direction combination. You can also read/write to any line in a port without affecting the data on any other lines in that port.
Some DAQ devices, such as the 6533 Family, support a wired-OR output mode. When configured for a wired-OR output mode, the output pin is driven to 0 V for logic low, but floats (tri-states) for logic high. Therefore, a wired-OR output driver requires a pull-up resistor to pull the pin to +5 V for logic high. A wired-OR driver has the following advantages over a standard driver:
- You can connect two or more wired-OR outputs together without damaging the drivers.
- You can connect wired-OR outputs to open-collector drivers, to GND signals, or to switches connecting to GND signals, without damaging the drivers.
- You can use wired-OR outputs bidirectionally. For example, after connecting wired-OR outputs together, you can read back the value of one of the pins to determine whether any of the connected outputs is logic low.
3. Block I/O
With block I/O operations, also called strobed or latched I/O, control lines are used to dictate when data transfers occur. These control lines are also digital (TTL) signals. Latched data transfers can fall into two main categories -- pattern generation and full, two-way, handshaking transfer. In two-way handshaking, each device involved in the data transfer controls at least one status line that it uses to inform the other device when it is ready for a data transfer. Digital applications sometimes require transferring data at a predetermined frequency without control lines, either in parallel or serially. Such parallel transfers are referred to as pattern generation.
4. Low-Speed Two-Way Handshaking
For this application note, low-speed data transfers relate to data that is transferred at a rate less than 1 million samples per second (1 MS/s).
This is the most common handshaking protocol. Common applications include interfacing to parallel digital I/O peripherals such as BCD-compatible panel meters and communication/control of test equipment. All Lab/1200 Family, DIO-24/96, and MIO-16D boards use an 8255 or 82C55 PPI. In this application note 8255 and 82C55 PPIs will be referred to simply as 8255. Although the 6533 Family can emulate the 8255 protocol, the following discussion relates to the actual 8255 handshaking and not to the 8255 emulation mode of the 6533. Each 8255 chip contains three 8-bit ports (PA, PB, and PC). When the 8255 is configured for a handshaking operation, lines in Port C are used to control the data transfer operation.
8255 -- Mode 1, Strobed Input
Figure 2. Timing Specification for Mode 1 Input
There are two control lines used in the strobed input operation -- STB* and IBF. The STB* line is an input line that is controlled by the peripheral device that is handshaking with the 8255. The IBF is an output line that is controlled by the 8255.
A low signal in the STB* line causes the 8255 to load data into the input latch. The 8255 outputs a high signal on the IBF line to indicate that data has been loaded into the input latch. When the IBF lines goes back to low, the peripheral device can then place a low signal on the STB* line to load new data into the input latch of the 8255.
8255 -- Mode 1, Strobed Output
Figure 3. Timing Specification for Mode 1 Ouput
The two control lines that are used in strobed output operations are ACK* and OBF*. The ACK* line is an input controlled by the peripheral device that is handshaking with the 8255. The OBF* is an output line controlled by the 8255. The 8255 device places a low signal on the OBF* line to indicate that data has been written to the port. The peripheral device places a low signal on the ACK* line to indicate that the data written by the 8255 has been accepted. The peripheral device then sets the ACK* signal back to high when it is ready to accept new data.
8255 -- Mode 2, Bidirectional Bus
Figure 4. Timing Specification for Mode 2 Bidirectional
Only Port A on the 8255 PPI can be configured for a bidirectional mode. Two main lines of port C are used to control handshaking of port A -- ACK* and STB*.
When you want to configure the port as output, both ACK* and STB* are initially high. When the ACK* line goes low, data will be driven to Port A as long as the ACK* line is low. As soon as the ACK* line goes high again, Port A goes back to a high impedance mode, and thus the pattern you just wrote will no longer be present.
When you want to read from Port A when configured as input, make sure ACK* and STB* are held high. Port A is now configured as the input port, and the peripheral device can externally drive the lines of the port without damage. To latch in the data, the STB* lines needs to be placed low.
Handshaking More than One Port or More than One 8255 PPI
Figure 5. Digital Scanning Input Group Handshaking Connections
More than one digital port can be grouped together so that more digital data can be transferred at a time, such as 16-bit data transfers with two ports instead of 8-bit data transfers with one port. For 8255-based devices that perform handshaking, all the STB* lines must be connected together for digital input. Only the IBF* line of the last port should be connected to the peripheral device.
Figure 6. Digital Scanning Output Group Handshaking Connections
When performing digital output handshaking on more than one 8255 port, connect only the ACK* and OBF* handshaking signals of the last port.
While the maximum attainable transfer rate on the 8255 PPI is about 100 kwords/s (1 word = 8 bits), the constant sustainable rate may be significantly less. Since boards that use the 8255 PPI do not implement DMA transfers for the block I/O operations, the actual transfer rate depends on the programming language, CPU, and so on.
5. High-Speed Two-Way Handshaking -- Asynchronous
There are two main categories of high-speed handshaking -- synchronous and asynchronous. The synchronous protocols use a shared clock between transmitter and receiver to perform the block transfer. High-speed handshaking in this application note refers to data transfers faster than 1 MS/s. While the DIO-32F DAQ devices implement all the following modes (except 8255 emulation and burst mode), they cannot handshake data at high speeds. Sustained transfer rates is typically less than 400 kwords/s with the driver software (1 word = 16 bits).
8255 emulation mode is available only on 6533 devices. This mode handshakes in a manner compatible with the 8255 PPI. The 6533 device emulation mode is a superset of the 8255 handshaking protocol. The 6533 device can perform back-to-back transfers much faster than a true 8255-based device. If the peripheral device needs more time, you can configure the 6533 device to add a data settling delay between transfers. The 6533 device can use 8255 emulation with 8, 16, or 32-bit data paths.
Level-ACK, Leading-Edge Pulse, Long Pulse, and Trailing-Edge Pulse
These protocols are recognized only by the DIO-32F and the 6533 Family DAQ devices. Two control lines are used to handshake the data transfers: ACK and REQ. The DAQ device (6533 or DIO-32F) controls the ACK signal and the peripheral device controls the REQ signal.
In level-ACK mode, the DAQ device asserts the ACK signal when ready for a transfer and holds the ACK signal level until an active-going edge occurs on the REQ line. After the REQ edge occurs, the 6533 device deasserts the ACK signal until ready for another transfer.
Note: The first ACK is generated after the first data pattern has been transferred. This is illustrated in the following timing diagrams for Level-ACK mode.
Figure 7. Level-ACK Mode Input
Figure 8. Level-ACK Mode Output
In leading-edge mode, the DAQ device and the peripheral device send each other pulses on the ACK and REQ lines. The leading edge of the ACK or REQ pulse indicates that the DAQ device or peripheral device is ready for a transfer. In input mode, the DAQ device sends an ACK pulse when ready to receive data. After receiving at least the leading edge of the ACK pulse, the peripheral devices can strobe data into the DAQ device by asserting the REQ signal. In output mode, the DAQ device sends an ACK pulse after driving output data to indicate new, valid output data. The peripheral device can latch the data on the falling or rising edge of the ACK signal, or at any time before returning a REQ pulse, thus requesting additional data.
Note: The first ACK is generated after the first data pattern has been transferred. This is illustrated below in the timing diagrams for Leading-Edge mode.
Figure 9. Leading-Edge Mode Input
Figure 10. Leading-Edge Mode Output
Long-pulse mode is a variant of leading-edge mode. The only difference is the effect of a data settling delay, if used. In long-pulse mode, a programmable delay is used to increase the minimum width of the pulse rather than delaying the ACK pulse. In long-pulse mode you can handshake with 8255 emulation mode, if you set the ACK and REQ signals to active low. If you want to use long-pulse to handshake with an actual 8255, make sure to select an adequate minimum pulse width for your 8255. A data-settling time of 500 ns is sufficient for any current 8255.
Note: The first ACK is generated after the first data pattern has been transferred. This is illustrated in the following timing diagrams for Long-Pulse mode.
Figure 11. Long-Pulse Mode Input
Figure 12. Long-Pulse Mode Output
In trailing-edge mode, the DAQ device and peripheral device send each other pulses on the ACK and REQ lines. The trailing edge of the ACK or REQ pulse indicates that the DAQ device or peripheral device is ready for a transfer.
Note: The first ACK is generated after the first data pattern has been transferred. This is illustrated below in the timing diagrams for Trailing-Edge mode.
Figure 13. Trailing-Edge Mode Input
Figure 14. Trailing-Edge Mode Output
6. High-Speed Two-Way Handshaking -- Synchronous
The burst-mode handshaking protocol is used only by 6533 Family DAQ devices. This handshaking mode is a synchronous, or clocked protocol. Common applications include electronic and logic testing, board and chip verification, pattern detection, and high-speed communication/data transfer with ATE (automated test equipment). In burst mode, three control lines are used for data transfers -- REQ, ACK, and PCLK. The data transmitter and receiver share a clock signal over the PCLK control line. The 6533 device controls the state of the ACK line, and the peripheral device controls the state of the REQ line.
Figure 15. Input Burst Mode Transfer Example
Figure 16. Output Burst Mode Transfer Example
In every PCLK clock cycle, the 6533 device asserts the ACK signal when it is ready to perform a transfer. If the peripheral device also asserts the REQ signal, a transfer occurs on the rising edge of the PCLK signal. Either the 6533 device or the peripheral device can insert a wait state into the protocol by deasserting the ACK or REQ signal, respectively. Every clock cycle in which both the ACK and REQ signals are asserted transfers one data point. The 6533 device can either drive a clock signal onto the PCLK line or receive an input clock signal from the PCLK line. Currently, 20 MHz is the fastest clock signal accepted by 6533 devices. Because burst mode is a synchronous handshaking protocol, it performs fast data transfers -- up to 76 Mbytes/s with 32-bit transfers over short distances (1 m cable). You may not achieve reliable handshaking with a longer cable; for example, a clock signal of 5 MHz may be the maximum reliable frequency with a 15 m cable.
When performing a burst-mode input operation with an external PCLK, data will be latched on the falling edge of PCLK. With all other data transfer functions and PCLK directions, data is latched on the rising edge of PCLK.
7. Pattern Generation
Pattern generation is possible only on DIO-32F and 6533 devices. Pattern generation is not a handshaking mode; it is typically used in applications that require data to be transferred at a predetermined frequency. Do not be confused by the name "pattern generation." It is a mode of operation, not a direction. The DAQ device can input or output data in pattern generation mode. The frequency at which data is transferred is determined by the signal connected to the REQ line. This timing signal can be generated externally (external request) or the DAQ device can generate its own REQ pulse (internal requests). When the DAQ device generates internal requests, the request pulse is present on the REQ line by default.
With the 6533 in pattern-generation mode, a TTL start and stop trigger can be supplied to begin and end an operation (triggering is not available with the DIO-32F). The 6533 can also be configured to trigger when a specified digital pattern is present on its data lines.
You can specify the following three parameters to the pattern-detection circuit:
- A mask, declaring which data bits you wish to examine
- The pattern value you wish to search for
- Polarity (whether to search for data that matches or that mismatches the specified pattern)
Figure 17. Pattern Detection Example
A variant of pattern generation is change detection. In change-detection mode, the 6533 device generates an internal request only when the input data changes. This mode is especially useful when you need to monitor activity on the input lines efficiently to avoid capturing several copies of the same input pattern. Change detection also increases CPU and bus efficiency. The pattern mask, as discussed for pattern detection, also applies to change detection. The 6533 device monitors only the significant bits for changes. After detecting a change, however, the 6533 device captures the values of all bits.
8. Deciding between Burst-Mode Handshaking and Pattern-Generation Mode
You can achieve high-speed data transfers with both burst-mode handshaking and pattern generation. How do you decide which mode to use? The major difference between these two modes is that burst mode is a synchronous handshaking protocol and pattern generation is not a handshaking mode. This means Burst Mode uses three (3) control lines that dictate data transfers -- the REQ, ACK, and PCLK signals. The 6533 device asserts the ACK line when ready for a transfer; the peripheral device asserts the REQ signal when it is ready for a transfer. Either the 6533 or a peripheral device can generate the PCLK signal; transfers occur on the rising edge of the PCLK signal as long as both the REQ and ACK lines are asserted.
If data transfers are taking place too fast, then either the 6533 or the peripheral device can deassert the ACK or REQ line respectively, thus pausing the data transfer process. When either device is ready to continue data transfers, it reasserts its control line. As long as the peripheral device can at least monitor the ACK signal of the 6533, then burst mode handshaking is the best mode in which to configure the 6533.
Pattern Generation mode uses only one (1) control line -- the REQ line. Data is transferred on every transition of the REQ line. If the REQ line pulses and the 6533 device or the peripheral device is not ready for a transfer, then that data is lost. If the peripheral device does not have a way to pause and resume transfers (that is, it cannot monitor the ACK signal of the 6533), and the frequency of the REQ line is within specification (given in Appendix A of the 6533 User Manual), then Pattern Generation mode should be chosen.
What if you want to go faster than pattern generation allows, but your peripheral device cannot monitor the ACK signal of the 6533? One solution is to use an external synchronous FIFO between the 6533 and the peripheral device. The FIFO would handle continuous data transfers from the peripheral device and handshake the data to the 6533.
9. Serial Data Transfers
Another form of digital I/O is serial data transfers. All of the modes discussed so far have related to the transfer of parallel data, either 8, 16, 32, or more bits of data in each sample. While serial data can be transmitted in these modes (perform an 8-bit transfer, where only one bit of the eight lines is significant), it is more efficient to use a device built for serial transfers. Efficiency here refers to:
- Memory usage (with a parallel digital I/O device, each sample uses 8 bits of memory instead of just one bit)
- Bus bandwidth (a 10 MS/s transfer with a parallel digital I/O device uses 10 Mbytes/s of the bus bandwidth, while the same transfer on a serial digital I/O device uses 1.25 Mbytes/s of the bus bandwidth)
- CPU workload (more software code is needed to process the parallel data).
Serial devices such as the NI 6810 perform efficient serial transfers and also offer advanced triggering capabilities. Data transfers can trigger on such events as serial patterns up to 64 bits long, rising and falling data edges, triggers from an external source, or a software trigger. The 6810 can also trigger on any logical combination of two trigger inputs. Serial data devices are used for applications such as telecom testing, CD-ROM testing, cellular testing, and bus monitoring.
Shown below is an example of using Port C in a nibble configuration for the DIO-24 and Lab-PC+ boards. You cannot use this directly with the SCXI-1200 and DAQPad-1200, because the registers on those boards are accessed via window registers. However, the 8255 setup is the same. If you can write some low-level register access functions, you will be able to use the Port C high and low nibbles independently on these and other boards that use the 8255 PPI.
/* BASE ADDRESS - change accordingly */
#define BASEADDR 0x210
/* 8255 register addresses */
/* NOTE: This is written for the DIO-24. if you want
to use the Lab-PC or Lab-PC+, then switch all the
inp/outp to use the LABPC_ constants. */
#define LABPC_PORTA BASEADDR + 0x10
#define LABPC_PORTB BASEADDR + 0x11
#define LABPC_PORTC BASEADDR + 0x12
#define LABPC_CNFG BASEADDR + 0x13
#define DIO24_PORTA BASEADDR + 0x00
#define DIO24_PORTB BASEADDR + 0x01
#define DIO24_PORTC BASEADDR + 0x02
#define DIO24_CNFG BASEADDR + 0x03
/* 8255 CONTROL WORD BIT PATTERNS */
#define SET_MODES 0x80
#define SET_A_MODE0 0x00
#define SET_A_MODE1 0x20
#define SET_A_MODE2 0x40
#define SET_A_IN 0x10
#define SET_A_OUT 0x00
#define SET_B_MODE0 0x00
#define SET_B_MODE1 0x04
#define SET_B_IN 0x02
#define SET_B_OUT 0x00
#define SET_CH_IN 0x08
#define SET_CH_OUT 0x00
#define SET_CL_IN 0x01
#define SET_CL_OUT 0x00
#define BIT_SET_RESET 0x00
#define SET_BIT0 0x00
#define SET_BIT1 0x02
#define SET_BIT2 0x04
#define SET_BIT3 0x06
#define SET_BIT4 0x08
#define SET_BIT5 0x0A
#define SET_BIT6 0x0C
#define SET_BIT7 0x0E
#define BIT_SET 0x01
#define BIT_RESET 0x00
/* Used for masking */
#define MASK_HI_NIBBLE 0xF0
#define MASK_LO_NIBBLE 0x0F
unsigned char data, dataOut;
/* 8255 Control Word bit map
D7 D6 D5 D4 D3 D2 D1 D0
mode A-mode A-mode A-dir CH-dir B-mode B-dir CL-dir
/* --------------- *\
STEP 1: SETUP
\* --------------- */
data = outp(DIO24_CNFG, SET_MODES | SET_A_MODE0
| SET_A_IN | SET_B_MODE0 | SET_B_OUT|
SET_CH_IN | SET_CL_OUT);
printf("Data written = \tHex %2X\n", data);
/* -------------------------------------- *\
STEP 2: OUTPUT TO LOW NIBBLE, PORT C
\* -------------------------------------- */
/* to write binary 0101 data to port C low nibble
data = outp(DIO24_CNFG, BIT_SET_RESET | SET_BIT0
printf("Data written = \tHex %X\n", data);
data = outp(DIO24_CNFG, BIT_SET_RESET | SET_BIT1
printf("Data written = \tHex %X\n", data);
data = outp(DIO24_CNFG, BIT_SET_RESET | SET_BIT2
printf("Data written = \tHex %X\n", data);
data = outp(DIO24_CNFG, BIT_SET_RESET | SET_BIT3
printf("Data written = \tHex %X\n", data);
/* or write out to port C directly */
dataOut = 0x0A;
data = outp(DIO24_PORTC, dataOut & MASK_LO_NIBBLE);
printf("Data written = \tHex %2X\n", data);
/* ---------------------------------------- *\
STEP 3: INPUT FROM HIGH NIBBLE, PORT C
\* ---------------------------------------- */
/* to read data from port C high nibble */
data = inp(DIO24_PORTC);
/* mask only high nibble and shift */
data = (data & MASK_HI_NIBBLE)>>4;
printf("Data read = \tHex %2X\n", data);
To port this program to a Macintosh, you must change the method of register accesses. First, assign the pointer address. To read from a register, simply read the data pointed to by the pointer. To write to a register, write data to the address pointed to by the pointer.
char *regPtr; /* pointer to 8-bit integer */
char value; /* 8-bit integer */
regPtr = REGISTER_ADDRESS;
*regPtr = 0xFF; /* assign 8-bit value 0xFF to
register at REGISTER_ADDRESS */
value = *regPtr; /* read value at 8-bit register
at REGISTER_ADDRESS */