title title title title



Serial Interfaces

Lets first take into account that computer systems are built on data and address buses that are parallel interfaces from memory cells to processing components and back to memory, so parallel ports to external subsystems were a natural choice in the early days of computing. But the cost and electrical shielding as bus width grew from 8 bits to 64 bits and the space to place these buses quickly gave way to the practical use of serial bus. This is all a natural selection process as the speed of digital circuit became so fast that the serial design didn’t delay the transport of data enough to discredit the approach.

Parallel interfaces are very simple to employ, because only a latch needs to be implemented to get data from one bus to another. Serial interfaces require a translation of bus data into an orderly frame and moving it in a synchronous method as to not lose the bit order, and then to retranslate a group of bits back into a parallel form to be used by a computing process. Even with this complication, serial interfaces reign supreme for many reasons, one of which is it only takes a transmit (Tx), receive (Rx), and a return line to complete the circuit. Now someone will say, “But what about one-wire buses?” Yes, you can time multiplex or order multiplex a single wire to establish a Tx Rx pattern, if followed carefully, will allow such a system to move data reliably (you still need a return). How the bits are bundled is then the big question and for that, there are as many ways as there are engineers to spec them out.

Notice how engineering ignores the return wire so the circuit is complete and electrons can actually move and the system function. We use the term “ground” to abstract away having to concern ourselves with this most essential piece of the circuit, but that’s because engineers know it always has to be there, so why clutter up schematics, etc. with a lot of lines that are a given. Calling a return a ground is another story. We’ll talk about that later. If you think about, what is a ‘1’ or ‘0’ in electrical terms? In TTL circuits, it’s a voltage near 5V for a ‘1’ and near 0V for a ‘0’, so to get a digital system to function, we need a bottom reference to measure these voltages from and that is the ground or common that establishes the return current to its source.

So what serial interfaces should we consider important and which ones don’t really need to be discussed, because no one uses them anymore. After all, we need to make room for all ones coming down the road we don’t know about yet. This sort of decision is what separates the engineer from the scientist. There are many approaches that work and some are very elegant, but to an engineer, the least expensive one that gets the job done, and where an IC chip is already available, is the best choice. Like all technical disciplines, electronics is divided into dedicated groups that become experts in particular areas and produce commercial products to sell. There’s no need to be the expert of all areas. As engineers, we comb through these choices and just grab one. So size, weight, power consumption, mounting, availability, cost are examples of successful implementation and where engineers spend time to get it right. Since there is a long legacy of IC packages, there have been significant improvements and innovation. With the advent of microcontrollers, many of the choices have been reduced to the ones that interface these chips with an emphasis on software to implement various functions. After all, we want a product not art for the most part. We’ll let the scientist further the understanding of the physics and chemistry of things.

Here’s a good place to mention protocols. A protocol is a spec that tells you how an interface is to be implemented, what each bit does and how to interpreted it. Timing and format are explicitly explained. There is no hardware choice mentioned. Hardware is designed from a protocol, so any manufacturer should, in theory, be able to build a device that should work fine if it follows the protocol. The reason I mention protocols as a concept is many of the older protocols like RS232 were implemented in hardware that was common, but is not explicitly followed now. New hardware says it uses such protocol but probably only borrows the bit pattern. So some caution has to be exercised when working from a protocol. It’s better to work with the selected chip specification that uses the protocol and gets the job done. We have bigger fish to fry. We have to learn programming language babble.

So let’s get to it. We need chips that can read a parallel bus and convert it to a serial stream and another chip to do the opposite. We need features like bus buffers so the transition transients won’t be seen on the interface, meaning only when the data is settled in do we want to open the gate to the outside world to see the data. Some chips employ a High-Z buffer, meaning a device that has extremely high impedance that basically isolates the internal circuit from the outside until the data is ready and then this impedance level is brought down to a very low value quickly. This switching property is very fast. The next choice is the bus size. Do we want an 8-bit, 16-bit, 32-bit or 64-bit or larger interface. Like I mentioned earlier, it is mostly determined by the processor selected. For hobbyist using an Arduino, which only uses 8-bit data and a 16-bit wide memory bus, this can be met by a lot of the older TTL chips. The Arduino only runs at 16MHz so the chip speed of the older chips is also capable. With the RaspberryPi the selection process should be more precise, because it has a 32-bit bus running in the GHz range.

The next consideration is distance. Data deteriorates with distance due to energy absorption of the media carrying the data and interference from RF and crosstalk between close runs of wiring. Remember the magnetic field discussion. By the way, RF consist of a magnetic field and static field waves moving through a medium 90 degrees from each other. I know, sounds crazy, but if studied, that’s what you get. The point is this magnetic field varying in intensity will induce a voltage in any conductor it cuts through. We call that RF noise. If extreme distance and privacy of the data is needed, then fiber optics is the best choice. For our discussion, we only need a few feet. If longer, we plan to use WiFi or Bluetooth. The Internet provides a super solution for data transport conduit and world wide connectivity.

Let me suggest the 74HC165 shift register as an 8-bit parallel input and shift that data out with a clock as a serial bit stream and the 74HC595 to take in 8-bits of serial data, hold it until all the bits are in place, then latch it to an output register to be read by a bus as parallel data via a High-Z buffer. These are the only two chips you need for hobbyist work with a custom programmable serial interface. We’ll show the details with a demo.

There are several control signals that must be set up, but a microcontroller can handle this with its basic digital I/O or GPIO pins easily. I’ll use the Arduino Uno.

Before I get to the demo, I need to mention two other bus schemes that are standard on most microcontrollers - the I2C bus and the SPI bus. Both use a bus wires that are held high with a 4.7k ohm resistor and use a pull-low protocol with a specific bit pattern. The I2C bus uses a data line and a clock line. This protocol sends out an address first. The device with that address sends a response when it’s ready to receive. Then the data is sent depending on the next command to receive or transmit. Any other device on the bus is dormant until its address is given. Once the data transfer is complete, a break message is sent and the active device goes back into a listen mode for its address again. Since an address can appear on the bus at any time, this is known as an asynchronous bus.

SPI bus is a four wire system. One for data from a master controller to slave devices , one for data to the master from the slave devices, a system clock line, and a chip select signal for each device on the system. A channel is selected by the chip select and the data can flow as a full duplex mode from master to slave and vice-versa. The clock is always running so this is a synchronous bus system. When a select signal is invoked, the data can begin to flow right away. The data format for SPI is not standard, so it depends on each device spec how to interpret commands and data. The SPI hardware is set up to handle a lot of data where as I2C is meant for a few bytes at a time. We’ll see demos of each.

One more bus is common on microcontrollers and that is the UART which stands for Universal Asynchronous Receive/Transmit and was based on RS232, 422, and 485 transceiver pairs using balanced signals read by chips dedicated to carry the Tx and Rx signals and other control signals that make up the bus design. This is the oldest style design so it has a lot of variation. Currently it is paired with a USB serial port to make more basic interfaces to microcontrollers compatible with conventional personal computers. New USB standards are quite fast. UART designs were meant to run at 480 Mbits/sec using a 10-bit word to carry a byte with a start and stop bits added.

The main way to communicate with the Arduino family of microcontrollers is USB to UART. The USB standard also specs a 5V supply with 500ma of available current, so this also provides power for the Arduino via the USB connector, thus there are four wires in the cable. This is an excellent way to match a PC to the Arduino. By the way, the ground wire in the cable is the ground reference for the data bus, so when connected to an Arduino, all the data signals are referenced to the same level.

The Raspberry-Pi has a dedicated power plug and expects data to be connected via an Ethernet network or have a WiFi connection or Bluetooth to communicate with a PC. The Pi also has the I2C, SPI, and UART serial interfaces included in its GPIO. The Pi is best utilized as a server and interface to the Internet or local network router and let other devices like the Arduino gather data for the Pi. Such a system is the best of both worlds and can provide a GUI interface using HTML, CSS, and JavaScript to implement a full service web app with live data inputs. At some point, we will pull all of this together in a IoT system as a demo.

Return to Video Demo page



parts