Raspberry Pi 3 and Zero

The two recent developments are the Raspberry Pi Zero and the Raspberry Pi 3. You could say these models are at opposite ends of the spectrum. The Zero is in high demand, mainly because of its killer price of $5. The Pi 3, on the other hand, has killer performance for the price.

This book is generally neutral about what Pi you choose to apply. The book was developed using a Raspberry Pi 3, but except for performance differences, all examples should work for all models.

Why GPIO Is Important

One of the keys to the success of the Raspberry Pi is a design that offers GPIO interfaces. In the PC era, people had to attach their home-brewed hardware through the PC’s printer parallel interface or work with the more cumbersome RS-232 interface. With the Pi, you have access to serial data, a clock, I2C, serial peripheral interface (SPI), pulse width modulation (PWM), and general I/O signaling. This arrangement is far more capable and opens a world of options to the Pi user.

What to Purchase

In addition to the basics necessary to run your Raspberry Pi, you’ll need to acquire the following items for the chapter experiments. Also listed are the specific chapters they apply to.

• Breadboard

• Plenty of Dupont wires (for breadboarding)

• Pi Cobbler (GPIO to breadboard)

• 74LS04 (Chapter 2)

• 74LVC244 (Chapter 2)

• 74LVC245 (Chapter 2)

• 74LVC244 (Chapter 2)

• CD4049 or CD4050 (Chapter 2)

• 74HCT244 (Chapter 2)

• 74HCT245 (Chapter 2)

• CD4001 (Chapter 2)

• High-Definition Multimedia Interface (HDMI) to VGA adapter (Chapter 3 only)

• LCD module 1602A (Chapters 4 and 12)

• I2C Serial Interface Module with PCF8574 chip, for LCD (Chapters 4 and 12)

• I2C level converter (Chapters 4 and 12)

• MC14490 chip (Chapter 5)

• 0.01 microfarad capacitor (Chapter 5)

• Push buttons (Chapter 5)

• YL-40 printed circuit board (PCB) using PCF8591 chip (Chapter 6)

• 3.1 kiloohm and 15 kiloohm 1/8 watt, resistors (Chapter 6)

• 1N914 diode (Chapter 6)

• 3.3 kiloohm 1/8 watt resistor (Chapter 6)

• 1 Kiloohm linear potentiometer (Chapters 7 and 12)

• Optional knob for potentiometer (Chapters 7 and 12)

• Keyes KY-040 rotary encoder (Chapters 8 and 12)

• Optional knob for rotary encoder (Chapters 8 and 12)

• 2 × 170 ohm resistor (Chapter 8)

• 2 × LEDs

• 74HC165 (Chapter 9)

• 74HC595 (Chapter 10)

• MCP23017 (Chapter 11)

• 2 × PCF8574P (Chapter 13)

• Hex keypad (Chapter 13)

Software to Download

For this book, you’ll need to perform two software downloads.

• Download the software for this book, Exploring the Raspberry Pi 2 with C++, from here:

  • https://github.com/ve3wwg/raspberry_pi2.git

• Download the source code for this book from either of the following locations:

  • https://github.com/ve3wwg/custom_interfaces_pi.git

  • www.apress.com/9781484217382

Once the Exploring the Raspberry Pi 2 with C++ software is downloaded, go into its directory and install it, as shown here:

$ cd raspberry_pi2
$ make all install

This will give you access to the C++ library code that this book builds upon, as well as the gp utility for controlling GPIO from the command line.

To build this volume’s source code, go into its subdirectory and type the following:

$ cd custom_interfaces_pi
$ make

This will compile all the programs discussed in this book, saving you from having to do that later. The compiled executables are left in their subdirectories and are not installed anywhere else on your Raspberry Pi.

Let’s Begin

With those formalities out of the way, you can begin your exploration of hardware interfaces on the Pi!

Most of the chapters can be read out of sequence. This is helpful when you are waiting for ordered components to arrive. Before attempting any interface involving 5 volts, however, I strongly recommend that you digest Chapter 2 first.

7400 Series (TTL)

The 7400 series of integrated circuit (IC) was developed in the 1960s and 1970s to be used as building blocks for digital mainframe computers (the 5400 series is the military-grade equivalent). This is known as transistor-to-transistor logic (TTL), which largely replaced the earlier diode transistor logic (DTL).

TTL circuits use a 5V power supply (usually referred to as V_CC) and use defined voltage ranges for what is considered true (1) or false (0). Any signal that is between these ranges is considered undefined or ambiguous.

Since these digital signal levels are measured by voltage and because the signals of interest are input or output signals, they use the symbolic notation shown in Table 2-1.

Input and output ranges are further qualified using the symbols in Table 2-2.

When we begin with logic levels, we must start with input logic levels. These levels decide what is considered a 0 or 1 when received from the sending circuit. Thus, the signals of primary interest are V_IL and V_IH . Look for these when examining a datasheet (you usually can find a datasheet for a given chip by Googling <part-number> datasheet PDF).

Table 2-3 describes the TTL (5V) levels. Notice that V_IH is defined in terms of V_CC for its highest voltage range. Remember also that V_CC can itself vary by up to 10 percent in value because the power supply varies. When V_CC varies like this, V_IH can be as low as 4.5 volts or as high as 5.5 volts.

It is clear from Table 2-3 that any digital signal from 0.0 volts to 0.8 volts is to be considered a false (0) input. Signals at 2.0 volts or higher are considered true (1). Any voltage between these levels is ambiguous and must be avoided. Ambiguous levels are interpreted unpredictably as 0 or 1.

Generating an exact voltage level consistently and reliably is difficult, if not impossible. For this reason, ranges of acceptable values are used. For example, if your digital input signal is 0.125 volts, it clearly falls within the TTL logic 0 range. In another example, a voltage input of 2.8 volts is clearly interpreted as a logic 1.

When you examine output signals, the output needs to meet the requirements of the input ranges if the signal is to reliably transmit digital data. For example, if a hypothetical part generates logic 1 output voltages between 3.0 volts and V_CC, then it meets the TTL interface requirements for logic high. This is because 3.0 volts meets and exceeds the 2V minimum. If the same part is guaranteed to generate logic low levels between 0.1 and 0.6 volts, then this clearly falls into the TTL low range also. With these voltage ranges, this part will successfully communicate with other TTL component inputs.

3.3V Logic

With the introduction of complementary metal-oxide semiconductor (CMOS) logic soon after TTL, a definition for CMOS logic levels had to be agreed upon. The difficulty with CMOS, however, was that it could operate over a range of different power supply voltages (note that the power supply is often referred to as V_DD for CMOS). For this reason, CMOS logic levels are usually defined in terms of the operating V_DD instead. Fractional values are provided in [1], while the percentage references can be found in [2].

Table 2-4 lists the CMOS logic level guidelines.

The CMOS ranges provided in Table 2-4 are approximate. The final range is defined by the device’s datasheet.

Even though the Raspberry Pi CPU is CMOS-based, the input specifications provided by Broadcom are slightly different and documented in Table 2-5.

In this chapter, you will have to pay attention to all three sets of input logic levels.

I’ve introduced several symbols and voltage levels. Figure 2-2 will help you visualize what I am about to discuss. For now, ignore the fact that the 5V signal exceeds the supply voltage for the 74LVC245. This will be explained later.

Figure 2-2. Example of logic level conversion

On the right side of Figure 2-2 is an example 5V TTL device (74LS04). In the middle is the level shifting device. Finally, on the left is the Raspberry Pi GPIO input that I want to feed a signal into.

The signal starts at the output of the 74LS04. According to its datasheet, the output is never lower than 2.7 volts when it represents logic 1 and never higher than 0.5 volts when it represents logic 0. These are the 74LS04 device’s V_OH and V_OL output levels, respectively. The arrows from the 74LS04 pointing left show how these voltage levels are passed into the left device’s inputs. Whether the left device sees a logic 1 or 0 depends upon its own input level definitions V_IH and V_IL. In the Figure 2-2 example, you can see that the 74LS04 clearly exceeds the 74LVC245 input requirements.

The middle device is illustrated with these two sets of parameters:

• Input levels V_IL and V_IH

• Output levels V_OL and V_OH

When examining interfaces, you must remind yourself that the input and output voltage levels differ. The output levels must exceed the input levels of the receiving device (if they only just met the requirement, there would be no “noise margin” of safety).

Examining the 74LVC245 device going left to the Pi, you must meet the Pi’s slightly different input parameters. Following the arrows going left, you can see that the 74LVC245 output levels definitely exceed the Pi’s input requirements. This is the general principle of level shifting from an output to an input.

Voltage Dividers

Converting from a higher to a lower voltage logic can sometimes be done using a pair of resistors in a voltage divider configuration (Figure 2-3). This can be attractive when there are only one or two signals involved. But this quickly becomes burdensome when the number of signals increases because of the parts count.

Figure 2-3. Voltage divider circuit

A pair of resistors wired in series can take a worst-case 5V signal and produce a 3V level by dividing the voltage. The values of the resistors are chosen from a ratio, as shown here:

The basic idea is that you make 3 volts appear across R₂ but drop the remaining 2 volts across R₁.

The first problem is that you must choose a value for R₁ or R₂ before the resistance can be solved. But if you choose too high a value, then any current flowing into or out of the midpoint junction will cause its voltage to vary (the divider is not “stiff” enough). The rule of thumb is that the series current through R₁ and R₂ should be at least ten times any incoming or outgoing current from the junction. The added current flow will stiffen the divider.

The Pi’s CMOS input requires nearly zero current. The only current that does flow is when there is a change of state, requiring a small charge or discharge to occur. This charge transfers to/from the stray capacitance at the chip’s pin and the CMOS gate. Engineering students can compute this tiny charge as an exercise, but here I’ll suggest that 1mA is plenty of “stiffness.”

Resistors come in different tolerances. You can assume the following 10 percent resistor values for this example:

If you were to do all the Ohm’s law math, you’d discover that the midpoint voltage (V_R2) would be 2.97 volts when the TTL input is 5 volts.

Let’s test this arrangement using a Texas Instrument 74LS04 output feeding into the voltage divider. The divider’s output will be used as an input for the Raspberry Pi. You want to test whether this will actually work under all possible conditions.

Assume a worst-case 74LS04 output low voltage of V_OH=0.5 volts, and assume V_OH=2-7 volts for output high. These represent the datasheet’s guaranteed worst-case figures. Table 2-6 summarizes how the voltage divider measures up. The column “Pi Margin” measures the difference between the Pi’s requirement and the value appearing at that input.

From Table 2-6 you can see that V_OL is below the Raspberry Pi requirement of 0.8 volts by a margin of 0.56 volts. The worst case for the 74LS04 output high (V_OH) has a lower margin of 0.19 volts over the Pi’s minimum of 1.3 volts. It appears that you’ve met the requirements, even though a bigger safety margin on the high side is desirable.

Is the circuit acceptable if you consider the worst-case values for the 10 percent resistors R₁ and R₂? Recall that I used a parts tolerance of 10 percent. The worst case here would be R₁ + 10 percent and R₂ – 10 percent because this would lower the midpoint voltage further. Table 2-7 summarizes this result.

It is clear from Table 2-7 that the V_OH result of 1.36 volts is dangerously close to the absolute limit of the Raspberry Pi specification (1.3 volts). The margin of error is only 0.06 volts. This is looking shaky.

From this, you might conclude that the voltage divider is not as attractive as it might first appear. From a hobby perspective, you can make this work by cherry-picking your resistors carefully or by using lower-tolerance resistors. What you didn’t consider was that the power supply can vary by another 10 percent in its supply voltage. If you were to turn this into a product (or a kit), you’d want to improve that error margin to avoid shipping faulty units.

Finally, consider also that this analysis is sensitive to the TTL part that is being used. If you substituted the 74LS04 for a part with poorer worst-case conditions, you may end up generating signals that are “out of spec.”

7400 Series Derivative Families

The 74L low-power series was introduced in 1971, which was soon superseded by the faster 74LS series. Several new series derivative families began to appear including 74H (high speed), 74S (high speed Schottky), and so on. Finally, CMOS-compatible families were added including HC and HCT. Currently several derivative families are available [3].

Table 2-8 lists some of the derivative families that may be of interest. We’ll focus on the HCT series and LVC series derivative families. While other families may sometimes work, you must also consider the speed of the device, particularly when you want to do high-speed SPI, for example.

Unused CMOS Inputs

Before I present breadboard experiments using CMOS devices, you should be aware of the unused input quirk of CMOS devices. TTL devices can have unconnected inputs, even though it is usually best to ground them to avoid noise. CMOS inputs, however, must be connected.

CMOS inputs can be tied to ground or V_DD. They simply must not be left “floating.” Failure to observe this practice can result in unusual behavior or potential device failure.

Converting 5V to 3V Input: 74LVC245

The LVC series derivative family can help when you want to convert a 5V signal to 3.3 volts. The first of this family that you’ll examine is the 74LVC245.

The 74LVC245 chip provides eight bidirectional buffers, with tristate capability. For a level translator, you’re not interested in the tristate or bidirectional capabilities. These can be hardwired to function in one direction only, and tristate can be disabled (some users might find the tristate useful, but the direction should be hardwired). What is of critical importance is how the configured input is transformed from the TTL level to the Pi level.

Figure 2-4 provides an abbreviated logic diagram for the buffers A1 and B1. The remaining seven buffers are controlled by the same DIR and OE gate inputs and are available on the remaining device pins.

Figure 2-4. 74LVC245 octal bus transceiver

Wiring the DIR and OE gate inputs to ground causes the data to flow from input B1 to output A1. This configuration enables the buffer going from right to left, while disabling the buffer going left to right.

The 74LVC245 was chosen here because it can be supplied with +3.3 volts but can accept input voltages (at B1) at voltages as high as +5 volts. This feature is critical, since most ICs will accept only a maximum of their supply voltage (+3.3 volts) plus one diode drop (about 0.6 volts). This is because of the way electrostatic discharge (ESD) protection works in the device.

The 74LVC245 must operate at +3.3 V so that its output (A1) will provide a maximum of +3.3 volts to the Raspberry Pi. It also happens to be the recommended operating voltage for this device.

Figure 2-5 illustrates the circuit for interfacing 5V inputs (B ports) to the Raspberry Pi (A ports). The single 7404N chip (IC2A) is shown to represent some arbitrary TTL level signal wired to B1. Additional TTL signals can be wired to B2 through B8 in the same way.

Figure 2-5. 74LVC245 as a TTL to 3V level converter

The figure doesn’t show this, but the 74LVC245 (IC1) chip must be powered from a +3.3V supply (Raspberry Pi supply). The TTL chip (IC2A), on the other hand, will be powered by the 5V supply.

Substituting a 7400 chip quad NAND gate for IC2A in Figure 2-5, its output was fed into the 74LVC245 (IC1) input B1 for an experiment. Table 2-9 summarizes the measured DC voltages.

Table 2-9. Measured 74LVC245 DC Voltages

7400 VCC	7400 Inputs	7400 Output	'245 VDD	'245 B1	'245 A1
+4.99 volts	Gnd	+4.45 volts	+3.29 volts	+4.45 V	+3.29 V
	+4.99 volts	+0.038 volts		+0.38 V	+0.009 V

Figure 2-6 shows my breadboard setup used for the measurements in Table 2-9. The lab unit shown on the left was a hamfest (ham radio flea market) deal that I scored one summer day. Hamfests are great for acquiring parts and used equipment (like the used Fluke bench DMM under the scope).

Figure 2-6. Breadboard test setup

From this test, it was observed that the 74LVC245 tolerated the +4.45V input and produced a nice +3.29V output on A1. The 3V supply was not raised, which can happen if an incorrect part is used for IC1 (because of internal protection diodes). When the TTL input of +0.38V was provided to B1, the 74LVC245 improved the V_IL signal as A1=+0.009V. The 74LVC245 performed marvelously as a 5V to 3V conversion device.

Converting 5V to 3V Input: 74LVC244

The 74LVC244 device is another member of the LVC derivative family (Figure 2-7). This device has the advantage that it is unidirectional, making it simpler and potentially cheaper than the 74LVC245 device. To use this device, the two OE inputs are wired to ground to permanently enable the 3V outputs (unless, of course, you need tristate). The inputs are 5V tolerant, making this another terrific logic level converter.

Figure 2-7. 74LVC244 pinout

Table 2-10 summarizes the measurements taken when the 74LVC244 was used.

Table 2-10. Measured 74LVC244 DC Voltages

7400 VCC	7400 Inputs	7400 Output	'244 VDD	'244 B1	'244 A1
+5.02 volts	Gnd	+4.69 volts	+3.31 volts	+4.69 V	+3.31V
	+5.00 volts	+0.035 volts		+0.35 V	+0.012 V

The experiment once again confirms that the input of the 74LVC244 was permitted to be higher than the V_DD supply of +3.3 volts. Had this device not possessed this special feature, the '244 input reading might be +0.6 volts or higher. This will be clarified when I discuss protection diodes.

Input Protection Diodes

The 74LVC245 and 74LVC244 devices were special devices because they allowed a 5V signal into an input, even when that device was operating at V_DD=+3.3 volts. Let’s take a moment to understand why this is special.

The CMOS gate is a metal oxide that is deposited on a thin layer above the silicon channel where current flows. Any small voltage change exerted on that insulated gate causes a larger change in electron flow in the channel beneath. But if the electric charge is high enough, the metal oxide can be punctured and shorted out. This damage is permanent and destroys Field Effect Transistor (FET) operation.

To protect the gate from static electricity, protective diodes are built into the device. There are different ways this is accomplished, but it is frequently done as shown in Figure 2-8. Diodes D₁ and D₂ are reversed biased in a way that causes them not to interfere with normal input signals.

Figure 2-8. Inverter equivalent circuit

The inverter circuit shown has the FET transistors Q1 and Q2 arranged in the typical CMOS configuration. When one transistor is on, the complementary transistor is off. The input is usually guarded by a low-valued resistance R₁ to limit the current flow when a static discharge occurs. Since the metal-oxide gates do not conduct electricity, the diodes D₁ or D₂ are designed to bleed the static charge away. By bleeding the charge away, the voltage levels are kept low enough to prevent gate puncture damage.

For the student, schematic diagrams are drawn so that diodes form an arrow of conventional current flow. That is, the current is shown flowing from plus to minus even though physicists have long ago proven that electrons flow from minus to plus. If you pretend conventional flow is correct while we look at the diagram, you can visualize the fact that no current flows from plus to minus through the diodes because they are reversed in polarity.

If you pet a cat and then come in contact with (or close to) this gate’s input, static electric current will flow from the input through D2 or D1, depending upon whether the electric charge is positive or negative. I have not been able to determine which charge it is though I have regularly snapped sparks to our cat’s ears. If you shuffle your feet on a carpet, the generated charge may be positive or negative depending upon the materials involved.

The protection diodes work rather well for static charges under normal handling conditions. The problem occurs when you want to do something like feed a 5V signal into a CMOS input when the device is operating at a supply voltage of +3.3 volts. Examine Figure 2-9, which is rearranged slightly to illustrate the high voltage flowing into a lower-voltage device’s input.

Figure 2-9. Current through protection diode D2

If the input pin of the inverter is raised to +5 volts, then the input voltage is above the chip’s own supply V_DD=+3.3 volts. This difference is as follows:

The voltage that develops across a silicon diode is usually about 0.6 volts, so you need to subtract that to arrive at the voltage across R₁.

The resistance value isn’t normally provided in the datasheets but may be near 200 ohms [4]. This means that when the input signal is provided at +5 volts, the current flow through R₁ is as follows:

The difficulty is that you have no guarantee that the protection diode can sustain 5.5mA of current. The protection diodes are designed to discharge weak currents for brief periods of time. For this reason, you shouldn’t design a circuit to rely on its use. A similar problem exists when the input is made less than -0.6 volts (negative), causing current to conduct through D₁ instead.

The special feature that permits you to provide a higher-than V_DD input voltage is a protection circuit that depends upon a Zener diode for D₁, as shown in Figure 2-10.

Figure 2-10. Inverter with Zener input protection

Diode D₂ is no longer required because D₁ is a Zener diode, which has a designed breakdown voltage in the reverse direction. The exact voltage where the Zener action occurs is not usually specified but guaranteed to occur above some absolute high value. The Fairchild Semiconductor datasheet for the CD4049UBC or CD4050BC lists the absolute maximum voltage for the inputs at +18 volts [5]. So, the Zener action must occur somewhere above that.

D₁ is a Zener diode when reversed biased. It otherwise conducts current like a normal diode when forward biased. This means that if the input signal goes negative, the Zener diode starts conducting at about -0.6 volts like the normal protection diode. Thus, the single Zener diode protects against both positive and negative static charges.

From this, I hope that you can see that there is a need for this special feature. Without this adaptation to allow an input signal to exceed the +3.3V V_DD level, you risk burning out a protection diode in the chip. In the datasheet, look for special mention of the ability to operate input signals above their supply voltage. The CMOS chips CD4049UBC (inverter) and CD4050BC (buffer) both possess this talent, along with the previously discussed 74LVC244 and 74LVC245 devices.

Converting 3 Volts to 5 Volts with the HCT Family

Now you can turn your attention to converting a 3V signal into the higher-level 5V signal. Here you turn to a different series family member. Previously the LVC family was used, but here you must use an HCT family.

The main reason for this is that you must power the device from 5 volts in order for it to have an output swing from 0 to 5 volts. Its outputs must match the receiving TTL input levels (V_IL of 0.8 volts maximum and V_IH of 2.0 volts minimum). Let’s first review the 74HCT245 device.

74HCT245

The main trick, however, is that the 74HCT245 device itself must accommodate a low enough input V_IH for the driving Raspberry Pi. Normally the CMOS high level (70 percent of 5 volts) would mean a V_IH of 3.5 volts. This is higher than the Pi can produce! But because the HCT family is designed to accept TTL input levels, you can count on its V_IH to be 2.0 volts instead. This is the special talent of the HCT family.

To make this easier to visualize, examine Figure 2-11. Notice that the 74HCT245 is being supplied by 5 volts this time, allowing its output to range from 0 to 5 volts. Even though the input to the 74HCT245 can go as high as 5 volts, the Pi will never deliver more than +3.3 volts. This is why it is important that the V_IH of the 74HCT245 is as low as 2 volts. Notice from the CMOS device on the left, sending to the '245 in the center and driving the TTL device at the right, the signal parameters are exceeded at every turn. By having this “noise margin,” a small noise blip on the signal won’t push it out of spec and cause erroneous readings.

Figure 2-11. 3V CMOS to 5V TTL conversion

A couple of notes about Figure 2-11 are in order.

• The V_OL and V_IL were estimated values for the CD4001 operating at +3.3 volts (Fairchild lists only the values for 5V operation).

• The Raspberry Pi’s output parameters are expected to be similar to the CD4001, though they are not actually provided by Broadcom.

To test this in a simple manner, the circuit in Figure 2-12 was breadboarded to illustrate the signal conversion from the Pi GPIO to the TTL signal. The output of the two-input NOR gate (IC2A) is used to simulate the output of the Raspberry Pi in this experiment. IC2A is supplied by a +3.3V power supply like the Pi would supply.

Figure 2-12. 3V to 5V conversion circuit

IC1 is the 74HCT245 device, which is powered from +5.0 volts in this circuit. This allows the output of the device to swing between 0 volts and 5 volts to drive the TTL device. The TTL input would be connected to the terminal “OUTPUT” in Figure 2-12.

Table 2-12 summarizes the experimental measurements. When the CD4001 supplied a 3V system high (+3.30 volts), the output of the 74HCT245 was +5.03 volts. When the CD4001 supplied a logic 0, the 74HCT245 supplied a low of +0.004 volts. These represent excellent results.

Table 2-12. Measured 74HCT245 Voltages

CD4001 VDD	CD4001 Inputs	CD4001 Output	74HCT245 VDD	74HCT245 In	74HCT245 Out
+3.30 volts	Gnd	+3.30 volts	+5.03 volts	+3.30 volts	+5.03 volts
	+5.03 volts	+0.0010 volts		+0.0010 volts	+0.004 volts

Switching Speed

One parameter that I have avoided discussing is the switching speed of various devices. For driving LEDs and motors, speed may not be critical. You might desire higher data rates for SPI interfaces, on the other hand. The question naturally arises, how fast can my device go?

The datasheets won’t answer this directly. They do, however, provide the following parameters:

• t_PHL: Propagation delay time, high to low

• t_PLH: Propagation delay time, low to high

The Fairchild CD4001 datasheet lists these values, as shown in Table 2-13.

For this device, both parameters have the same times, but they need not be identical (these are the values listed for 5V operation). So, the absolute maximum speed these devices can signal from low to high and low again can be calculated as follows:

But this is not all there is to it because the signal must usually hold for a time in one state or the other. The actual rate could easily be half or less. If, for example, the high state hold time is 50ns, the rate reduces to the following:

The NXP 74LVC244 datasheet specifies in a small print note that “t_pd is the same as t_PHL and t_PLH.” They list t_pd with a maximum of 7.5ns for this device at 3.3 volts. So, what is the absolute maximum frequency for this device?

Notice the difference in signal rate. Again, this does not take hold times into account, but knowing the absolute limit is helpful in planning. As Clint Eastwood said (as Harry Callahan), “A man’s got to know his limitations.”

Summary

This chapter has been a little intense about signals, levels, voltages, and parameters. This was designed to help you understand the critical issues involved. If you don’t yet have a mastery of digital electronics, then you’d still be well served with the following simple advice:

• When converting from 5 volts down to 3 volts, use the 74LVC244 device (or 74LVC245), powered by +3.3 volts.

• When converting from a 3V signal up to 5 volts, use the 74HCT244 device (or 74HCT245), powered by the 5V supply.

• When considering alternative devices, don’t forget to evaluate their switching speeds. Many older devices are much slower than today’s devices.

• Never connect a 5V device directly to a 3V device.

The knowledgeable electronics practitioner will know some other alternatives. But the LVC and HCT family solutions presented are simple, economical, and reliable for the Raspberry Pi enthusiast. For each '244 you get eight level shifters in one chip.

Bibliography

1. “Logic Voltage Levels.” Wikipedia. Wikimedia Foundation, n.d. Web. 17 Apr. 2016. < https://en.wikipedia.org/wiki/Logic_level >.

2. Lancaster, Don, and Howard M. Berlin. CMOS Cookbook. 2nd ed. Indianapolis, IN: Sams, 1988. Print. p19.

3. “7400 Series.” Wikipedia. Wikimedia Foundation, n.d. Web. 02 Apr. 2016. < https://en.wikipedia.org/wiki/7400_series >.

4. Lancaster, Don, and Howard M. Berlin. CMOS Cookbook. 2nd ed. Indianapolis, IN: Sams, 1988. Print. p21.

5. “CD4049UBC – CD4050BC Hex Inverting Buffer – Hex Non-Inverting Buffer.” Fairchild Semiconductor, n.d. Web. 18 Apr. 2016. < https://www.fairchildsemi.com/datasheets/CD/CD4049UBC.pdf >.

VGA Converters

One of the great things about the Raspberry Pi Zero is that you get a video interface for free (or split the Zero’s price of $5 in two: $2.50 for the Broadcom video core and $2.50 for the CPU). This is a spectacular feature that cannot be matched in the Arduino world.

Using the Pi’s video interface naturally requires a monitor. This chapter explores how to use a VGA monitor on a Raspberry Pi using a VGA converter. VGA monitors can be a bit finicky, however, so I’ll also discuss video settings to allow you tune your Pi to match the monitor.

I purchased an HDMI to VGA converter on eBay for the unbelievable price of $2.80. My own experience with it so far has been very good. There doesn’t seem to be any manufacturer information on the outside. It is possible that it has not been tested against the North American and European radio emissions standards, so buyer beware.

The unit I purchased includes an electronic converter circuit, which obtains its power from the HDMI cable. The only suitable unit that I am aware of looks like the one in Figure 3-1.

Figure 3-1. HDMI to VGA adapter

I already owned several VGA monitors, but I wondered about general VGA monitor availability. They are bound to be more plentiful presently given that everyone is switching to HDMI monitors. A search on Kijiji quickly confirmed that they can be had for as little as $20 (and probably less by the time you read this). For example, one $20 monitor I found being sold was a Samsung SyncMaster 193V 19-inch LCD monitor. The native resolution was 1280×1024. Such a deal!

With a VGA converter and a cheap VGA monitor, you can strap the Pi on the back of the monitor and have a cheap self-contained display terminal. With the Pi 3, you could have a self-contained Linux terminal with WiFi and Bluetooth.

Resolution and Refresh Rates

Despite that the converter does the heavy lifting, you may need to make some adjustments to the Pi’s display mode to be compatible with your VGA prize. Consider the following monitor spec-related items:

• Native and supported resolutions (for example, 1280×1024)

• Vertical refresh rate (for example, 75Hz)

• Horizontal refresh rate (for example, 81kHz)

If your monitor supports 1024×768 or greater resolution, you may find that you can use the default Pi settings. Install the adapter and boot up the Pi to see whether it works.

If not, don’t give up yet—you may be able to reconfigure the Pi for a lower resolution. The flexibility of Broadcom VideoCore is amazing when you consider the price of the $5 Raspberry Pi Zero or other Pi model.

/boot/config.txt

The all-important config.txt file is located in your /boot partition. Edit that file carefully to instruct the Pi to use different video configurations.

Some have suggested that you need to set the parameter hdmi_force_hotplug=1. I left it commented out in my own testing and didn’t need it. However, if you get a black screen, you may want to set it by uncommenting the parameter line to read as follows:

hdmi_force_hotplug=1              

These are the parameters of main concern for your monitor:

• hdmi_group

• hdmi_mode

The hdmi_group parameter can take one of three values from Table 3-1.

The hdmi_mode parameter is much more comprehensive in the range of values possible. Table 3-2 lists hdmi_mode values that are possible when hdmi_group=1 (CEA).

Table 3-3 lists the modifiers used in Table 3-2.

The hdmi_mode values listed in Table 3-4 apply when htmi_group=2 (DMT) [1].

There is a pixel clock limit that limits the highest resolution to 1920×1200 at 60Hz with reduced blanking [2].

After making changes to your /boot/config.txt file, be sure to sync the file system to flush out unwritten disk file changes (even though the system shutdown should normally take care of this). After a reboot, you should be able to test your VGA monitor hookup.

Confirming Resolution

Sometimes after a bootup it is obvious what the new resolution is. At other times, the change can be subtle, leaving you to wonder whether anything actually changed. So, how do you confirm?

The frame buffer set command (fbset), when used with the -s option, can show you information about the current display mode. The following was displayed when I attached my Dell 1707FPT monitor and allowed the Raspberry Pi to default for the display:

$ fbset -s
mode "1280x1024"
    geometry 1280 1024 1280 1024 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

When configured for low-resolution VGA, I was able to boot with this display mode using a lesser monitor:

$ fbset -s
mode "640x480"
    geometry 640 480 640 480 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

When choosing video modes for your monitor, be sure to stay within the refresh rate limits of your monitor. They need not be exact, but vertical refresh rates should be close to, but not exceed, the rating.

Summary

The Raspberry Pi Zero is great for its size and price. Attach a low-cost VGA monitor, and you can create a killer project for cheap. The Zero or Pi 3 is small enough that it might even mount the unit inside of the monitor casing. Be sure to check out your local used market for VGA deals. You may even find friends or family willing to give you VGA monitors, knowing that you have a use for them.

Bibliography

1. “RPiconfig.” RPiconfig. N.p., n.d. Web. 30 Jan. 2016. < http://elinux.org/RPiconfig >.

2. “Raspberry Pi: Does RPi Support Resolution of 2560x1440?” Raspberry Pi: Does RPi Support Resolution of 2560x1440? N.p., n.d. Web. 30 Jan. 2016. < www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=20155&p=195417&hilit=2560x1600#p195443 >.

LCD Module 1602A

A search on eBay shows that the 1602A LCD module can be purchased for as little as $1.71 (the “Buy It Now” price). Figure 4-1 illustrates the topside of the unit, with its connections along the bottom.

Figure 4-1. The top of the 1602A LCD module

Figure 4-2 shows the bottom side of the module. The bottom side shows that connector CON1 has 16 connections. The number of connections is a nuisance from a wiring and interfacing standpoint, but there is a solution for that.

Figure 4-2. The bottom side of the 1602A LCD module

The logic and the LCD portions of this PCB require 5 volts, which makes this a little bit of a challenge for the Pi. But there is a solution for that too. The unit includes backlighting, so you must add the current for the logic plus the backlighting when planning your power requirements. The figures seem to vary depending upon the manufacturer, but one datasheet lists the current as 150mA for the logic plus another 100mA for the backlighting. So, this unit is likely to draw about 250mA total from your Pi’s 5V supply.

The 1602A module uses eight data lines and three control lines for data transfers. That would require 11 GPIO lines to be allocated from the Pi. However, it is possible to operate the module in 4-bit mode instead. This still requires seven GPIO lines, which is inconvenient.

To work around this problem, there is a nice I2C adapter module that can be economically purchased and used.

I2C Serial Interface

The module I purchased on eBay was titled “Black Arduino 1602LCD Compatible Serial Interface (IIC/I2C/TWI/SPI) Board Module.” The SPI in the title is bogus, since this is an I2C module. The module is based upon the PCF8574 chip, for which you can also obtain a datasheet.

To find the module on eBay, search for 1602 serial module. I usually check the “Buy It Now” option so that there is no need to mess around with auctions and wait times. These modules can be purchased for as little as $1.10. Figure 4-3 illustrates the module that I purchased.

Figure 4-3. The I2C Serial Interface module with the PCF8574 chip at the center. Pin 1 is at the right side, despite the silk screen.

The module has three solderable jumpers marked A0, A1, and A2 (on the bottom right of Figure 4-3). Since CMOS inputs must not be left floating, there are pull-up resistors on the board. Based upon resistance readings taken, it appears that the three surface mount resistors marked “103” are the 10kΩ pull-up resistors to each of the address inputs. Soldering in a shorting jumper will change the address input to a logic 0.

Without any jumpers installed, this I2C PCB will respond to I2C address 27 hexadecimal (hex). With all jumpers installed, the I2C address changes to hex 20. If you should get a unit with the PCF8574A instead, the I2C address changes to 3F hex, with no jumpers or 38 with jumpers installed.

I have been unable to find a schematic for this exact PCB, but measuring between the VCC connection and the SDA or SCL connections confirms a resistance of 4–7kΩ (you can see resistors labeled “472” on the PCB). This evidence of a pull-up resistor is bad news for 3.3V operation because VCC on the PCB will be connected to 5 volts when used with the LCD module. The serial interface PCF8574 chip is able to operate from 3.3 volts, however, so before you connect it to the LCD module, let’s check the I2C module to see whether the unit is functional and usable by the Pi.

I2C Module Configuration

The PCF8574 peripheral is rather unique in that it does not require any formal configuration. The datasheet specifies that its ports are quasi-bidirectional. So, how does this work?

To set an output, you simply write a bit pattern to the outputs over the I2C bus. Pins written with a 1 bit turn off their pull-down transistor and cause the pull-up current source to bring the output pin high. This pull-up current source is weak, supporting only 100μA. The NXP documentation indicates, however, that there is an accelerated strong pull-up that is active during the high time of the I2C acknowledge clock cycle. This briefly helps the output turn sharply high at the right time but requires only 100μA to maintain that state after. This works fine for interfacing to CMOS input signals. But because of the weak high-side drive, the ports cannot source current into LEDs.

Output ports that are written with a 0 bit cause their pull-down transistor to activate to conduct port current to ground level. This driven output can sink up to 25mA of current, though the chip total must not exceed 80mA. This makes the port capable of driving LEDs when the ports are used to sink LED current.

To be able to read an input, there is a cheat step required: the port must first be written with a 1 bit so that its weak pull-up current source can allow the port to rise high. Then the component driving the input can pull the voltage down to ground level when transmitting a 0 bit to the input. When a 1 bit is transmitted to the port, the signal is simply brought high again with some assistance from the weak pull-up current source.

If the input port was left in the output 0 bit state, the port’s output driver transistor would keep that port grounded. To indicate a 1 bit, the component driving this input would have to overcome this with a struggle. This could result in high currents and potential damage.

I2C Module Output

Figure 4-4 is a generic schematic of the different I2C modules available. For this experiment, don’t attach the LCD display yet, since the display module will not function on 3.3 volts. But the wiring of the unit is important to note because you need to know where the port pins appear on the edge of the PCB.

Figure 4-4. Generic schematic of the 1602 I2C adapter PCB

From Figure 4-4 you can see that four of the outputs go to pins 11 to 14 of the 16-pin header strip. These will be used to send four bits at a time to the LCD module. These are port bits 4 through 7, respectively. Three of the four remaining bits go to the LCD interface pins 4, 5, and 6 to control the information handshaking. These are pins 0 through 2, respectively, with port pin 3 left unconnected (on some LCD modules, pin 3 switches backlighting on or off).

Table 4-1 summarizes the port pins and the corresponding LCD pins for your convenience.

Let’s first verify that the I2C bus is available, as shown here:

$ i2cdetect -l
i2c-1 i2c        3f804000.i2c                     I2C adapter

If i2cdetect is not installed, then install it now, as shown here:

$ sudo apt-get install i2c-tools

Now that you have confirmed that the I2c-1 bus is available, attach the serial module (without the LCD connected). Connect the V _CC to the Pi’s 3.3V supply and GND to the Pi’s ground. Finally, connect SDA and SCL to the Pi’s SDA and SCL connections, respectively (the T-Cobbler silk screen should identify these plainly).

With this wired up, start your Pi and perform the following scan of I2C bus 1, as shown here:

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

The session output confirms that the I2C device is seen as address 27 (hex). This is a good sign that the device is working. If you have a different model of the PCB, you may find the unit at a different address, perhaps 3F. Substitute your address in the tests that follow.

Change to the subdirectory pcf8574 in the supplied source code. Perform a make command (if not already performed), which should leave you with an executable named i2cio. The command takes optional arguments, which are explained with the use of the help (-h) option.

$ ./i2cio -h
./i2cio [-a address] [-i pins] [-h] [out_value1...]
where:
       -a address  Specify I2C address
       -i 0xHex    Specify input port pins (0=none=default)
       -h          Help

If your unit was found at a different address than the default hexadecimal address of 27, then you will need to supply that in the commands afterward with the option -a.

I recommend doing this experiment with Dupont wires only since it is easy to cause a short circuit and ruin something. Either place the PCB module on the breadboard and connect to it through the breadboard or locate some male/female Dupont wires to safely attach your connections.

Connect the negative lead of your voltmeter/DMM to the ground of the Pi. Using the plus lead of the DMM, measure the voltage present at pin 14 of the 16×1 header strip. You should measure either 3.3 volts or 0 volts. Now run the following command (substituting for the I2C address if necessary). Do not omit 0x where it appears, as this specifies that the number is in hexadecimal notation.

$ ./i2cio -a0x27 0x80
I2C Wrote: 0x80

This command writes the hex value 80 to the I2C port at address 27. After this runs, you should measure approximately 3.3 volts at pin 14. If you don’t get that, then check that you have the correct pin. My PCB unit marks pin 16 with a square, suggesting it is pin 1, but this is actually pin 16.

To confirm the port’s operation, let’s now write a 0 out.

$ ./i2cio -a0x27 0
I2C Wrote: 0x00

After the message I2C Wrote: 0x00, you should immediately see the voltage go to 0 on pin 14. This confirms the following:

• That the unit is operating and responding to the I2C address you specified

• That port bit 7 corresponds to connection 14 on the header strip

• That you know which end of the header strip is pin 1

This last item is important since it is easy to get this wrong. Cheap clones of the original board are being made all the time, and important matters like this are often incorrect or mislabeled.

Now check bit 4, using the value 0x10, followed by setting it to 0. Did pin 11 on the PCB module obey? Finally, using the value 0x01, does the RS signal (header pin 4) measure the correct changes?

I2C Module Input

Having succeeded in performing I2C output to the module, it is now time to try input. Connect a Dupont wire to header pin 14 (DB7) and the other end to your breadboard. Just leave it unconnected for the moment and perform this test:

$ ./i2cio -a0x27 -i0x80
I2C Read: 0x80 (Inputs: 80)

By adding the option -i0x80, you have made bit 7 an input. This was done by first setting the output bit to a 1 so that inputs could be performed on it. The command then performs a read and reports what it read. In this case, only the high bit is significant, and since 0x80 indicates a high value, you know the input bit was a 1.

If you don’t want to see the other bits, you can force the others to 0 by doing an output first and then repeating the following:

$ ./i2cio -a0x27 0
I2C Wrote: 0x00
$ ./i2cio -a0x27 -i0x80
I2C Read: 0x80 (Inputs: 80)

After setting all output bits to 0, only the input should ever show up as a 1 bit.

Before running the command again, connect your input Dupont wire to ground. When you perform the read test this time, the reading should change, as shown here:

$ ./i2cio -a0x27 -i0x80
I2C Read: 0x00 (Inputs: 80)

Again, only the high bit (7) is significant since that is the only input you’re polling. You can see from the value reported that the grounding of that pin caused the command to read 0. Unground the Dupont wire and repeat. Did the read value change back to 0x80?

PCF8574P Chip

From the preceding experiments you can see that this module can be used as a cheap and nearly configuration-free I2C GPIO extender. The main issue is that the PCB is designed to work with the 1602A LCD. This might mean that only seven of the eight GPIOs are brought out to the header strip (the blanking bit may be supported, however, to make eight).

The PCF8574P chip is available in the plastic DIP form from various sources including eBay, for as little as $0.66. Since this chip will operate at 3.3 volts, it is a good trick to keep in your back pocket when adding GPIOs to the Raspberry Pi. With no complicated software configuration required, it is quite easy to use. Just keep in mind that when driving a current load (like an LED), always arrange the port to sink the current.

3 Volts to 5 Volts

The LCD module must operate at 5 volts. So, now you must cross that digital divide from the 3.3V realm to the 5V TTL world. Note that Chapter 2’s techniques do not apply to the I2C bus, so you must find another way to do this. Figure 4-5 shows a tiny little level converter with the header strips installed. On eBay, you can purchase these for a “Buy It Now” price of $0.99.

Figure 4-5. Topside of I2C level converter with header strips installed

Figure 4-6 shows the bottom-side silk screen. There is a 3V output derived from the 5V input, shown on the top right of the figure. But I recommend you use that as a last resort. Use the Pi’s 3.3V power instead because I have found that this connection can be higher than it should be. If you do use it, the silk screen indicates that it is limited to 150mA.

Figure 4-6. Bottom side of I2C level converter

There are four remaining pins on the left and right sides. The idea is that on one side you have your 5V signals and on the right are the 3.3V signals. This device is bidirectional, using MOSFET transistors to do the level conversions. For these purposes, you need the I2C SDA and SCL lines converted.

To keep the various systems in perspective, Figure 4-7 illustrates the signal realms involved, including the Raspberry Pi on the left, the level converter at the center, and the 5V I2C serial module for the LCD on the right.

Figure 4-7. Block diagram of Raspberry Pi, I2C level converter, and I2C serial module

The dashed lines of Figure 4-7 illustrate the I2C signals as they progress from the Pi to the I2C serial module at the right. Except for the fact that this level conversion adds another module to the mix, the circuit remains otherwise simple. The two I2C signals SDA and SCL are all that are required to communicate with the LCD module.

Attaching the I2C Serial Module

Take a good look at Figures 4-2 and 4-3. Note particularly where pin 1 of CON1 is shown in Figure 4-2. This pin is near the mounting hole in the upper right of the photo. This is where pin 1 of the I2C serial adapter needs to go.

On my serial adapter, the silk-screen square is shown at the top left. This is incorrect! Using a DMM, I was able to confirm that V0, which is pin 3, is actually the third pin from the top right of Figure 4-3. I seem to have a clone of the original design where they botched the silk screening. The PCB square should have been at the top right instead. I mention this to save you a lot of agony. Once the PCB is soldered to the LCD module, it is difficult to separate them. Take your time getting the orientation correct before you plug in that soldering iron.

Figure 4-8 shows the I2C module installed on the LCD module. The power and the two I2C connectors should be located at the upper right. I put a piece of electrical tape underneath the I2C module before soldering it in place. This will keep bare connections from bumping into connections on the LCD module.

Figure 4-8. I2C module attached to LCD module

I like to test things as I go since this saves a lot of troubleshooting effort when things go wrong and provides a confidence boost when things are going right. The best way to do this is to yank the microSD card out of the Pi so that it doesn’t boot. That way, if something goes wrong, you can yank the power without having to worry about corrupting the microSD card. It also saves you from having to do a formal shutdown when you’re done testing.

As part of this test, adjust the potentiometer so that you start to see the character cells in the display. You’ll likely readjust again, once text is shown on the display later. My LCD module initialized such that one line of cells was showing. Yours may show a different pattern. Even if you get no pattern at all, don’t panic about it until you try sending data to it under software control.

If you want to take a current reading, this is a good time to do it. While my LCD was operating under test in Figure 4-9, I measured about 87mA of current. On the I2C module, there is a jumper at one end. Removing it turns off the backlighting for the module by disconnecting the power for it. Once I did this, the current dropped to about 6mA. If you have a battery-operated system, you could save power this way.

Figure 4-9. The LCD powered from the Pi’s 5V supply, supplied through the I2C module on the back

The next step is to hook up the I2C level converter. Wire the Pi’s +5 volt to the level converter’s 5V input and its ground to ground. Also connect the serial module SDA and SCL lines to the 5V side of the level converter, but save the 3.3V SDA and SCL for later. Leave those unconnected. Using your voltmeter/DMM, measure the 3.3V SDA and SCL pins on the level converter when powered. You should get a reading near 3.3 volts. If you read something else, you need to investigate. If the voltage reads higher than +3.6 volts, then don’t go any further since hookup could damage your Pi’s GPIO ports. Once you have good readings, you are clear to connect the Pi’s SDA and SCL ports to the level converter’s 3.3V side.

Displaying Data

Once everything is wired, you are ready to display some data on the LCD. Figure 4-10 illustrates the LCD connected to the Pi with some text displayed. In the subdirectory pcf8574, there is a program named lcd.cpp that should have been built as executable lcd. If the executable does not yet exist, type the make command now to build it.

Figure 4-10. Final hookup with I2C level converter

Invoke the command simply as follows:

$ ./lcd

If all went well, you should see the same text as displayed in Figure 4-10. The trickiest part is getting the LCD module to initialize, partly because you must operate in the LCD controller’s 4-bit mode.

The initialization procedure for 4-bit operation is a little strange. The HD44780 controller chip used by the display always powers on in the 8-bit communication mode. Because you are going through the PCF8574 and using four of those bits for controlling the signal handshaking, only the upper four data bits are being seen by the controller when you write to it.

Inside the class method LCD1602::initialize(), the following is done to coax the LCD controller into using 4-bit mode. The reusable source files are lcd1602.cpp and lcd1602.hpp, should you want to use it in your own code.

165     usleep(20000);          // 20 ms
166     lcd_write4(0x30);       // 8-bit mode initialize
167     usleep(10000);          // 10 ms
168     lcd_write4(0x30);
169     usleep(1000);           // 1 ms
170     lcd_write4(0x30);
171     usleep(1000);           // 1 ms
172     lcd_write4(0x20);       // 4-bit mode initialize
173     usleep(1000);           // 1 ms

Line 165 just begins with a delay in case there was recent activity with the display. Line 166 calls upon internal class method lcd_write4() to write out the 8-bit command 3X, where X represents garbage (likely seen as 3F by the controller). You do this three times and then finally set the mode you really want in line 172. This sets the controller into 4-bit mode.

After this point, all 8 bits of a command or data byte are sent as two back-to-back 4-bit writes (using the method lcd_cmd() or lcd_data()). Each write is preceded by a busy check, by reading from the controller. When it reads that bit 7 is no longer a 1, it then knows that it is safe to write into the controller again. This is performed in method lcd_ready() for the curious.

Reading from the LCD1602

Except for the initialization sequence, the code driving the LCD does not use delays. This has the benefit of increasing the data rate to almost as fast as the device will accept it. The initialization sequence, however, requires the use of delays since the controller does not provide any busy status during that time. Once initialized, there is a busy status flag that can be read.

Reading the status from the LCD controller is tricky when conversing through the PCF8574 in 4-bit nibbles. Recall that to read an input from the PCF8574, you must first write a 1 bit to the pin first. Since the status is available immediately after an LCD command write, you have to be careful in how you perform this.

Steps 1 through 4 are all that are required to send an 8-bit command to the LCD controller through the PCF8574 chip (Table 4-2). Some LCD commands, however, such as “clear screen,” require extra time to complete. If you sent another command byte during this busy period, the command would be ignored. You could use a programmed delay, but different LCD commands take different amounts of time. It is best to have the LCD controller tell you when it is no longer busy.

Before you look at the read cycle, I’ll explain what happened during the write steps. Step 1 sets the BL bit to 1 if you want to keep the backlighting enabled. This bit is ignored if the I2C adapter doesn’t support this feature. The RS=0 bit indicates that a command byte is being sent. Bit RW=0 indicates to the LCD controller that a write operation is being performed. Finally, E=1 prepares the LCD controller to receive 4 bits of data on bits 7, 6, 5, and 4. In 4-bit handshaking, the remaining bits of the data bus are ignored. Keep in mind that these bits are being written over the I2C bus into the PCF8574 chip and appearing at the chip’s own GPIO pins, which are interfaced to the LCD module (review Figure 4-7).

No data is captured in the LCD controller yet, until step 2. In this step, the signal E=0 is established (by another I2C write operation). The transition from E=1 to E=0 clocks the data into the controller (the high nibble). Steps 3 and 4 repeat steps 1 and 2, except that the low-order nibble is transmitted. Once step 4 has completed, the LCD controller has received eight bits of command data and begins to carry it out.

To know when it is safe to send another command (or data), you must ask the LCD controller for the BF (busy flag) status bit. To prepare for a read from the PCF8574, you must first write 1 bits to bits 7, 6, 5, and 4, where you expect data. Additionally, RW=1 is established to warn the LCD controller that you will be performing a read operation. This is what step 5 is all about.

Nothing happens on the LCD controller until it sees the E signal change from 0 to 1 in step 6. At this transition, the controller puts the status byte out to its data lines. At this point, the controller is driving bits 7, 6, 5, and 4 of the PCF8574 pins. Step 7 tells the PCF8574 chip to take a reading and send it back to the Pi on the I2C bus. Table 4-2 has an X marked in the remaining positions as “don’t care.” You are only receiving data transferred in the upper nibble of this byte read.

Steps 8 through 10 repeat steps 5 through 7, except this time the lower nibble of data is transferred. Step 11 ends the read cycle and informs the LCD controller you are done.

Now the BF flag is examined. When BF=1, the LCD controller is still busy carrying out the last command. The Pi program then repeats again starting from step 6. This repeats until the controller finally returns BF=0, indicating “ready.”

How long does all of this take? With I2C operating at 100kHz, each byte takes approximately the following amount of time:

There is a start bit, eight data bits, and one stop bit for each I2C byte written to the PCF8574. So, assuming you don’t receive BF=1, the write followed by a status read should take approximately this long:

This means you can issue approximately 909 LCD commands per second, ignoring busy wait times. From my own testing, I found that most commands do not incur any busy time because of the time involved in the I2C traffic. The only instance I encountered where BF=1 was in clearing the screen. Given that it takes seven I2C cycles to read the LCD status, this results in a delay of 100 × 7 = 700μsec of time. Most LCD commands complete in much shorter times (consult the HD44780 controller datasheet for actual times).

Given these facts, it is tempting to program delays instead. But it is best to consult the BF status flag because if the LCD controller should miss a command or data byte, you would have no knowledge of it in your program. The display would continue in a messed-up state until it was reset by your code.

Class LCD1602

I2C programming is covered in Chapter 11, so I won’t repeat that here. However, the source code includes the following two files in the pcf8574 subdirectory:

• lcd1602.hpp

• lcd1602.cpp

Include the class definition in your program with the following:

#include "lcd1602.hpp"

Then you can make use of the LCD1602 class to interact with your display. To instantiate the class, you code it with the optional I2C address and bus number, as shown here:

LCD1602 lcd(0x27,1); // I2C address and bus number

After this, you need to initialize it only once, as shown here:

if ( !lcd.initialize() ) {
    fprintf(stderr,
        "%s: Initializing LCD1602 at I2C bus %s, address 0x%02X\n",
        strerror(errno),
        lcd.get_busdev(),
        lcd.get_address());
    exit(1);
}

From that point on, in your own code you can invoke the public functions such as lcd.clear() and lcd.putstr(). The following is a summary of the public members of the LCD1602 class:

class LCD1602 {
        ...
public: LCD1602(unsigned i2c_addr=0x27,unsigned bus=1);
        ∼LCD1602();

        const char *get_busdev() const  { return busdev.c_str(); };
        unsigned get_bus() const        { return i2c_bus; }
        unsigned get_address() const    { return i2c_addr; }

        bool initialize();              // Initialize the LCD
        bool lcd_ready();

        bool lcd_cmd(uint8_t byte)      { return lcd_write(byte,true); }
        bool lcd_data(uint8_t byte)     { return lcd_write(byte,false); }

        bool clear();
        bool home();
        bool moveto(unsigned y,unsigned x);

        bool putstr(const char *str);

        bool set_display(bool on=true);
        bool set_blink(bool on=true);
        bool set_backlight(bool on=true);
        bool set_cursor(bool on=true);

        bool get_display() const        { return display; };
        bool get_blink() const          { return blink; };
        bool get_backlight() const      { return backlight; };
        bool get_cursor() const         { return cursor; };
};

If you want to learn more about the features of the LCD module, locate the HD44780 controller’s datasheet in PDF form. That document will describe all the commands and features supported by the controller.

I2C Baud Rate

Throughout this book, the default system I2C baud rate is used. You can discover what that rate is with the following command:

$ dmesg | grep -i i2c
[5.102698] bcm2708_i2c 3f804000.i2c: \
           BSC1 Controller at 0x3f804000 (irq 83) (baudrate 100000)

From this you can see that the I2C driver initialized with the baud rate of 100kHz (100,000). This is not particularly fast but is considered reliable. The I2C level shifter used in this chapter also limits the reliability of the connection and probably shouldn’t be pushed much higher. Despite the I2C bus operating at 100kHz and using 4-bit I/O transfers, you’ll still find that the display is responsive. A simple LCD command structure and the fact that the display holds only 32 characters means that the I/O system is not unduly taxed.

Profit and Loss

In this chapter’s project, you used a level translator and a PCF8574 I2C extender on a PCB to communicate with the 1602 LCD module. Let’s review some of the pros and cons of doing this.

Here are the pros:

• Only two lines are needed for communicating to the LCD from the Pi.

• I2C allows a few meters of distance between the Pi and LCD.

• Only two GPIOs are required from the Pi side.

• The PCF8574 I2C module might provide backlighting control.

• The 1602 LCD, PCF8574 PCB, and level translator are all inexpensive.

Here are the cons:

• The method requires commanding the LCD module in 4-bit mode.

• The PCF8574 I2C module is slower driving the LCD.

• The LCD module is 5 volts, requiring a level translator.

• Configuration of the LCD is limited.

Certainly there is some complexity involved with the added components, but the overall cost is low. Because communication occurs over the I2C bus, the LCD can be a few meters away from the Pi itself.

The one negative I saw was that there seems to be no way to configure the LCD module for other modes of operation in 4-bit data transfer mode. The command 0x20 is used to put the LCD controller into 4-bit mode (note that this is sent in 8-bit mode). This works because the 2 in 20 is in the upper nibble that the controller can see. But the lower nibble of that “function set” command consists of the N and F bits that allow two-line (N=1) or one-line (N=0) displays and a 5 × 10 dots (F=1) or 5 × 10 dots (F=0) font.

In my own experiments, the configuration always went to N=1, leaving F to be ignored (the LCD won’t do two-line displays with the larger font). I suspect that this is the result of the low nibble signals being pulled high by the LCD module (these are unconnected). This results in the controller seeing N=1. This is not too much of a hardship given that most people will want the two-line display more than the larger font in one line.

Summary

This chapter covered a lot of ground, partly because of the challenges faced by using a 5V I2C part. Additionally, the PCF8574 GPIO extender was applied to reduce the number of lines required to drive the display. By using the I2C communication bus, it becomes possible for your LCD display to be a few meters away from the Pi. The best part is that the LCD display is cheap, is readily available, and requires only power and two lines of communication.

Hardware: MC14490

Several potential hardware solutions are possible, but one of the best approaches uses a low-cost IC designed for the purpose. While the part is now considered obsolete, it is still available from various suppliers including eBay ($1.12 with free shipping). Keep in mind that this 16-pin DIP provides debouncing for six inputs. At 17 cents per input, the price is right!

The MC14490 is a CMOS device and can operate from 3 volts up to 18 volts. This makes it an easy sell for Pi projects using the +3.3V power supply. Finally, only one external component is required, making this an easy chip to wire up or breadboard. Be sure to take this chip for a test run.

Figure 5-2 shows the basic circuit with the debounced outputs AOUT through FOUT available for reading directly into Pi GPIO input ports. Also shown in the diagram is the +3.3V regulated Pi power to pin 16 (V _DD ) and the power grounded at pin 8 (V _SS ). In normal operation, the chip requires much less than 1mA and will not stress your Pi’s supply in the least.

Figure 5-2. MC14490 circuit with up to six inputs and debounced outputs

Two switches (or buttons) are shown in the figure, with S1 connected to signal AIN and S2 connected to FIN. These are the inputs to AOUT and FOUT, respectively. An additional four inputs could be added to the unused pins. Normally CMOS requires that every input be connected so that it is not left floating in voltage. The MC14490 chip is designed, however, with a built-in pull-up resistor for every input. This makes the addition of resistors to the circuit unnecessary. This also allows the unused inputs to be left unconnected. Input pin 7 will have a capacitor attached to it.

Chip Operation

The MC14490 chip is marvelously simple in operation yet very effective. The datasheet for the device illustrates a block diagram consisting mainly of a 4-bit shift register, a -bit delay, and a clock circuit. Each of the six input lanes consists of the same logic.

The operation of the device can be understood more easily in simpler human terms. At each device clock pulse, the current input is compared against the last shifted in input value. If the values differ, the shift register is cleared, and the process starts over. In this way, any bouncing of the contacts will keep clearing the shift register, and no change at the output will occur.

However, if after multiple clock pulses there is no change seen in the input value, the input level bits eventually make it out of the -bit shift register. Once this happens, the debounced output appears on the output pin. That is the procedure in a nutshell.

In reality, the operation is a little more complicated because the shift register clear is actually implemented as a “load” operation. It must set bits all to 0s or all to 1s, depending upon the current state of the output. By doing this, the debounce process works for a signal going high and for one going low.

Capacitor C1

The frequency of the clock is determined by the value chosen for C ₁. The ON Semiconductor datasheet lists formulas to use for various voltages. The lowest voltage formula given is for 5V operation, as shown here, where the value of C ₁ is given in microfarads (μF):

I tried to estimate it for 3.3 volts, but the relationship is not linear across voltages. So, I tried some sample capacitors and hooked up the chip’s pin 9 (OSC _out ) to a frequency counter (Figure 5-3). Using the results in Table 5-1, you won’t need to do the same.

Figure 5-3. An old Fluke 1953A frequency counter used to determine the 3.3V formula for C₁, by measuring frequency

The factor is computed by rearranging the equation given by the datasheet, as shown here:

So, the factor is determined by simple multiplication. When the factor K is computed for each Table 5-1 row, it seems a value between 0.42 and 0.44 works. The fact that they tend to be all about the same value suggests that there is a solution. Now you can compute the approximate frequency for a 3.3V operation with K=0.42, as shown here:

The datasheet tells you that a stable debounced output occurs in -bit shifts. If you used a C ₁ value of 0.00022μF, then your clock frequency is rather high at about 1916Hz. For a frequency of 1916Hz, each cycle takes the following:

Multiplying that figure by 4.5 times gives you about 2.35ms. That is a rather short debouncing period. Scratchy contacts can require up to 50ms of settling time. Using a value of 0.01μF reduces the clock frequency to 44Hz, which provides a debounce period of 102ms. That should more than suffice for the scratchiest of metal contacts.

Experiment

Wire up your Raspberry Pi using a breadboard and the MC14490 chip according to Figure 5-4, except leave the connection between AO on the chip disconnected from the Pi GPIO#16. Attach a Dupont wire to the Pi’s GPIO#16, while leaving the other end unconnected. You’re going to play with that wire.

Figure 5-4. One debounced input hooked up to the Raspberry Pi on GPIO#16

Choose a suitable capacitor C ₁. I recommend you use 0.01μF or slightly less. This value should be fairly responsive and yet immune to bouncing contacts.

Using the gp command, which was installed as part of the software in Chapter 1, monitor the GPIO input pin 16. Select GPIO#16 (-g16), configure it for input (-i), enable the pull-up resistor (-pu), and monitor that pin forever (-m0), until you hit Control-C.

  gp -g16 -i -pu -m0
Monitoring..
000000 GPIO 16 = 1
000001 GPIO 16 = 0
000002 GPIO 16 = 1
000003 GPIO 16 = 0
000004 GPIO 16 = 1

Once the gp command is monitoring, the session output shows the result of scratching your GPIO#16 wire to ground. You might see several hundred changes in the output. This is what your software would see if you placed a scratchy metal contact button on that input. Now let’s let the MC14490 work its magic.

Connect the GPIO#16 to the AO output of the MC14490 (pin 15). Next attach another Dupont wire to the MC14490 AIN input. Now try scratching that wire to ground, off and on. Do you get nice clean 1 and 0 outputs?

If you don’t see it working, then check that the capacitor is properly wired in. Don’t use extremely high-valued capacitors like 1 or more μF (in fact, high-valued capacitors may ruin the chip at power off/on). If your oscillator is operating at a very low frequency, you may have to hold the change for a long time to see the output change. On the other hand, if your changes are occurring immediately, then perhaps the oscillating frequency is too high, providing very short debouncing periods. If still no joy and you lack an oscilloscope or logic analyzer, try the PiSpy program from the book Exploring the Raspberry Pi 2 with C++ (Apress, 2016).

With the circuit performing correctly, you can hook up a push button like the one illustrated in Figure 5-5. This is a simple button that I found to be bad for bouncing contacts. Attached directly to the GPIO input without debouncing, this button is simply unusable.

Figure 5-5. A cheap scratchy push button, with two wires soldered to it

Attach one wire of the push button to ground and the remaining one to the debouncing input AIN (pin 1). Keep the gp command monitoring (or restart it), and now when you press and release the button, you should get clean, distinct 1 and 0 events. Make sure you push the button with enough force if you don’t see any events. Sometimes these cheaply made buttons don’t function well.

More Inputs

You can’t have too many inputs, and clearly six are not always enough. For the price of another MC14490 chip, you can easily add six more debounced inputs. You don’t even need the extra capacitor.

The schematic in Figure 5-6 illustrates how IC1’s oscillator output can be shared with IC2. Both debouncing chips will run at the same frequency and reduce the number of capacitors needed.

Figure 5-6. Two MC14490 chips sharing one oscillator

The schematic can be wired up on your breadboard and tested. Here you move the push button to IC2’s AIN and connect the Pi’s GPIO#16 to IC2’s debounced output on pin 15. Wire it up and test it as before to satisfy yourself that this works.

Figure 5-7 shows the two ICs connected to share one oscillator. The scratchy push button was moved to IC2 to prove that it too operates correctly.

Figure 5-7. Two MC14490 chips sharing one oscillator, interfacing with GPIO#16

If you download and read the ON Semiconductor datasheet, you’ll find that it is possible to do some other tricks with the MC14490. For example, if you use two debouncers and a NOR gate, you can have one input produce a pulse when the button is pressed. This is useful when you need a pulse, even when the end user holds the button down without releasing it.

Software Debouncing

I’ve discussed one hardware solution in this chapter, but if you don’t mind expending some CPU cycles, you can do the same work in software. Here is one fairly simple approach for software:

1. Clear your program state by reading the GPIO input (as v) and then doing one of the following:

   1. Set shiftr to 0 if the input v is a 0 bit.

   2. Set shiftr to all 1 bits when the input v is a 1 bit.

2. At the top of the loop, read the GPIO pin (again) into variable b.

3. Shift shiftr left one bit, and set shiftr.bit_0=b.

4. Examine the lower four bits of shiftr.

   1. Are they all 0 bits? Set s=0.

   2. Are they all 1 bits? Set s=1.

   3. If they’re neither all 0 bits or all 1 bits, repeat the exercise starting with step 2.

5. If s = v, then there is no change. Repeat the exercise starting with step 2.

6. If s ≠ v, then you have a debounced change in signal. Continue with step 7.

7. Now set the debounced signal as v = s.

8. Repeat the loop with step 2.

The idea is that you keep shifting bits into a shift register (shiftr) at regular intervals. When the input stays high or stays low, the bits shifted into the register will all be the same.

Let’s use a concrete example, using eight bits to hold shiftr to illustrate the procedure.

1. 00000000: This is the initial value of shiftr. You also assume that the debounced state is 0.

2. 00000001: The bit shifted in from the right indicates that the input line went high.

3. 00000010: Because of bouncing contacts, you shifted in the next read value, which is low.

4. 00000101: Because of bouncing, the next read value was a high value.

5. 00001011: Read another high value.

   Steps 2 through 4 have sampled the input line four times now. But the low-order bit pattern is currently 1011, which is neither all 1 bits nor all 0s. So, you don’t register any debounced change in value.

6. 00010111: Read another 1 bit (line still high). The low-order bits are 0111, which still does not represent a debounced change.

7. 00101111: Read another 1 bit (line still high). Now when you look at the low-order bits, you see 1111. Because the saved state is 0, this represents a change to the 1 state. You now can set the debounced state to 1.

   From the concrete example, you see that nothing changes until the requisite four lower bits are all 1s. Now as long as you keep reading 1 bits on the line or even mostly 1 bits, the state will never leave the debounced state of 1.

   After a while, the user is going to flip the switch to the opposite state (in this case, grounding the input).

8. 01011110: Read a 0 bit (the line has gone low).

9. 10111101: Read a 1 bit because of bouncing contacts.

10. 01111010: Read a 0 bit (the line has gone low again).

11. 11110100: Read another 0 bit. The lower four bits are 0100, which is nothing special.

12. 11101000: Read another 0 bit. There’s still nothing special about the lower four bits.

13. 11010000 Read another 0-bit. Now the low-order four bits are 0000. This indicates a debounced zero level.

Now you have reached the debounced state for zero.

Whenever the signal waffles between 0 and 1, it pollutes the bit pattern in the shift register so that no action is taken. However, when the signal stabilizes, the bit pattern will be either 0000 or 1111. If the state differs from the pattern, you know that you have a debounced transition.

In this example, I am assuming that you needed four bits. This was arbitrary and inspired by the MC14490 design. I have used three, four, or even five bits depending upon the sampling period and the response time required for various projects.

Experiment

To perform the software signal debouncing experiment, wire up a scratchy push button to your Raspberry Pi, as shown in Figure 5-8.

Figure 5-8. Software push button debouncing experiment

Change to the debounce subdirectory and type make if the software has not yet been compiled yet. This will create the executable program debounce. Run it as follows, once you have the push button wired up:

$ ./debounce
Now debouncing gpio_pin = 16. ^C to exit.
State changed: 1
State changed: 0
State changed: 1
State changed: 0
State changed: 1
State changed: 0
State changed: 1
^C

This session shows several push button presses and releases. Did your scratching push button work like a good one?

Listing 5-1 shows the software listing for debounce.cpp. Lines 016 to 027 of the main program configures GPIO#16 as an input, with the pull-up resistor applied. The pull-up resistor is necessary so that when the push button is not pressed, the open circuit allows the resistor to pull the GPIO line high. Otherwise, the GPIO line would float and sometimes read high and sometimes low. Not a happy situation!

Line 031 initializes the state variables. The value of state just tracks whether the debounced output is high or low. Variable shiftr is the shift register, loading the most recently read bit into the variable from the right (bit 0). Value b is the most recently read bit from GPIO#16.

Line 036 shifts the most recently read bit from the GPIO into the shift register. Old bits are simply shifted out of the register. Line 037 is where the value of m is assigned the lowest four bits from the shift register.

Things get interesting in line 039 where m is tested to see whether the bit pattern is 0000 or 1111. If one of those patterns applies, line 040 tests to see whether the low-order bit matches the current state. A state change occurs only if the line value differs from what you already have established. If there is indeed a change of state, execution proceeds to line 041 where the new state is saved and a message is printed, for demonstration purposes.

Listing 5-1. The debounce.cpp Software Debouncing Program

001 // debounce.cpp
002
003 #include <stdio.h>
004 #include <unistd.h>
005 #include <stdlib.h>
006 #include <string.h>
007 #include <errno.h>
008
009 #include "gpio.hpp"
010
011 static int gpio_pin    = 16;    // Input
012
013 static GPIO gpio;
014
015 int
016 main(int argc,char **argv) {
017   int rc;
018
019   if ( (rc = gpio.get_error()) != 0 ) {
020          fprintf(stderr,"%s: starting gpio (sudo?)\n",strerror(rc));
021          exit(1);
022    }
023
024   gpio.configure(gpio_pin,GPIO::Input);
025   assert(!gpio.get_error());
026   gpio.configure(gpio_pin,GPIO::Up);
027   assert(!gpio.get_error());
028
029   printf("Now debouncing gpio_pin = %d. ^C to exit.\n",gpio_pin);
030
031   int state = 0, shiftr = 0, m, b;
032
033   for (;;) {
034          b = gpio.read(gpio_pin);   // Read bit
035
036           shiftr = (shiftr << 1) | (b & 1);
037           m = shiftr & 0b00001111;  // Mask out low order bits
038
039           if ( m == 0b00001111 || m == 0b00000000 ) {
040                if ( (shiftr & 1) != state ) {
041                      state = shiftr & 1;
042                      printf("State changed: %d\n",state);
043                 }
044          }
045          usleep(10000);
046    }
047
048   return 0;
049 }

Before the loop repeats, you pause the program’s execution in line 045, with a delay of 10,000μsec (10ms). This step is necessary for two reasons.

• Without the delay, the CPU would be consumed in a tight execution loop. This is not only wasteful but will cause your Pi to consume more power and get warmer (did you purchase a heatsink for your Pi 3?).

• You look only at the four lower bits in the shift register (shiftr). If you want to debounce about 40ms of contact bounce and perform this in four samples, then you need to sample about 10ms apart.

So if you want more samples, or quicker response, play with the number of bits and the delay time.

Summary

The MC14490 is a great little chip when you need a hardware solution to debouncing input contacts. These contacts could come from switches, buttons, relays, or reed relay contacts. With the information provided, you will be able to apply this chip at 3.3 volts to the Raspberry Pi and pick the correct capacitor for the type of response you need.

If, however, you decide upon a software solution for debouncing, then the code in this chapter provides a working solution for you.

The YL-40 PCB

This chapter explores the YL-40 PCB, which is about 1 inch by 1.5 inches in size. You might use a different PCB, using the same PCF8591 chip. The YL-40 comes preassembled with header strips and extras that make it easy to use. In addition to the PCF8591 chip’s ability to convert an analog signal into a digital value, it has one digital-to-analog converter (DAC) output channel, which you’ll explore later. Figure 6-1 illustrates the topside of the YL-40 PCB.

Figure 6-1. The YL-40 PCF8591 PCB

Header strip P2 (left) consists of these analog inputs and outputs:

• AOUT (DAC), output

• AIN0 (ADC), input 0

• AIN1 (ADC), input 1

• AIN2 (ADC), input 2

• AIN3 (ADC), input 3

The power is applied on the right through P3 connector pins V_CC and GND (shown on the right of Figure 6-1). Additionally, the I2C signals for SDA and SCL are found at P3. One of the advantages of the PCF8591 chip is that it will operate from 3.3 volts, interfacing nicely with the Raspberry Pi. Figure 6-2 is a schematic of the YL-40 PCB.

Figure 6-2. Schematic of the YL-40 PCB

Three jumpers come installed on the YL-40 that enable or disable extra features.

• Jumper P4, when installed, enables a temperature-sensitive resistance sensor (R₆). On my PCB, this didn’t seem to work (on two PCBs that I purchased). Later in this chapter, I’ll show you how to fix that.

• Jumper P5 enables the light-dependent resistor (LDR) and connects it to AIN0. This jumper can be removed when you want to provide your own analog input to AIN0.

• Jumper P6 connects the wiper arm of potentiometer R₃ to AIN3. Using a small screwdriver, you can turn R₃ clockwise or counterclockwise to cause an analog reading to change. This is extremely useful during initial testing. You can, of course, remove the jumper on P₆ and use AIN3 for any other purpose. Turning R₃ fully clockwise grounds AIN3, while counterclockwise brings AIN3 to V_CC potential.

AIN2 has no jumper and is available at header strip P2. No other component on the PCB is attached to it.

Voltage Range

Because the PCF8591 (YL-40 PCB) is powered from the Raspberry Pi’s 3.3V supply, the analog input voltages must be kept between 0 volts and 3.3 volts. The V_REF is taken from the power supply on the YL-40 PCB. If you’re wiring this up yourself, you have the option of using a lower V_REF voltage, but the maximum voltage should not exceed V_DD (on the YL-40 PCB, this is also known as V_CC). The datasheet lists any input voltage V _I as V_DD +0.5V (3.3 + 0.5 volts) as the absolute maximum. The lowest voltage for any input is listed as -0.5 volts.

You can find further technical details by Googling PCF8591 datasheet PDF.

I2C Bus

The PCF8591 uses the I2C bus to communicate. As an I2C slave peripheral, the YL-40 PCB provides two weak pull-up resistors, R₈ and R₉, which are 10kΩ each. The Raspberry Pi will already have its own pull-up resistors on these lines (1.8K each). If you are rolling your own circuit, you may want to install these 10kΩ pullup resistors also, though they are not strictly necessary.

I2C Addresses

The PCF8591 chip possesses three address pins, A0 to A2, allowing you to choose one of eight possible peripheral addresses from 0x48 to 0x4F. The YL-40 PCB, however, connects all three of these pins to ground, restricting the address to 0x48 (jumpers would have been nice). Unmodified, only one YL-40 PCB can be attached to a given I2C bus. Later in the chapter, you’ll see how the PCB can be modified to overcome this limitation.

DAC (AOUT)

With the Linux device driver operating, you can write a value from 0 to 255 to have the DAC output (AOUT) establish an output voltage. The driver input value, however, must be multiplied by ten. Assuming that you have exactly 3.3 volts powering the PCF8591 (and thus V_REF = 3.3 volts), a value of 255 should establish a voltage very near that. A value of zero establishes a ground value instead. A midpoint value of 128 should generate a value near half of 3.3 volts (1.65). When multiplied by 10 for the driver, the values used are 2550, 0, and 1280, respectively.

The YL-40 PCB, however, has a yellow LED D₁ through a R₄=1 kΩ resistor is connected in series to AOUT (shown up close in Figure 6-3). With the DAC set to produce maximum output, the yellow D1 should light up. But this turns out to be less brilliant than the red power LED D₂ beside it. When I measured the voltage, AOUT was only 2.89 volts, which is well short of the expected 3.3 volts. After I removed the LED (D₁), the voltage came up to a respectable 3.29 volts and begs the question: just how much current can the DAC drive?

Figure 6-3. DAC LED D₁ between D₂ and C₁

A careful look at the NXP datasheet under the heading “14.2 D/A characteristics” lists these parameters:

The upper line where the conditions state “no resistive load” confirms that the maximum output reading should be V_DD (a supply voltage of 3.3 volts). What is interesting is that when a 10 kΩ load is attached, the voltage drops to 0.9 × V_DD, or 2.97 volts (0.9 × 3.3 volts).

If you treat the DAC output like a battery, you can determine what the source resistance R_S is. A practical battery can be modeled as an ideal battery with a source resistor in series with it. Knowing the source resistance allows you to predict its output voltage for any given current flow (or load resistance). Figure 6-4 illustrates the idea in schematic form.

Figure 6-4. Equivalent circuit for DAC output AOUT

In Figure 6-4, the ideal battery (V_DD) represents the 3.3 volts provided to the PCF8591 chip. The unknown source resistance (R_S) is connected to AOUT feeding the load (R_L). You know the following from the datasheet:

• When R_L = 10kΩ, the voltage V(R_L) is 0.9 × V_DD, which in this case is 2.97 volts.

Armed with this information, you can apply Ohm’s law to determine the resistance of R_S. Because of this information:

• V_total = V(R_S) + V(R_L)

• V(R_S) = V_total – V(R_L)

• V(R_S) = 3.3 volts – 2.97 volts, which is 0.33 volts

you also know the following:

• V(R_L) = 2.97 volts

• 

This now allows you to calculate R_S. Because I(R_S) = I(R_L) in the series circuit, you get this:

From this you can conclude that the series resistance is about 1.1 kΩ. Let’s now apply this information.

If you consider the LED (D₁) and its resistor together as R_L (the load), using Ohm’s law you can now compute the current flow through the LED (and thus coming out of AOUT).

• V(R_S) = V_DD – V(R_L), = 3.3 volts – 2.89 volts = 0.41 volts

• 

With an LED current flow of 0.372mA, it is no wonder that the LED is weakly lit! LEDs often require 3mA or more for proper illumination.

All of this highlights the fact that the DAC output at AOUT is not suitable for driving loads requiring current. It does provide a controllable output voltage, however, but it is not capable of any substantial current drive. Use a voltage-to-current driver, when required. This further supports my suggestion for removing or disabling the output LED on the YL-40 PCB.

Removing YL-40 LED D1

Because the YL-40 PCB connects a resistor (R₄=1kΩ) and yellow LED to the AOUT circuit, the output accuracy of the DAC is compromised. For this reason, remove D₁ if you care about output accuracy. Figure 6-3 illustrates the location of D1 on the YL-40 PCB between the power LED (D2) and capacitor C1. Carefully apply a soldering iron to both ends of D1 to remove it. Make certain that no solder blobs remain to short things out.

Figure 6-5 illustrates the PCB area with D₁ removed. On mine, there was a little white triangle underneath showing the direction for LED current flow. The bottom pad (D₁ cathode) connects to ground, while the upper pad (D₁ anode) connects to R₄, which is then connected to AOUT. Measuring resistance from the upper pad (anode) to ground should show a near-infinite resistance after LED removal. Measuring from the same upper pad to AOUT should read about 1 kΩ (the value of R₄). If you read something else, check for a solder short.

Figure 6-5. LED D₁ removed

Hacking YL-40 I2C Address

If you want to use more than one YL-40 module, you’ll need to hack the I2C address for each of the additional modules. Figure 6-6 illustrates the lifting of pin 6 to solder a small wire to it. The other end of the wire is soldered to V_DD (pin 16) where the +3.3V supply is connected. In this way, address bit A1 becomes a 1 bit instead of a 0 bit. This change results in the I2C address of 0x4A. The wire I used was solid 30-gauge wire-wrap wire.

Figure 6-6. Changing I2C address by lifting pin 6

These pins are small and difficult to work with. With patience and a small prying tool like an eyeglass screwdriver, you may be able to pry up a leg without using a soldering iron. Don’t overdo it or the leg may break off. Once separated from the PCB pad, use a small, tipped soldering iron to apply just enough solder to attach the wire to the pried-up leg.

The PCF8591 address pins are as follows:

The YL-40 PCB has all three pins soldered to ground, resulting in an I2C address of 0x48. By lifting address pins and connecting them to +3.3 volts, additional addresses are possible. Table 6-1 summarizes the extra I2C addresses.

It is important that the lifted pins be connected to +3.3 volts. Otherwise, static electricity will collect on the pins causing the address to change sporadically.

I2C Bus Setup

If you haven’t already done so, install i2c-tools, as shown here:

$ sudo apt-get install i2c-tools

Once installed, then list your I2C buses, as shown here:

$ i2cdetect -l

If nothing is displayed, then you need to change the configuration so that the I2C drivers get loaded at boot time. The new kernels use the /boot/config.txt file to enable I2C support. Edit the file so that the i2c_arm=on line is uncommented, as shown here:

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

Save your changes and reboot.

sudo /sbin/shutdown -r now

After the reboot, try listing the I2C buses again, as shown here:

$ i2cdetect -l
i2c-1 i2c        3f804000.i2c                    I2C adapter

From this session output, you now see i2c-1 is available as expected.

Reading from PCF8591

If you are using the YL-40 PCB, you can read the built-in potentiometer using the in3_input (to change the potentiometer, turn the white control with a small screwdriver). If you built your own PCF8591 circuit, then attach a potentiometer (R₃), as shown in the schematic (Figure 6-2). Turning R₃ full-clockwise should cause a reading of AIN3 of near 0. Turning R₃ full counterclockwise should cause it to read 255.

In subdirectory pcf8591 are a few programs, including readadc (run make if that has not already been done). Invoke the program with option -h to display some usage information, as shown here:

$ ./readadc -h
./readadc [-a address] [-i input] [-h]
where:
      -a address   Specify I2C address
      -i input     Specify AINx (AIN3 is default)
      -d           Enable and leave DAC enabled
      -h           Help

By default, the readadc program assumes I2C address 0x48. To specify a different address, use the -a option and the new address. If the address is prefixed with 0x, the address will be interpreted as hexadecimal. For example, the following will use the I2C address of 4A in hex:

$ ./readadc -a 0x4A

The -i option for readadc defaults to 3 for accessing the chip input channel AIN3. Specifying a different number allows you to read other channels. For example, the following reads from AIN1 with the I2C address of 4A in hex:

$ ./readadc -a 0x4A -i1

Finally, the -d option just enables the DAC output (I’ll discuss this more later).

$ ./readadc
0

$ ./readadc
255

$ ./readadc
137

Writing to the DAC

In the same pcf8591 subdirectory is a program named writedac. It accepts nearly the same command-line options, while the trailing arguments are expected to be values to be written to the DAC.

$ ./writedac -h
./writedac [-a address] [-h] values to write...
where:
      -a address   Specify I2C address
      -h           Help

To write the value 128 to the DAC, use the following command:

$ ./writedac 128

or the following:

$ ./writedac 0x80

If multiple values are listed, they are all written to the DAC in sequence before the command exits.

$ ./writedac 128

$ ./writedac 0

$ ./writedac 255

$ ./writedac 255
$ ./readadc -i2 -d
255
$ ./readadc -i2 -d
254

$ ./writedac 128
$ ./readadc -i2 -d
177
$ ./readadc -i2 -d
127
$ ./readadc -i2 -d
127

Limitations

The PCF8591 chip has some limitations.

• Its maximum sampling rate is f_s=11.1kHz, making it unsuitable for most audio.

• ADC returns the prior result and the current value (further reducing the effective sample rate).

• The ADC value is 8-bit resolution.

Despite the limitations, the PCF8591 has some advantages.

• 3.3V-compatible with the Raspberry Pi

• I2C enabled

• Economically priced

• Built-in Linux driver support

Extending Voltage Range

You’ve already seen the device do direct voltage measurements. But how do you measure voltages greater than 3.3 volts? Use a voltage divider, as shown in Figure 6-7.

Figure 6-7. Using a voltage divider

The object of the voltage divider is to put the input voltage into a reduced range for the ADC input. Since the ADC is powered from the Raspberry Pi 3.3V supply, the ADC input range is limited to a maximum of 3.3 volts. To extend the range to, say, 16 volts for automotive measurement, you can compute the values of R₁ and R₂ in Figure 6-7.

The simplified design procedure is as follows:

1. Arriving at a current flow through R₂ of about 1mA, producing 3.3 volts requires that R₂ be about 3300Ω:

2. 16 volts minus 3.3 volts means you want a minimum voltage drop across R₁ of about 12.7 volts.

3. To compute R₂, use this:

4. The next 10 percent tolerance resistor value greater than or equal to 12.7kΩ is 15kΩ.

With R₁ = 3.1kΩ and R₂=15kΩ, let’s check the actual input voltage range achieved.

To get a full reading of 3.3 volts across R₂, you require 1mA of current. R₁ will have the same current flow as R₂ since it is in series. So if 1mA is flowing through R₁, you know that it would have a voltage drop of I × R = 1mA × 15000 Ω = 15 volts. Therefore, the total voltage that the divider pair can handle is as follows:

3.3 volts + 15 volts = 18.3 volts

What is the resolution of this range using the 8-bit ADC? An 8-bit resolution means you have a total of 256 steps (2⁸ = 256). Consequently, the resolution is as follows:

The conclusion is that the 8-bit ADC can measure 0 to 18.3 volts in 0.071V increments.

Repairing the Temp Sensor

With the jumper installed in P4, you can read the current temperature sensed by thermistor R₆, which changes in resistance with temperature. The thermistor is in series with the R₁=1kΩ resistor, and thus it divides the 3.3V supply. The AIN1 input measures the midpoint voltage of the divide, between the top of R₆ and ground.

But there is a problem—the YL-40 module’s PCB didn’t ground the lower leg of R_6- It is in fact unconnected. This results in reading the highest value, 255, because the AIN1 input is effectively attached only to the +3.3V supply. With a bit of Googling, you’ll find that others have also experienced this problem.

Fortunately, the solution is not difficult to correct if you have a soldering iron. Figure 6-8 shows how to locate the supposed-to-be-grounded end of R₆. Use your DMM to check to see whether that leg and ground shows 0Ω. If it does not, a fix is needed (if your ADC reading is 255, this is already a strong indication that the repair is needed).

Figure 6-8. Location of ground end of thermistor R₆

Figure 6-9 illustrates the underneath side of R₆. Since there are no inner PCB layers, this connection is quite visibly unconnected.

Figure 6-9. Bottom view of R₆ ungrounded leg

Based on Figure 6-9, you could run a small wire from R₆ to the ground post just above and to the right. I believed that to be too risky for short circuits and chose to solder a wire to a ground point shown in the bottom left of Figure 6-10 instead.

Figure 6-10. R6 grounded to point, bottom left

Check with the DMM to see that the R₆ leg is indeed grounded after soldering. After the repair, you should get a reading from AIN1 near 231 when at room temperature. The reading should definitely be less than the value 255 that was obtained before the repair.

Conversion to Celsius

Reading the temperature of R₆ requires some calculation after taking a reading from AIN1. You’ll be using the simplified calculation [1] because you don’t know all of the parameters for the thermistor part. The calculation requires these four steps:

1. Read AIN1 to get an ADC reading of the voltage at R₆ (you’ll assume 234 for this example).

2. Compute the resistance of R₆ based upon the ADC reading.

3. Compute the temperature in degrees K.

4. Convert degrees K to degrees Celsius.

To calculate the current resistance of R₆, the ADC reading “a” is plugged into the following formula:

The 256 in the previous formula comes from the fact that the ADC has a resolution of 8 bits (256 steps). Assuming that the reading from the ADC is 234, you plug in the following for variable “a”:

Now that you know the resistance of R₆, you can compute the temperature in degrees Kelvin.

In that formula, the values are as follows:

• T is the computed temperature in degrees Kelvin.

• T₀ is the room temperature in degrees Kelvin (25°C is 298.15°K).

• B is the coefficient of the thermistor (adafruit.com claimed 3950).

• R₀ is the resistance at room temperature (adafruit.com claimed 10kΩ).

Plugging everything in, you get the following:

To convert to degrees Celsius, you use this:

Compare your reading with another thermometer in the room. You may want to add or subtract a small calibration offset for your project.

Reading Temperature

To read the temperature-sensitive device (R₆) attached to input channel AIN1, you can apply the program readtemp in the pcf8591 subdirectory to read it. This program is almost the same as readadc, except that it defaults to -i1 and performs the somewhat nasty Celsius calculation for you.

$ ./readtemp -h
./readtemp [-a address] [-h]

where:

        -a address     Specify I2C address
        -i input       Specify AINx (AIN1 is default)
        -h             Help

The default options for readtemp are -a0x48 -i1.

$ ./readtemp
ADC=228, R6 = 8142.9 ohms, T=302.846 deg K, 29.696 deg C

The YL-40 LDR

The YL-40 PCB includes a light-dependent resistor (LDR), which is R₇ on the schematic (shown earlier in Figure 6-2). The nature of the LDR is that it has high resistance in the dark and low resistance in light. The change in resistance is relatively slow, making it unsuitable for audio reception, yet it is fast enough for control applications. The YL-40 connects this device to AIN0 when the jumper P5 is installed.

The LDR can be made of various materials and consequently has varying responses to light and wavelengths. Without knowing the exact part and parameters for the one included on the YL-40, you can make only general assumptions about the device used. The tolerances for the part also vary as much as 30 percent [2].

The resistance of the LDR (R₇) can be calculated in the same way that you did for the thermistor R₆.

$ ./readadc -i0
238

$ ./readadc -i0
160

$ ./readadc -i0
50

1N914 Experiment

The 1N914 is a small glass-encased signal diode, shown up close in Figure 6-11. The cathode (negative) end of the diode is marked with a black band around it. The other end (anode) is positive for forward conduction, according to the conventional flow of electricity. This experiment will measure the voltage-to-current relationship of this diode, using forward current flow.

Figure 6-11. 1N914 diode to be tested

You’ll take advantage of the fact that you can establish a small current source from the DAC output AOUT. If the diode being tested were to act as a short circuit, you would want to limit the current to about 1mA for this experiment. You know that full voltage will be near 3.3 volts, so using Ohm’s law, you can calculate the series resistance needed.

The breadboard circuit is wired according to Figure 6-12, with R₁=3.3kΩ in series with the 1N914 diode D₁. The voltage will be applied out of the DAC to the series resistor R₁, while you take voltage readings at the top of diode D₁, into AIN0. The DAC will perform a slow sweep from 0 volts to the maximum. By measuring the voltage at the junction of R₁ and D₁, you’ll be able to calculate the current in D₁ using Ohm’s law.

Figure 6-12. 1N914 diode circuit

You also measure the voltage provided by the DAC itself using ADC input AIN1. This is done because the drive capability of the DAC is limited in current, causing its output voltage to droop. When the DAC output sags in voltage, you can use the AIN1 reading to more accurately assess the current actually flowing.

The program diode.cpp sets a test DAC voltage and then reads AIN0 and AIN1 to plot the readings. This experiment will use gnuplot-x11 to plot the results, so if you don’t have it installed yet, do the following:

# sudo apt-get install gnuplot-x11

If you ssh’ed into your Pi, make sure you enable X11 Window tunneling with the -X option.

$ ssh -X pi@pi

Further, if you expect gnuplot to open on your remote machine (like your Mac OS X laptop), you need to set up permissions or simply do the following on the display server:

$ xhost +

If you’re using a keyboard and monitor attached to the Pi itself, you can ignore this.

Running the diode program requires no command-line options, unless you need to specify the I2C address.

$ ./diode -h
./diode [-a address] [-h]
where:
      -a address   Specify I2C address
      -h           Help

Once your breadboard circuit is ready, run the diode program.

$ ./diode
DAC 0, AIN0 1, AIN1 1, VD1=0.0, VR=0.0, I=0.0000
DAC 1, AIN0 1, AIN1 1, VD1=0.0, VR=0.0, I=0.0000
DAC 2, AIN0 2, AIN1 2, VD1=0.0, VR=0.0, I=0.0000
DAC 3, AIN0 3, AIN1 3, VD1=0.0, VR=0.0, I=0.0000
DAC 4, AIN0 4, AIN1 4, VD1=0.1, VR=0.0, I=0.0000
DAC 5, AIN0 5, AIN1 5, VD1=0.1, VR=0.0, I=0.0000
DAC 6, AIN0 6, AIN1 6, VD1=0.1, VR=0.0, I=0.0000
DAC 7, AIN0 6, AIN1 7, VD1=0.1, VR=0.0, I=0.0000
DAC 8, AIN0 7, AIN1 7, VD1=0.1, VR=0.0, I=0.0000
DAC 9, AIN0 8, AIN1 8, VD1=0.1, VR=0.0, I=0.0000
DAC 10, AIN0 9, AIN1 9, VD1=0.1, VR=0.0, I=0.0000
DAC 11, AIN0 10, AIN1 10, VD1=0.1, VR=0.0, I=0.0000
...

The program reports several lines to the terminal, which can be helpful in debugging your experiment. The DAC, AIN0, and AIN1 values are reported on each line. Additionally, the calculated V_D1, V_R, and I are displayed. V_D1 and I are written to the file diode.dat. The diode program also writes out the file gnuplot.cmd that you can use to plot the results.

# gnuplot -p gnuplot.cmd

If all went well with gnuplot, you should have a plot displaying the results, as shown in Figure 6-13. If you chose not to remove the LED (D1) from the DAC circuit, you might not reach as high a current as shown, but you should get similar results. If gnuplot is not cooperating, check that your environment variable DISPLAY is set and exported.

Figure 6-13. gnuplot of diode test

The plotted results show you that your diode reached a maximum of about 0.0007A in current (0.7mA) when the voltage reached or exceeded 0.6 volts. The curve demonstrates that the diode’s response is exponential in nature, becoming almost linear after the 0.6V level was reached. This is the general characteristic for silicon diodes.

What happens if you try an LED instead? Does color make a difference? Also, try a germanium diode (1N34A).

Software

In this chapter you used the I2C bus driver in Linux to communicate to the PCF8591 device using the provided C++ programs. These are found in the pcf8591 subdirectory and can be cloned and modified for your own purposes. The basics of I2C programming will be discussed in Chapter 11.

Potential Experiments

The following are potential experiment ideas that you can perform using the PCF8591 with any Raspberry Pi:

1. Measure the voltage of a 1.5V dry cell (of your choice) wired to a flashlight bulb. Measure the voltage over time, measuring the lifetime of the cell. Repeat with different brands, noting the cost of each cell. Construct a chart of the most economical batteries based upon brand, cost, and lifetime.

2. Repeat experiment 1 for rechargeable cells. How do they compare?

3. Using the YL-40 LDR, record the moonlight level for a week or more and use gnuplot to plot it.

4. Place your Pi in the refrigerator and track the light-on time to measure door open times.

5. Use the DAC to produce a low-frequency sine wave. Produce a triangle, saw, and square waves.

Summary

This chapter showed the versatility of the economical PCF8591 ADC/DAC chip. You also saw the variety of experiments that the YL-40 PCB offers after certain adjustments are made. Despite the limitations of 8-bit resolution, the response of a signal diode was measured and plotted. At the low price of a PCF8591, how can you argue with the geek fun that it provides?

Bibliography

1. “Thermistor.” Using a Thermistor. Adafruit.com, n.d. Web. 30 Jan. 2016. < https://learn.adafruit.com/thermistor/using-a-thermistor >.

2. “Measuring Nocturnal Light.” Measuring Nocturnal Light. N.p., n.d. Web. 30 Jan. 2016. < http://home.earthlink.net/∼nevadabat/Moonlight/MoonLight.html >.

Potentiometers

Figure 7-1 illustrates a small collection of single-turn potentiometer types. Two old knobs for the shafted pot types are shown at the top of the photo. The bottom of the photo presents some small “trimmer” pots. These are known as trimmers because they are used in circuit boards to trim the resistance needed. These are not normally used for user controls.

Figure 7-1. A small collection of different potentiometers

The row above the trimmers shows examples of three PCB mount pots on the left and one panel mount pot (with solder lugs) on the right. These will be the primary focus of this chapter because they are the kind that get fitted with knobs for users to twiddle with.

To see how they work, the back protective cover can be removed, as done in Figure 7-2. The protective cover comes off easily with four tabs bent back for removal. On the end of the shaft is a round piece of plastic holding wiper contacts. You can see the fingers of the main wiper contact at 11 o’clock. The other sliding contact is under the middle near the shaft, connecting the wiper arm to the center connection.

Figure 7-2. The revealed innards of a PCB potentiometer

The three fingers are designed to reduce the scratching that might otherwise be noticeable when the shaft is rotated. While the wiper is moving, the metal contacts bounce a little, but with three contacts, usually one or more remain in contact with the resistive material.

The range of motion is usually 270°, or approximately three-fourths of full rotation [1]. The wiper moves across the resistive material from about 8 o’clock to about 4 o’clock. The resistive material is made out of some carbon composite material. The resistance between the two outer connections of the pot is fixed in value. But as the wiper moves from one end to the other, the resistance is divided between the two ends. Apply a voltage across the outer connections, and the center connection becomes a voltage divider.

Voltage Dividers

This section is for students who have not studied electronics. Here I’ll explain in layman’s terms how a potentiometer operates as a voltage divider. This concept is important for applying potentiometers with ADC conversion.

Figure 7-3 illustrates the schematic view of a potentiometer. The upper end of the potentiometer is connected to the power supply (in this example), while the bottom end is connected to ground. In between the two ends is the carbon composite resistance that the wiper glides across. This material is shown as a squiggly line using the US schematic convention. The center connection (at right) has an arrow pointing to the resistive material (to the left). This arrow represents the wiper arm for that connection.

Figure 7-3. Schematic representation of a potentiometer

Some schematics may also show an extra arrow. This schematic has this arrow pointing upward. This means that the wiper arm goes up when rotated fully clockwise [2].

Looking at Figure 7-3, imagine that the wiper arm is 50 percent of the way between the two extremes. This divides the voltage +3.3V (from the top) by half. So, you would expect to measure the following at the center connection:

If you rotated the potentiometer fully clockwise, the center connection would measure 3.3 volts (or very close to it), assuming the negative lead of the DMM was connected to ground. This occurs because the wiper arm is virtually in contact with the +3.3V connection of the pot. This is the meaning of that second arrow—it tells you which end of the pot is connected when cranked fully clockwise.

Rotating the pot fully counterclockwise moves the wiper arm toward the grounded end. In this case, you would measure 0 volts (or very nearly). Sometimes there is a small residual amount of resistance involved at either end of the pot, affecting the readings at the rotational extremes.

You should now begin to see the pattern here. If you move the pot to 10 percent above its fully counterclockwise position, you should read 10 percent of the 3.3 volts. That 10 percent of 3.3 volts is 0.33 volts.

The voltage is divided across both halves of the potentiometer. When the pot is positioned at 10 percent (from counterclockwise), you expect 10 percent of the voltage from the wiper to ground. There is also 90 percent of the supply voltage appearing between the supply side and the wiper in the middle. Both will add up to 100 percent, which is why it’s called divided.

This also means that if you measure 0.33 volts between the wiper and ground, there is the following between the supply side and the wiper arm:

ADC Circuit

Figure 7-4 shows the basic potentiometer-based control circuit. The idea is that the pot will divide the voltage between the supply voltage and ground. The ADC device will take a voltage reading from the divider and thus determine the position of the potentiometer. When the potentiometer is fully clockwise, the ADC will read maximum voltage; when fully counterclockwise, it will read minimum voltage; and so on.

Figure 7-4. The basic potentiometer-based ADC circuit

Pot Resistance

As mentioned, the resistance between the two ends of the carbon composite material is fixed. You get variability by moving the wiper across it in a sweeping arc, but the total resistance is fixed. But when you go to select a potentiometer, how do you choose what resistance to order?

It depends upon the input impedance of the ADC device you are interfacing it to. Unfortunately, the PCF8591, for example, doesn’t publish this information. The general principle is that you want to have the potentiometer present much less impedance than the input impedance of the ADC device. This is critical at higher sampling rates. But the rate of change for a human-operated control is rather low, so you can sidestep that issue.

A potentiometer of 1kΩ consumes the following amount of current:

If the rather small 3.3mA of current doesn’t put you over your current budget, I recommend that you use a 1kΩ pot. Even a 2kΩ to 5kΩ potentiometer would likely be fine for the PCF8591 if you wanted to save current for battery operation.

If you know the input impedance of your ADC device, then you can confidently use a higher pot resistance when it is well under. For example, let’s say the ADC input impedance is known to be 100kΩ. The “ten times less” rule would suggest that your input pot resistance should be 10kΩ or less.

Avoid using lower than 1kΩ potentiometers because this results in wasted current. For example, if you used a 100Ω pot, you would be consuming a steady current of 3.3 / 100 = 33mA, which is too much.

Taper

You should be aware that potentiometers come in different tapers. In this chapter, you’re interested in linear taper potentiometers, where the change in resistance follows knob rotation in a linear fashion. With linear changes in voltage, you can easily predict the rotation of the knob in the software from an ADC read.

In audio applications, the logarithmic taper is often used because of the way the ear responds to loudness. At low volumes, the ear is sensitive and responds to small changes more than in louder sounds. To make the volume control more natural to use, the low volume part of the pot responds differently than the louder part.

Other types of tapers are possible, such as the “anti-log” taper. These are much less common.

Potentiometers are normally marked with a prefix or suffix letter that indicate their taper. There are different markings in use, but the most common convention is the Asia method. Table 7-1 lists the various marking codes.

When ordering your potentiometer, make sure you are buying a linear unit. This usually means that the unit is prefixed with a B. An example of a linear 10kΩ pot would be marked “B10K.”

Effect of ADC Bits

The PCF8591 ADC chip performs a conversion from analog to 8-bit digital. But what does this mean as far as the user control knob? What’s the resolution of this?

Since 8-bit samples range in value from 0 to 2⁸–1, you know that a maximum of 256 (2⁸) steps can be measured. In terms of degrees then, your resolution is computed as follows:
where:

• d is the range of motion, in degrees.

• b is the digital sample size, in bits.

If you assume a typical potentiometer with 270 degrees of motion and assume an 8-bit ADC will be used, then you can compute the following:

The 8-bit ADC will report a maximum of 256 steps as the control is rotated from counterclockwise to fully clockwise. As a result of that calculation, you now know that each of those steps requires 1.05 degrees of knob rotation. If you had a 10-bit ADC available, the steps become much finer and resolve to about 0.264 degrees per step.

Experiment

This experiment requires that you use the following:

• YL-40 PCB (PCF8591) ADC (8-bits) or equivalent

• A linear 1kΩ potentiometer (or higher)

Higher-valued pots should function OK, but try to stay under the 10kΩ limit. Above that, your results may be poor.

Plug your YL-40 (PCF8591) ADC into your breadboard, wire it up to the I2C bus, and start your Pi (with the YL-40 jumpers installed). Review Chapter 6 if necessary. Change to the subdirectory pcf8591 and run the following command (change the I2C address for the -a option if necessary for your unit):

$ ./readadc -a 0x48 -i3

Now turn the YL-40’s white trim pot (marked “103”) counterclockwise. Repeat the read command, and you should read something like this:

$ ./readadc -a 0x48 -i3
247

I purposely didn’t crank mine fully, but it appears that the way the pot is wired on the YL-40 PCB, that counterclockwise will read maximum voltage. Crank the trim pot clockwise and take another reading.

$ ./readadc -a 0x48 -i3
0

You should see a low reading, depending upon how cranked your trim pot was. If you see these results, you can be confident that your ADC framework is working. Now let’s “get off the pot” and use a real control.

Shut down your Pi and turn off the power. Using Figure 7-4, wire one of the ends of the pot to the +3.3V Pi supply. The opposite end should be wired to ground. The middle leg of the pot is the wiper. Attach that to your YL-40 AIN3 input, and remove the PCB jumpers (or just P6). This now connects your pot to the ADC peripheral. Adjust your pot to about midway in its travel.

Figure 7-5 shows my breadboard experiment. I found an old pot and soldered three “bus wires” on each lug so that I could plug it into the breadboard. This was about a 2.5kΩ linear pot. The left leg is Dupont wired (white) to ground, while the right wire (orange) goes to the Pi’s +3.3V supply. The center dark blue wire goes over to the YL-40’s AIN3 connector, seen just above the PCB trim pot. A nice old chicken knob was attached to the pot for good measure.

Figure 7-5. My pot experiment using the YL-40 module

When you conduct this experiment with the YL-40, make certain you remove the onboard jumpers (or at least jumper P6). Otherwise, the onboard trim pot will interfere.

After applying power and starting up your Pi again, enter the pcf8591 subdirectory where your readadc executable is. Run the program with the knob twisted to known positions like counterclockwise, 50 percent, and clockwise. If you wired it as I did, you should get a near 0, 128, and 255, respectively.

If your readings are the opposite of these, then try reversing the wiring of the outer legs of the pot (but leave the middle wiper connection where it is). After repeating the experiment, the readings will agree.

At this point you should celebrate because you now have a position encoder. A program can read the ADC input and determine how much the knob is rotated. This has practical uses in the Pi.

Applying Potentiometer Controls

You obviously want to capitalize on what you just performed in the experiment. For example, a pot can be used as a selector, to choose from a menu. A simple selection would simply be to choose one number from 1 to 10. To do this, you need to perform some mapping of your ADC input values. You know that with an 8-bit ADC, your readings will vary between 0 and 255 and will need to be divided into 10 distinct ranges. Each selection will cover the following:

Given that the ranges are not evenly divisible, you’ll need to settle for an approximation, as illustrated in Table 7-2.

In software, you can compute the “number” from the ADC reading using the following approximation:

If you don’t mind your program doing floating-point calculations, the divide by 25.6 rounded to an integer is fine. If you want to stay within integer calculations, you can multiply the ADC reading by 10 and then divide by 256. Note that you add one in the calculation to arrive at a number starting from 1 rather than 0.

To test this idea, run the program selten as shown here (the options -a and -i are optional and otherwise the same as used by readadc):

$ ./selten -a 0x48 -i3
The selection is 7 (byte = 204)
The selection is 6 (byte = 179)
The selection is 5 (byte = 153)
The selection is 6 (byte = 154)
The selection is 5 (byte = 153)
The selection is 4 (byte = 127)
The selection is 5 (byte = 128)
The selection is 4 (byte = 127)
The selection is 3 (byte = 102)
The selection is 2 (byte = 76)
The selection is 3 (byte = 77)
The selection is 2 (byte = 76)
The selection is 1 (byte = 51)
The selection is 0 (byte = 25)
The selection is 1 (byte = 26)
The selection is 2 (byte = 52)
The selection is 1 (byte = 51)
The selection is 2 (byte = 52)
The selection is 3 (byte = 77)
The selection is 2 (byte = 76)
The selection is 3 (byte = 77)
The selection is 2 (byte = 76)
The selection is 3 (byte = 77)
The selection is 4 (byte = 103)
The selection is 5 (byte = 128)
The selection is 4 (byte = 127)
The selection is 5 (byte = 128)
The selection is 4 (byte = 127)
The selection is 5 (byte = 128)
The selection is 6 (byte = 154)
^C

This program will run until you interrupt it with Control-C. As you rotate the knob and a new number is “selected,” it will be displayed on the console. The program also reports the ADC value (as byte) for demonstration purposes.

Listing 7-1 shows the loop that performs the selection calculation.

Listing 7-1. The Potentiometer Read Loop and Selection Calculation

085     int last = -1, s;
086
087     for (;;) {
088             rc = i2c_read(i2c_addr,i2c_ainx|enable_dac,rbyte);
089             if ( rc == -1 ) {
090                    fprintf(stderr,"%s: reading %s device at 0x%02X\n",
091                            strerror(errno),
092                            i2c_device,
093                            i2c_addr);
094                    exit(1);
095 }
096
097             s = int(rbyte) * 10 / 256;
098             if ( s != last ) {
099                    printf("The selection is %d (byte = %d)\n",
100                            s,rbyte);
101                    last = s;
102             } else {
103                    usleep(1000);
104             }
105    }

The variable last is used to keep track of the last ADC value read, which can never be negative. This forces the first value to be printed in line 099 no matter what the current reading is. The ADC value is read in line 088, which will be a value from 0 to 255 (variable rbyte). Note that rbyte is passed by reference in the call, so it is updated by the function i2c_read. To compute a selection from 1 to 10, the calculation in line 097 is used. This is done entirely in integer arithmetic. The value 256 used in this calculation is 25.6 × 10, not the ADC width 2⁸.

If the computed value s is the same as last, then the program just goes to sleep for 1ms (line 103). This keeps the CPU from being wasted and keeps the I2C bus available for other I/O operations. But if the value has changed, no sleep is performed in case the value might still be changing.

Selection Resolution

It might be tempting to think that a selection of 1 of 256 possibilities with an 8-bit DAC is feasible. But this is not practical because the ADC is not as precise as you need it to be. Factor in the fuzziness of your potentiometer and you’ll soon discover that some of those selections are not that selectable. Finally, a given selection may drift into a neighboring selection as temperature changes affect the ADC readings. These are all practical reasons to downgrade your ADC resolution when turning your pot into a selection mechanism.

The other aspect of control resolution is the amount of movement necessary to achieve a selection. With a 270-degree range of motion and using an 8-bit ADC, each step requires a little more than one degree of movement. Thus, having a user make a selection on that fine a motion is impractical.

Pots make good selection mechanisms, however, if you downgrade their precision. In the selten experiment, it was easy to achieve specific settings because each selection required about 10.5 degrees of motion. The setting can be ±5.25 degrees from the center point and be valid for the selection.

Summary

This chapter explored the application of using potentiometers as an analog input control in combination with ADC. As an analog value, many applications are possible including the typical volume control variety.

As you have seen, potentiometers can also be used as selectors, when the design is right. When the number of selections is within reasonable limits, the pot makes an effective selection control. Because many ADCs have multiple analog inputs, it can be cost effective to sense multiple potentiometers.

Bibliography

1. “Potentiometer > Resistor Guide.” Potentiometer > Resistor Guide. N.p., n.d. Web. 17 Sept. 2016. < www.resistorguide.com/potentiometer/ >.

2. “Linear Power-supply Potentiometer Feedback (17/05/16).” Linear Power-supply Potentiometer Feedback. N.p., n.d. Web. 17 Sept. 2016. < http://imajeenyus.com/electronics/20160517_potentiometer_feedback/index.shtml >.

3. “Potentiometer Taper - Audio Taper > Resistor Guide.” Potentiometer Taper - Audio Taper > Resistor Guide. Accessed September 20, 2016. < www.resistorguide.com/potentiometer-taper/#What_is_potentiometer_taper >.

Keyes KY-040 Rotary Encoder

While the device is labeled an “Arduino Rotary Encoder,” it is also quite usable in non-Arduino contexts. A search on eBay for KY-040 shows that a PCB and switch can be purchased (assembled) from eBay for about $1.28. Figure 8-1 shows both sides of the PCB unit I purchased.

Figure 8-1. The Keyes YL-040 rotary encoder

It is also possible to buy the encoder switch by itself on eBay, but I don’t recommend it. The PCB adds considerable convenience for pennies more than the cost of the switch. But the main reason to buy the assembled PCB unit is to get a working switch. I have given up on buying good rotary switches by themselves from eBay. I suspect that many eBay rotary switch offerings, if not all, are factory rejects and floor sweepings.

The Switch

To help convince you of the need for buying quality, let’s take an inside look at how switches are constructed. Figure 8-2 illustrates the contact side of a switch assembly that I did an autopsy on.

Figure 8-2. Contact side of the rotary encoder

Figure 8-2 shows that there is a contact pad (lower left) for the wiper arm. The top portion (right side of the figure) shows the other contact points. The smear seen there is some conductive grease. Figure 8-3 illustrates the wiper half of the assembly.

Figure 8-3. The wiper assembly of the rotary encoder

The photos illustrate the cheap nature of the rotary encoders’ construction. They must go through some sort of quality control at the factory, but it wouldn’t take much more than a bent wiper arm to render one faulty.

Figure 8-4 shows the KY-040 schematic without the optional push button switch. The units with the optional push switch have another connection labeled “SW” on the PCB. The return side of that switch connects to ground (GND).

Figure 8-4. The KY-040 schematic (excluding optional push switch)

The schematic shown focuses on the rotary switches that connect switches A and B to the common point C. The KY-040 PCB includes two 10kΩ pull-up resistors so that when either switch is open, the host will read a high (1 bit). When the A or B switch is closed, this brings the signal level low (0 bit). Finally, note that the KY-040 PCB labels the connections as CLK and DT. According to reference [1], switch A is the CLK connection, while B is the DT connection. These specifics are unimportant to its operation.

Operation

The rotary encoder opens and closes switches A and B as you rotate the knob. As the shaft is turns, both switches alternate between on and off at the detents. The magic occurs in between the detents, however, allowing you to determine the direction of travel. Figure 8-5 illustrates this effect.

Figure 8-5. Rotary encoder signals

Starting from the first detent shown in Figure 8-5, switches A and B are open, reading 11 in bits (both read high). As the shaft is rotated toward the next detent, switches A and B become both closed (reading as 00). In between the detents however, you can see that switch A closes first (reading as 01), followed by switch B later (now reading 00). The timing of these changes allows you to determine the direction of travel. Had the shaft rotated in the reverse direction, switch B would close first (reading as 10), followed by A.

Voltage

As soon as you see the word Arduino, you should question whether the device is a 5V device because many Arduinos are 5V-based. For the KY-040 PCB, it doesn’t matter. Even though the reference [1] indicates that the supply voltage is 5 volts, it can be supplied the Raspberry Pi level of 3.3 volts instead. The rotary encoder is simply a pair of mechanical switches and has no voltage requirement.

Evaluation Circuit

The evaluation circuit can serve as an educational experiment and double as a test of the component. It is simple to wire up on a breadboard, and if the unit is working correctly, you will get a visual confirmation from the LEDs. Figure 8-6 illustrates the full circuit. The added components are shown at the left, consisting of resistors R ₃, R ₄ and the pair of LEDs.

Figure 8-6. KY-040 evaluation circuit

The dropping resistors R ₃ and R ₄ are designed to limit the current flowing through the LEDs. Depending upon the LEDs you use, these should work fine at 3.3 or 5 volts. Assuming a forward voltage of about 1.8 volts for red LEDs and the circuit powered from 3.3 volts, this should result in approximately:

If you want to use less current for smaller LEDs, adjust the resistor higher than 170Ω.

Figure 8-7 illustrates my own simple breadboard test setup. You can see the dropping resistors R ₃ and R ₄ hiding behind the yellow LEDs that I had on hand at the moment. This test was performed using a power supply of 3.3 volts. The photo was taken with the shaft resting at a detent, which had both switches A and B closed, illuminating both LEDs.

Figure 8-7. Evaluation test of the rotary encoder

When rotating the shaft, be sure to hold the shaft (a knob is recommended) securely so that you can see the individual LEDs turn on and off before the shaft snaps to the next detent. You should be able to see individual LED switching as you rotate.

If you see “skips” of LED on/off behavior for LED 1 and/or 2, this may indicate that you have a faulty switch. The only thing you can do for it is to replace it. But do check your wiring and connections carefully before you conclude that.

Interfacing to the Pi

Now it is time to interface this to the Raspberry Pi. Since the KY-040 PCB already provides the pull-up resistors, you only need to connect the + terminal to the Pi’s 3.3V supply and wire the A/CLK and B/DT connections to GPIO inputs. Don’t forget to connect GND to the Pi’s ground.

But before doing so, consider this: what kind of port are the GPIO pins you have selected at boot time? That is, what is their default configuration? If a particular GPIO is an output at boot time and if one or both of the rotary switches are closed, then you are short-circuiting the output until the port is reconfigured as an input. Given the amount of boot time, this could result in a damaged GPIO port.

Before hooking up GPIO ports to switches, you should do one of two things:

• Use GPIOs that are known to be inputs at boot time (and stay that way).

• Use isolation resistors to avoid damage when the GPIOs are outputs (best).

Using isolation resistors is highly recommended. By doing this, it won’t matter if the port is initially (or subsequently) configured as an output port. If your isolation resistor is chosen as 1kΩ (for example), the maximum output current will be limited to 3.3mA, which is too low to cause damage. Figure 8-8 illustrates the Pi hookup, using isolation resistors.

Figure 8-8. Safe hookup of the rotary switch to the Raspberry Pi

The schematic uses 10kΩ isolation resistors to hook up the rotary encoder to the Pi. If the selected GPIOs should ever be configured as outputs, the current will be limited to 0.33mA. Once the GPIOs are reconfigured by your application to be inputs, the readings will occur as if the resistors were not there. This happens because the CMOS inputs are driven mainly by voltage. The miniscule amount of current involved results in almost no voltage drop across the resistors.

Figure 8-9 shows a photo of the breadboard setup. An old knob was put onto the rotary controller to make it easier to rotate. In this experiment, the following GPIOs were used:

Figure 8-9. YL-040 rotary encoder hooked up to Raspberry Pi 3

• GPIO#20 was wired to CLK (via 10kΩ resistor)

• GPIO#21 was wired to DT (via 10kΩ resistor)

To verify that things are connected correctly, you can use the gp command to verify operation. Here you are testing GPIO #20 to see that it switches on and off:

$ gp -g20 -i -pu -m0
Monitoring..
000000 GPIO 20 = 1
000001 GPIO 20 = 0
000002 GPIO 20 = 1
000003 GPIO 20 = 0
000004 GPIO 20 = 1
000005 GPIO 20 = 0
...

Repeat the same test for GPIO #21.

$ gp -g21 -i -pu -m0
Monitoring..
000000 GPIO 21 = 0
000001 GPIO 21 = 1
000002 GPIO 21 = 0
000003 GPIO 21 = 1
000004 GPIO 21 = 0
000005 GPIO 21 = 1
000006 GPIO 21 = 0

Observe that the switch seems to change cleanly between 1 and 0 without any contact bounce. That may not always happen, however.

Experiment

As a simple programmed experiment, change to the software subdirectory YL-040. If you don’t see the executable yl040a, then type the make command to compile it now. With the circuit wired as in Figure 8-8, run the program yl040a and watch the session output as you turn the knob clockwise. Use Control-C to exit the program.

$ ./yl040a
00
10
11
01
00
^C

You should observe the general pattern shown in Table 8-1, perhaps starting at a different point. You should observe this sequence repeating as you rotate the control clockwise. If not, try counterclockwise. If the pattern shown here occurs in the reverse direction, simply exchange the connections for GPIO #20 and GPIO #21.

Note that the 00 and 11 patterns occur at the detents. The 10 and 01 patterns occur as you rotate from one detent position to the next. Rotating the knob in the reverse direction should yield a pattern like this:

$ ./yl040a
00
01
11
10
00
01
^C

Don’t worry if you see some upset in the sequence runs. There is likely to be some contact bounce that your next program will have to mitigate. The pattern however, should generally show what Table 8-2 illustrates.

From this, you see that rotation in one direction closes or opens a switch ahead of the other, offering information about rotational direction. There is still the problem of contact bounce, which you might have observed from your experiments. The next program will apply debouncing.

Experiment

Chapter 5 showed how software debouncing could be done. You’re going to apply that same technique in program yl040b for this experiment. Run the program and rotate the knob clockwise.

$ ./yl040b
00
10
11
01
00
10
11
01
00
10
11
01
00
10
11
01
00
10
11
^C

In this output, you can see the debounced sequence is faithful until the end. Despite this, it is possible that if you rotated the knob fast enough, there may have been discontinuities in the expected sequence. You’ll need to address this in the software.

Sequence Errors

Error handling in device driver software can be tricky. Let’s begin by looking at what can go wrong. Then let’s decide on an error recovery strategy. Here are events that could go astray:

• Debouncing was not effective enough, returning erratic events.

• The control was rotated faster than can be read and debounced.

• The control became defective or a connection was lost.

You’ll look at code at the end of the chapter, but program yl040b uses 4 bits of shift register to debounce the rotary input. Switch events from a rotary control can occur more rapidly than a push button, so a short debounce period is used, lasting about 68 μsec × 4 = 272 μsec. If you take too long, the control can advance to the next point before you stabilize a reading.

When the control is rotated rapidly, you can lose switch events because the Pi was too busy or because the events occurred too quickly. When this happens, you can have readings appear out of sequence. If you read 00 immediately followed by 11, you do not know the direction of the travel. Lost or mangled events also occur when the control becomes faulty.

So, what do you do when an event occurs out of sequence? Do you:

• Ignore the error and wait for the control to reach one of the expected two states?

• Reset your state to the currently read one?

The class RotarySwitch defined in files rotary.hpp and rotary.cpp has taken the first approach. If it encounters an invalid state, it simply returns a “no change” event. Eventually when the control is rotated far enough, it will match one of the two expected next states. The second approach would avoid further lost events but may register events in the wrong direction occasionally.

Experiment

Program yl040c was written to allow you to test-drive the rotary control with a counter. Run the program with the control ready.

$ ./yl040c
Monitoring rotary control:
Step +1, Count 1
Step +1, Count 2
Step +1, Count 3
Step +1, Count 4
Step +1, Count 5
Step -1, Count 4
Step -1, Count 3
Step -1, Count 2
Step -1, Count 1
Step -1, Count 0
Step -1, Count -1
Step -1, Count -2
Step -1, Count -3
Step +1, Count -2
Step +1, Count -1
Step +1, Count 0
^C

The program clearly states the direction of the step as clockwise (+1) or counterclockwise (-1) and reports the affected counter. The counter is taken up to 5 by a clockwise motion and taken back to -3 in a counterclockwise motion and then clockwise again to return to 0. When your control is working properly, this will be an effortless exercise.

FM Dial 1

While your rotary control seems to work nicely, it may not be convenient enough in its current form. To illustrate this, let’s simulate the FM stereo tuner knob with the rotary control. Run the program fm1 with the control ready. Try tuning from end to end of the FM dial (the program starts you in the middle).

$ ./fm1
FM Dial with NO Flywheel Effect.
100.0 MHz
100.1 MHz
100.2 MHz
100.3 MHz
100.4 MHz
100.5 MHz
100.6 MHz
100.7 MHz
100.8 MHz
100.9 MHz
101.0 MHz
101.1 MHz
101.2 MHz
101.3 MHz
101.2 MHz
101.1 MHz
101.0 MHz
100.9 MHz
100.8 MHz
100.7 MHz
100.6 MHz
100.5 MHz
100.4 MHz
100.3 MHz
100.2 MHz
100.1 MHz
100.0 MHz
 99.9 MHz
 99.8 MHz
 99.7 MHz
 99.6 MHz
 99.5 MHz
 99.4 MHz
 99.3 MHz
 99.2 MHz
 99.1 MHz
 99.0 MHz
 99.1 MHz
^C

How convenient was it to go from 100.0MHz down to 99.1MHz? Did you have to twist the knob a lot? To save rotational effort, many electronic controls simulate a “flywheel effect.”

The program fm1 uses the RotarySwitch class, which responds in a simple linear fashion to the rotary encoder. If the control clicks once to the right, it responds by incrementing the count by 1. If it clicks counterclockwise, the counter is decremented by 1 instead. You’ll look at code for this at the end of this chapter.

Spin a bicycle wheel, and it continues to rotate after you stop and watch. Friction causes the rotation to slow and eventually stop. This is flywheel action, and it is convenient to duplicate this in a control. Some high-end stereo and ham radio gear have heavy knobs in place so that they continue to rotate if you spin them fast enough.

FM Dial 2

Let’s repeat the last experiment with the program fm2. In the following example, the dial was turned clockwise slowly at first. Then a more rapid twist was given, and the dial shot up to about 102.0MHz. One more rapid counterclockwise twist took the frequency down to 98.8MHz.

$ ./fm2
FM Dial with Flywheel Effect.
100.0 MHz
100.1 MHz
100.2 MHz
100.3 MHz
100.4 MHz
100.5 MHz
100.6 MHz
100.8 MHz
101.0 MHz
101.2 MHz
101.4 MHz
101.6 MHz
101.7 MHz
101.8 MHz
101.9 MHz
102.0 MHz
101.9 MHz
101.8 MHz
101.7 MHz
101.6 MHz
101.5 MHz
101.3 MHz
101.0 MHz
100.8 MHz
100.6 MHz
100.2 MHz
 99.8 MHz
 99.5 MHz
 99.3 MHz
 99.1 MHz
 98.9 MHz
 98.8 MHz
 98.7 MHz
 98.6 MHz
 98.7 MHz
 98.8 MHz
 98.9 MHz
 99.0 MHz

With a more vigorous twist of the knob, you can quickly go from one end of the dial to the other. Yet, when rotation speeds are reduced, you have full control with fine adjustments. It is important to retain this later quality.

The following session output demonstrates some vigorous tuning changes:

$ ./fm2
FM Dial with Flywheel Effect.
100.0 MHz
100.1 MHz
100.2 MHz
100.3 MHz
100.4 MHz
100.5 MHz
100.8 MHz
101.4 MHz
102.3 MHz
103.4 MHz
104.6 MHz
105.8 MHz
107.2 MHz
107.9 MHz
107.9 MHz
107.9 MHz
107.9 MHz
107.9 MHz
107.9 MHz
107.8 MHz
107.7 MHz
107.6 MHz
107.5 MHz
107.4 MHz
107.2 MHz
106.7 MHz
105.8 MHz
104.3 MHz
102.2 MHz
 99.8 MHz
 97.2 MHz
 94.6 MHz
 91.9 MHz
 89.2 MHz
 88.1 MHz
 88.1 MHz
 88.1 MHz
 88.1 MHz

Class Switch

To keep the programs simple, I’ve built up the programs using C++ classes. The GPIO class is from the librpi2 library, which you should have installed already (see Chapter 1). This gives you convenient direct access to the GPIO ports.

Listing 8-1 illustrates the Switch class definition. This functions well as the contract between the end user and the implementation of the class. Aside from instantiating the Switch class in the user program, the only method call that is of interest is the read() method, which reads from the GPIO port and debounces the signal.

Listing 8-1. The Switch Class for Handling Rotary Encoder Contacts and Debouncing in switch.hpp

009 /*
010  * Class for a single switch
011  */
012 class Switch {
013     GPIO&          gpio;   // GPIO Access
014     int            gport;  // GPIO Port #
015     unsigned       mask;   // Debounce mask
016     unsigned       shiftr; // Debouncing shift register
017     unsigned       state;  // Current debounced state
018
019 public: Switch(GPIO& gpio,int port,unsigned mask=0xF);
020     unsigned read();       // Read debounced
021 };

Listing 8-2 shows the constructor for this class. The reference (argument agpio) to the caller’s instance of the GPIO class is saved in the Switch class for later use in line 010 (as gpio). The GPIO port chosen for this switch is indicated in aport and saved in gport. The value of amask defaults to the value of 0x0F, which specifies that 4 bits are to be used for debouncing. You can reduce the number of bits to 3 bits by specifying the value of 0x07.

Listing 8-2. The Switch Class Constructor Code in switch.cpp

006 /*
007  * Single switch class, with debounce:
008  */
009 Switch::Switch(GPIO& agpio,int aport,unsigned amask)
010 : gpio(agpio), gport(aport), mask(amask) {
011
012     shiftr = 0;
013     state = 0;
014
015     // Configure GPIO port as input
016     gpio.configure(gport,GPIO::Input);
017     assert(!gpio.get_error());
018
019     // Configure GPIO port with pull-up
020     gpio.configure(gport,GPIO::Up);
021     assert(!gpio.get_error());
022 }

The shift register for debouncing (shiftr) is initialized to 0 in line 012, and the variable state is initialized to 0 also. Line 016 configures the specified GPIO port as an input and activates its pull-up resistor in line 020.

The assert() macros used will cause an abort if the expressions provided ever evaluate as false. These give the programmer the assurance that nothing unexpected has happened. They can be disabled by defining the macro NDEBUG at compile time, if you like. The cost of these is low, so I usually leave them compiled in.

Listing 8-3 illustrates the code for reading the switch and debouncing the contacts. The algorithm used is the same procedure as described in Chapter 5.

Listing 8-3. The Switch::read() Method for Debouncing Contacts in switch.cpp

024 /*
025  * Read debounced switch state:
026  */
027 unsigned
028 Switch::read() {
029     unsigned b = gpio.read(gport);
030     unsigned s;
031
032     shiftr = (shiftr << 1) | (b & 1);
033     s = shiftr & mask;
034
035     if ( s != mask && s != 0x00 )
036            return state;   // Bouncing: return state
037     if ( s == state )
038             return state;  // No change
039     state = shiftr & 1;    // Set new state
040     return state;
041 }

The Switch class provides input and debouncing for only one contact. To make a rotary control, you need to debounce two switches. For that, you define the RotarySwitch class shown in Listing 8-4.

Listing 8-4. The RotarySwitch Class for Debouncing and Reading in rotary.hpp

008 /*
009  * Class for a (pair) rotary switch:
010  */
011 class RotarySwitch {
012     Switch         clk;    // CLK pin
013     Switch         dt;     // DT pin
014     unsigned       index;  // Index into states[]
015 protected:
016     unsigned read_pair();  // Read (CLK << 1) | DT
017
018 public: RotarySwitch(GPIO& gpio,int clk,int dt,unsigned mask=0xF);
019     int read();            // Returns +1, 0 or -1
020 };

In the RotarySwitch class, notice how the two switch contacts are handled by two Switch class instances named clk and dt (lines 012 and 013). Line 014 declares a variable index, which will be described shortly. The class method read_pair() is declared in the protected region so that when using class inheritance, you will have access to it (line 016). The constructor in line 018 is almost the same as Switch, except that you have two GPIO numbers provided for clk and dt.

Listing 8-5 shows the read_pair() method code. It reads a bit from switches clk and dt and returns them as a pair of bits for convenience. Lumping them together in this way provides some programming convenience.

Listing 8-5. RotarySwitch::read_pair() Method in rotary.cpp

029 /*
030  * Protected: Read switch pair
031  */
032 unsigned
033 RotarySwitch::read_pair() {
034   return (clk.read() << 1) | dt.read();
035 }

Listing 8-6 shows the more interesting code. To read the encoder, a small table is used, declared in lines 008 and 009. These identify the next bit pairs expected when rotation is progressing clockwise.

Listing 8-6. The RotarySwitch::read() Method for Interpreting the Rotary Encoder in rotary.cpp

05 /*
006  * State array for CLK & DT switch settings:
007  */
008 static unsigned states[4] =
009     { 0b00, 0b10, 0b11, 0b01 };
010
...
038 /*
039  * Read rotary switch:
040  *
041  * RETURNS:
042  * +1      Rotated clockwise
043  *  0      No change
044  * -1      Rotated counter-clockwise
045  */
046 int
047 RotarySwitch::read() {
048     unsigned pair = read_pair();
049     unsigned cw = (index + 1) % 4;
050     unsigned ccw = (index + 3) % 4;
051
052     if ( pair != states[index] ) {
053             // State has changed
054             if ( pair == states[cw] ) {
055                    index = cw;
056                    return (pair == 0b11 || pair == 0b00) ? +1 : 0;
057             } else if ( pair == states[ccw] ) {
058                    index = ccw;
059                    return (pair == 0b11 || pair == 0b00) ? -1 : 0;
060             }
061    }
062
063    return 0;        // No change
064 }

As the comments document (lines 041 to 044), the RotarySwitch::read() method returns a signed value.

• +1 when the control has rotated clockwise

• -1 if in the reverse

• 0 if there was no event to report

The first operation is to read from the pair of switches (line 048). This bit pair is debounced thanks to the work of the Switch class that was used to manage them. The values cw and ccw are the computed next index values into array states for clockwise and counterclockwise (lines 049 and 050).

Line 052 checks to see whether the value read (variable pair) has changed from the last time. If so, an event has happened, and line 054 tests to see whether you went clockwise. If so, the value of index is updated in line 055 and a +1 or 0 is returned. The +1 is returned, however, only if the control is now at one of the detent positions where pair reads as 0b00 or 0b11. Otherwise, you pretend that nothing happened by returning 0. Lines 057 to 059 perform the same function for counterclockwise. Failing all else, line 063 returns 0 to indicate that nothing interesting happened.

Listing 8-7 shows how the class Flywheel inherits from class RotarySwitch. This allows you to leverage what you’ve already built, while adding the flywheel effect on top. The constructor in line 019 for Flywheel is the same as for RotarySwitch. Like before, the Flywheel::read() method returns the same values.

Listing 8-7. Class Flywheel for Rotary Control with Flywheel Effect, in flywheel.hpp

011 /*
012  * Class for a (pair) Rotary switch:
013  */
014 class Flywheel : public RotarySwitch {
015     timespec       t0;     // Time of last motion
016     double         ival;   // Last interval time
017     int            lastr;  // Last returned value r
018
019 public: Flywheel(GPIO& gpio,int clk,int dt,unsigned mask=0xF);
020     int read();            // Returns +1, 0 or -1
021 };

To implement the Flywheel class, you need a fine set of timing functions. Listing 8-8 shows some local functions that are used by the class. The function get_time() is used to get time with nanosecond precision. It should be understood, however, that the time returned in the structure timespec may not be that accurate but is provided in seconds (member tv_sec) and nanoseconds (member tv_nsec).

Listing 8-8. The Local Static Functions Used by the Flywheel Implementation, in flywheel.cpp

009 static inline void
010 get_time(timespec& tv) {
011   int rc = clock_gettime(CLOCK_MONOTONIC,&tv);
012   assert(!rc);
013 }
014
015 static inline double
016 as_double(const timespec& tv) {
017   return double(tv.tv_sec) + double(tv.tv_nsec) / 1000000000.0;
018 }
019
020 static inline double
021 timediff(const timespec& t0,const timespec& t1) {
022   double d0 = as_double(t0), d1 = as_double(t1);
023
024   return d1 - d0;
025 }
026
027 Flywheel::Flywheel(GPIO& agpio,int aclk,int adt,unsigned amask)
028 : RotarySwitch(agpio,aclk,adt,amask) {
029
030   get_time(t0);
031   lastr = 0;
032 };

The function as_double() in lines 015 to 018 convert the timespec value into a double value, which is more convenient to compute with. The routine timediff() in lines 020 to 025 compute the time difference in seconds.

The constructor in lines 027 to 032 initializes the inherited RotarySwitch class (line 028) and initializes t0 with a start time.

Listing 8-9 is the main star of this chapter, illustrating the extra code used to implement the flywheel effect. Line 035 replaces the RotarySwitch::read() method for this class with new code and tricks.

Listing 8-9. The Meat of the Flywheel Class in flywheel.cpp

034 int
035 Flywheel::read() {
036     static const double speed = 15.0; // Lower values change faster
037     timespec t1;                   // Time now
038     double diff, rate;             // Difference, rate
039     int r, m = 1;                  // Return r, m multiple
040
041     r = RotarySwitch::read();       // Get reading (debounced)
042     get_time(t1);                   // Now
043     diff = timediff(t0,t1);         // Diff in seconds
044
045     if ( r != 0 ) {                // Got a click event
046             lastr = r;             // Save the event type
047             ival = ( ival * 0.75 + diff * 1.25 ) / 2.0 * 1.10;
048             if ( ival < 1.0 && ival > 0.00001 ) {
049                    rate = 1.0 / ival;
050             } else rate = 0.0;
051             t0 = t1;
052             if ( speed > 0.0 )
053                    m = rate / speed;
054    } else if ( diff > ival && ival >= 0.000001 ) {
055            rate = 1.0 / ival;      // Compute a rate
056            if ( rate > 15.0 ) {
057                    if ( speed > 0.0 )
058                            m = rate / speed;
059                    ival *= 1.2;    // Increase interval
060                    t0 = t1;
061                    r = lastr;      // Return last r
062            }
063     }
064
065     return m > 0 ? r * m : r;
066 }

Line 041 uses the original RotarySwitch::read() call to read the value of +1, 0, or -1 depending upon the rotary control. But the Flywheel version of read() will perform some additional processing.

Line 042 assigns the current time in nanoseconds to t1. Using the start time t0, the elapsed time from the last event is computed in line 043 (variable diff). This difference in time is a floating-point value in seconds but includes the fractional difference in nanoseconds. If the control has been sitting idle for a long time, this difference may be very long for the first time (perhaps minutes or hours). However, successive events will have time differences of perhaps of 10 milliseconds.

Line 045 tests to see whether you got an event in variable r. If there was rotation, r will be nonzero. The rotation event is recorded for later use in line 046 (variable lastr). Then a weighted average is computed from the prior interval and current difference in line 047 (stored in variable ival). An additional 10 percent is added to the value by multiplying by 1.10. The rationale for this adjustment will be revealed shortly, including why lines 048 to 053 compute a rate value and a multiple m.

Lines 045 to 053 just described operate when there is a rotational event—either the control has clicked over, clockwise or clockwise. But what happens after quickly rotating the knob and releasing it? Or slowing down?

When there is no rotational event in line 045, control passes to line 054 to test whether the current time difference (diff) is greater than the last computed interval ival. Recall that the weighted value of ival had 10 percent added to it (at the end of line 047). As the rotational rate increases, the time difference between events gets smaller (diff). So, as long as this time interval decreases or remains about the same, the generated flywheel events are suppressed. In fact, the rate of rotation would have to drop below 10 percent of the current weighted average before the flywheeling applies. By doing this, expected events that occur on time are handled normally. Only when expected next events are late do you consider synthesizing events in the flywheeling code.

Line 054 also insists that the last weighted interval time (ival) is greater than 0.000001. This is a rate-limiting action on the flywheeling effect. Line 055 computes a rate, which is the inverse of time interval (ival). Only when the rate rises above 15.0 do you synthesize more flywheel events (line 056). The variable speed is hard-coded with the value 15.0 (line 036). It is used to compute the multiple m from the rate using division (lines 053 and 058). If you change the value of speed to zero, there will be no multiplying effect.

The effect of the multiple of m is to increase the value returned from a simple +1 to, say, a +8, when the rotational rate is high. This applies to line 065. When the rotational rate slows, the multiple has less effect, and the control responds in smaller increments.

In the flywheeling section in line 059, you compute a next interval time (ival). Here the interval time has 20 percent added to it so that it slows and becomes less likely to synthesize another event. This reduces the next rate calculation in line 056. As ival is increased, eventually the rate value drops below 15.0 and then ceases to synthesize any more events. Lines 060 and 061 reset the timer t0 and set the returned r to the lastr value saved. Line 065 brings it all together by applying multiple m and r.

Main Routine

To knit this all together, let’s review the main program for fm2.cpp, which uses the Flywheel class. Because the tricky stuff is located inside the class implementation code, the main programs used in this chapter are essentially the same. Listing 8-10 presents fm2.cpp.

Listing 8-10. The Main Program for fm2.cpp

012 #include "flywheel.hpp"
013
014 /*
015  * Main test program:
016  */
017 int
018 main(int argc,char **argv) {
019     GPIO gpio;             // GPIO access object
020     int rc, counter = 1000;
021
022     // Check initialization of GPIO class:
023     if ( (rc = gpio.get_error()) != 0 ) {
024             fprintf(stderr,"%s: starting gpio (sudo?)\n",strerror(rc));
025            exit(1);
026     }
027
028     puts("FM Dial with Flywheel Effect.");
029     printf("%5.1lf MHz\n",double(counter)/10.0);
030
031     // Instantiate our rotary switch:
032     Flywheel rsw(gpio,20,21);
033
034     // Loop reading rotary switch for changes:
035     for (;;) {
036            rc = rsw.read();
037             if ( rc != 0 ) {
038                    // Position changed:
039                    counter += rc;
040                    if ( counter < 881 )
041                            counter = 881;
042                    else if ( counter > 1079 )
043                            counter = 1079;
044                    printf("%5.1lf MHz\n",double(counter)/10.0);
045              } else {
046                    // No position change
047                    usleep(1);
048              }
049     }
050
051     return 0;
052 }