And the Meek Shall Dictate the Bus Speed

If you have ever worked with standard bus interfaces before, you will know that in almost all cases, the transfer speed of the bus is, in some way, fixed between devices on the bus. This is the typical case for both point-to-point and multi-point busses.

Having a fixed bus speed can simplify the design and implementation of the bus. But it does require that the devices that participate on the bus must be able to provide and consume the data at the prescribed rate, without data loss.

One of the oldest interface busses, serial, implemented various serial transmission rates. This would allow different devices of different aggregate data transfer rates to utilize the serial interface to facilitate device to device transfers. But there is no mechanism to dynamically determine supported serial transfer rates between devices. The rates must be known ahead of time.

The SPI standard implemented a much higher serial data transmission rate than classic serial. Yet the data rates between devices must be known in advance. In the case of SPI, there isn’t a fixed rate between devices, rather a maximum data transfer rate that can be supported. Regardless, that maximum rate must be known ahead of time, and can’t be determined dynamically.

The I2C interface is another variation of a serial interface bus. But unlike classic serial and SPI, I2C does specify a minimum serial transfer rate that must be supported by all devices. There are also upper serial transfer rates that depend on the rates supported by different I2C devices. But it can at least agree on a minimum data transfer rate.

Classic serial provided handshaking via optional handshaking lines. As with serial baud rate, support for handshaking is not guaranteed and must be agreed upon ahead of time. Unlike classic serial, SPI and I2C provide no such standard handshaking mechanisms.

OpenDAQ relies on micro-controller modules to run the show. These devices typically will implement classic serial and SPI interfaces. Some will also implement I2C. There is no other standard interface available on any micro-controller that can be leveraged to work on OpenDAQ. Classic serial, SPI and I2C can be used as long as their limitations are understood and worked with.

SPI is the best-supported interface for connecting function-specific integrated circuits and sub-systems. These include, but are not limited to, analog to digital converters, digital to analog converters, digital IO expander devices, and micro-SD bulk storage devices. SPI sub-systems include USB, Bluetooth, WIFI and Ethernet interfaces. Working with these devices requires that the host SPI system must understand and not exceed the maximum serial transfer rate of each of these devices.

For basic DAQ systems, serial interfaces will do the job. But as the complexity and performance of DAQ systems increases, the limitations of serial interfaces becomes a challenge.

OpenDAQ allows for greater performance and complexity by taking a modular approach that allows more than one brain, or micro-controller module, to be utilized in a single OpenDAQ system. Such increased complexity may require communications between processors that can’t be met by serial interfaces. To provide the needed flexibility, OpenDAQ borrows a page from the dark ages of device interfacing, and implements a version of an interface that, although decades old, is still supported in some DAQ instruments to this day, IEEE488.

The IEEE488 interface is unique in that it implements a handshaking mechanism that tailors the data transmission rate to the slowest participating device on the bus. Although this may sound limiting, the slowest bus device only dictates transfer rates while commands are sent, and while data is transferred with the slowest device. When data is being transferred between faster devices, the slowest device does not limit the transfer rate.

There is no set data transfer rate one the IEEE488 bus. It can run as fast as the fastest devices can manage, yet run as slow as the slowest device needs, without any up-front configuration or negotiation.

It may not be readily apparent, but when implementing communication between devices with varying workloads, this bus fits the bill perfectly. It adapts to both devices in real-time. And, unlike serial interfaces, IEEE488 supports multiple devices shared on the same bus without the need for extra hardware.

Although the IEEE488 bus was designed and implemented as an external bus, using cables to connect different physical devices, OpenDAQ implements a version of this bus internally, to connect intelligent sub-systems together in a manner that utilizes the real-time adaptability of the bus to ensure that data transfers never over-run. As an internal interface, the maximum bus transfer rate can achieve transfer speeds significantly faster than the 1 MByte/Sec maximum transfer rate of the external IEEE488 bus.

Given the horsepower that is now available with off the shelf micro-controller modules, it is now possible to implement an internal version of this interface using simple I/O lines, rather than relying on IEEE488 controller and peripheral devices that are obsolete and no longer available. Despite the obsolescence of the hardware, the functionality and flexibility of the IEEE488 interface bus has yet to be matched by any other interface bus currently available.


Comments

Leave a Reply