Code V.igoro.us - Arduino

LCD Display and TMP102 sensor

nospam@example.com (Dustin J. Mitchell) — Sun, 18 Apr 2010 02:22:01 +0000

It is incredibly easy to throw things together with an Arduino. It's common to see criticism of the device when it's used in in projects that don't require even a fraction of its power, and that might be justified. As a flexible platform for test-driving complex modules, though, the Arduino hits the mark perfectly on flexibility and usability.

I don't have a particular project in mind for my Arduino, but since I don't have a multimeter or an oscilloscope, I want to use it as a test harness for various basic components as I experiment with them. To this end, I bought a cute 16x2 character amber LCD display. With thoughts of building a fermentation-temperature monitor and learning about the I²C bus, I also bought a relatively cheap TMP102 and breakout board. With a little bit of reading, I was able to stitch them together quickly and easily.

LCD Display

The display I purchased is command-driven via a 4-bit parallel port. It's a ST7066, compatible with HD44780. There are two datasheets available -- one for the ST7066, and one for the assembled board. The latter adequately described the pinout through unattributed copying from the former, but was otherwise useless. "Qiu", "Chen", and "Ye", all three of whom helpfully signed the cover page, should be ashamed. Anyway, here's a brief description of the pins and some more details I culled from the ST7066 datasheet:

V_ss (ground) and V_dd (positive supply): these are rated up to 7V, so running from the Arduino's 5V supply is great.
V₀ sets the LCD contrast. Short on jumpers, I initially assumed I could leave this unconnected to get "reasonable" contrast. Not so! I tried setting up a few voltage dividers to get the right contrast, without any luck. Plan to add a 10k pot between ground and the positive supply, and tie the wiper to this pin.
RS (register select) selects whether an operation is to configuration registers (0) or RAM (1)
R/W (read/write) selects whether an operation reads or writes to the device
DB0-DB7 is the data bus
E (enable), strobed to move a byte across the data bus
LED+/LED- supply power to the LED backlight, and can be wired directly to the 5V supply.

The Arduino has a lot of digital pins, but all the same it's handy to save a few pins. The display supports reading character and font data, but that's not much use: the Arduino can remember whatever it needs to. So we won't need the R/W pin, and can tie it to ground (read) instead.

The display can operate in two data lengths (controlled by the DL configuration bit). In the default mode, only 4 bits (DB4-DB7) on the parallel bus are used. The display starts in 8-bit mode, but fortunately the DL bit comes in at pin DB4, so it's relatively easy to reset the data length with only 4 pins connected. Note that there's an odd sequencing required here, where you need to set 8-bit mode three times before setting 4-bit mode. Don't worry, though: the Arduino LiquidCrystal library takes care of that for you.

So aside from pins tied to V+ or GND, we only need 6 digital I/O pins. It's best to avoid the pins that have other functions on the Arduino: 0 and 1 are RS-232 I/O, and 13 is the onboard LED. I used pins 2-5 for the data bus, pin 12 for E, and pin 13 for RS, since that was at the top of the LiquidCrystal example. V_ss, LED-, and R/W go to GND; V_dd and LED+ go to the 5V supply; and V₀ is wired as described above.

From there on out, it's a straightforward application of the LiquidCrystal library:

#include <LiquidCrystal.h>

LiquidCrystal lcd(12, 11, 5, 4, 3, 2); 

void setup() {    
    lcd.begin(16, 2); 
}

void loop() {
    lcd.setCursor(0, 0);
    lcd.print("Hello, World");
}

Note that the display itself is capable of a number of interesting things not supported by the library. It has an 80-byte character memory, and can scroll that through the display without rewriting the entire screen every time. It can also accept 8 custom 5x11 glyphs, making rudimentary animation possible.

TMP102

The TMP102 is ridiculously tiny - smaller than the SMD resistors that Sparkfun has placed around it on the breakout board. It senses temperature internally, which means it's basically monitoring the temperature of its leads.

The device speaks I²C (also known as the two-wire interface or SMBus), which makes it pretty easy to connect to the Arduino. The MCU speaks I²C via hardware, so the corresponding Arduino library doesn't even need to bit-bang the data. On the Duemilanove, it uses analog-in pin 4 for SDA and analog-in pin 5 for SCL. You'll also need to hook up V+ to the 3.3V pin on the Arduino (the device is only specified for 3.6V) and GND to the TMP102's GND. Finally, the TMP102's ADD0 pin can cleverly select one of four addresses for the device by tying it to one of these four pins. I tied it to GND, giving address 0b1001000. ALARM is an output pin, so you can leave it unconnected.

The TMP102 is a very nice low-power device that's designed to handle several common tasks without any interaction from the MCU - it can trigger an interrupt when the temperature strays from a configured boundaries, poll temperature on a relatively slow schedule, or even poll on command. I didn't use any of that, relying on the device to simply sample the temperature on its own schedule.

The TMP102 has four registers, but we'll only use one -- temperature (0b01). Like many devices, this one multiplexes addresses and data over the same bus. To read a register, you first select the register by writing it to the device, then read the 16-bit value, again with the MSB first. Once a register is selected, it can be read multiple times.

The device's temperature register contains a two's-complement 12-bit value, left-aligned, where 0x7FF is 128°C; equivalently, a change of one unit in the 12-bit value is equivalent to 0.0625°C.

Putting it Together

The obvious combination of these tools is to display the ambient temperature on the LCD screen. Here's the program to do so:

#include <Wire.h>
#include <LiquidCrystal.h>

LiquidCrystal lcd(12, 11, 5, 4, 3, 2); 

#define TEMP_REG 0b00000000
int tmp102 = 0b1001000;  // with ADD0 tied to ground

void setPR(int reg) {
  Wire.beginTransmission(tmp102);
  Wire.send(reg);
  Wire.endTransmission();
}

int getReg() {
  unsigned char lo, hi;

  Wire.requestFrom(tmp102, 2);
  hi = Wire.receive();
  lo = Wire.receive();
  return (hi << 8) + lo;
}

void setup()   {    
  lcd.begin(16, 2);
  Wire.begin();
  setPR(TEMP_REG);
}

void show_temp() {
  int temp_reg = getReg();
  lcd.setCursor(0, 0);
  show_bin(temp_reg);

  temp_reg >>= 4;

  float temp_C = temp_reg * 0.0625;
  float temp_F = (temp_C * 9 / 5) + 32;

  lcd.setCursor(0, 0);
  lcd.print(temp_C);
  lcd.print("\xdf""C  ");
  lcd.setCursor(0, 1);
  lcd.print(temp_F);
  lcd.print("\xdf""F  ");
}

void loop() {
  show_temp();
}

The setup function sets up the LCD, then uses setPR to point the TMP102 at the temperature register. Subsequent reads will then return the 12-bit encoded temperature. The loop function reads the temperature register, decodes it, and displays the result in both Celsius and Fahrenheit.

Note that this is horrendously inefficient: the TMP102 only measures temperature every 26ms or so, during which loop will probably run a half-dozen times, feeding the same time strings to the LCD each run. It would be much better to put the TMP102 in one-shot mode, and measure the temperature at a much lower frequency - say once a second - with a correspondingly low update frequency for the display. I'll leave that as an exercise for the reader.

Charlieplexing: watch your voltage levels!

nospam@example.com (Dustin J. Mitchell) — Sun, 31 Jan 2010 02:58:57 +0000

Charlieplexing is a technique to allow n tristate digital output pins to control n(n-1) LEDs, by exploiting the high-impedence state of the output pins and the reverse-bias tolerance of LEDs.

I put together a circuit to test this out, similar to the 6-LED diagram in the Wikipedia entry. I added three 220Ω resistors, though. This ASCII art sums it up nicely:

      +--->|---+          +--->|---+          +--->|---+    
      |  LED1  |          |  LED3  |          |  LED5  |
 <----|        |-/\/\-+---|        |-/\/\-+---|        |-/\/\-+-->
      |  LED2  |      |   |  LED4  |      |   |  LED6  |      |   
      +---|<---+      R   b---|<---+      G   +---|<---+      B

where R, G, and B are the three connections to the Arduino, and the arrows on the left and right side are joined by a jumper. I put together some simple Arduino-level code to drive this layout in a simple counter sequence, and fired it up.

One thing I will say about the Arduino: tinkering pays off. After the usual forgotten-semicolon cleanup, LEDs started blinking immediately. This is good, because I don't have much of an Arduino-debugging toolbox at this point!

Anyway, there's a problem. When an LED is fully illuminated, two other LEDs glow at about 50% brightness. For example, when LED1 is on, LED4 and LED6 glow too. It's not hard to see why: to turn LED1 on, the arduino drives R low and B high. The path through LED1 is intended, but LED4 and LED6 are also forward-biased in series, albeit with more resistance inline and the voltage-drop from two LEDs. Can this be prevented?

Let's work out the math here, using the resistance r as the only parameter I can change. The LEDs I'm using (5mm Green LEDs from CHINA YOUNG SUN) don't have a lot of performance data, but do list a forward voltage drop of 1.8-2.2V, so let's use 2V. My Arduino is running from the USB power at 5V. The resistor to the left of R defines the current through that leg for the remaining 5-2 = 3V, so I₁ is 3/r. On the leg containing LED4 and LED6 a total of 1V remains across two resistors, so I₄ and I₆ are both 1/2r.

The LED datasheet lists a maximum average current (20ma) and peak current (30ma), but doesn't list a minimum current. Guessing 1ma, I need 1/2r < 0.001, so r > 500. At that point, though, I₁ is just 6ma - not nearly bright enough to impress, particularly with a 16% duty cycle when multiplexing all 6 LEDs. All the same, I figured I'd try it. The closest resistor I had was 470Ω, so I gave that a shot. The result was bad on all fronts: the expected LED is dim, and the unwanted LEDs are still visible.

I suspect that, to get this to work, I'd need to reduce the supply voltage to something less than twice the LEDs' forward voltage drop. Then two LEDs in series would carry no current. I considered doing this with a simple voltage divider on each microcontroller pin, but this of course ruins the tri-state behavior that's critical to charlieplexing. I could build that by using two transistors for each pin, but by that point the benefits of charlieplexing in terms of component count are long lost.

So, in short, for good charlieplexing, make sure that your source voltage is less than twice the V_f of your LEDs.

[EDIT: it turns out, after some futzing that this also "works fine" if you just leave out the ballast resistors. Presumably this relies on a limited duty cycle and a "high enough" internal resistance to not melt the LEDs]

2005 Mac Mini as an Arduino Development System

nospam@example.com (Dustin J. Mitchell) — Sun, 24 Jan 2010 00:00:28 +0000

I have an early Mac Mini that's not good for much of anything anymore. It's not too fast, and it's a 32-bit PPC chip, so most proprietary-blob software is off-limits, meaning it doesn't make a good media PC. I put Gentoo on it, and decided to use it to interface with my new Arduino Duemilanove. I'm more interested in the Arduino as a processor I can play with, rather than a gateway to flashing LEDs, so I don't want the full IDE - just a compiler and assembler, and a USB-based programmer.

This post documents the process I followed to set all of this up.

Smoketest

As a smoketest, I downloaded the Arduino application on my Macbook and modified one of the blinkie examples to make a chaser for a 7-segment display I had handy. I tweaked the code, hooked up some jumpers, and clicked the "Upload" button. The code was pretty simple, but I did encounter an elementary digital logic problem: my display was common-anode, but a digital HIGH is +5V. I can't simply ground the common pin - what to do, then? My confusion was based on the false assumption that logic LOW is unconnected - of course, it's actually ground. So I connected the common anode to the +5V rail, and set up to illuminate each segment with a LOW digital out signal (routed through a 220Ω resistor). Here's the code:

Software

Next up, installing the requisite software on the Mini. First, the crossdev tools. Most documentation suggests simply:

emerge crossdev
crossdev --target avr

But this failed:

 * ERROR: cross-avr/avr-libc-1.6.4 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called pkg_setup
 *   avr-libc-1.6.4.ebuild, line   40:  Called die
 * The specific snippet of code:
 *              die "AVR toolchain not found"
 *  The die message:
 *   AVR toolchain not found

The solution, available from Gentoo bug #230343, is to add the --without-headers flag, which instructs the crossdev tool to build the compiler first, then the C library. The -s4 builds a stage-4 compiler, including the C++ frontend.

crossdev -s4 --target avr --without-headers

This takes a long time on a system of this vintage.

While I was in the root shell, I installed avra, an AVR assembler:

emerge avra

Next up, the kernel driver. For the particular board I have, I need kernel support for the FTDI USB-to-serial chip. The driver is ftdi_sio, and the kernel option is Device Drivers -> USB Support -> USB Serial Converter Support -> USB FTDI Single Port Serial Driver. If you happen to be on a PPC machine, don't forget to run ybin -v after upgrading the kernel. With this set up, the USB serial device appears at /dev/ttyUSB0.

Finally, the programmer. I'm using avrdude. I installed this from portage. I had to install version 5.8 (keyworded ~ppc) to get the ATMEGA328P support. The problem is, avrdude doesn't automatically reset the device by pulsing DTR. The Arduino IDE does this just before running avrdude. There is a patch available on Avrdude bug #6866, but it hasn't yet been merged. Rather than try to set up an avrdude ebuild in a local portage overlay, I opted for the simpler solution described in the arduino.cc forums: reset the device with a perl script just before invoking avrdude. The code is simple:

I needed to emerge dev-perl/Device-SerialPort first. Then, to upload a new program:

./pulse && avrdude -c arduino -b 57600 -p m328p -D -U flash:w:/tmp/Blink.cpp.hex:i -P /dev/ttyUSB0

Compiling

Up to now, I've been using Blink.cpp.hex, compiled earlier on the Macbook. Now it's time to start building locally. All of the libraries and headers that make an Arduino sketch into an executable are in the dev-embedded/arduino ebuild. I keyworded this (~x86 since there's no ppc keyword in the ebuild) and added USE=-java since I don't need the IDE, and emerged it.

I copied /usr/share/arduino-0017/hardware/cores/arduino/Makefile into my sketch directory and ran make. The result:

/bin/sh: /usr/share/arduino-0017/hardware/cores/arduino/Print.d: Permission denied

There are some comments in the ebuild about this -- apparently the IDE builds the .d files when it is first run, using group id uucp. The easiest fix was just to run make as root, once, to build these files.

The Makefile references wiring_serial.c, but this file is not present in the distribution. I removed it from the Makefile. Presumably I'll be on my own to configure serial I/O?

I'm starting to get the impression that using the IDE is the smart way to go here! The next error is from the linker, unable to find its script:

/usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.x: No such file or directory

This is Gentoo bug #147155, which at the moment is not fixed. The workaround:

ln -s /usr/lib/binutils/avr/2.20/ldscripts /usr/avr/lib/ldscripts

And finally, we have a build:

dustin@erdos ~/tmp/Blink $ make
# Here is the "preprocessing".
# It creates a .cpp file based with the same name as the .pde file.
# On top of the new .cpp file comes the WProgram.h header.
# At the end there is a generic main() function attached.
# Then the .cpp file will be compiled. Errors during compile will
# refer to this new, automatically generated, file.
# Not the original .pde file you actually edit...
test -d applet || mkdir applet
echo '#include "WProgram.h"' > applet/Blink.cpp
cat Blink.pde >> applet/Blink.cpp
cat /usr/share/arduino-0017/hardware/cores/arduino/main.cxx >> applet/Blink.cpp
/usr/bin/avr-gcc -mmcu=atmega168 -I. -gstabs -DF_CPU=16000000 -I/usr/share/arduino-0017/hardware/cores/arduino -Os -Wall -Wstrict-prototypes -std=gnu99  -o applet/Blink.elf applet/Blink.cpp -L. applet/core.a -L/usr/avr/lib -lm
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-std=gnu99" is valid for C/ObjC but not for C++
/usr/bin/avr-objcopy -O ihex -R .eeprom applet/Blink.elf applet/Blink.hex


   text    data     bss     dec     hex filename
      0    1244       0    1244     4dc applet/Blink.hex

running make upload as root, right after pressing the reset button in the board, successfully uploads the program. Blinkies!

Cleanup

A few small changes will make a lot of this easier. First, I want to make sure that the USB device is writable by a non-root user, using udev. First, I used the following command to get the udev identifying information for the device.

udevadm info --attribute-walk -n /dev/ttyUSB0

The identifiers for the device are given from most-specific to least-specific. The device itself doesn't have much to identify it:

  looking at device '/class/tty/ttyUSB0':
    KERNEL=="ttyUSB0"
    SUBSYSTEM=="tty"
    DRIVER==""

but I need something to match on this device, so I used SUBSYSTEM=="tty". To avoid confusion with other tty devices, though, I needed something more specific. Looking at the parent entry, I see

    ATTRS{interface}=="FT232R USB UART"

which looks like a good identifier for this component. Aside from setting the ownership and permissions, I decided to add a /dev/avr symlink, too. The completed rule is:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001" GROUP="users", MODE="0666", SYMLINK+="avr"

The first three fields match the device using the numbers from lsusb, and the last three set the proper group-id, mode, and dev-tree symlink for the device. I put this rule in /etc/udev/rules.d/10-user.rules and updated udev:

udevadm trigger

sure enough, /dev/avr now exists. I added this path as the PORT in the Makefile.

The second problem is that the makefile is not smart enough to reset the unit before uploading. That's easily fixed, using a variant of the pulse script from above, by adding a perl invocation to the Makefile (don't forget the whitespace must be a tab character!):

Finally, I commented out the value of CDEBUG in the Makefile, as I don't see any real utility for debug symbols on a microcontroller.

Summary

This turned out to be a lot of work -- the Arudino developers have done a good job of encapsulating a lot of complexity in a nice, easy-to-use IDE. But now I can use my usual editor and workflow to develop programs for the ATMEGA328P, and that means a lot to me!