Physical Considerations

Be aware that on the Duemilanove PCB, and probably other boards as well, there are two surface-mounted capacitors that can collide with the extra pins found on the power and analog connector row of some shields designed for the R3 extended baseline layout. Some variants of the Uno also have components that can collide with shield pins.

Another consideration is that the type B USB jack found on the Duemilanove and Uno boards can potentially short out against a shield PCB. The DC power jack on these boards can also interfere with a shield PCB. Although it is plastic and won’t short anything, it can prevent the shield from seating completely. Figure 10-6 shows this situation with a Duemilanove and an Ethernet shield.

For these reasons, it’s a good idea to either size the length of the shield so that it won’t interfere with the underlying Arduino, or design the component placement on the shield PCB to leave collision areas blank. See the next section, Chapter 4, and Chapter 8 for more on PCB dimensions and shield stacking.

When designing a shield you may also want to consider what will no longer be accessible on the Arduino under the shield and what can, or cannot, be mounted on it. This includes the reset button, the surface-mounted LEDs, and the ICSP pin group. Some shields deal with this by simply replicating the pinout of the Arduino board. Others, like most LCD shields, may not replicate the Arduino’s pins to the top side of the shield PCB, but sometimes provide a reset button. With an LCD shield this makes sense, of course, since it would be the top shield in a stack in any case.

Figure 10-6. Duemilanove with shield

Stacking Shields

One of the nice things about the Arduino form factor is the ability to stack shields. You could create a stack containing a base Arduino board (an Uno, for example) with an SD memory card shield on top of it, followed by an input/output shield of some sort, and then an LCD or TFT display shield on top of all of that. Presto, you now have a basic data logging device.

What can be mounted above a shield should always be a consideration, be it another shield or perhaps some type of sensor module. When selecting components for a shield it is wise to consider the height of the various parts. If the parts are too high and another shield cannot be physically attached without interfering with something, then that shield will always need to be on the top of the stack.

There are basically two ways to allow for shield stacking: staggered socket and pin headers, and extended pin socket headers. Staggered, in this context, means that the upper connectors (socket headers) are offset from the lower pins (pin headers) by some amount, with both the upper digital I/O and power/analog headers shifted to the same side by the same amount.

In Figure 10-7 you can see a modular I/O shield on a Duemilanove. There are a few things to notice here. First, the modular I/O shield uses the staggered connector approach, so it is not vertically edge-aligned with the underlying Arduino board. This may need to be taken into account if the assembly will be mounted in some type of enclosure that might be subjected to shock or vibration—it may not be possible to secure the shield with nuts and bolts. Secondly, the shield does not bring out the ICSP pins, so that functionality is effectively lost (which may, or may not, be a big deal). Lastly, the pins of the connectors along the edge of the shield above the Arduino’s power and USB connector can (and do) collide, so some type of insulating shim is necessary.

Figure 10-7. Example of a staggered shield

Extended pin connector sockets are a common variation on the 0.1 center connectors that have a long pin that goes through the PCB. The pin is long enough to make a solid connection with an underlying board, and the connector sockets provide for another shield board to mount on top and be in alignment with the shield below it. These are found on many shields, and you should look for them when selecting a shield.

A big consideration in shield design is Arduino pin usage. This is in addition to stacking concerns. The pins used by a shield determine what else can be used with that shield in a stack. Avoiding exclusive use of the SPI and I2C pins means other shields can be used in a stack, including SD and microSD flash memory, I/O expander, Bluetooth, ZigBee, Ethernet, and GSM shields. In other words, don’t repurpose the SPI or I2C pins unless the shield design absolutely needs them.

Sometimes you may encounter shields that someone obviously thought were a good idea, but which don’t always work out so well in practice. I/O shields often have multiple blocks of connector pins that are rendered inaccessible if another shield is placed on them. Other shields have solder pads that interfere with the ICSP pins on the Arduino PCB. Problems like these are not uncommon. Unfortunately it’s not always possible to know in advance if there are problems with a shield, and sometimes the only way to know if a particular shield might have physical mounting issues is to purchase one and try it.

Electrical Considerations

If your custom shield has nothing but passive components (i.e., connectors, switches, resistors), power supply requirements probably won’t be an issue for the board. However, if it has LEDs or active circuitry, it is a good idea to consider how much power it will need, and where it will get it. Even something as simple as an LED draws some power, and enough of them can overload an AVR processor and do some damage.

As a general rule, if a shield has one or more relays or connectors to attach things that could draw more than a few milliamps each, then some type of driver circuit or IC should be considered. It is possible to operate a shield from a separate power supply, but passing signals between the Arduino and the shield can sometimes be tricky.

If a shield has its own DC power source, then ground might also be something to consider. There are three ground sockets on a baseline Arduino: two on the side with the analog inputs and one on the digital I/O side. If you use only one of the Arduino’s ground sockets for the signal ground reference for a shield, you can avoid potential problems with induced noise and ground loops. Although these situations are very rare, they are still a possibility, particularly for shields that may incorporate high-gain operational amplifiers or high-frequency circuits. Applying good design practices can help avoid strange and hard-to-diagnose problems in the future.

Objectives

The goal of this project is to create a shield that can be used as an autonomous remote monitor to sense temperature, humidity, soil moisture content, and ambient light level. Based on predefined sensor input limits, it will control two relays.

The relays can be used to control a water valve, and perhaps a fan or maybe some lights to compensate for cloudy days. It also has six LEDs: two for high and low humidity points, two for high and low soil moisture levels, and an LED for each relay to indicate activity.

The software will support a command-response protocol and maintain an internal table of automatic relay functions mapped to sensor inputs and limits. Alternatively, a host control computer can obtain the sensor readings on demand and control the relays directly.

Definition and Planning

The shield will incorporate a DHT22 combination temperature and humidity sensor, a light-dependent resistor (LDR) sensor (see Chapter 9) to detect the ambient light level, and a conductivity-based soil moisture probe. Two relays will provide automatic or commanded control of external devices or circuits.

Sensor inputs:

• Temperature

• Relative humidity

• Soil moisture (relative)

• Ambient light level

Control and status outputs:

• Two control relays, software function definable, 10A control capability

• Four LEDs to indicate soil moisture and humidity limits

• Two LEDs to indicate relay status

Electrical interface:

• Two-position terminal block for moisture probe input

• Two-position terminal block for LDR connection

• One three-position terminal block per relay (NC, C, and NO)

• +5V DC supplied by attached Arduino board

Control interface:

• Command-response protocol, control host driven

• Sensor readings available on demand

• Relay override by control host

All of the components will be placed on a standard baseline-type shield, with dimensions as described in Chapter 4. Most of the components will be surface-mount types, with the exception of the terminal blocks, the relays, and the DHT22 temperature and humidity sensor.

Design

The GreenShield is intended to be used without a display or user controls. In other words, it and an Arduino will operate as an autonomous remote sensor and controller. It can be connected to another computer system (the master host system) to receive operating parameters, return sensor data, and override relay operation.

Autonomous in this case means the GreenShield will be able to operate the relays automatically when specific conditions are met, such as humidity, soil moisture, or light levels. The software will accept commands from a master computer to set the various threshold levels and override the operation of the relays. It will generate a response on command containing the current temperature, humidity, light level, and relay states. All interactions between the control host and a GreenShield Arduino will be command-response transactions.

The GreenShield software will be developed entirely with the Arduino IDE. The host computer used to compile and upload the finished code will also serve as the test terminal interface when the code is running on the Arduino. Ideally one would want to create a custom interface program using something like Python, or, in a Windows environment, a terminal emulator like TeraTerm. It includes an excellent scripting facility, and I highly recommend it.

Functionality

The first consideration is the physical design of the shield PCB. The block diagram shown in Figure 10-8 gives an overview of what types of functions will be on the shield.

Note that in Figure 10-8 none of the hardware functions interact directly. The sensors, LEDs, and relays are just extensions of the Arduino’s basic I/O capabilities.

The humidity/temperature sensor is mounted on the PCB, while the photocell (a light-dependent resistor) and the soil moisture probe can be located off-board if desired. Miniature terminal blocks are used for sensor connections, so no soldering or connector crimping is required.

Figure 10-8. GreenShield block diagram

The GreenShield is intended to be the last (top) shield on a stack. This is due to the relays and the temperature/humidity sensor, all of which are tall enough to prohibit stacking another shield.

Hardware

Circuit-wise the GreenShield isn’t very complicated, as can be seen in the schematic shown in Figure 10-9. A ULN2003A is used to drive status LEDs and two relays. A dual op amp is used to buffer the voltage level from a soil moisture sensor and an LDR for input to the AVR ADC.

The sensors connected to the op amp inputs are effectively variable resistors, and with the two trimmer potentiometers they form a voltage divider. The trimmers can be adjusted to achieve an optimal response from the op amp without driving it too far one way or the other voltage-wise.

Figure 10-9. GreenShield schematic

The GreenShield has been designed to allow for extending the Arduino shield stack by avoiding critical digital and analog I/O pins. Table 10-1 lists the Arduino pins and assignments used for the GreenShield.

Table 10-1. GreenShield Arduino pin usage

Pin	Function	Pin	Function
D2	ULN2003A channel 1	D7	ULN2003A channel 6
D3	ULN2003A channel 2	D8	DHT22 data input
D4	ULN2003A channel 3	A0	Soil moisture sensor input
D5	ULN2003A channel 4	A1	LDR sensor input

Notice that the SPI pins—D10, D11, D12, and D13—are not used, so they are available for SPI shields. D0 and D1 are also available if you want to connect an RS-232 interface and forgo the USB. A4 and A5 are available for I2C applications.

Now that we have a schematic we can assemble a complete parts list, which is given in Table 10-2.

Table 10-2. GreenShield parts list

Quantity	Type	Description	Quantity	Type	Description
2	SRD-05VDC-SL-C	Songle 5A relay	4	2.2K ohm, 1/8W	Resistor
1	DHT22	Humidity/temperature sensor	2	3.3K ohm, 1/8W	Resistor
1	Generic	LDR sensor	2	10K trim	PCB mount potentiometer
1	SainSmart	Soil moisture probe	2	0.1” (2.54 mm)	3-position terminal block
6	3 mm	LED	2	0.1” (2.54 mm)	2-position terminal block
1	LM358N	Op amp	2	0.1” (2.54 mm)	8-position socket header
1	ULN2003A	Driver IC	2	0.1” (2.54 mm)	6-position socket header
6	1K ohm, 1/8W	Resistor	1	Custom	Shield PCB

Prototype

To create the prototype for this project I’m using something called a Duinokit, which is shown in Figure 10-10. This clever thing has an array of sensors, LEDs, switches, and other accessories along with an Arduino Nano, all mounted on a large PCB with lots of socket headers. It also has a position for attaching a conventional shield (or stack of shields). It’s like a modern take on the old all-in-one electronics project kits that were once popular.

Figure 10-10. The Duinokit

An equally valid approach would be to assemble all the necessary components from a sensor kit and just about any Arduino, but the Duinokit keeps things neat and tidy, and it provides a nice development platform to use to create the software while waiting for the PCB and some of the other parts to show up. The Duinokit is available from http://duinokit.com and through Amazon.com.

The Duinokit has one DHT11 temperature/humidity sensor, which is a slower, lower-resolution version of the DHT22 that will be used with the GreenShield. In terms of software, the DHT11 and DHT22 are similar but not identical. The DHT22 uses a different data word (bit string) than the DHT11 to accommodate the improved accuracy of the DHT22 sensor.

The LDR and soil moisture sensor use an LM358 dual op amp, with one-half assigned to each input. I placed the LM358 on the solderless breadboard provided on the Duinokit’s single large PCB. This also provided a place to mount the resistors, and the two 10K potentiometers on the Duinokit served as the input offset trim controls.

// GreenShield prototype software
// 2015 J. M. Hughes
//
// Uses DHT11 library from George Hadjikyriacou, SimKard, and Rob Tillaart
//
// Repeatedly reads and outputs temperature, humidity, soil moisture,
// and light level. No relay setpoint functionality.

#include <dht11.h>

// Definitions

#define LHLED       2       // D2   Low humidity LED
#define HHLED       3       // D3   High humidity LED
#define LMLED       4       // D4   Low moisture
#define HMLED       5       // D5   High moisture
#define RY1OUT      6       // D6   RY1 enabled
#define RY2OUT      7       // D7   RY2 enable
#define DHT11PIN    8       // D8   DHT11 data
#define SMSINPUT    A0      // A0   SMS input
#define LDRINPUT    A1      // A1   LDR input

// Global Vars

int curr_temp   = 0;        // current (latest) temperature
int curr_hum    = 0;        // current humidity
int curr_ambl   = 0;        // current ambient light level
int curr_sms    = 0;        // current soil moisture

int cntr = 0;


// dht11 object is global
dht11 DHT11;


// Read data from DHT11 and store in curr_hum and curr_temp global
// variables for later use
void readDHT()
{
    if (!DHT11.read(DHT11PIN)) {
        curr_hum = DHT11.humidity;
        curr_temp = DHT11.temperature;
    }
}


// Read data from analog inputs via LM358 op amp circuits and store
// in curr_ambl and curr_sms for later use
void readAnalog()
{
    curr_ambl = analogRead(LDRINPUT);
    curr_sms  = analogRead(SMSINPUT);
}


// Celsius to Fahrenheit conversion
// From example code found at http://playground.arduino.cc/main/DHT11Lib
double Fahrenheit(double celsius)
{
    return 1.8 * celsius + 32;
}


// Celsius to Kelvin conversion
// From example code found at http://playground.arduino.cc/main/DHT11Lib
double Kelvin(double celsius)
{
    return celsius + 273.15;
}


// dewPoint() function NOAA
// reference: http://wahiduddin.net/calc/density_algorithms.htm
// From example code found at http://playground.arduino.cc/main/DHT11Lib
double dewPoint(double celsius, double humidity)
{
    double A0= 373.15/(273.15 + celsius);
    double SUM = -7.90298 * (A0-1);
    SUM += 5.02808 * log10(A0);
    SUM += -1.3816e-7 * (pow(10, (11.344*(1-1/A0)))-1) ;
    SUM += 8.1328e-3 * (pow(10,(-3.49149*(A0-1)))-1) ;
    SUM += log10(1013.246);
    double VP = pow(10, SUM-3) * humidity;
    double T = log(VP/0.61078);   // temp var
    return (241.88 * T) / (17.558-T);
}

// delta max = 0.6544 wrt dewPoint()
// 5x faster than dewPoint()
// reference: http://en.wikipedia.org/wiki/Dew_point
// From example code found at http://playground.arduino.cc/main/DHT11Lib
double dewPointFast(double celsius, double humidity)
{
    double a = 17.271;
    double b = 237.7;
    double temp = (a * celsius) / (b + celsius) + log(humidity/100);
    double Td = (b * temp) / (a - temp);
    return Td;
}


void setup()
{
    // Init the serial I/O
    Serial.begin(9600);

    // Set up the AVR's pins
    pinMode(LHLED,OUTPUT);
    pinMode(HHLED,OUTPUT);
    pinMode(LMLED,OUTPUT);
    pinMode(HMLED,OUTPUT);
    pinMode(RY1OUT,OUTPUT);
    pinMode(RY2OUT,OUTPUT);

    // Initial current data variables
    curr_temp = 0;
    curr_hum  = 0;
    curr_ambl = 0;
    curr_sms  = 0;
}


void loop()
{
    // Get DHT11 readings
    readDHT();

    // Get LDR and SMS readings
    readAnalog();

    // Print data to output
    Serial.println("
");
    Serial.print("Raw LDR           : ");
    Serial.println(curr_ambl);
    Serial.print("Raw SMS           : ");
    Serial.println(curr_sms);
    Serial.print("Humidity (%)      : ");
    Serial.println((float)DHT11.humidity, 2);
    Serial.print("Temperature (oC)  : ");
    Serial.println((float)DHT11.temperature, 2);
    Serial.print("Temperature (oF)  : ");
    Serial.println(Fahrenheit(DHT11.temperature), 2);
    Serial.print("Temperature (K)   : ");
    Serial.println(Kelvin(DHT11.temperature), 2);
    Serial.print("Dew Point (oC)    : ");
    Serial.println(dewPoint(DHT11.temperature, DHT11.humidity));
    Serial.print("Dew PointFast (oC): ");
    Serial.println(dewPointFast(DHT11.temperature, DHT11.humidity));

    // Scroll up to align display
    for (int i = 0; i < 12; i++)
        Serial.println();

    delay(1000);
}

Final Software

The prototype software only handles the sensor inputs. The final version will also handle the host control interface and relay setpoint function mapping. This involves input command parsing, along with data storage and lookup.

There are no output displays beyond the four humidity and temperature range status LEDs, and no manual control inputs. A simple USB serial interface is used for command-response transactions between the GreenShield Arduino and a host control computer. The bulk of the software involves interpreting the commands from the control host PC, and then applying the setpoint mapping to the relays.

Source code organization

The final version of the GreenShield source code is contained in multiple source files, or modules. When the Arduino IDE opens the main file, GreenShield.ino, it will also open the other associated files in the same directory. The secondary files are placed in “tabs” in the IDE as shown in Figure 10-11.

Figure 10-11. The Arduino IDE with the GreenShield files loaded

Table 10-8 lists the files in the GreenShield set. Two files are shared by all the source modules. These are gs.h and gs_gv.h. The global variables defined in gs_gv.cpp that would otherwise be found at the start of a conventional sketch are compiled separately and shared as necessary among the other modules.

Table 10-8. GreenShield source code modules

Module	Function
GreenShield.ino	Primary module containing setup() and loop()
gs_gv.cpp	Global variables
gs_gv.h	Include file
gs.h	Constant definitions (#define statements)
gs_mapping.cpp	Function mapping
gs_mapping.h	Include file
gs_parse.cpp	Command parsing
gs_parse.h	Include file
gs_send.cpp	Data send (to host) functions
gs_send.h	Include file

Organizing a project in this manner makes it easier to deal with just one section at a time without wading through line after line of source code. Once the main section is done, then changes can be made to other modules without interfering with the finished code. This approach also helps in thinking about your software from a modular perspective, and this in turn makes it easier to understand and easier to maintain.

Software description

Figure 10-12 shows the flowchart for the main loop of the software. The loop() function begins with the “Start” block and it will continue until the Arduino is powered off. Note that there are three primary functional sections: command input and response processing, data acquisition, and minimum/maximum setpoint testing. Also note that the block labeled “Setpoint Test” is one instance of four blocks, one for each pair of min/max setpoints. In order to keep the size of the diagram reasonable, only one test section is shown.

The GreenShield.ino source file, shown in Example 10-2, contains the setup() and loop() functions. The complete GreenShield software can be found on GitHub.

Figure 10-12. GreenShield flowchart

Example 10-2. GreenShield main source file

// GreenShield.ino
//
// Created for "Arduino: A Technical Reference," 2016, J. M. Hughes
// Chapter 10

#include "gs.h"
#include "gs_gv.h"
#include "gs_parse.h"
#include "gs_send.h"
#include "gs_mapping.h"
#include <dht.h>

void setup()
{
  Serial.begin(9600);

  pinMode(LED1, OUTPUT);
  pinMode(LED2, OUTPUT);
  pinMode(LED3, OUTPUT);
  pinMode(LED4, OUTPUT);

  pinMode(RY1,  OUTPUT);
  pinMode(RY2,  OUTPUT);

  Serial.println("OK");
}


void loop()
{
    ParseCmd();

    curr_temp  = ReadTemp();
    curr_humid = ReadHumidity();
    curr_moist = ReadMoisture();
    curr_light = ReadLight();

    ScanMap();
}

The Arduino IDE relies on the #include statements to determine which modules belong in the code set. Even if a source file isn’t directly used by the top-level module, it must still be included.

The global definitions file gs.h, shown in Example 10-3, defines a set of constants used by the GreenShield source modules. The #define statements result in a smaller compiled object, as demonstrated in “Constants”.

Example 10-3. GreenShield global definitions

// gs.h
//
// Created for "Arduino: A Technical Reference," 2016, J. M. Hughes
// Chapter 10

#ifndef GSDEFS_H
#define GSDEFS_H

#define MAXINSZ         12      // Input buffer size

#define NOERR           0       // Error codes
#define TIMEOUT         1
#define BADCHAR         2
#define BADVAL          3

#define LED1            2       // LED pin definitions
#define LED2            3
#define LED3            4
#define LED4            5
#define RY1             6       // Relay pin definitions
#define RY2             7

#define DHT22           8       // DHT22 I/O pin
#define MPROBE          A0      // Moisture probe input
#define LDRIN           A1      // LDR input

#define MAXRY           2       // Maximum num of relays

#define MAP_NONE        0       // Mapping vectors
#define MAP_TEMPMIN     1
#define MAP_TEMPMAX     2
#define MAP_HUMIDMIN    3
#define MAP_HUMIDMAX    4
#define MAP_MOISTMIN    5
#define MAP_MOISTMAX    6
#define MAP_LIGHTMIN    7
#define MAP_LIGHTMAX    8

#endif

In Example 10-3 the definition of MAXRY is 2. This can be a larger value if the hardware to support additional relays is present, and the outputs don’t have to be relays. The include file gs_mapping.h, shown in Example 10-4, declares the functions for reading the DHT22 and the analog inputs, setting the on/off state of each relay (or all relays), controlling the status LEDs, and performing a scan through the response conditions that will control the relays in the function ScanMap().

Example 10-4. GreenShield mapping functions

// gs_mapping.h
//
// Created for "Arduino: A Technical Reference," 2016, J. M. Hughes
// Chapter 10

#ifndef GSMAP_H
#define GSMAP_H

void ReadDHT22();
int  ReadTemp();
int  ReadHumidity();
int  ReadMoisture();
int  ReadLight();

int  RyGet(int ry);
void RySet(int ry, int state);
void RyAll(int state);

void LEDControl(int LEDidx);
void ScanMap();

#endif

The ScanMap() function in gs_mapping.cpp, shown in Example 10-5, is executed on each cycle of the loop() function in the GreenShield.ino main source file. It evaluates the analog inputs against a set of configurable limits, and either enables or disables the relays based on those conditions.

Example 10-5. The GreenShield function map scanner

// NOTE: There are no checks in this code to prevent multiple relays being
// mapped to the same operational mode.

// Each RY is mapped to one of 8 possible operational modes. Determine the
// mapping for a specific relay and see if the enable condition has been
// met. This is extensible to any reasonable number of relays.
void ScanMap()
{
    for (int i = 0; i < MAXRY; i++) {
        if (rymap[i] != MAP_NONE) {
            switch (rymap[i]) {
                case MAP_TEMPMIN:
                    if (curr_temp < mintemp)
                        { RySet(i, 1); } else { RySet(i, 0); }
                    break;
                case MAP_TEMPMAX:
                    if (curr_temp > maxtemp)
                        { RySet(i, 1); } else { RySet(i, 0); }
                    break;
                case MAP_HUMIDMIN:
                    if (curr_humid < minhum)
                        { RySet(i, 1); } else { RySet(i, 0); }
                    break;
                case MAP_HUMIDMAX:
                    if (curr_humid > maxhum)
                        { RySet(i, 1); } else { RySet(i, 0); }
                    break;
                case MAP_MOISTMIN:
                    if (curr_moist < minmoist)
                        { RySet(i, 1); } else { RySet(i, 0); }
                    break;
                case MAP_MOISTMAX:
                    if (curr_moist > maxmoist)
                        { RySet(i, 1); } else { RySet(i, 0); }
                    break;
                case MAP_LIGHTMIN:
                    if (curr_light < minlite)
                        { RySet(i, 1); } else { RySet(i, 0); }
                    break;
                case MAP_LIGHTMAX:
                    if (curr_light > maxlite)
                        { RySet(i, 1); } else { RySet(i, 0); }
                    break;
                default:
                    // Do nothing
                    break;
            }
        }
    }
}

The source module gs_parse.cpp contains one primary function, ParseCmd(), and a couple of support functions (CntInt() and SendErr()). Example 10-6 shows the contents of gs_parse.h.

Example 10-6. GreenShield parse module include file

// gs_parse.h
//
// Created for "Arduino: A Technical Reference," 2016, J. M. Hughes
// Chapter 10

#ifndef GSPARSE_H
#define GSPARSE_H

void ParseCmd();
int  CvtInt(char *strval, int strt, int strlen);
void SendErr(int errtype);

#endif

The ParseCmd() function is by far one of the largest functions in the GreenShield code set. If uses a fast descending conditional tree-type parser to determine the type of an incoming command, and then extract the subfunction code and any parameters. This function will also execute any immediate commands such as enabling or disabling relays, returning relay state information, and acquiring and returning analog data to the control host or a user. Immediate command execution occurs at the endpoints of the descending tree structure.

Fabrication

It is beyond the scope of this book to provide a step-by-step walk-through for creating schematics and printed circuit boards. This is a high-level description of the steps involved to move from schematic to PCB layout to finished PCB. For the low-level details, I would refer you to the texts listed in Appendix D. A Google search for “CadSoft Eagle” will come back with numerous tutorials. I recommend the tutorials from SparkFun, Adafruit, and, of course, CadSoft.

The Eagle version of the Greenshield schematic is shown in Figure 10-13. Notice the block labeled “ARDUINO_R3_SHIELD.” This is from the SparkFun parts library for Eagle, and it’s intended specifically for creating shields. It is much more convenient than working out the placement of the pin header pads manually later on during the PCB layout phase.

Figure 10-13. GreenShield schematic (Eagle version)

The Eagle schematic editor, like all such tools, takes some time to get used to. It’s not always intuitive or obvious. Normally I use a different tool to create publication-quality line art, including schematics, but to create a PCB it’s useful to have a schematic editor and PCB layout tool that can share data. You can compare Figure 10-13 with Figure 10-9 to see the difference. The Eagle tool, and the Fritzing design tool used in the Switchinator project, can keep schematics and layouts synchronized, whereas a standalone graphics tool for line art and illustrations cannot.

When creating a schematic, make sure you have selected the correct part. For example, the symbol for a resistor is the same no matter if it’s an 0805 SMD (surface-mount) part or a 1/4 watt through-hole component. Sometimes it can be a challenge to find the right part in the schematic editor’s parts library. With Eagle you can use wildcard characters to search the library. When looking for the ULN2003AD part for the GreenShield I entered *2003* and found what I was looking for under the uln-udn category. Sometimes it is necessary to go online and search for a part that someone may have already created. SparkFun, Adafruit, and others have created large libraries of parts that are available to download for free.

Once the schematic is complete the PCB can be generated. Initially the PCB layout is just a jumble of parts and thin connection lines (“air wires,” as they are sometimes called) that form a wiring “rat’s nest.” The rat’s nest shows the point-to-point connections as defined in the netlist (the network list) created from the schematic.

The first step is to move all the parts into the PCB region, and then arrange them. The main objectives when arranging the parts are to locate connectors in the desired locations, group parts by function, and minimize the number of occurrences of crossed rat’s nest lines by rotating parts as necessary. Once this initial step is complete it’s much easier to start creating the traces that will connect the parts.

You can elect to route each trace (or track, as they are sometimes called) by hand, using the rat’s nest wires as a guide, or if you are feeling lucky you can let an autorouter take a shot at it. Eagle does have an autorouter, but I generally don’t use it. Autorouting is typically an iterative process of trying to get a good layout, ripping it up, moving and rotating parts, and then trying it again. After a while it becomes obvious with some designs that it is quicker to just do it manually.

In Eagle, you do not need to manually place a via. (A via transfers a trace from one side of the PCB to the other via a plated-through hole, hence the name.) If you need to transition from the top to the bottom of the PCB (or vice versa), simply change from one side to the other with the layer selection pull-down located at the lefthand side of the trace draw toolbar. Eagle will automatically place a via at that location for you and switch the trace routing to the selected side of the PCB.

The PCB layout is shown in Figure 10-14. The top (component) side is brownish-red, and the bottom (solder) side is blue. If you happen to have the printed version of this book you should see the top side traces as light gray, and the bottom traces as dark gray. The component outlines are in light gray.

Figure 10-14. GreenShield PCB layout

The files generated by the Eagle CAM (Computer Aided Manufacturing) tool, called “Gerber” files, are used by a PCB fabricator to create the actual PCB. I used the Gerbv tool, part of the gEDA package, to load and view the Gerber files as a last step check. A screenshot of the Gerbv screen is shown in Figure 10-15.

Figure 10-15. Gerbv Gerber file viewer

It takes about 7 to 10 days to get a finished PCB back. Figure 10-16 shows the bare PCB from the fabricator.

After the parts are soldered onto the PCB it’s always a good idea to spend a few minutes examining both sides for cold solder joints and shorts (called “bridges”) between the pads and traces. I use a standard jeweler’s loupe for this. Figure 10-17 shows what a completely assembled GreenShield looks like.

You might notice that I used stacking headers for the connections to an underlying Arduino or another shield. While it would be awkward to put another shield on the GreenShield (and I would advise against it), I wanted to have some readily accessible test and I/O points.

Figure 10-16. Finished bare GreenShield PCB

Figure 10-17. Fully populated GreenShield PCB ready to go

Final Acceptance Testing

Surface-mounted parts have their own unique set of potential problems. Before applying power to the GreenShield we should do some quick checks to make sure things are wired correctly and there are no short circuits on the PCB:

Visual inspection

Carefully examine the components on the PCB for solder bridges (solder bridging two pads or between a pad and a trace). Examine the resistors to see if any have an end that may be lifted above the pad and not connected. This can happen when using regular solder and a soldering iron (I used solder paste and a hot air SMD reflow tool). Look at the pads for the ICs (U1 and IC1) to make sure there are no solder bridges between them.

Component placement

There are nine parts that may accidentally be mounted backward. These are the two ICs, the LEDs, and the DHT22 sensor module. The op amp IC may have a dimple or dot to indicate pin 1, but some packages have a beveled edge. In addition to different lead lengths, LEDs will usually have a small flattened area next to the cathode (–) connection.

Short circuits

Using a DMM, preferably with a continuity test function (the beeper mode), check each pair of pins on the LM358 op amp (IC1) for shorts. None of the pins should short to another pin. Now check that the VCC on pin 8 of IC1 is tied to the 5V on the pin header. Also check that pin 4 is tied to one of the ground pins on the pin header.

Repeat this process for the ULN2003A driver (U1). None of the input or output pins should be shorted, pin 8 should be tied to ground, and pin 9 should be connected to the 5V supply.

Power safety

Before connecting the GreenShield to an Arduino board, use a DMM to measure the resistance between the +5V and ground pins on the pin header. You should see a value of no less than about 30K ohms, probably higher. If you get a reading of zero then there is a short somewhere, and it will need to be found and cleared before attempting to power up the GreenShield.

If the GreenShield appears to be acceptable electrically, then we can mount it on an Arduino and apply power. None of the LEDs on the GreenShield should be active initially (unless there is some software already running on the AVR on the Arduino that is controlling the digital I/O pins). Functional testing involves four basic steps:

Initial functional testing

The first part of functional testing is rerunning the same tests as were done with the prototype to test the analog inputs and the DHT22.

Upload the prototype version of the software to the Arduino and open the IDE’s serial monitor window. If everything is working correctly you should see a repeating display with the temperature, humidity, and analog inputs.

Analog input testing

Connect a 470-ohm resistor across the LDR inputs. While observing the continuous output, adjust R12 until the value goes to zero. This demonstrates that this part of the circuit is working correctly. Now repeat this with R8 for the moisture sensor.

DHT22 testing

The output readings from the DHT22 should be what you would expect for the local ambient temperature and humidity. You can use a hot air source (a hair dryer, for instance) to apply warm (not hot!) air to the DHT22 and observe its response.

Software functional testing

Now load the full version of the GreenShield software. You can use the serial monitor window of the Arduino IDE for these tests. This is not an extensive suite of tests, as we’ve already been through some of this earlier with the prototype.

With the full GreenShield software loaded, you should see the word “OK” when it first starts. The GreenShield does not provide a prompt. Enter the command RY:0:? and the response should be RY:0:0. Now enter the command RY:0:1. The relay should click and the associated LED should illuminate. Using the RY:0:? command now will return RY:0:1.

We should exercise the rest of the commands as well. We can test the analog limits by shorting or opening the analog inputs. The DHT22 is self-contained, so we don’t need to do a lot with that, but you can set the limits very close and use a hot air source and some steam from a pot of boiling water to verify that the temperature and humidity limits work as expected.

Operation

The GreenShield is physically simple, but it can be functionally complex in terms of how it is integrated into its intended environment. The two main variable inputs, light level and soil moisture, must be calibrated for a specific set of conditions. The range of the light-dependent resistor and the soil moisture probe determine how the midpoints are set using the trimmer potentiometers. Not all LDRs are the same, and there will be a difference between a moisture probe that is just a pair of probes and one with a transistor on it.

There are two basic approaches for adjusting the GreenShield: (1) calibrate the GreenShield for known ranges using references of some sort, or (2) adjust the GreenShield to a specific environment using subjective evaluation (i.e., does the soil feel wet enough?).

The calibrated approach will allow you specify ranges based on hard data, and if you know the ideal soil moisture content for, say, tomatoes, then you can use those values once you have done the calibration and worked out how the ADC readings correspond to moisture content. “Prototype testing” described the basic procedures involved in calibrating the GreenShield for soil moisture and light levels, but you could also use expensive lab equipment as reference sources.

The subjective approach is much easier, and since the primary intent is to avoid killing off your plants it’s probably just as effective after a bit of tweaking. You can adjust the trimmer potentiometers to suit the high and low ends of a subjective evaluation of what is acceptable.

I would suggest some experimentation to see which approach works best for your intended application. I would also suggest taking the time to log data from the GreenShield and build up some profiles that you can study to achieve the best responses for your situation.

Next Steps

The GreenShield is rather minimal, to be sure, but it has a lot of potential. You can use it with a Bluetooth shield or even an Ethernet shield, and remotely monitor the soil conditions of your favorite potted plant, some tomatoes or orchids in a greenhouse, a small outdoor vegetable plot, or a garden in a Mars colony. Connect a standard 24VAC sprinkler system valve to one of the relays and you can automate the watering. You could use the other relay to enable a ventilation fan in a greenhouse to cool it down, or connect it to a heater to keep the interior nice and warm during the winter. And, of course, you could always add another relay or two with an external relay module like those described in Chapter 9.

A microSD shield could also be used if you wanted to strap the GreenShield to a tree in the forest and do some long-term data logging (a solar panel to keep it running would be a good idea, as well). Add a WiFi or GSM shield, and you could scatter GreenShields around a good-sized farm to keep an eye on soil conditions.

Programming a Custom Design

If you want to use the Arduino bootloader with a brand-new AVR microcontroller, then you will need to install the bootloader in the chip’s built-in flash memory. Once this is done, you can then treat your custom board like any other Arduino. The tools and procedures involved in uploading executable code to an AVR MCU are covered in “Uploading AVR Executable Code” in Chapter 6. As an alternative to installing the bootloader firmware yourself, many sources sell AVR devices with the Arduino bootloader already installed. Check out Adafruit and SparkFun for ATmega328 ICs with the Arduino bootloader firmware preinstalled. Entering “ATmega328 with Arduino bootloader” into the search box on Amazon.com or eBay returns numerous listings.

Once the bootloader is in place, you can use a USB-to-serial adapter or even a standard serial interface with a suitable RS-232 module like the one shown in Figure 10-26 or a USB-to-serial breakout like the SparkFun device shown in Figure 6-8. For some projects, such as the Switchinator in the next section, the serial interface is not an option for programming the MCU if it is already in use, or if the bootloader is not used. This means you will need to use an ISP (ICSP) programmer such as the Atmel-ICE or the USBtinyISP, both of which are discussed in Chapter 6.

Definition and Planning

The Switchinator is a standalone PCB that can use a plain ATmega328 or ATmega328p MCU without the Arduino bootloader. It can also use an MCU with the bootloader firmware installed with a serial programmer or a USB-to-serial converter. I have elected to use the Arduino IDE for compiling, and an Adafruit USBtinyISP for the programming. Refer to Chapter 6 for more on programming the MCU.

Core hardware:

• ATmega328

• 16 MHz crystal clock source

• ICSP programming interface

• Integrated 5V DC power supply (9 to 12V DC input)

Inputs and outputs:

• 4 analog inputs

• 14 discrete digital outputs

Control interface:

• RS-232 host interface

• Command-response protocol, control host driven

• Analog readings available on demand

• Output override by control host

The Switchinator provides 14 discrete digital outputs and 4 analog inputs, and the SPI interface is available through an ICSP pin array. The discrete digital outputs and the analog inputs are terminated at the edge of the PCB using screw terminal blocks. An RS-232 interface is used for communication between the board and a control host computer via the D0 and D1 pins on the MCU.

The PCB is a 100 percent through-hole design. This simplifies the assembly at the expense of a larger PCB and a potentially more challenging PCB layout. The PCB size will not exceed a rectangular size of 100 mm by 140 mm. Mounting holes are located in each corner of the PCB.

The discrete digital outputs of the Switchinator can be used for driving relays, such as the type used on the GreenShield, or controlling up to three unipolar stepper motors using a basic circuit like the one shown in Figure 10-18.

Figure 10-18. ULN2003A connected as stepper driver

The digital outputs of the Switchinator can also drive high-current LEDs, solenoids, or DC motors, as shown in Figure 10-19.

A basic prototype based on a solderless breadboard will be used to develop the initial version of the software. The final version will be completed on the finished hardware.

For the final hardware design I will use Fritzing for schematic capture and PCB layout.

Design

The Switchinator is a single PCB, 124 × 96 mm in size with four corner mounting holes. The final board size is larger than would otherwise be possible with a surface-mount design (it is also larger than the size limits set by the free version of the Eagle tool used for the GreenShield).

There is no enclosure or power supply, which greatly simplifies the design. The Switchinator is entirely self-contained, requiring only an external DC power source for operation.

Functionality

The Switchinator is a digital output device with some analog input capability. Its primary purpose is to switch DC loads, both inductive and noninductive. An ATmega328 AVR MCU is used to decode command inputs and return status data to the control host.

Figure 10-19. ULN2003A DC motor driver

An ATmega328 is used primarily as a command decoder to interface the I/O on the PCB to a host system. Although it has been programmed to act as an I/O device, it could also be programmed to perform autonomous functions based on the analog inputs. By using a linear temperature sensor, such as the LM35, the Switchinator could easily be reprogrammed to serve as a controller for an environmental test chamber or an epoxy curing chamber.

Circuit-wise the Switchinator is comprised of three main sections: MCU, digital I/O, and power supply. Figure 10-20 shows a block diagram of the Switchinator.

The discrete digital outputs are driven by ULN2003A ICs. Four analog inputs are also provided, and the analog reference and AVCC voltages may be supplied either on-board from the internal power supply or externally. Jumpers are used to select the analog voltage sources.

A simple, human-compatible command-response protocol is used to monitor and control the Switchinator.

Hardware

The Switchinator will have 14 digital outputs, each connected to the Darlington outputs of a pair of ULN2003A driver ICs. The ULN2003A drivers have seven channels per IC, and each ULN2003A channel can handle up to 300 mA or more in some cases.

A Microchip MCP23017 I2C digital I/O expander will be used to drive the ULN2003A parts, mainly to avoid using up all of the available digital I/O pins on the AVR MCU. Two of the digital I/O pins on the AVR are used for the serial interface, and two of the analog pins are used for the I2C interface to the MCP23017 IC. The unconnected digital I/O pins are not used, but are available for future expansion.

Figure 10-20. Switchinator block diagram

An RS-232 interface is implemented using a MAX232 TTL-to-RS232 transceiver IC. The serial interface will be used to communicate with a host system acting as a master controller. The master controller may be a PC, an Arduino, or some other type of programmable controller with an RS-232 interface. A DB-9 connector is used for the serial interface. This is not a full implementation of RS-232, just the RxD and TxD signals. The Switchinator does not have a USB connector.

The digital outputs and the analog inputs are terminated using 3.5 mm (0.138 inch, 138 mil) pitch screw-type terminal blocks. In addition, two jumpers allow for externally supplied analog V+ and analog reference voltage inputs via a terminal block. A standard PCB-mount DC-barrel type connector is used for DC power. The power input can range from 6 to 12V DC (9V is optimal). A 7805 in a TO-220 package is used for voltage regulation to 5V on the PCB. Figure 10-21 shows the schematic created by Fritzing.

Note

The schematic notation used in Figure 10-21 illustrates what happens when the parts in a tool’s library don’t all follow the same conventions for size and spacing. This is a common issue with open source tools because not every contributed part may have followed the same rules. That doesn’t mean it won’t work; it just looks odd.

Figure 10-21. Switchinator schematic

I used a 16 MHz crystal in the Switchinator for the MCU clock, mainly because I have a bunch of them. For the Switchinator the internal RC oscillator in the AVR would probably do just fine. While the crystal will allow the MCU to run at a specific rate, it also adds some complications with the internal fuse bits the AVR MCU employs for internal configuration. Reading and setting these is discussed in “Setting the AVR MCU Fuse Bits for a 16 MHz Crystal”.

The four analog inputs are brought out to a pair of four-position terminal blocks. The remaining positions are used for V+, ground, and optional analog reference and AVCC inputs. Jumpers JP10 and JP11 are used to select the external voltage sources by removing them from the PCB.

Two of the MCU’s digital pins (D0 and D1) are used for the RS-232 serial interface. Three of the digital pins (D11, D12, and D13) are used for the ICSP programming interface. The remaining digital pins are unassigned. Four of the analog inputs (A0, A1, A2, and A3) are used as general-purpose analog inputs. Pins A4 and A5 are used for the I2C interface between the MCU and the MCP23017 IC. Table 10-10 lists the pin assignments for the Switchinator.

Table 10-10. Switchinator MCU pin usage

Pin	Function	Pin	Function	Pin	Function
D0	RxD for RS-232	D7	Not used	A0	General-purpose analog input
D1	TxD for RS-232	D8	Not used	A1	General-purpose analog input
D2	Not used	D9	Not used	A2	General-purpose analog input
D3	Not used	D10	Not used	A3	General-purpose analog input
D4	Not used	D11	ICSP MOSI	A4	I2C SCL
D5	Not used	D12	ICSP MISO	A5	I2C SDA

Based on the schematic presented in Figure 10-21 we can generate a detailed parts list as shown in Table 10-11.

Table 10-11. Switchinator parts list

Quantity	Description	Quantity	Description
2	Capacitor, .1 uF	4	Red LED
2	Capacitor, 10 uf	1	Green LED
2	Capacitor, 27 pF	5	1K ohm resistor, 5%, 1/4 W
1	Capacitor, .001 uF	1	10K ohm resistor, 5%, 1/4 W
4	Capacitor, 1 uF	1	330 ohm resistor, 5%, 1/4 W
1	1N4001 diode	1	Switch, tactile pushbutton
1	MCP23017 I2C I/O expander	1	ATmega328 MCU, 28-pin DIP
2	ULN2003A output driver	1	MAX232 RS232 transceiver, 16-pin DIP
1	Power jack, 5.5 mm barrel	1	7805 voltage regulator, TO-220
1	AVR ISP connector package, 2 × 3 pins	1	DB9 connector, PCB mount, male
6	Terminal block, 3.5 mm pitch	1	16 MHz crystal
2	2-pin jumper header	1	Custom PCB

Software

As with the GreenShield project, the most complex part of the Switchinator is actually the software. Figure 10-23 shows a block diagram of the software.

Figure 10-23. Switchinator software block diagram

When the Switchinator is waiting for command input it will send a single “>” character followed by a space. Responses are preceded with a “<” character and a space, followed by the response data. The use of the “>” and “<” characters is mainly for the convenience of software running on a control host system. All input and output lines are terminated with a newline ( or 0x0A) character.

On every pass through the main loop the analog inputs are read and the values saved. These are returned to the control host when an analog reading is requested, which means they will be updated at the rate of the main loop.

Next, the software checks for incoming serial data. If there is data in the input buffer the input read function is called to read characters until a newline (a linefeed character), ASCII value 10 (0x0A or ), is encountered. The parser then extracts the command from the string, parses out the parameters, and executes the commanded operation.

Control of the Switchinator is done using a simple command-response protocol. For every command or query sent by the control host the Switchinator will respond with a single response. The Switchinator will never initiate a communications transaction with the control host. The complete command-response protocol is shown in Table 10-12.

Table 10-12. Switchinator command-response protocol

Command	Response	Description	In/out format
A:n	A:n:val	Get analog input n in raw DN	Hex
R:nM	R:n:val	Read status of output n	Hex (0 or 1)
W:n:val	OK	Write 0 or 1 to output n	Hex
S:val	OK	Set all outputs to hex value	4-digit hex
G:?	G:val	Get hex value for all outputs	4-digit hex

The command set is simple, and only the W (write) command uses two parameters instead of just one. All parameter and response values are in hexadecimal notation. This allows digital port numbers to be single hex digits, while the analog input values (the A command) and the mass set and retrieve commands (S, or set all ports, and G, get all ports, respectively) use four-digit hex values. The digits 0 and 1 are nominally in hex, but they are the same in decimal notation.

Error detection is handled by examining the string returned from the Switchinator. If the A, R, or G commands return the string sent, then an error occurred. If the S or W commands encounter an error they will return the original string; if they succeed, then the string “OK” will be returned.

The A command accepts a single digit from 0 to 3, and the analog data is the actual value returned by the ADC in the AVR MCU. It is returned as a hexadecimal value of 1 to 3 digits, with 0x3FF as the maximum possible value.

The R and W commands have the specific digital output port number in the form of a single hex digit, ranging from 0 to 0xF (15). Output channels 7 and 0xF are used for on-board LEDs; they are not brought out through the ULN2003A drivers.

Notice in Table 10-12 that to control or get the status of more than one output the S and G commands are used with a hexadecimal value. With this scheme we can enable (set to an on state) noncontiguous outputs, or read back the state of all the outputs.

If, for example, we wanted to set outputs 5, 6, 12, and 13 to an on state, then we would send the value 3060h, which translates to binary as follows:

Bit   | 15   11    7    3  0
---------+----+----+----+---
Binary|  0011 0000 0110 0000
Hex   |     3    0    6    0

Remember that the channel numbering is zero-based.

Tip

Sending a hexadecimal value will cause outputs to change state to match the command value. That means that if an output is on, and the command value has a zero in that position, it will be set to off.

Use a read-modify-write operation (get bits, change data, set bits) to set or clear a specific output bit without disturbing other bits. This is how the W command works.

The last step in the loop transfers the digital output state bits to the hardware. If no changes have been made since the last update the outputs will not do anything; otherwise, bits that have been changed will appear as changes in the on or off state of the ULN2003A outputs.

Prototype

The prototype mainly focuses on the RS-232 interface and the command-response control protocol, so the prototype hardware consists mainly of an ATmega328 mounted on a solderless breadboard. An RS-232 adapter module is used as a stand-in for the MAX232 in the final board. Figure 10-25 shows the prototype fixture.

The RS-232 module is a self-contained unit with a MAX3232 IC. This part is functionally equivalent to the MAX232 used in the Switchinator. The MAX3232 is nominally a 3.3V part, although it is 5V tolerant. It is also slightly more expensive than the MAX232. Figure 10-26 shows a close-up of the RS-232 interface module.

These modules are available from multiple vendors for between $3 and $6. A Google search for “arduino rs232 module” or “arduino rs232 converter” will turn up numerous results.

Figure 10-25. Switchinator prototype fixture

Figure 10-26. RS-232 interface module

Most desktop PCs still have a single RS-232 port and a DB-9 connector on the rear panel, but if you have a late-model notebook PC you may not have a serial port available. To get around this, you can use a USB-to-RS232 adapter. These range in price from around $4 to over $30, with some specialty types costing even more. For more details about RS-232 and the connectors used with it, I would recommend my books Real World Instrumentation with Python and Practical Electronics: Components and Techniques (see Appendix D). Both contain sections dealing specifically with RS-232, DB-9 connectors, gender changers, and how to wire a DB-9 to allow RxD/TxD communications without the handshaking signals.

SUBSYSTEM=="usb", ATTR{product}=="USBtiny", ATTR{idProduct}=="0c9f", 
ATTRS{idVendor}=="1781", MODE="0660", GROUP="dialout"

sudo vi tinyusb.rules

sudo restart udev

Software

Although it is possible, and often advisable, to create a simplified version of the software for use with the prototype, in the case of the Switchinator it begins life as a multifile code set. The main file is, of course, Switchinator.ino. The other files in the set contain the global definitions, the global variables, the command parser, the response generator, and the I/O control code. The I/O module, sw_io.cpp, is not necessary in the prototype version of the software.

Software description

As with any Arduino program, the action begins in the main sketch file. The contents of the Switchinator.ino main file are listed in Example 10-9.

Example 10-9. Switchinator.ino

//-------------------------------------------------------------------
// Switchinator.ino
//
// Created for "Arduino: A Technical Reference," 2016, J. M. Hughes
// Chapter 10
//-------------------------------------------------------------------

#include <stdint.h>
#include <Wire.h>

// the MCP23017 library
#include <IOexp.h>

// Include all source modules
#include "sw_parse.h"
#include "sw_gv.h"
#include "sw_defs.h"
#include "sw_io.h"

// define the clock rate
#define F_CPU 16000000UL

bool waitinput = false;
bool usedelay  = false;

void setup()
{
    Serial.begin(9600);

    // Startup banner and start flag string
    Serial.println();
    Serial.println("SWITCHINATOR V1.0");
    Serial.println("READY");
    Serial.println("####");     // Start flag
}


void loop()
{
    // Read analog inputs and update GV array
    ScanAnalog();

    // Emit only one input prompt
    if (!waitinput) {
        waitinput = true;
        Serial.print(INPPCH);
    }

    // Check for incoming command
    if (GetCommand()) {
        waitinput = false;      // Reset input prompt output flag
    }
    else {
        ClearBuff(0);
        ResetBuffLen();
        // if no input then enable loop delay
        usedelay = true;
    }

    // Parse command (if received)
    if (DecodeCommand()) {
        // Return response to control host (or user)
        Serial.println();
        Serial.print(OUTPCH);
        Serial.println(gv_cmdinstr);
    }

    // Update the digital outputs using state bits
    SetDigBits();

    // delay briefly if no input detected
    if (usedelay) {
        usedelay = false;
        delay(50);
    }
}

The setup() function contains the usual initialization statements along with the initial startup message. The loop() function continuously updates the output bits and checks for incoming commands from a control host system via the GetCommand() function in the SW_parse.cpp module.

Referring back to Figure 10-23 the block “Get command string” refers to the GetCommand() function in the sw_parse.cpp module, the “Parse” and “Generate response” function blocks are contained in the DecodeCommand() function, and “Update digital output bits” is the SetDigBits() function in the sw_io.cpp module. Figure 10-27 shows how the output bit state buffer, gv_statebits, is used to hold an internal representation of the output bits. All bit modification functions operate on gv_statebits, not on the actual digital outputs.

Figure 10-27. Switchinator’s virtual bit buffer in operation

Note that writing 0x00 to either port A or port B will also enable the associated port LED. Writing an 0xFF to either port will disable the LED. The output bits are updated about once every 50 ms if no serial input is present to be parsed and decoded.

Fabrication

For the hardware design I used the Fritzing design tool. This is an integrated virtual breadboard, schematic capture, and PCB layout tool that is easy to install and relatively easy to use. Fritzing has a large and vibrant user base and lots of preloaded parts in its library, and best of all, it’s free. Some Linux distributions may have an older version of Fritzing in their repository, but you can download the latest version from http://fritzing.org/home. I used version 0.8.5 running on a Kubuntu 14.04 LTS Linux system. There are also versions of Fritzing available for Windows and Mac OS X.

Compared to other tools I’ve worked with over the years, I was pleasantly surprised at how easy Fritzing’s user interface was to use. To be honest, I wasn’t all that impressed by the autorouter, but then I’ve seen high-end autorouters struggle with things I thought would be easy. And autorouting software is very challenging to program, so I wasn’t expecting a miracle. I ended up doing the layout manually (and it shows, I’m sure). The DRC (design rules check) worked well, and while the schematic editor had some unique quirks, it too was completely usable. My main complaint with Fritzing is the parts library. It seems that not everyone is on the same page when it comes to dimensions for schematic symbols, so parts from one contributed library might be really small, while the stock parts supplied with Fritzing are actually nice, large symbols. You will see this when you look at the schematic in Figure 10-21. The upshot is that unless all the parts in a tool’s library—both the symbols and the layout footprints—adhere to the same dimensioning constraints, it is difficult to get perfectly orthogonal lines or traces without doing some serious fiddling with the grid sizing and snap functions.

Once the schematic (shown in Figure 10-21) is complete, the PCB layout work can begin. The first time the PCB layout appears it will have no traces, just the rat’s nest lines to indicate which pins are connected on the parts. In Figure 10-28 I’ve already placed the components where I think they should go, and Fritzing is showing some of the rat’s nest lines. Clicking and holding on a pin on any part will highlight all the other places it should be connected in bright yellow.

Figure 10-28. PCB after parts placement, but before routing

The components are grouped by function: the power supply is in the lower-left part of the PCB; the MCP23017 and the two ULN2003A parts are in the upper-left region; the MCU, crystal, ICSP connector, and analog inputs are located at the upper right; and the serial interface is located at the bottom right of the layout.

You might notice that I reversed the analog input terminal block symbols to simplify the wiring. They will still be mounted correctly, and since a prototype PCB like this doesn’t have a top layer silkscreen it won’t make any difference.

Some of the trace routing is rather tortuous, due mainly to the use of through-hole parts. Vias are used to shift the traces between the top and bottom sides of the PCB in order to route without collisions. Figure 10-29 shows the final version of the PCB that went out for fabrication.

Figure 10-29. Final version of the Switchinator PCB layout

Before sending out the Gerber files, I checked the design with the Gerbv tool (which was introduced earlier with the GreenShield). A screenshot is shown in Figure 10-30.

Fortunately, the fabrication house (Advanced Circuits) discovered two pads that were almost, but not quite, connected. It would have been easy to fix on the workbench, but it would have been a challenge to find the problems. Good thing someone was paying attention and checked the layouts.

The Switchinator is a through-hole PCB, so assembly is straightforward. Figure 10-31 shows the bare PCB before any parts are installed.

The first parts to solder into place are the DC jack and the 7805 regulator, along with the associated power supply components, consisting of D1, C2, C3, C4, and C5. Note that there is no C1 (it vanished in an earlier revision). To test the power supply we also need to install R5 and LED5. Once these parts are installed we can connect a 9 to 12V DC wall supply via the DC power jack and verify that the regulator is producing 5 volts DC at the anode of LED5 (which should be glowing).

Figure 10-30. Gerbv PCB layout display

Next we will install the RS-232 connector, labeled X1 in the schematic; U2 (the MAX232 IC); and C9, C10, C11, and C12. Using the prototype breadboard we can attach the Rx and Tx signals from pins 2 and 3 of the MCU to the U1 pins 2 and 3 on the PCB. Then we run the software already on the AVR MCU and verify that our integrated RS-232 is working correctly. Remember to tie the ground and 5V DC power from the PCB to the breadboard (and disconnect the breadboard’s power supply, of course).

With the power supply and the RS-232 interface installed and running, we can now install U1 (the MCU), IC1, IC2, and IC3. LED1, LED2, R1, and R2 can also be soldered in place, along with the six terminal blocks. Next, the crystal, C6, C7, C8, R3, R4, R6, LED3, and LED4 are installed. The reset switch, S1, and the ICSP connector are the last things to mount on the PCB.

Figure 10-31. The bare Switchinator PCB

Figure 10-32 shows the finished PCB with everything installed and ready to go. The maximum current that the ULN2003A drivers can supply is determined by the power supply and by the ratings for the ICs themselves. The datasheet states that the ULN2003A is capable of supplying around 300 mA per channel, or about 2.1A per IC. By comparison, the ATmega328 and the MCP23017 draw very little current, so the major concern will always be the ULN2003A devices. A power source capable of supplying at least 5A should be more than sufficient if you want to use the Switchinator for something like a small CNC tool or an LED display controller.

Acceptance Testing

Final testing of the finished Switchinator is largely a repeat of the testing done with the prototype. The big difference now is that there are two ULN2003A drivers and an integrated RS-232 interface based on a MAX232 IC. The power supply also needs to be tested, as well as the analog inputs.

Figure 10-32. The finished Switchinator

Next Steps

Not all of the discrete digital I/O pins on the MCU have been used; 10 pins (including 6 capable of PWM output) are available. I didn’t bring these out due to space constraints on the PCB, but it should be possible to modify the PCB for a couple of six-position pin socket headers. It will, however, require some clever use of vias to get the traces routed through the resulting traffic jam around the MCU.

The SPI interface is available on pins D11, D12, and D13, and these are wired to the ICSP connector. If you select an unused pin for the SS line you can connect an SPI module to the Switchinator. The analog pins can be used as digital I/O pins by referencing them as pins D14 through D19.

You may have also noticed that there is no fuse, and no input protection for the analog inputs. For an example of analog input protection, see Chapter 11 and the input circuit used for the signal generator.