The Stuff You Need

Although this project has more parts than some of the previous ones, they’re smaller, simpler, and among the most common parts out there.

Electronic Dice

Computers in general are very bad at creating randominity when they’re working correctly. The entire point of logic circuitry is repeatability: a given set of inputs result in a given output. Randominity flies in the face of this. There are many random generation algorithms. It’s a heavily researched field, since encrypted data should be indistinguishable from random values. Indeed, a friend of mine who wrote software for slot machines once told me it takes a great deal of study and quite a lot of computing power to generate sufficiently random values for gambling.

So how did the $20 (about $60 or $80 in modern dollars) electronic dice device I saw in that magazine back in the bronze age of computers accomplish it? Here’s how the circuit worked.

We talked about counters in Chapter 6. If you tied the 74LS92 to the 20MHz oscillator on the Cestino, you undoubtedly observed that the 74LS92 can count very, very fast. You’ll recall from Chapter 7, the logic probe, that we humans can’t even perceive LEDs changing from bright to dark or back in much less than 20ms. The dice device used both these factors to its advantage.

It was a simple beast. It contained a pair of TTL decade counters, one for ones and one for tens, each of which had outputs for zero through nine. Because a die can’t roll zero, the ones counter was wired to show one higher than its actual count: its zero output is wired to LED 1, and so on.

When the ones counter’s output nine switched on, instead of lighting an LED, it incremented the tens counter. The tens counter, by contrast, was wired to count from zero to nine. Left to run freely, the counters would count from zero to ninety-nine, lighting up one or two LEDs to indicate values from 1 to 00. (00 had a separate LED, and represented a 10s digit of 0.)

A six-position switch and two AND gates were used to select the die. For four-, six-, and eight-sided dice, the switch simply tied output four, six, and eight (which represented five, seven, and nine, as the ones counter is skewed by one) to the reset circuit for both counters. For 12-and 20-sided dice, it connected to the output of an AND gate. The 12-sided die’s AND gate tied output 2 (representing 3) of the ones counter and output one (representing 10) of the tens counter together to represent 13. When the counters reached 13, the AND gate would reset them long before the LED could light. The 20-sided die worked the same way. Output zero of the ones digit (representing 1) and output 2 of the tens digit (representing 20) were wired to the other AND gate, and when the selector switch was set to its output, and those two outputs went high, the AND gate would reset the counters before the LED could light.

For percentiles, the reset circuit was grounded and both counters were permitted to run freely.

To actually roll the dice, you held a button down. It connected an oscillator to the counters, and this is where the randominity was generated. We don’t think of our actions as random, but measured on the scale of a few hundred kHz, when our thumb actually comes off a button, and when the button’s contacts stop bouncing (more on that later) is actually quite solidly random. So once you selected the die you wanted, you held the button down. All the LEDs up to your roll appeared to light simultaneously, even though no more than two were ever actually on, and when you let up, they stopped at your roll apparently instantly.

It’s an elegant, all TTL design . It uses two decade counters, a dual AND gate for die selection, and a quad NAND gate, used with a resistor and a capacitor as an oscillator. The rest are switches, LEDs, resistors, and a battery. Because they used 4000 series CMOS TTL, the device could tolerate a wide range of battery voltages as the battery ran down. Because it was simple, it would have been fairly cheap to manufacture.

Apparently they didn’t take the gaming world by storm. The patent, US4431189, was filed in 1981, and by 1987 it had expired for failure to pay maintenance fees. In 30-plus years I’ve been gaming, I’ve seen exactly one in use.

We’re going to have the Cestino generate random numbers the same way, by measuring the button-down time some hundreds of thousands to millions of times a second. We’re also going to exploit the low speed of human eyes and LEDs the same way as we drive our seven segment displays.

Driving 7 Segment Displays

So what exactly is a seven-segment display with a right-hand decimal and a common anode? It’s seven LEDs shaped like segments of a number from zero to 0xf plus one that is on the right and very small, where it serves as a decimal point. Common anode means all the anodes (positive terminals) of the LEDs are tied together. You put voltage on the anode, ground the cathode pins for the segments you want on (as always, with dropping resistors, but we’ll get to that) and you have a display. Put two of them together and tie the cathodes for each pair of segments in the same position, and you have a two-digit display, which is what the LTD4608JG is. You chose the digit you want by choosing an anode to apply power to, and you chose what segments to light by choosing which cathodes to ground. Note that the digits are numbered left to right, so the leftmost digit is digit one, and the rightmost digit is digit two.

The cannonical “correct” way to wire the seven-segment display is with one dropping resistor per segment. But this eats up a lot of breadboard real estate and takes a lot of extra wiring. Plus, two of our 330Ω resistors are permanently tied up in the logic probe circuit. If you’ve looked closely at the photo of the Cestino Dice Device (Figure 10-1), you’ll see I took another tack.

Recall that Kirchhoff’s first law is that the sum of the currents flowing into a node of a circuit equal to the sum of the currents flowing out. This means that whichever side of the LED we put the dropping resistor on, it will impose the same current limit and cause the same voltage drop. We can, as easily, put our dropping resistors on the anodes. Because all of our segments in each display digit share a common anode, this cuts our resistors to two. If we connected one of these resistors from + to - it would drop 5 volts and dissipate a bit over 15mA, and a wattage of about 75mW. Our resistors are rated at 250mW (0.25 Watt), so we’re fine there. Does adding the LEDs in parallel decrease their resistance? Yes, but it’s unimportant. The forward drop of each LED remains the same, about 1.5 volts, which means our dropping resistor limits the current to about 10mA. (The datasheet doesn’t specify the forward drop. It’s a lousy datasheet.)

It’s tempting to calculate each segment’s load and add them together, and then worry about the wattage of the resistor, but recall Kirhhoff’s first law says it isn’t so. The current is limited by the resistor and all the circuits tied to it share that current. This means that the LEDs get slightly dimmer, the more of them that are switched on, as they divide the 10mA available among all eight (worst case) LEDs.

This isn’t standard industry practice, and there’s a reason. Each LED in a seven-segment display has slightly different characteristics. Some may draw more current than others, or they may have slightly different voltage drops, or different internal resistance. As you add these variations together, you can get a display that is hard to read, or has some segments brighter than others. My LED display worked fine, but if you’re having these problems, add a 150Ω resistor between each cathode and its respective PORT A pin.

So we know we can switch the current we need to light the seven segment LEDs, but what if we want more digits? What if we wanted to make a calculator? Can we really only drive four seven-segment displays with one ATmega1284P? Do we really have to use two full ports just for these two digits? Could we really only drive four seven-segment displays with an ATmega1284P, and that only if we didn’t want it to do anything else?

The answer is no. We can drive an arbitrary number of digits with one port, plus one pin per digit. The technique is called time division multiplexing.

Time Division Multiplexing

From our experiments with the logic probe , we know that between the speed of an LED and the speed of human vision, we can’t perceive off pulses on an LED of less than about 20ms, or a frequency of about 50Hz. We’ll use 60Hz from here on. I am an American, and our wall power is 60Hz. If the LEDs cycle much slower than the overhead lights, it can make them appear to flicker at the difference between the two frequencies.

For those outside the Americas, the Caribbean, and parts (but not all) of Korea and Japan, your power is probably 50Hz, which fits the metric way of thinking better. You might need to slow the display timing in the sketch to suit your lights if it appears to flicker. You could also increase the display speed until the flicker goes away.

As long as we power each LED at least every 16.6ms, we won’t see the difference. We know from those same experiments that 60Hz is glacial compared to the speed of transistor logic. That’s how the digits in this project are driven. If the port can react at least once every 8.3 ms per digit (hint: it can) we can drive two digits with different values and have them appear to be lit at the same time. Three digits would need updating every 5.53ms, and so on.

As with all things, there’s a cost. We have to control, with great precision, which display is active at any given time. Their common anodes give us an easy mechanism to do that. To talk to digit 1, on the left, we connect the common anode of that digit to the + bus (by way of the dropping resistor). To talk to digit 2, on the right, we disconnect digit 1 from the + bus and connect digit 2 to it. We can switch whichever cathode lines we want. Without power to its anode, digit 1 won’t do anything. Again, as long as we get back to powering digit 1 in less than 16.6ms, we won’t see the difference.

We could reduce the duty cycle further, powering each digit for less than half the time, either by adding more digits to the multiplexing system, or by making the duty cycle asymmetric—off more than it’s on—and if we needed to conserve power, the extra complexity might be worth it. For this project, we’ll stick with a 50 percent duty cycle, and two digits. With the circuit we’re going to build, we could run up to eight, on two ports. With a better design (an oscillator, a decade counter, and some buffers, perhaps) we could do many more with only one port. If we had an ATtiny, with only three or four GPIO pins available, we could multiplex the individual segments as well .

Interrupts

The big catch of multiplexing (muxing, for short) is that it’s time sensitive. If our loop function gets busy doing something else, and the display switching doesn’t happen on time, it will be visible. Worse, if the display switching and the port switching get out of sync, the digits could be transposed or superimposed over each other. We need a way to let the ATmega do the job we want of it, but make sure that every so often, it stops and updates the display. Fortunately, like nearly all microprocessors and microcontrollers ever made, the ATmega1284P has circuitry that, when activated, stops whatever it’s doing, and jumps to another part of the code. When that part is done, it jumps back and picks up where it left off. It’s called an interrupt.

The piece of code (a function, since we’re using C/C++) called when the interrupt is activated is called the Interrupt Service Routine, or ISR.

If we were looking at assembly language, the address in program memory that the interrupt causes a jump to is called the interrupt vector. These are handled for us by the Arduino core.

The ATmega1284P has two types of interrupts: internal and external We’ll deal with the external type first.

If you look at the pinout diagram in the ATmega1284P datasheet (I left them out of the one in Chapter 2) you’ll see that all the pins of all the ports have a PCINT number. These are not the interrupts we’re looking for. These are the PCINT system.

The PCINT interrupt system is designed to monitor whole ports at a time for any change to the pins, whether or not the pins are set up as outputs. Each port’s PCINT system can call one fixed interrupt service routine (ISR)—the code that the interrupt sends the processor to. This is handy for things like the ATA Explorer (although we didn’t use it) so that when the drive returns a byte of data, our code can go deal with it, regardless of what else it was doing at the time.

Although there are several libraries for Arduino that allow PCINT to be used in sketches, we won’t be using the PCINT system in this project. We need finer control over what events cause an interrupt.

Instead, we will use the external interrupt system, called INTs. There are three INT pins: INT0, INT1, and INT2 (ATmega328 based Arduinos have only the first two). These are found on pins INT0/PD2 (Pin 16), INT1/PD3 (Pin 17) and INT2/PB2 (Pin 3) of the ATmega1284P. These lines are, in other microprocessors and microcontrollers, called IRQ lines—Interrupt ReQuest lines. File that away. You’ll see IRQs again in chapter 11.

The ATmega1284P’s three interrupt lines can be configured to activate when the pin is low—below 0.3 volts, when it is high—above 0.6 volts, when it rises from below 0.3 volts to above 0.6 volts, when it falls from above 0.6 volts to below 0.3 volts, or on any change at all, like the PCINT system. Each interrupt pin has its own interrupt vector, so it can call a specific interrupt service routine. The INT system allows us to know which pin /exactly/ changed and what exact change occurred before we even get to the interrupt service routine (ISR). This is its big advantage over the PCINT system.

attachInterrupt(1, read_selector_isr, FALLING );

Timer/Counters

If you think back to Chapter 6, where we talked about the 74xx92 counter, timers will make a whole lot more sense. Imagine you connected that counter, or one of the decade counters I mentioned earlier to the 20MHz TTL oscillator that drives your Cestino. You know that the counter generates some combination of signals every time its input goes positive. You know that it will go positive exactly 20,000,000 times a second. If you know the oscillator’s speed and you count the pulses, you have a timer.

To set the timer, you have to have a place to store a bit pattern that you can check against the output of the counter, and some logic that does something if they match, or don’t match.

With an extra place to store some control settings and some logic, you could use the same electronics as a counter for other events, too. Two functions out of one circuit. Awesome.

This is exactly how timers work in the ATmega1284P. If you guessed that the control settings and the bit pattern to match are stored in registers, you catch on fast. The Arduino world goes to great machinations to hide the timer registers and make them “easy to use” by creating a #define for each bit of each mask, and suggesting you logically combine them, but we’re used to looking at eight and sixteen bit registers. We’ve done it for the last two chapters. Here’s how the ATmega1284P really handles timers.

Build the Dice Device

For all the complexity of using the hardware timers and interrupts, as you can see from the schematic in Figure 10-2, the actual circuit of the dice device is very simple. (That’s the advantage of using the hardware timers and interrupts.) There’s also a certain dumbness in this circuit, that I’ll explain when we get to it.

Figure 10-2. Dice Device Schematic

There are four components besides the Cestino in this circuit: two buttons, the dual LED display, and a ULN2803. This last is an integrated circuit containing eight Darlington transistor channels, complete with built-in load and base resistors, as well as diode protection. It’s a staple of the Arduino world, used to drive loads up to half an amp per channel, for electric motors (where the diode protection is a must), light bulbs, solenoids, and large strings of LEDs. Here’s where the dumbness comes in: it’s not really the right choice to drive a common anode LED display. The common anodes connect to the + bus of the Cestino. When one of the bases of the ULN2803A is raised high, the corresponding output pin is connected to a common ground. All the emitters of the Darlington transistors are tied to it. In order to use it in this circuit, what I’ve done is put the 330 Ohm dropping resistors between the anodes of the LED displays and the + bus, and then wired the display side of each resistor to one of the ULN2803 channels . When that channel of the ULN2803 is activated, the common anode is shorted to ground. This works, but it means that when a display is turned off, more current is consumed and turned into heat by the dropping resistor, than when it’s switched on. In a battery driven situation, this would be incredibly wasteful. If you have separate Darlington transistors, such as the TIP120, or any other power transistors rated at 15mA or more plus whatever resistors they need to switch at 5v, you could wire the emitter to the common anode (via the dropping resistor), and the collector to the + bus and only consume current to make light. The ULN2803A is not really the right IC for the job, but when you’re making electronics from stuff in your junk box, sometimes you have to compromise. In fairness, we’re making no effort whatever to conserve power with the Cestino either.

That said, let’s go ahead and build it.

As you saw in Figure 10-1, I put the display at the top of the breadboard, followed by the ULN2803A, followed at some distance by the buttons. Make sure you can tell your buttons apart. The upper one will roll, and the lower one will select what die to roll.

We’ll drive the LED display with port A, so wire pins 1, 2, 3, and 5 of the LED display (assuming you’re using the LTD4608JG or JR—the red version) to PA0-PA3, and 6, 7, 8, and 10 to PA4-PA7. Yes, seven segment displays have only seven cathodes, but the decimal points have one each, too. If you find your display gets too dim, or the segments are not evenly lit, you can go back and add the resistors marked Opt. 150 (optional 150Ω) between PA0-8 and pins 1,2,3,5,6,7,8, and 10 on the LED display.

Wire a 330Ω resistor to pin 18 of the ULN2803, and from there to the + bus. Do the same with the second 330Ω resistor and pin 17. Then wire the junction between pin 18 and the resistor to pin 9 of the LTD4608JG LED display. This is the common anode line for digit 1, which is the leftmost, or most significant digit. That’s how the datasheet for the LTD4608J series reads, and for clarity, I’ll call them the same thing.

Connect the junction between the resistor and pin 17 of the ULN2803 to pin 4 of the LTD4608JG. This is the common anode for digit 2, the rightmost, least significant digit.

Now wire pin 1 of the ULN2803, which controls the common anode for digit 1, to PC0, (Pin22) and pin 2, which controls the common anode for digit 2 to PC1, (Pin 23).

The display is now wired.

If you are using a different LED display than the LTD-4608JG or JR, it is vital that you find a datasheet on it and read it. Your pinout will be different. Don’t count on the segments being lettered the same either. If your display is a common cathode display (they’re not as common) you will need to change the common anode driver circuit (the connections to the ULN2803) accordingly and change part of the sketch to reflect that your segments are active high instead of active low. You can do this. It took me maybe half an hour to convert the sketch and the circuit to this display from the one I used in the prototype. It’s just lighting up LEDs. As long as they make light in the right place given the right signal, it’ll work fine.

The roll button (the red one in Figure 10-1) is connected to pin 16. You might notice that this is INT0, and you may have heard that using INT0 messes up serial communications between Arduinos and the host computer. All true, but we’re not using the interrupt on this pin. This pin will be poled by the loop() function , that is, loop() will read it over and over again (using digitalRead, no less.) Go ahead and wire PD2 (Pin 16) of the ATmega to one side of the roll button. Wire the other side of the roll button to the - bus.

The selector button will use an interrupt, INT1, in this case, which is connected to PD3 (Pin 17), so go ahead and connect one side of your button switch there and the other side to ground. If you’re guessing we’ll be turning on the pull-up resistors on both these pins, you’re right, and normally you’d be jumping ahead, except that we’re done with the wiring. Really, that’s all there is to it.

The Sketch

The sketch, for all the complexity we’ve added using interrupts and hardware timer/counters isn’t that complex either. Sometimes knowing why we do something is far more complicated than actually doing it. But the why is half of why we’re doing it, right?

In any case, we begin with the usual precompiler definitions. First, we define our busses. SEG_BUS drives the displays and MUX_BUS drives the common anodes to allow us to multiplex, mux for short, the displays.

#define SEG_BUS PORTA
#define MUX_BUS PORTC

We define the port settings for the MUX_BUS next. Remember that the common anodes, because of how we had to wire them to use the ULN2803, are active low. So to turn /on/ the MSD, which is digit 1, we need to make sure that PC0 is low and PC1 is HIGH. We do this by setting the port to 0x2, in hex, which turns on the two bit, and turns all other bits off. LSD_COMMON works the same way, save that it turns on the ones bit and turns off all the others. Active low, as we’ve seen over and over again, makes everything backward.

#define MSD_COMMON 0x2
#define LSD_COMMON 0x1

Most of our displayed values will fit the usual hexidecimal digits, but because the seven segment (plus decimal) displays can display some values that aren’t in hex, we define those here. We define them in decimal for clarity, but they’d be 0x10 and 0x11 in hex.

#define DECIMAL 16
#define BAR 17

Next we define which pin is the button pin (the roll button is connected here) and its interrupt (even though we don’t use it) and the selector button pin, and its interrupt, which we do use.

#define BUTTON_PIN 16
#define BUTTON_PIN_INTERRUPT 0
#define SELECTOR 17
#define SELECTOR_INTERRUPT 1

Interrupt service routines have one particular annoying feature: they can neither take data nor return data. Since we’re dealing with them in C as functions instead of C++ objects, we have to store their data in global variables. Some of the variables also need to be persistent, rather than recreated every time a function is called, to save compute time. Again, using an object would make this simpler.

The first global is seg_decode_array . It defines an array from zero to 17 that contains all the possible port settings to drive that particular value on one digit of the LED display. Remember that we defined 16 as BAR and 17 as DECIMAL, so they’re the last two entries in the array. Because we’re initializing the array at the same time we define it, and it’s a constant, we don’t have to specify an index number. With this specific LED display, and the segment order used in its datasheet, the order of the bits in this pattern are, from MSB to LSB:

A B G F D E Decimal Point C

const byte seg_decode_array[] = {
  0b00100010, //0
  0b10111110, //1
  0b00010011, //2
  0b00010110, //3
  0b10001110, //4
  0b01000110, //5
  0b01000010, //6
  0b00111110, //7
  0b00000010, //8
  0b00001110, //9
  0b00001010, //A
  0b11000010, //B
  0b01100011, //C
  0b10010010, //D
  0b01000011, //E
  0b01001011, //F
  0b11111101, //DECIMAL
  0b11011111  //BAR
};

Each 0 in these bit patterns corresponds to a lit LED segment, and each 1 corresponds to one that is left dark. Obviously, if your display is wired differently from the one in the schematic (note that the A B G assignments may also be different) these patterns will produce gibberish on your display, and you’ll need to create your own .

The next global variables are for ISRs. The first of these is msecs, a count of miliseconds, which we use for debouncing the selector button. What does this mean? Well, consider that the ATmega can respond to an interrupt in microseconds to nanoseconds, and that nothing we do with our fingers happens in that time. Further, a switch’s contacts are physical. They can bounce around and remake contact. Because the ATmega is so fast, we’ll interrupt on every one of them. This makes a push-button selector pretty much useless. We could put a capacitor in series with the push button, so that the jitter is soaked up by the capacitor, but we can do the same thing in software and save a component. As you get deeper into electronics, especially if you’re designing for manufacture, you’ll find that saving a component by adding software is a constant theme. Ever wonder why nothing has a real power switch anymore?

You might note that milis is declared volatile. This tells the compiler that this variable is always to be read from RAM, rather than from a stored register. Globals modified by interrupt service routines should be volatile, since when a given variable is updated and by what routine (the ISR or a regular function) are difficult to know.

The other value here is a flag, a simple boolean to tell us whether we’ve rolled since the last time we selected. This is used in loop() and I’ll cover it there.

volatile unsigned long msecs = 0;
boolean rolled_since_select = false;

Roll stores the value of the last die rolled. It’s sent to the display system every time loop() is called when rolled_since_select is true.

Die does the same thing, except that it’s set by the selector button ISR, so it’s declared volatile.

D_select is the value of the die that is selected. It’s modified by the selector button ISR, so it’s volatile.

LSD and MSD are the variables that hold the value of each of the two digits in the display, from 0x0 to 0x11, remembering that 0x10 and 0x11 are bar and decimal, respectively. While they’re read by the timer/counter interrupt ISR, they’re not changed by it, so they need not be volatile.

Lsd_active is modified by the timer/counter ISR, so it is declared volatile. It’s used to determine which digit is currently active.

byte roll = 1;
volatile byte die = 4;
volatile byte d_select = 0;
byte lsd = BAR;
byte msd = BAR;
volatile boolean lsd_active = true;

Next comes the read_selector interrupt service routine. When the selector button is pushed, and the interrupt sends the ATmega off on the interrupt vector to run some code there, this is the code that gets run.

The millis() function returns the number of milliseconds that have elapsed since the sketch started. We subtract msecs from it. If more than 250ms have elapsed since the last time the selector interrupt fired, we increment d_select, and set msecs to millis(). If it’s less than 250ms, a quarter of a second, we’re probably looking at button jitter, so we ignore it. Regardless, we set rolled_since_select false. We’ve just selected. Once all this is done, the ATmega goes back to what it was doing. Most likely executing code in loop().

void read_selector_isr() {
  if (millis() -msecs > 250) {
    d_select = d_select + 1;
    msecs = millis();
  }
  rolled_since_select = false;
}

What’s next is the interrupt service routine for Timer/Counter 3. Note that, like I said at the end of the section about interrupts, it’s defined using the ISR() macro, which is part of the AVR GCC compiler . It passes that macro a parameter to tell it which interrupt vector to use. The result of all this is that the interrupt vector points directly at the function below, without the benefit of attachInterrupt.

Once called, the ISR sets all the bits of SEG_BUS to 1s to turn them off (active low, remember?). It then clears the two bits of MUX_BUS that we’re using by anding it with 0b11111100.

if lsd_active is true, we’re writing to the least significant (rightmost) digit, aka digit two. We set MUX_BUS to LSD_COMMON to activate the correct common anode. We then set SEG_BUS to the value of seg_decode_array[lsd], which looks up the correct bit pattern for the value stored in lsd, and displays it.

if lsd_active is false, we are writing to the most significant digit, or the leftmost digit. This is different.

In some cases, if the most significant digit is 0, we don’t want to display it. When using a dedicated driver IC for 7 segment displays (you knew they existed) this would be done with the ripple blanking pin. Here, we do it in software. The only time we want to display the leading zero is when we’ve rolled 100. In this case, MSD will equal 0xA. So we first test to see if msd is greater than zero, and if it isn’t, we don’t display anything. If it is greater than zero and it’s equal to 0xA, or 10, we set it to zero. Since we’ve already passed the greater than zero test, that leading zero will be displayed. After that, we set mux_bus to MSD_COMMON to activate the correct digit, (active low, remember?) and look up the bit pattern for msd in seg_decode_array, the same as we did for the least significant digit.

ISR(TIMER3_COMPA_vect) {//toggle the LED pin
  SEG_BUS = 0b11111111;
  MUX_BUS = MUX_BUS & 0b11111100;

  if (lsd_active) {
    MUX_BUS = MUX_BUS | LSD_COMMON;
    SEG_BUS = seg_decode_array[lsd];
  }
  else { //we must be writing to the most significant digit.
    if ((msd != 0)) { //only display msd if it’s nonzero.
      if (msd == 0xa) msd = 0;
      MUX_BUS = MUX_BUS | MSD_COMMON;
      SEG_BUS = seg_decode_array[msd];
    }
  }
  lsd_active = !lsd_active;
}

The next function is setup(). Normally a mild-mannered function where we initialize the serial console (which we don’t do here, since we’re not using it), this function is where we’ll see all the machinations we do to use the external interrupt for the selector and the counter/timer and its interrupt. It’s not that bad.

We start by setting our ports up. We set PORTA up to write on all pins. We set PORTC up to read on the top four pins and write on the bottom four pins. We don’t use the other four pins of PORTC for anything, so their setting doesn’t actually matter. PORTD is set to read, as you’d expect, and we OR the two bits where we have the buttons wired with 1s to switch on the pull-up resistors. These pins will be positive unless some low resistance connects them to the - bus. Like the roll or selector button.

void setup() {
  DDRA = 0b11111111;
  DDRC = 0b00001111;
  PORTC = 0b00001100;
  DDRD = 0b00000000;
  PORTD = PORTD | 0b00001100;

Here’s where we set up both our timer/counter interrupt and our external INT interrupt. The first thing we do is turn interrupts off, so that we don’t get interrupted while we’re messing with the interrupts and interrupt vectors. It could happen, and the results could be unpredictable. How does this work? Remember in Configuring Timer/Counters where I mentioned that there’s a global interrupt enable flag? This Arduino function sets and clears that flag.

  noInterrupts();

Next, we set TCCR3A to 0. We don’t need any of its bits set. We’re not using any compare output pin modes, and the two clock select bits it has aren’t ones we need.

  TCCR3A=0;

TCCR3B is set to 0b00001101. This means the three Clock Source bits are set to 101, which gives us the prescaler dividing the system clock by 1024. Note that we’ve turned the timer/counter on, too, not that it can do anything with interrupts turned off. It is counting, however. We also set WGM32 on. Combined with the zero values in WGM30, WGM31 (in TCCR3A), and WGM33 here, this gives our total WGM bit field a value of 0b0100, which is CTC mode 4. The timer/counter will count to the value in OCR3A and reset when it gets there. I’ve left the bit field definition comment in place for clarity.

  // ICNC3 ICESN0 - WGM33 WGM32 CS32 CS31 CS30
  TCCR3B=0b00001101;

Finally we set TCCR3C to zero. We don’t want to force any compare-matches. This isn’t really necessary.

  TCCR3C=0;

Having set our timer/counter in motion by setting it up with a clock source, we need to tell it what to count to, and what to do when it gets there, so we set OCR3A (remember, it’s a 16 bit register, so I set it with a 16 bit hex value. You don’t have to use the leading zeros, but I think it makes things clearer.) Hex 00A3 is 163. if we divide a 20MHz clock by 1024, we get about 19.5kHz. If we divide that by 163, we get a bit under 120Hz. Because a given display is only updated on alternate interrupts, this gives us about 60Hz per display which should keep flicker from happening. If you’re wondering whether this could have been done using timer 3’s own output pins instead of writing the ISR, technically yes, although ripple blanking would have been a problem, and we wouldn’t have learned how to write timer/counter ISRs.

  OCR3A = 0x00A3;

Okay, our timer is running, it’s counting from zero to 163 about 120 times a second. It’s busily setting the OCF3A flag (bit) in the TIFR3 register, but even if global interrupts were on, it wouldn’t do anything. Yet. Let’s change the timer/counter interrupt mask to let OCF3A get through. The OCF3A flag corresponds to the OCIE3A interrupt enable bit in the mask, so we set TIMSK3 to 0b00000010, and set that output compare interrupt enable bit. Once again, I’ve left the comment with the bit pattern in place for clarity.

  // - - ICIE3 - - OCIE3B OCIE3A TOIE3
  TIMSK3 = 0b00000010;

Now the timer’s hooked up. We’ve already set up its ISR, so once we turn interrupts back on, our display should switch back and forth between the two digits, so fast we can’t see them.

We do have to hook up the interrupt for the selector button too, but because it’s an external interrupt, and external interrupts are covered by the attachInterrupt mechanism in Arduino, we can set the interrupt, ISR, and mode up in one statement. SELECTOR_INTERRUPT is #defined at the beginning of the sketch, and read_selector_isr is the function we defined earlier to do the job. Note that we DON’T put the usual parens () when we name read_selector_isr. It looks wrong, but I’m sure the attachInterrupt function is creating a pointer to our function. When you do that, the parameters are in a separate pair of parens. In any case, that’s the syntax and that’s how the Arduino foundation said it should be. When the button attached to SELECTOR_INTERRUPT’s pin shorts that pin to ground, the falling edge (transition from above 0.6v to below 0.3v) will trigger the interrupt, which will jump to read_selector().

  attachInterrupt(SELECTOR_INTERRUPT, read_selector_isr, FALLING );

Finally, we turn interrupts on, and let the whole thing loose.

  interrupts(); //turn interrupts on.
}

The loop function, as you’re undoubtedly tired of hearing by now, is called over and over again by the Arduino core. A lot of the time, we’ve stopped that from happening by putting an infinite loop at the end of our code, so we can control when loop runs, and what variables are reset.

I didn’t do that here. I let loop() run over and over again. This is the other reason there are so many global variables.

The first thing we do is initialize a byte variable called display_value and set it to zero. Display_value is split into two decimal digits to make LSD and MSD later.

If rolled_since_select is true, we set display_value to roll, the last value rolled on the dice device. Otherwise we set it to die, the last die type selected.

void loop() {
  byte display_value = 0;

  if (rolled_since_select) {
    display_value = roll;
  }
  else {
    display_value = die;
  }

Next, we break display_value apart into its least and most significant decimal digits. We get the low digit by taking the modulus of display_value by 10. The high digit is set to the display value divided by ten. There is a huge assumption here. This mechanism depends on the fact that this is integer division. Anything less than zero is ignored. If you tried to mistreat real numbers this way, you’d get bizarre results. By the time we reach the bottom of this part of the sketch, either the last die selected or the last roll rolled will be set to display on the LED display. We don’t have to touch the display itself. That’s handled by the timer interrupt. It’s a little strange when you’re used to controlling when everything happens in a sketch to just say “that happens in the background.” But it does.

  lsd = display_value % 10;
  msd = display_value / 10;

The other goings on in the background, whether the user has pushed the selector button or not, may have incremented the d_select variable. We declare a quick constant array with all the possible die_values in it, and then look up the die at d_select, and put that value in die. If the user has pressed the selector button since the last time the roll button was pressed, rolled_since_select will be true. We don’t need to do anything about that right now. Just set the variables and let loop() do the additional processing next time it comes around.

  const int die_value[] = {4, 6, 8, 10, 12, 20, 100, 18};
  die = die_value[d_select];

  if (d_select > 7) d_select = 0;

Enough with the spooky background stuff and letting loop pick up changes faster than we can see them. Here’s the part of the sketch where we actually pole the roll button as fast as we can (once per cycle of loop()). As long as the roll button is held down, keep setting LSD and MSD to BAR and keep incrementing roll If roll goes higher than die, reset roll to 1. Also, keep setting rolled_since_select true. Over and over again. Don’t do anything else until the user lets up on the button. Except, of course, that the timer interrupt for the display will go on interrupting. If we were really insistent on this loop running as fast as it can and not being interrupted, we could turn interrupts off. We’re not that time sensitive here.

  if (!digitalRead(BUTTON_PIN)) {
    while (!digitalRead(BUTTON_PIN)) {
      lsd = BAR;
      msd = BAR;
      roll++;
      if (roll > die)roll = 1;
      rolled_since_select = true;
    }

Okay, we’re out of the die rolling loop. The user has let up on the button, but we’re still inside the original if statement that tested the button.

You might be wondering how we’re going to roll 3d6. Just roll from 1 to 21 and add three? No, that gives you different odds. Having generated a random number, if die is 18, and if rolled_since_select is true, we seed the clib random function with roll, and add three calls to the random() function with a low value of one and a high value of 6 together and put them in roll. Those are the correct odds.

    if (die == 18 && rolled_since_select) {
      randomSeed(roll);
      roll = (int)random(1, 6) + (int)random(1, 6) + (int)random(1, 6);
    }
  }
}

And that’s the end. The loop() program is called over and over again forever, so our newly generated roll will be displayed next time around, and of course, our timer/counter will go on interrupting loop() to update the display.

As always, the complete sketch with all the comments (and there are a lot of them) is included here.

//Dice Device
//-----------------------------------------------------------
// This sketch generates die rolls based on timing randominity.
// Essentially, this method of random generation assumes that
// human reflexes are not accurate to less than about a
// quarter of a second, and a sufficiently fast counter that
// rolls over will generate good random values when switched
// on and off by a human pushing a button.
//
// This sketch generates the rolls for a full set of
// polyhedral dice used in various role playing games,
// including a properly implimented 3d6 roll, and displays
// them to a multiplexed pair of 7 segment displays.
//-----------------------------------------------------------

// Precompiler #defines
//-----------------------------------------------------------
#define SEG_BUS PORTA
#define MUX_BUS PORTC
// Define the port to talk to the 7 segment display
// and the one that controls multiplexing via a uln2803

#define MSD_COMMON 0x2
#define LSD_COMMON 0x1
// Define the port settings for the multiplexer.

#define DECIMAL 16
#define BAR 17
// Define special characters as integer values.

#define BUTTON_PIN 16
#define BUTTON_PIN_INTERRUPT 0
#define SELECTOR 17
#define SELECTOR_INTERRUPT 1
// Define the pin and interrupt used by the roll button and
// the selector button.

//Global Variables
//-----------------------------------------------------------
const byte seg_decode_array[] = {
  //7 segment decoding byte array.
  //A B G F D E DP C
  0b00100010, //0
  0b10111110, //1
  0b00010011, //2
  0b00010110, //3
  0b10001110, //4
  0b01000110, //5
  0b01000010, //6
  0b00111110, //7
  0b00000010, //8
  0b00001110, //9
  0b00001010, //A
  0b11000010, //B
  0b01100011, //C
  0b10010010, //D
  0b01000011, //E
  0b01001011, //F
  0b11111101, //DECIMAL
  0b11011111  //BAR                                                
};
volatile unsigned long msecs = 0; //stores time in ISRs for debouncing.
boolean rolled_since_select = false; //Have we rolled?
//If so, this is true. Used in loop()

byte roll = 1; //value of the last roll of the dice.

volatile byte die = 4; //Die, as in d4, d8, d16, etc.
volatile byte d_select = 0; //what die is selected.
volatile byte lsd = BAR; // leftmost digit’s integer value.
volatile byte msd = BAR; // rightmost digit’s integer value.

volatile boolean lsd_active = true; //Used by timer ISR
// to store whether we’re writing to the least significant
// digit or the most significant digit.

//-----------------------------------------------------------
//read selector ISR
//
// This function is an interrupt service routine. It takes no
// parameters and returns no data.
// When the button connected to BUTTON_PIN is pressed, the
// interrupt executes this function. It checks to see if 250ms
// have elapsed since the last press (for debouncing) and if
// so, increments d_select by 1.
// d_select is actually processed in the loop() function.
//-----------------------------------------------------------
void read_selector_isr() {

  Serial.println("read_selector Fired");
  if (millis() -msecs > 250) {
    d_select = d_select + 1;                                                                              
    msecs = millis();
  }
  rolled_since_select = false;
}

//-----------------------------------------------------------
// ISR Timer interrupt service routine)
//
// This function takes no parameters and returns no data.
// it selects which digit is enabled (lsb or msb) by clearing
// MUX_BUS and then setting to LSD_COMMON or MSD_COMMON, then
// sets SEG_BUS to the bit pattern for the value in LSD or
// MSD respectively.
//
// This function also impliments ripple blanking, where
// the MSD is not displayed if it contains zero /unless/
// MSD contains 0xa (10), which we only hit if we’re selecting
// or rolling percentile dice.
//
// We’re using timer 3 for the display multiplexer. ATmega328
// based Arduinos will need to use a different timer.
// This ISR is connected to the TIMER3_COMPA interrupt vector.
// This means that when the timer’s value matches the contents
// of TIMER_3_COMPA, this ISR will be called.
//-----------------------------------------------------------
ISR(TIMER3_COMPA_vect) {//toggle the LED pin
  SEG_BUS = 0b11111111;
  MUX_BUS = MUX_BUS & 0b11111100;

  if (lsd_active) { //write to lsd

    MUX_BUS = MUX_BUS | LSD_COMMON;
    SEG_BUS = seg_decode_array[lsd];
  }
  else { //we must be writing to the most significant digit.
    if ((msd != 0)) { //only display msd if it’s nonzero.
      if (msd == 0xa) msd = 0;
      // if msd is 0xa set it to zero after the zero test.
      // leading zero will show on d100 select and 100 rolls.

      MUX_BUS = MUX_BUS | MSD_COMMON;
      SEG_BUS = seg_decode_array[msd];
    }
  }
  lsd_active = !lsd_active;                                                                              
}

//-----------------------------------------------------------
// setup()
//
// This function is called once by the Arduino core. It returns
// no data and takes no parameters.
// It sets up the serial console, sets the ports into the
// necessary states, and sets up the segment decoding array.
// It then turns interrupts off, sets up the timer interrupt
// and attaches the external interrupt to the
// SELECTOR_INTERRUPT interrupt and to the read_selector
// function. After that, it re-enables interrupts.
//-----------------------------------------------------------
void setup() {
  Serial.begin(115200);
  //Init the serial console.

  DDRA = 0b11111111;
  DDRC = 0b00001111;
  PORTC = 0b00001100;
  DDRD = 0b00000000;
  PORTD = PORTD | 0b00001100;
  //Set up the various ports. Note the pullup resistors
  //being set on port D.

  noInterrupts(); //turn interrupts off

  //Set up the timer/counter and timer/counter interrupt.
  //---------------------------------------------------

  TCCR3A = 0; // Clear all pin control bits and
  TCCR3B = 0; // set clock select to 0. Stops the timer.
  TCNT3 = 0;  // Zero the timer count register

  //TCCR3A:
  // COM3a1 COM3a0 COM3b1 COM3b0 - - WGM31 WGM30
  TCCR3A=0;
  // All four COM3 bits remain at zero: the port
  // operates normally. Likewise the WGM31 and 30
  // bits remain at zero. We only turn on WGM32,
  // for CTC mode 4, and that’s in TCCRB3.

  //TCCR3B
  // ICNC3 ICESN0 - WGM33 WGM32 CS32 CS31 CS30
  TCCR3B=0b00001101;
  // turn on WGM32 for CTC mode 4
  // and set the clock select bits to 101 for the
  // 1024 prescaler.

  //TCCR3C                                                
  // FOC3A, FOC3B, no other pins are used.
  TCCR3C=0;
  // Make sure FOC3A and B are cleared. We don’t want to
  // force a compare.

  OCR3A = 0x00A3; //output compare register.
  // 20mHz/1024 (the prescaler) is about 19.5kHz.
  // Hex 00A3 is 163. 19.5kHz/163 is a bit over 120Hz.
  // Bearing in mind that each digit is refreshed every other
  // interrupt, that gives us about 60Hz per digit,
  // which is enough to avoid flicker. Persistence of vision
  // FTW.
  // Yes, this could have been done with a timer/counter
  // configuration using the OC3A and OC3B pins and no
  // ISR at all, but then we wouldn’t learn how to do
  // timer ISRs.

  //TMSK3
  // - - ICIE3 - - OCIE3B OCIE3A TOIE3
  TIMSK3 = 0b00000010;
  // Set OCIE3A - enable an interrupt when output compare
  // match A (TCNT3 = OCR3A) occurs.

  //Set up the selector interrupt.
  //---------------------------------------------------

  attachInterrupt(SELECTOR_INTERRUPT, read_selector_isr, FALLING );
  //read_selector interrupt - when the read_selector pin changes
  //from high to low, interrupt.

  interrupts(); //turn interrupts on.
}

//-----------------------------------------------------------
// loop()
//
// Called over and over forever by the Arduino core.
// Loop sets the values of the globals lsd and msd for the
// display ISR to pick up,
// processes what the read_selector ISR has set in the
// d_select global variable,
//-----------------------------------------------------------
void loop() {
  byte display_value = 0;                                                                              

  if (rolled_since_select) {
    display_value = roll;
  }
  else {
    display_value = die;
  }

  lsd = display_value % 10;
  msd = display_value / 10;
  //Button is active LOW, so if the roll button is NOT pushed,
  //display either the selected die or the last roll.

  const int die_value[] = {4, 6, 8, 10, 12, 20, 100, 18};
  die = die_value[d_select];

  if (d_select > 7) d_select = 0;
// set die to whatever value was last selected by the
// select ISR with die_value[].

  if (!digitalRead(BUTTON_PIN)) {
    while (!digitalRead(BUTTON_PIN)) {
      lsd = BAR;
      msd = BAR;
      roll++;
      if (roll > die)roll = 1;
      rolled_since_select = true;
    }
// If the roll button is pressed, display bars in both digits
// and increment roll every time loop is called.Also set
// rolled_since_select to true.

    if (die == 18 && rolled_since_select) {
      randomSeed(roll);
      roll = (int)random(1, 6) + (int)random(1, 6) + (int)random(1, 6);
      //The D18 mode is really 3d6 for chargen.
      // Seed with roll and call random() 3 times
      //Cast random results as int since they are long
      // otherwise.
    }
  }
}

Credit where Credit is Due

The Dice Device drew inspiration from an electronic die roller from the early 1980s whose name I won’t mention lest I stumble over a trademark. Nevertheless, I will mention that you can read its patent, look at the schematic, and understand the thing’s marvelous simplicity here: https://www.google.com/patents/US4431189 . I may yet have to build one for my own use with the original ICs, as they’re unobtanium on the secondary market.

Understanding the timers and interrupts was something I had to do in spite of the Arduino foundation, rather than based on their documentation. I got most of it from the ATmega1284P datasheet, but I got the code working first based on several web tutorials. There are so many now that I can’t put my finger on which one exactly. Nevertheless, this is a good set of tutorials on the subject: http://www.engblaze.com/microcontroller-tutorial-avr-and-arduino-timer-interrupts/

And of course, one must credit the late E. Gary Gygax for inventing the game, whose name is also a trademark, for which the dice were used, and without whose invention my life might have been more productive, but far less fun. https://en.wikipedia.org/wiki/Gary_Gygax