Breadboard Setup

The best place to start is the wiring of the pair of PCF8574P chips on the breadboard, as shown in Figure 13-1 (the second chip is optional). Do this with the Pi powered off and leave out the keypad for now.

Figure 13-1. The PCF8574P wiring to the Raspberry Pi’s I2C bus (VCC=+3.3 volts)

Figure 13-1 shows two PCF8574P chips wired up to the I2C bus. The second chip is optional but recommended. This second chip will be used to drive an LED indicator. Note that IC2’s A0 is connected to the +3.3V supply so that its I2C address will be 0x21. IC1 will have address 0x20 because its inputs are all tied to ground.

With the wiring done and the Pi booted up, you should now be able to perform some simple tests on it. Let’s check to see whether the two chips are detected on the bus.

$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

If all went well, the i2cdetect command should find addresses 20 and 21 (hexadecimal) as shown. The 1 on the i2cdetect command line specifies I2C bus 1.

If you see zero or one addresses, check that you’ve wired the A0, A1, and A2 pins of IC1 and IC2 correctly. If you wired them both in the same way, both chips will try to respond to the same address. Alternatively, this could result in neither being seen. These addresses must be unique on the bus. You can use different addresses than the ones I chose, but the software presented later will expect addresses 0x20 and 0x21.

Output Tests

The supplied I2C utilities allow you to try these chips without writing any code. Let’s write the value 0xFF to IC1 to set all outputs high.

$ i2cset -y -r 1 0x20 0xFF
Value 0xff written, readback matched

This command example skips interactive mode (-y) and reads back from the chip (-r) as verification. The fact that the command responded with “readback matched” gives you confidence that this write was successful. Otherwise, you can drop the -r option.

$ i2cset -y 1 0x20 0xFF

Some of you might be grabbing some LEDs now to hook one up. Hold off on that since there are some specifics about this chip that must be taken into account (hint: you must sink the LED current rather than source it). This will be discussed later in this chapter. But do go and get your DMM so that you can take some voltage readings.

With your DMM, you can check the outputs of IC1. Outputs P0 through P7 should all measure high (+3.3 volts). Now let’s set P0 to 0, while leaving all other outputs high.

$ i2cset -y 1 0x20 0xFE

Now measure P0 on IC1 (pin 4). Does it read low? All other pins P1 through P7 should remain high. If so, congratulations! Now repeat the experiment with address 0x21 for IC2. You should be able to repeat the results.

Input Tests

The datasheet for the PCF8574 describes this chip as a quasi-bidirectional I/O port. What on Earth does that mean?

One of the great things about this chip is that there is virtually no configuration involved. If you want to output a bit pattern, you simply write to that I/O port like you did with the i2cset command (or using a system call in C/C++). Reading an input value, however, requires one little setup step. You must first write 1 bits to each position that you want to read from and then perform the read. The write operation needs to be performed only once—you can consider that the configuration step. That’s why I said “virtually” no configuration.

Once a bit position has a 1 bit written to it, you can read from it. Let’s set all IC1 outputs to 1s again so that all eight bits are inputs.

$ i2cset -y 1 0x20 0xFF

If you now took the time to measure P0 through P7 with your DMM on IC1, they would all show as high again. However, in this state, the designers of the chip have effectively just enabled a resistor internally to the supply side. This causes the ports to measure high by your DMM. However, since these are all basically linked to the supply by internal resistance, you can pull these down to force a 0 (low) on those pins without causing damage.

To test this, pick a pin, say P3, which is pin 7 of IC1. Attach a Dupont wire from pin 8 (IC1’s ground) to pin 7. Then let’s read the port.

$ i2cget -y 1 0x20
0xf7

The hex value of F7 indicates that bit 3 has been read low while all other bits have remained high. If you now remove that Dupont wire, you should read a high in bit 3 again.

$ i2cget -y 1 0x20
0xff

Confirmed. In this case, without the grounding of P3, the output driver internal to the chip is pulling it high once again. Hence, when you read it back, it has returned to a 1 bit. Grounding P3, on the other hand, forced it to read low even though there was a slight tug to the positive side internally. There is a small tug of war going on in there, but this one is designed to be safe.

High-Side Driver

Let’s expand on this high-side driver concept a bit more. The TI datasheet shows that when the output port is driven high, a 100μA constant current source is activated. If you short that output to ground, as you did when supplying a 0 bit to the input port, you are actually causing 100μA to flow from the supply to ground. This is not a large amount of current, so it remains safe to do. Applying Ohm’s law, you can calculate the effective resistance, which amounts to the following:

So, while the internal resistance is not actually a resistor, it behaves as if there was a 33kΩ resistor tied to the supply side.

People working with the Raspberry Pi or Arduino devices will often wire up an LED, which is turned on when the output port is set high. This is known as sourcing the current through the LED since the current comes from the port (indirectly the supply rail). This is perfectly acceptable when the output port supports this. But the PCF8574 will not source more than 100μA of current. Most LEDs require about 2mA or more before it will emit any light.

While 100μA is not a lot of drive current, it is perfectly adequate for driving high inputs of other CMOS inputs. But driving an LED with the PCF8574, however, requires that you to sink the current instead.

Low-Side Driver

The low-side output driver of the PCF8574 can handle up to 25mA maximum (TI). When you write a 0 bit to the output, that output transistor will conduct up to 25mA of current from that pin (Px) to ground. Because the current is going to ground, this is known as sinking the current.

It is at this point where you interrupt this program to warn about a tug of war that can be fatal. Say you have an external circuit sending its output to your PCF8574 input. If your port has been set to a 0 bit, perhaps because of a software bug, then a high amount of current will flow from that external circuit into the PCF8574’s sinking transistor, when the external circuit’s level is high. This is effectively a short circuit, which left unremedied can mean failure. This is why the PCF8574 powers on in the high state, which is always safe.

If this tug of war possibility exists in your design, you can protect the external circuit and the PCF8574 by wiring them through a 1kΩ resistor. This limits the short-circuit current to a safe level of 1mA and does not interfere with the transmission of the signal.

Driving an LED

Figure 13-2 shows the two different ways that an LED can be driven from an output port. The left side shows an LED being sourced with current from Px, using R1 as a current-limiting resistor. When the output port is set to a 1 bit (active high), the LED is expected to light. This will not work for the PCF8574, since the high-side driver will not supply more than 100μA.

Figure 13-2. PCF8574 sourcing (incorrect) and sinking (correct) of current

The right side of Figure 13-2 shows the correct way to drive an LED from the PCF8574. Using this circuit, the current is sourced by the power supply, and the current is sinked by the output port Px. In this case, the LED is lit when the output is written as a 0 bit (active low). Up to a maximum of 25mA can be driven this way by the PCF8574.

The Keypad

Figure 13-3 illustrates the top side of the keypad I am going to use for this experiment. I chose this format because it is arranged as a 4×4 matrix of buttons and is cheap on eBay ($1.25). If you look carefully at the copper traces of Figure 13-3 and the bottom side of Figure 13-4, you can see how the buttons are wired in four rows and four columns. This will allow you to sense the keypad with four outputs and four inputs.

Figure 13-3. Keypad with 16 buttons. Note the copper traces on the top side going to the edge connector.

Figure 13-4. Bottom view of the keypad. Note the copper traces going to the edge connector and where pin 1 is, with the square pad.

In rummaging through my junk parts, I came across some old calculator keypads that I have saved since the early 1980s (Figure 13-5). These were purchased by mail order catalog and are still like new. These keypads occasionally show up on eBay, though usually at a higher price ($7). But before you purchase these for a project, realize that these are not always organized in a matrix. My Figure 13-5 keypads have 12 connections and a ground. In other words, all 12 keys are arranged in one electrical row.

Figure 13-5. Some oldies but goodies from the 1980s

Looking at the bottom side of the hex keypad in Figure 13-4, make note of where pin 1 is. It is the square pad shown at the bottom right of the figure. This pin appears on the top side of the board nearest S13 on the silk screening (Figure 13-3). If you are using the same keypad and have the pin 1 located, you should be able to reproduce the same results developed in this chapter. You can of course use a different keypad, but you’ll have to make the appropriate adjustments.

From a breadboard perspective, the header strip on the keypad is inconvenient. To bring the keypad interface onto the breadboard, you may want to use some female-to-male Dupont wires. Ideally a pair of four-conductor cables would work best. I had to use four two-conductor wires instead. Arrange these cables to bring the eight connections from the keypad to the breadboard for ease of wiring.

Figure 13-6 illustrates the connections inside the keypad, as well as their terminal connections T1 through T8. These are wired on the breadboard to IC1’s Px, as shown in brackets. With no keys pressed, you can see that there are no connections between any of the T1 through T4 rows to any of the columns T5 through T8. But when button SW7 is pressed, a connection is made between row T3 to column T7.

Figure 13-6. Keypad connections diagram

After making the connections between the keypad and IC1, as shown in Figure 13-6, you can manually run some experiments using the I2C tool commands. First, let’s configure the left four bits as 0 bits and the right four bits as 1 bits so you can read from them.

$ i2cset -y 1 0x20 0x0F

Now using the bash shell, let’s enter a loop that will slowly read IC1 for any changes.

$ while true; do i2cget -y 1 0x20; sleep 1; done

This loop will do an i2cget read in a loop, with a one-second delay between each read. Use Control-C to stop it later. With the command running, you will initially see this:

0x0f

This is to be expected since you wrote that pattern out to the port. While that continues to run, successively press S1 through S4. Do you see this?

$ while true; do i2cget -y 1 0x20; sleep 1; done
0x0f
0x0e
0x0f
0x0d
0x0f
0x0b
0x0f
0x07
0x0f
^C

Once again, the first 0x0f is the port-configured value. However, when I pressed button S1 (and waited), 0x0e was returned. After releasing S1, the next reading was 0x0f again. Pressing S2 returned 0x0d, S3 returned 0x0b, and S4 returned 0x07. This demonstrates that you were able to read rows T1 through T4 as bits 3 through 0 of IC1’s port.

Now repeat the experiment with buttons S5 through S8, S9 through S12, and S13 through S16. You should get the same results. These all return button presses because you have all rows T1 through T4 set low. Let’s now make the reading more specific. Set row T3 to low, while T1, T2, and T4 are high with the hex value 0xDF (the bits used are 11011111, specifying only bit 5 as zero).

$ i2cset -y 1 0x20 0xDF

With only bit 5 set low, only button presses in column T7 will ever read a low (buttons S5 through S8). By scanning T1 through T4, you can detect columns that have button presses.

Before presenting C++ code to scan the keypad, let’s do one more manual experiment. With the output still set to 0xDF, what happens if you simultaneously press S5, S6, S7, and S8?

$ while true; do i2cget -y 1 0x20; sleep 1; done
0xdf
0xd5
0xdd
0xdf
0xd8
0xd0
0xdf
^C

It was a bit of a struggle for me to get all the buttons simultaneously pushed down in that row, but eventually I succeeded (the value reported was 0xd0). This illustrates the fact that the program scanning the keyboard must be prepared to filter these events out or return them as a keycode of some sort. This is similar to the kind of thing that your PC keyboard must do when it sees the Microsoft-made-famous Control-Alt-Delete.

Keypad Program

In your source directory, change to the keypad subdirectory and type make, if you haven’t already compiled the code.

$ cd keypad
$ make

With the executable keypad built, run it and press some buttons. In the session shown, I pressed S1, S6, S11, and S16 in a diagonal.

$ ./keypad
keypress: EE (S1)
release:  EE (S1)

keypress: DD (S6)
release:  DD (S6)

keypress: BB (S11)
release:  BB (S11)

keypress: 77 (S16)
release:  77 (S16)

The two-digit hexadecimal number shown is effectively the “scan code” that you saw previously using the i2cget utility. Recall that the left four bits select a row, and the right four represent the column selected. The program then looks up the scan code to translate that into a “key name,” like S1.

108 int
109 main(int argc,char **argv) {
110     uint8_t keypad, row, col;
111
112     // Open the I2C bus
113     i2c_fd = open(i2c_device,O_RDWR);
114     if ( i2c_fd == -1 ) {
115         fprintf(stderr,"%s: opening %s\n",
116             strerror(errno),
117             i2c_device);
118         exit(1);
119     }
120
121     for (;;) {
122         // Scan each keypad row:
123         for ( row=0x10; row != 0; row <<= 1 ) {
124             // Drive the row select
125             i2c_write(i2c_keypad_addr,∼row);
126
127             // Read the column inputs
128             keypad = i2c_read(i2c_keypad_addr);
129             col = keypad & 0x0F;
130
131             if ( col != 0x0F ) {
132                 // Keypress event
133                 printf("keypress: %02X (%s)\n",
134                     keypad,
135                     key_lookup(keypad));
136
137                 while ( (i2c_read(i2c_keypad_addr) & 0x0F) == col )
138                     usleep(50000);
139
140                 printf("release:  %02X (%s)\n\n",
141                     keypad,
142                     key_lookup(keypad));
143             }
144             usleep(50000);
145         }
146     }
147
148     return 0;
149 }

024 static std::unordered_map<uint8_t,std::string> keymap({
025     { 0xEE, "S1" }, { 0xED, "S2" }, { 0xEB, "S3" },
026     { 0xE7, "S4" }, { 0xDE, "S5" }, { 0xDD, "S6" },
027     { 0xDB, "S7" }, { 0xD7, "S8" }, { 0xBE, "S9" },
028     { 0xBD, "S10" }, { 0xBB, "S11" }, { 0xB7, "S12" },
029     { 0x7E, "S13" }, { 0x7D, "S14" }, { 0x7B, "S15" },
030     { 0x77, "S16" }
031 });
...
095 const char *
096 key_lookup(uint8_t scancode) {
097
098     auto it = keymap.find(scancode);
099     if ( it != keymap.end() )
100             return it->second.c_str();
101     return "???";   // Multiple keys pressed
102 }

037 void
038 i2c_write(int addr,uint8_t byte) {
039     struct i2c_rdwr_ioctl_data msgset;
040     struct i2c_msg iomsgs[1];
041     int rc;
042
043     iomsgs[0].addr = unsigned(addr);// Address
044     iomsgs[0].flags = 0;            // Write
045     iomsgs[0].buf = &byte;          // Buffer
046     iomsgs[0].len = 1;              // 1 byte
047
048     msgset.msgs = iomsgs;           // The message
049     msgset.nmsgs = 1;               // 1 message
050
051     rc = ioctl(i2c_fd,I2C_RDWR,&msgset);
052     if ( rc == -1 ) {
053         fprintf(stderr,
054             "%s: writing to I2C address 0x%02X\n",
055             strerror(errno),
056             i2c_keypad_addr);
057         exit(1);
058     }
059 }

065 uint8_t
066 i2c_read(int addr) {
067     struct i2c_rdwr_ioctl_data msgset;
068     struct i2c_msg iomsgs[1];
069     uint8_t byte;
070     int rc;
071
072     iomsgs[0].addr = unsigned(addr);// I2C Address
073     iomsgs[0].flags = I2C_M_RD;     // Read
074     iomsgs[0].buf = &byte;          // buffer
075     iomsgs[0].len = 1;              // 1 byte
076
077     msgset.msgs = iomsgs;           // The message
078     msgset.nmsgs = 1;               // 1 message
079
080     rc = ioctl(i2c_fd,I2C_RDWR,&msgset);
081     if ( rc == -1 ) {
082             fprintf(stderr,
083                     "%s: reading I2C address 0x%02X\n",
084                     strerror(errno),
085                     i2c_keypad_addr);
086             exit(1);
087     }
088     return byte;                    // Return read byte
089 }

Combination Lock

To finish off this chapter, let’s create a practical keypad application—the combination lock. For this project, let’s add two more components to the breadboard.

• A green LED to indicate unlock success

• A red LED to indicate that the attempted combination has failed

For the LEDs, refer to Figure 13-2, using the circuit shown on the right (the LED being sinked). Connect the green LED to the second PCF8574 (IC2) port P0 and the red LED to IC2’s P1. The only thing left is to determine the resistors needed.

The voltage drop V _F of an LED varies with the color of the device [1]. A green LED is listed between 1.9 and 4 volts, while a red LED is 1.6 to 2 volts. Since you’re using a +3.3V supply, this means you only have a difference of V _CC – V _F = 3.3 – 1.9 = 1.4 Volts for green LEDs and 3.3 – 1.6 = 1.7 Volts for red. The dropping resistor you need can be determined with the following:

Many LEDs will use about 10mA, which is well within the PCF8574 sinking capability. So, calculate the following:

The closest E12 resistance value to this is 180Ω. If you have trouble finding of that value, you can safely go up to 200Ω or even go lower.

With R2 of Figure 13-2 set to a value of 180Ω, the resistor wired to the +3.3V side, and the other end wired to the LED, connect the green LED cathode to IC2’s P0. Do the same for the red LED, except that the LED cathode goes to P1. Before you present the software, let’s prove that the hardware is good. Turn on the green LED (note that the I2C address is 0x21 this time for IC2).

$ i2cset -y 1 0x21 0xFE

If everything is wired correctly, the green LED should light, and the red one should remain dark. Now enable the red LED.

$ i2cset -y 1 0x21 0xFD

The red LED should light, and the green one should be dark. Finally, let’s light both.

$ i2cset -y 1 0x21 0xFC

To turn them both off again, write the value 0xFF to the port. Note that only the last two bits actually matter here as far as the LEDs are concerned.

Combination Lock

With the LEDs installed and tested, you can turn your attention to the combination lock software. The program must implement a state machine based upon key press events. The state machine you’re going to use is as follows:

1. The initial state is that no keys have pressed yet. Clear the buffer of key codes.

2. Wait for a key press. Proceed to the next step when it arrives.

3. Add a key code to the buffer.

4. Have four keys been pressed? If not, go to back to step 2.

5. If four keys have been pressed, is the combination correct? If not, light the red LED and go to step 1.

6. The combination is correct: light the green LED to announce the unlocking of the device.

7. Has a key been pressed? If so, turn off the green LED and return to step 1. Otherwise, continue to wait.

The program combo.cpp located in the ./keypad subdirectory implements this overall procedure, except that it checks the combination code as the keys are entered. You’ll examine that later.

Figure 13-7 illustrates my breadboard arrangement. Don’t be intimidated by the number of wires. Most of the wires (most of them white) are wires to ground for the PCF8574 address pins. The remaining white wires take connections from the keypad to IC1.

Figure 13-7. A breadboarded circuit for the keypad.cpp and combo.cpp programs

With the hardware ready, run the program combo, as shown here:

$ ./combo
*** LOCKED ***
code[0] = 7D (S14)
code[1] = BB (S11)
code[2] = DD (S6)
code[3] = ED (S2)
*** FAILED ***
*** LOCKED ***
code[0] = BE (S9)
code[1] = D7 (S8)
code[2] = DD (S6)
code[3] = DB (S7)
*** UNLOCKED ***
*** LOCKED ***
^C

The session output helps display state information as the code runs. A full implementation would provide some kind of feedback for each key as it is entered. You could, for example, use the remaining ports of IC2 to light an LED for each of the four codes. This is left as an exercise for you.

Initially, the session reports that the lock is “locked.” As each key is pressed, the scan code and the key name are displayed (for demonstration purposes). At the end of four codes, the lock either fails to unlock (red LED) or becomes unlocked (green LED).

The first attempt shown in the session output has an entry of S14, S11, S6, and S2 before the red LED comes on and the session reports “failed.” At this point, the state machine restarts, allowing entry of a new code.

The red LED is permitted to stay on until the entry of the first key code. You’ll see that in the code later in this chapter. In the second attempt, keys S9, S8, S6, and S7 are pressed to successfully unlock the device. The green LED will remain lit until another (any) key is pressed. At that point, the green LED is turned off, and the device enters a locked state once again.

140 int
141 main(int argc,char **argv) {
142     static uint8_t code[4] = {
143         // 9, 8,    6     7:
144         0xBE, 0xD7, 0xDD, 0xDB
145     };
146     uint8_t keypad, kx;
147     bool matched;
148
149     // Open the I2C bus
150     i2c_fd = open(i2c_device,O_RDWR);
151     if ( i2c_fd == -1 ) {
152         fprintf(stderr,"%s: opening %s\n",
153             strerror(errno),
154             i2c_device);
155         exit(1);
156     }
157
158     i2c_write(i2c_led_addr,0xFF);   // Both LEDs off
159
160     for (;;) {
161         puts("*** LOCKED ***");
162
163         // Wait for entry of all four codes:
164         matched = true;
165         for ( kx=0; kx<4; ++kx ) {
166             keypad = get_key_code();
167             printf("code[%u] = %02X (%s)\n",
168                 kx,keypad,
169                 key_lookup(keypad));
170             if ( keypad != code[kx] )
171                 matched = false;
172             if ( kx == 0 ) {
173                 // All LEDs off
174                 i2c_write(i2c_led_addr,0xFF);
175             }
176         }
177         if ( !matched ) {
178             // Failed: Red LED + start over
179             i2c_write(i2c_led_addr,∼red_led);
180             puts("*** FAILED ***");
181             continue;
182         }
183         // Code matched: unlock
184         i2c_write(i2c_led_addr,∼green_led);
185
186         // Wait for any key code to lock
187         // and restart
188         puts("*** UNLOCKED ***");
189         get_key_code();
190         i2c_write(i2c_led_addr,0xFF);
191     }
192
193     return 0;
194 }

111 uint8_t
112 get_key_code() {
113     uint8_t keypad, row;
114
115     // Wait for key release:
116     while ( (i2c_read(i2c_keypad_addr) & 0x0F) != 0x0F )
117             usleep(20000);
118
119     // Wait for key press:
120     for (;;) {
121             // Scan each keypad row:
122             for ( row=0x10; row != 0; row <<= 1 ) {
123                     // Drive the row select
124                     i2c_write(i2c_keypad_addr,∼row);
125
126                     // Read the column inputs
127                     keypad = i2c_read(i2c_keypad_addr);
128
129                     if ( (keypad & 0x0F) != 0x0F )
130                             return keypad;
131                     usleep(20000);
132             }
133     }
134 }

Interrupts

One concept that I didn’t have the space to explore was the concept of the interrupt (/INT) pin on the PCF8574. With the current programs, it must continually poll the PCF8574 chips to see whether there is a key press. The interrupt pin of the PCF8574 chip can signal a data change to a Pi GPIO input. A poll of the GPIO pin is quick and cheap and leaves the I2C bus available for other traffic.

Additionally, each /INT output is driven by an open collector transistor. This permits two or more /INT signals to be wired together so that only one interrupt signal line is required. This requires only one pull-up resistor on the line. I encourage you to read the datasheets and explore this important functionality.

Summary

You’ve reached the end of this book; all good things must come to an end. I hope that this book has inspired you to try some hardware attached to the Raspberry Pi and come up with ideas of your own. A hobbyist can have fun just reproducing “how to” articles, attaching Pi hats, and so on. But the real fun is in taking an idea and designing the interfaces yourself!

Bibliography

1. Poole, By Ian. “LED Characteristics & Colours.” LED Characteristics and Colours. Accessed November 05, 2016. < www.radio-electronics.com/info/data/semicond/leds-light-emitting-diodes/characteristics.php >.