Update

The fun didn't last long. After 3 months in operation, the display began to show signs of degradation and developed zebra bar contact issues shortly after. Instead of obtaining a new Nokia compatible display, I just ported the software to my ILI9163 driver and the replacement looks and works way better. See the video below for HWMonitor2.

Introduction

This is my very first project using AVR microcontrollers. I recently got a batch of Arduino Pro Mini clones (ATMega328p) in my mailbox and started hacking on them. As expected, I encountered some beginner's issues and thought about sharing my experience in the hope that I might offer some useful hints for others who would like to start experimenting with these highly popular devices.

The first roadblock I encountered was the programmer. I more or less inherited a USBProg V3, which I didn't get to work on Windows within an hour or so. It was suggested here and there that libusb might be of help, yet the combination of 64 Bit Windows 10 and the USBProg was rather tricky. Hence, I switched over to my Macbook and downloaded the AVR toolchain from [1]. The avrdude in that package worked at once and I never looked back.

I chose an LCD display for my Windows machine's system health as the target for my first project. Since I had an old Nokia 6110 display lying around for years, that one had to serve as the first victim. This type of GLCD has been used in numerous models of old Nokia phones, including the 3310, 5110 and 6110. In addition, the LCD itself can still be bought via EBay on a customized PCB.

LCD Preparation

: Pin numbering on Nokia PCB (click enlarge)

: Connecting the 6110 LCD to the Atmega328p (click enlarge)

: First test, PCB still uncut

The pinout of the LCD and it's variants is nicely explained in [2]. In my case, when looking on the PCB in its upright position, Pin 1 is the rightmost one (see image, click for enlargement). I chose to keep the original PCB and solder the cables through the holes at the bottom of the connector area. Some holes were covered with lacquer so that I had to dremel them open with a 0.3mm drill.

In the process I also swapped the original green LEDs for UV type LEDs. Sadly, the UV component doesn't pass the LCD assembly but I like blue more than green anyway. The LEDs are connected in parallel, so I just needed to add one more pair of wires which also went from back to front through existing holes in the PCB.

Concering the wiring, I connected the display to the ATMega Port B pins in order to keep the option of hardware SPI. It depends on the ATMega model, which pins correspond to hardware SPI. The ATMega 328p I used has it's MOSI/MISO/SCK pins at PB3/PB4/PB5 (same as ATMega8, for example). A pin configuration for Type 1 displays can be found at [3].

The display runs with 2.7...3.4V while my ATMega came with a 16 MHz crystal and 5V VCC. To avoid damaging the PCD8544 controller on the display, I placed 6.7k/10k voltage dividers between the ATMega and the LCD. Other people suggested that a 10k resistor between the ATMega and the PCD8544 should also be sufficient for the task.

The pins of the LCD and the chosen connection to the other components are as follows:

1. VCC 3V
2. SCLK (clock input) - PB5 (SCLK)
3. SI (serial input) - PB3 (MOSI)
4. D/C (data/command) - PB0
5. /CS (chip select) - PB1
6. Osc - VCC 3V
7. GND - GND
8. Vout - 100nF - GND
9. /RES - PB4 (MISO)

It must be noted that the connection of the LCD reset pin to the MISO pin of the ATMega has one drawback in conjunction with hardware SPI mode. According to the Atmel documentation, the pin must be set as input for hardware SPI to work. Hence, the LCD reset must be done (once) before enabling hardware SPI.

The LCD and it's LEDs are powered by a common LM317 voltage regulator. For the first tests, I just hooked up a common CR2032 battery.

Software on ATMega

As this type of display has been very popular, quite a number of driver implementations are available as opensource. I've chosen the C++ software stack from [4] as a starting point. It's just a few files with easily customizable initialization and comes directly with a ready-to-use demo. That was exactly what I needed as starting point to verify that I had soldered the display properly.

As I have opted for the commandline based toolchain, I have written an appropriate makefile for the GNU toolchain including flashing via avrdude (make flash). The settings in the makefile concerning the programmer, chip type and clock frequency need to be adapted to the respective chip/board.

Despite a lot of modifications, the display library is still initialized with a single call to it's init method using the pin assignments as arguments. I've written new (and faster) methods for image drawing that allow to specify the image size and destination location.

The ATMega program communicates with the host computer over RS232. Since I did not find a MAX232 in my box that day, I've soldered myself a simple transistor-based inverter [5]. The system health on LCD protocol is quite simple, yet flexible. The display is logically divided into two columns and 6 rows (row height 8). The configuration string is prefixed by the letter @, followed by the specification of the desired column types. Uppercase letters denote double-column entries (such as text over the whole width), lowercase letters denote single-column entries. Any command is delimited by \r. After configuration, the LCD displays the column headers. Updates to the columns (in the same order as the configuration request) are prefixed by A,B,C,... at the beginning of a line, followed by ASCII text to be displayed at the desired position, delimited again by \r.

As any re-configuration of the display layout can be done at runtime without reprogramming the ATMega (if necessary, directly by hand in a serial terminal), the current level of flexibility suits my needs (so far).

Host Software

I've put a simple single-file image converter in the software package that takes NetPBM images as input and writes an appropriate header file to use for the Nokia display. Images larger than 84x48 pixels are cropped to the maximum size. For grey-level and RGB images, thresholding at level 128 is applied implicitly. To get PNM/PGM or PBM images, software like GIMP or the commandline ImageMagick are viable candidates among other options.

The PC host software for communication over RS232 is written in Powershell. It queries WMI, specifically the information provided by OpenHardwareMonitor [6]. After gathering the sensor data, the array hwstrings is traversed to locate the sensor data with the respective id. The command code letter is prefixed and the data is then sent via UART. It should be fairly easy to rewrite the script for bash/perl/python if the display is to be used with *nix host operating systems.