Serial Communications
Getting data from one processor to another
Introduction
Data is one thing, but getting it to where it can be used is a matter of synchronization. Why? Because digital information has to be read by a receiving processor and that requires looking at specific times. Data streams are meaningless if synchronization is lost. Beginnings and endings are blurred. Edge condition glitches are a nightmare. This also implies data will be sent with a clock that is twice the data rate so clock synchronization allows the data be read in the middle of any one data pulse. Corruption of the transmission of data and clocks are a constant design challenge. Reading data at a distance gets a bit tricky (pardon the pun).
Project Description
Serial data in software is a matter of turning on an output channel labelled "clock", delaying, and turning it off again. This would be a half-cycle. Next we delay again. Now we are ready to turn on the channel again to start the next cycle. We use the positive-going clock edges to line up with the center of the data stream to maximize the success of reading the value. So the software needs to send data at half the rate of the clock. The software will control the data waveform in the same manner, but at half the rate. The demo circuit and software are set up like the diagram below.
By controlling the data and clock transmission lines, serial data can be read by hardware at the other end. In the world of OSI/TCP models for data transmission, we are working in the Layer 1 area. We are setting up a "data-frame" concept with associated hardware. In this case, two Arduinos, but we could add in balanced drivers or fiber optic circuits or even and Ethernet NIC arrangement. In the demo we are using a 3-wire twisted cable (data, clock, and a ground so the receiving hardware has a reference level and the circuit has a return path).
The variety of hardware solutions to gap the distance and not loose the data are many. We won't concentrate on those scenareos. We will focus on the software apps at either end that send data and receive that same data successfully.
When we get into the program, you will see the clock rate was set at 50ms. The deviation from that seen in the diagram are caused by the processors latencies to run the C++ instructions and program functions.