It’s a very common question from the Netduino users. It’s about how to connect two or more boards/shields when they are relatively far each other.
The appliances and the mains.
It’s perhaps the habit to take the mains everywhere simply adding a piece of chord: the vacuum-cleaner works. Or else, during Christmas, when we have to plug half a dozen of light strings to the mains. No matter how we plug the cables: the Christmas tree is shining. We’ve only to take care of: (1) ensure a good mains connection, and (2) take care to avoid any false-contact which may cause overheat.
By the way, everything is working fine for several reasons:
- the voltage is high enough, so that any small voltage drop will be insignificant;
- the waveform of the mains is a wonderful sine, swinging at a very low frequency (50 or 60Hz);
- but, of sure, the most important fact is that:
there’s no any information carried over the mains wiring, thus our appliance will “understand” just “go/no go”.
The digital signals.
Working on digital logic, microcontrollers and else, we need mostly transfer “information” from a block to another one. This “information” can be a simple bit high/low, but it can be much more complex (e.g. the SPI). The higher is the quantity of information, the harder is to protect it from errors.
It’s the famous “signal-to-noise ratio“, which impose a limit to the maximum quantity of information over a line when the noise has a certain level.
Here I won’t show you anything mathematical, instead I want to show you that not always the things are simple as they seem.
The experiment.
As base for the experiment, I created a simple circuit with my Netduino. Nothing special about it: it’s a circuit seen many times.
The Netduino SPI drives a 74HC595, which dirves a 7-segment display. The display itself has the only meaning to show a certain “pattern” to the observer (me). Of course, it’s much more simple to recognize a number, than a sequence of leds. That’s the way I’ve chosen a display over eight leds.
The Netduino runs a very simple program, which has to present sequentially the 16 digits of the hex-base. Each digit is held for 500ms, and the sequence is kept running forever.
public class Program
{
/// <summary>
/// Segment pattern for the hex-digits
/// </summary>
static readonly int[] Digits = new int[16]
{
0xBF, //0
0x06,
0xDB,
0x4F,
0xE6, //4
0x6D,
0xFD,
0x07,
0xFF, //8
0x6F,
0xF7,
0x7C,
0xB9, //C
0x5E,
0xF9,
0x71,
};
public static void Main()
{
//define the SPI configuration
var config = new SPI.Configuration(
Pins.GPIO_PIN_D10, // SS-pin
false, // SS-pin active state
0, // The setup time for the SS port (not used)
0, // The hold time for the SS port (not used)
true, // The idle state of the clock
true, // The sampling clock edge
1000, // The SPI clock rate in KHz
SPI_Devices.SPI1 // The used SPI bus (refers to a MOSI MISO and SCLK pinset)
);
//define a single-cell buffer used by the "Write" method
int i = 0;
byte[] buffer = new byte[1];
//open the SPI port
using (var spi = new SPI(config))
{
while (true)
{
//issue the digit pointed by the index
buffer[0] = (byte)(Digits[i] ^ 0xFF);
spi.Write(buffer);
i = (i + 1) & 0x0F;
//small delay
Thread.Sleep(500);
}
}
}
}
Note 1: The segment pattern follows the “standard” map used by the 7-seg displays. Bit #0 maps to segment “A”, whereas bit #7 maps to the decimal point.
Note 2: I used to make the DP on for the even digits, and off for the odds.
Note 3: The display I’ve used is a common-anode (toward +5V), so the activation logic is reversed. That’s explain the XOR-op.
I won’t change anything in the above program, other than the SPI clock rate, which is initially equals to 1 MHz (=1000). I would have used an higher clock rate (e.g. 10 MHz), but my scope has a limited bandwidth (100 MHz), and the waveform would not be shown as it is.
The target of the experiment is showing how the SPI signal is at the 74HC595 pins, upon several different wiring.
Tight wiring.
That’s the reference. Everything is wired very tight, keeping the wires as short as possible. Also the grounding (which is *very* important) is shared on the same bread-board, and the supply is given by the Netduino itself.
The circuit is working fine (tested up to 40 MHz of clock-rate, just for your information).
The waveform is perfectly squared: no noise, nor delays.
The upper trace is the SCLK, while the lower is the MOSI.
Shielded cable.
The second test is performed using a 2.5m (about 8 ft) of multi-pole shielded cable of good quality. The problem is about the SPI, which needs at least three signals (SCLK, MOSI, SS), plus ground. For a bidirectional data exchange we’d need another wire.
The circuit is still on the bread-board, but the Netduino is moved off the area. The supplies are separate: the Netduino is supplied via USB, which the HC595 circuit via a regulated power supply.
The ground is shared by connecting the cable shield to both sides.
Again, there’s a little distortion of the signals, but the data transfer is still reliable. The shielded cable works correctly, but I should have to “adapt” the wires at the HC595-side, by “terminating” each signal with a proper resistor. I didn’t for simplicity of comprehension.
The problem is the cost and the thickness of the cable.
Un-shielded cable.
The third test is performed using a 3m (about 10 ft) of multi-pole cable of poor quality. It’s cable for phones, burglar alarms, and similar wiring. Very cheap and thin (although the mine has only three wires: for the ground I’ve used another wire).
Again, the Netduino supply only itself, and the HC595 is supplied by a separate power.
The waveform is clearly getting worse, but the circuit still counting correctly.
The waveform shows rippled, thus it’s interesting to make an attempt by raising the clock rate.
Un-shielded cable at 2 MHz.
Doubling the clock-rate the result is getting even worse. However, the circuit seems still working fine.
Un-shielded cable at 5 MHz.
At 5 MHz the signals are almost unrecognizable, and -yes- the circuit is not working anymore. It displays strange patterns, sometime correct, but mostly randoms.
Effect of the noise on the un-shielded cable.
Let’s take the clock back to 1 MHz, but let’s try to see what happens when a noise-source is close to the cable.
For instance, we might think to another cable, close to the signals’ one, used for motors, inverters, or many others loads that involves “high-frequencies”.
In this case, I took the same shielded cable of the previous test, but I’ve used the shield as “emitter”. Basically, I’ve connected the shield to a square-wave generator (about 4 MHz), and I’ve let the cables over the un-shielded. There’s *NO* metallic connection, but for capacitive coupling (i.e. electrostatic) there’s an interference on the signals’ cable.
The resulting waveform by the HC595 is clearly showing how the noise “sums” to the useful signals.
Of course the circuit is not working!
Conclusions.
The SPI is not a good way to transfer data on long wiring: too wires, too high clock rate. But I wanted to highlight you the effects of a long wiring on a relatively high speed.
Of sure I’d bet on the classic serial port (i.e. UART), which needs just two signals and ground. However, even the RS-232 interface cannot be used for lengths over 15m (50 ft).
For very long distances, the speed must get lowered, and the things are getting harder. However, there are many interesting ways to solve small projects without getting crazy.
Highfield Tales 