The 74HC595 is a very common used chip, because it acts as an output expander for the Netduino. It is a serial-in/parallel-out shift-register exposing 8 HCMOS outputs, but it is possible to chain several chips together, giving you many more available outputs.
The 74HC595 embeds a very common shifting logic, which can be conveniently driven by the Netduino SPI. All you need is three wires, all of them carrying signal from the Netduino to the 74HC595 chip.
These signals are:
- MOSI (Master-Out/Slave-In), which carries the data-bit you are going to transfer (i.e. the outputs value);
- SCLK (Serial Clock), which is basically a square wave and it has a double purpose (one per edge): (1) indicates when the data (MOSI) is changing, and (2) when the data has to be sampled (i.e. is stable);
- SS (Slave Select), which tells to the shifter to "listen" to the incoming data synchronization.
However, not all the logic chips behave the same way, and some may be hard to interface.
For details about these pins, please have a look at these references:
How the 74HC595 internally works
The very first thing to do is to read carefully the 74HC595 specifications
. They are pretty comfortable to understand, because the same info are reported under several forms. For instance, the Table 3 (page 5) summarizes the functional description of the embedded logic. At first glance it may be cryptic to read, but it is simple instead.
There are no more than six different functions performed by the 74HC595: each one is well described as per-row.
The first three rows may be ignored, because they have the /MR input at low-level (L). Under this condition the whole logic is frozen (clearing all the outputs), and your goal is to manage a data transfer instead.
The fourth row is the most useful. It says that the data is sampled (thus shifted in) on the rising edge of the clock (SHCP input), and it is clear that the data to be shifted must be stable. That is exactly what you need: take a bit out of the Netduino MOSI and feed into the 74HC595.
Why the 74HC595's latch stage is important.
There would be a problem: consider the SPI pushing out a whole byte, where only the very first bit has to be high (true). Assuming the MSB is coming first, the byte would be 0x80, and the MOSI will expose the bit#7 first (true), then all the remaining seven bits as false.
Now, imagine the shift-register's outputs: on each clock rising edge, the 74HC595 will shift the high bit of just one position. If you were able to see what is happening (very fast indeed), you would see the high output "moving" from pin to pin.
Now, if your goal is to light a bunch of leds, maybe you may ignore this problem, but most of the times that is an unwanted side-effect.
That is because the 74HC595 embeds a special stage called "latch". The actual outputs derive from this latch, instead of directly from the shifter. With this trick, you may shift whatever with want without worrying at all for the outputs. When the whole bit stream is completely transferred, you must "tell" the chip to "take a snapshot" of the shifter status, and store it in the latch stage indefinitely. To achieve this function, the STCP input must detect a rising edge.
Choosing the right settings
At this point, your goal is to determine what are the right SPI-settings to use for the 74HC595.
Browsing the above parameters, you may conveniently assert:
- the Clock_Edge must set to "true", because the 74HC595 shifts/samples the MOSI data on the rising edge of the clock;
- the ChipSelect_ActiveState must set to "false", so the SS will tied low along the whole transfer, then pulled up: that generates the "STCP rising edge" usful for the latch;
- the Clock_Idle could be set to either false or true (it may be other different chips connected, thus the idle state could be chosen accordingly);
- the ChipSelect_SetupTime and the ChipSelect_HoldTime may be set to zero, because the 74HC595 is very fast and do not need any extra delay;
- the Clock_Rate would not be a problem, however you should avoid too high clock rates (stray capacitance and wiring may create problems over 10-20 MBit/s);
Relationship between hardware and software layers¶
You may also take a look at the Atmel MCU SPI specifications
. It is worthwhile to bear in mind that the .Net Micro Framework is designed to be hardware-independent, but Netduino is built over a well-specific Atmel MCU. In this section you may learn the relationship between the Atmel specifications and the Micro Framework interface.
In the below picture there are the four possible combinations of NCPHA and CPOL, as the Atmel MCU specifications indicate for the SPI. Since you must choose the right settings for the software interface, you should first understand how the hardware layer works.
With a small effort, the timings depicted show that:
NOTE: the MOSI/MISO diagrams show crossing points at every clock edge (rise/fall). A "cross" means the data is changing, thus a sample will not reliable (and must be avoided).
- CPOL = Clock_Idle
- NCPHA = Clock_Idle XOR Clock_Edge
- Clock_Idle = CPOL
- Clock_Edge = CPOL XOR NCPHA