Graphic LCDs for Data Bus

Graphic LCDs are excellent debugging tools. Digole offers an I2C adapter with Arduino library that I've ported to mbed.

128x64 Graphic LCD on Data Bus displays GPS, battery, etc.

The 128x64 module I used on Data Bus was indispensable last year. It graphically displays battery voltage, GPS fix quality, and also displays IR ranger information. No ground station required.

With limited serial ports and a desire for XBee (or something) wireless, I wanted to run the LCD off the I2C bus. Digole's universal backpack supports serial, I2C, and SPI, selectable with a solder jumper. The solution is fully-wrought with good documentation and Arduino demo and library code.

My Digole backpack on a giant LCD

After responsive customer support helped me fix a manufacturing defect on my own (wrong resistor installed in a voltage divider), I2C worked. For the time being I wrote the mbed library to speak only I2C. It uses Arduino print routines.

The backpack supports common graphic LCDs. Digole also sells OLED backpacks that use the same library. Since the LCDs I have are so heavy I may switch to an OLED instead.

While experimenting, I found something odd. When I held the backpack and LCD just so, it would operate stably, when I didn't I'd see junk characters or other misbehavior. Apparently my thumb was acting as a pull up resistor for a pin pad marked NC. A 10k resistor replaced my thumb with the same effect.

If this is a KS0108-driven LCD (the eBay seller didn't specify), the NC pin would correspond to Chip Select 2 (CS2). Perhaps the backpack simply shouldn't be configured for KS0108. I'll edit this if I find out more later but for now it works reliably and I can get busy porting Data Bus code to use the new LCD.

Data Bus Software Design

To that end, I am working to decouple display details from the main code, an inevitable side effect of scrambling to get a robot done for a competition.

Main routines should not know how to draw boxes and bar graphs, locate cursors and print data. Nor should it care whether the output device is a Digole or Sparkfun backpack, or even if it's a 128x64 Graphic or 16x2 text display.

I'm shooting for a more flexible solution that supports any number of output devices interchangeably. By the same token, I also want the same kind of flexibility for sensors and input. Why?

My dream is to make a hackable, flexible autopilot software and hardware for other hobbyists. I don't want hardware lock-in like I see in some 3d autopilot solutions; I want hackability and flexibility. Run whatever sensors, outputs and ground stations you want and reuse or write code modules accordingly.