To download NI software, including the products shown below, visit ni.com/downloads.
This tutorial and its attached example programs explain how to configure NI waveform-based digital I/O devices to communicate with serial protocol interfaces using the NI-HSDIO or NI-DAQmx driver software.
Serial protocols are prevalent in modern electronics systems across many industries and applications. The need to emulate and test these systems has introduced a need to communicate with devices and subsystems through serial protocols. Classically, dedicated hardware was implemented to drive and receive messages with protocol-specific encoding and timing. However, modern waveform-based devices with high-speed sample clocks are capable of accurately emulating protocol buses for the purposes of communication and parametric test. This article discusses the configuration of waveform-based hardware for protocol communication.
For the purpose of this discussion, waveform-based hardware can be defined as a device that generates or acquires digital patterns (waveforms) using a memory or FIFO space and a sample clock. All NI High-Speed Digital I/O devices and many NI DAQ devices are examples of this type of hardware. A pattern of digital samples is created as a digital waveform, which is stored in a memory buffer -- usually a bank of memory on the I/O device. A sample clock, generated by either an onboard oscillator or a counter/timer circuit, is used to generate the digital pattern with deterministic timing at a specified rate.
This technology can be utilized to emulate low-speed serial protocol signals using oversampling. Oversampling is a method of generating or acquiring signals using a sample clock that runs at an integer multiple of the signal frequency. In terms of digital communication, the oversampling technique is applied to the protocol waveform. For example, a waveform that is oversampled at 2 MHz allows the smallest time separation between any two edges defined in the waveform to be 500 ns. If it is oversampled at 4 MHz, 8 MHz, 10 MHz, etc., the precision of that edge definition is increased accordingly. When generating a serial protocol waveform, the required rate of the oversample clock is set by the precision with which that protocol's timing parameters must be defined. This makes low-speed protocols ideal for the oversampling method.
Using a waveform-based device to emulate serial transactions has a major advantage in its reusability. A single device can be used to emulate several different protocols and communicate directly with multiple types of sensors, instruments, or DUTs within a single application, merely by generating a different waveform from the device.
The basic approach to using a waveform-based device for serial protocol communication is:
1. Generate an oversample clock
This may be done using an onboard oscillator and a divide-down sampler, or it may be done using a counter/timer circuit. Either approach can be configured through the device's driver API.
2. Build an output waveform
Creating a serial protocol waveform using oversampling can be a complex task. Protocol signals are normally created using a state machine implemented in hardware or firmware embedded in the I/O device. A software tool used to emulate device behavior must account for all the logic transitions and custom timing normally built into that state machine. It must also account for interactions between bus devices that are not defined by the protocol standard. Commonly, the more strictly-defined the protocol, the easier it is to design a software tool to build a waveform for that protocol.
NI Systems Engineering has developed Reference Libraries for some commonly used low-speed serial protocols. These components should be studied as examples of how to create a fast, efficient software API for generating any serial protocol waveform. They can also be directly used in applications to communicate with these protocols:
3. Generate the waveform while acquiring the slave device's response
Using the device's driver API, generate the protocol waveform and simultaneously acquire the slave's response using the same oversample clock as the generated data.
4. Parse the response data for desired information
The acquired response data can be parsed to extract protocol-specific information, such as a message from the slave device, a CRC check, or an acknowledgement from the slave. This method of extracting information from a raw waveform is an example of "bit-banging".
The flexibility of this approach makes it very attractive for many applications. It is, however, a method of emulating a custom hardware design, so the tradeoffs should be considered. The first such tradeoff is shown in step 4 above, where input data must be parsed to obtain meaningful information. This process is almost universally different for every application, and so a custom function is usually written for each implementation to provide maximum efficiency.
The second tradeoff is in overall system throughput. Although a single interaction on the bus runs at full rate by sampling the stored waveform directly, the analysis of the interaction and the queuing of a second interaction requires processing on the host CPU or controller. The time required can be on the order of 10's or 100's of microseconds. As a result, when an error condition occurs on the bus -- for example, a "Not-Acknowledge" is signaled in I2C, or a slave device fails to respond when addressed -- this situation will not be recognized and handled for a very long time, in terms of the serial bus clock. (For all but the lowest-speed buses, the system response to a bad packet or error condition will be orders of magnitude longer than the period of the sample clock.)
For the same reason, waveform devices are not suited to acting as a slave on most serial buses. Slave devices normally listen to the bus and respond immediately to the master device when addressed. The low throughput of a host-side bit banging emulation makes it difficult to configure waveform-based devices to respond to serial addressing mechanisms immediately.
For applications whose purpose it is to simply communicate with a slave device, these tradeoffs are not a limiting factor. Since interactions on most low-speed serial buses are initiated and controlled by a master device, the application software can respond to each packet (or otherwise-defined bus interaction) at its leisure: the slave devices will wait until the master is ready.
There are several NI devices capable of performing clocked digital I/O operations using waveform data. These devices come from many product families which use multiple driver APIs. The following sections review template applications that explain how to configure and run devices from each family for serial protocol communication. Each template groups device families according to their capabilities and associated driver software. Example VIs based on the templates are provided in the Downloads section of this article.
Use the following table of contents to jump to your hardware's section:
The NI-HSDIO driver is designed to control high-speed digital I/O modular instruments. These devices are designed with impedance-matched termination, several types of triggers and exported events, and a high-speed onboard oscillator that can be divided to achieve sampling rates up to 200 MHz. There is a set of "core" features that can be used with NI-HSDIO based device to achieve serial protocol communication for most buses. A few extra "advanced" features available on some of these devices are useful for achieving faster system throughput and for communicating on bidirectional (half-duplex) buses.
All 654x, 655x, and 656x devices share a common set of features that can be configured for serial communication using the same function calls. These features configure a device to generate a waveform using actively-driven outputs on dedicated output pins while simultaneously acquiring a waveform on dedicated input pins. (The generated data can be acquired on the dedicated output pins as well; this can be useful for correlating events in the input and output waveforms.)
The initial configuration of the device is performed only once. The following features are configured in this stage:
Once the device has been configured, common set of functions can be called in sequence to load a waveform, generate it, and retrieve the acquired data from the device. This sequence of calls can be made repeatedly for subsequent bus interactions.
The waveform retrieved from the acquisition engine can now be parsed to retrieve pertinent protocol-specific information.
Some NI devices (including the 655x series) feature advanced capabilities which expand the set of protocols that can be emulated and increase the throughput of the emulating application.
Some protocols, such as I2C, minimize wire count by transferring data in half-duplex. This requires bidirectional communication across some pins, and often the role of driving the pin is transferred between master and slave within a single clock period. NI devices that support Per-Cycle Tristating can deactivate their line drivers within a single clock cycle to accommodate this operational requirement.
An additional benefit of per-cycle tristating is that the device can be used on buses that require passively-driven outputs, such as open-drain, wired-OR and open-collector drivers. By using "Z" as the high state and "0" as the low state, a waveform can be written that causes the device to pull the line low for a '0' bit and let it float for a '1' bit. This is a requirement for the I2C and SMBus protocols.
Because of this requirement, only devices with the per-cycle tristate feature can be used to emulate I2C communication as described in this article.
The Hardware Compare feature is another useful advanced feature of NI-HSDIO based devices. The hardware compare feature allows the application software to fetch only a record of interesting samples from device memory, instead of all acquired samples. This means that much less time is spent transferring data from the device to the host CPU. It also means that the parsing function which analyzes the acquired waveform to extract protocol information has less work to do and can be designed more efficiently. As a result, using hardware compare in a serial protocol application increases overall system throughput at runtime.
To activate Per-Cycle Tristating, the waveform data generated by the device must be encoded with the "Z" state where appropriate. Likewise, the Hardware Compare states "L", "H", and "X" must be used in the waveform to make use of that feature. Hardware Compare state encoding is used in all of the SDW, JDW, and IDW reference libraries linked above, and open-collector output levels ("Z" and "0") are used in the IDW library.
The device programming flow differs only slightly when utilizing Hardware Compare:
Parsing the sample errors is much more efficient than parsing the raw waveform. A template algorithm for sample error parsing is provided for each protocol in the attached example programs.
The NI-DAQmx driver supports several families of products. Some of these products have digital I/O buffers that can be used with a sample clock to emulate a serial bus interaction. These devices do not generally support oversample clock rates as high as the NI-HSDIO based devices, nor do they support any advanced NI-HSDIO features. (As such, they cannot be used to emulate bidirectional bus transactions in the manner discussed here.)
There are two primary methods of generating an oversample clock for an NI-DAQmx based device. Some devices provide an onboard oscillator that can be used to generate the clock internally, while other devices provide counter/timer circuits for generating a clock signal.
The 6535/6/7 devices have an onboard oscillator and divide-down circuitry available for generating sample clocks. This makes their programming flow very similar to the core NI-HSDIO flow.
The initial configuration sequence is performed only once:
Once the device has been configured, common set of functions can be called in sequence to load a waveform, generate it, and retrieve the acquired data from the device. This sequence of calls can be made repeatedly for subsequent bus interactions.
The waveform retrieved from the acquisition engine can now be parsed to retrieve pertinent protocol-specific information.
NI DAQ devices do not generally have an onboard oscillator used to run hardware-timed DIO tasks. However, some devices, like the M-series (62xx), are capable of correlating their DI and DO tasks to an externally generated clock signal. A counter/timer on the device can be used to generate an oversample clock, which can then be internally routed to the DI and DO tasks.
The device programming flow for M-series devices only differs slightly from the flow for internally clocked devices. The initialization sequence has two differences:
The runtime sequence of function calls is nearly identical, except that the CO task must also be managed alongside the DI and DO tasks:
This tutorial and the attached Reference Application were created by the NI Systems Engineering group.
Description-Separate-2Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
I test serial_wfm_1_0_1_lv86.zip on my PXIe-6556 , it work well for single a byte reading form my I2C Device, but If i read continuous bytes, data are wrong. I did not know why? Any one can help to answer this problem? I get another example VI form https://www.dssz.org/1860279.html , but the waveform pattern generator VI are not compatible to integrate them for byte and word access I2C device, I hope someone have better suggestion.
Denny
Hi , I keep getting an error while trying to use th downloadable examples.
the following error Message appears:
"Specified read or write operation failed, because the number of lines in the data for a channel does not match the number of lines in the channel.
If you are using the Digital Waveform datatype, make sure the number of lines in the digital waveform matches the number of lines in the channel. If you are using boolean data, make sure the array dimension for lines in the data matches the number of lines in the channel.
Number of Lines in Channel: 1
Number of Lines in Data: 3
Task Name: _unnamedTask<1C>"
Thnx