I was interested to see if this kind of display technology would be of any use for the "Occam's Dirk" rig, when packaged up for mobile applications.
It was the overall size of the 20*4 alphanumeric display I had used before that was tempting me to consider an alternative - not the sense that I needed to display any more information - quite the opposite, in fact. This diminutive unit seems just the thing.
Unfortunately, there were two obvious disadvantages to confront - and one surprise! We'll deal with the obvious disadvantages first...
The old alpha LCD unit interfaced to the Arduino via I2C, which has no "cost" on the pin allocation, since the I2C interface is already used (in the Occam's Dirk rig) to talk to the Si5351 RF generator. Switching to the new Nokia LCD requires four or five pins - PROBLEM!
What's more, the little Nokia display talks in 3v3 logic language, whereas the Arduino UNO is running with 5V logic, so interface requires a level converter on these four or five pins. Not exactly a problem, but at least an inconvenience.
Some people use the 4050 as a level converter - but I decided to press into service one of my Octuple level converter plug-in modules to experiment with the screen.
I looked around on the internet and soon found the Adafruit Nokia library, which calls upon Adafruit's GFX graphics library (with which I was already familiar after having played with a color TFT screen).
I played around with the screen under the "pcdtest" example which Adafruit supply with the library and verified that all was working FB.
Unfortunately, when I tried to include the libraries with the Occam's Dirk program, the resulting code was too large to load onto the little microcontroller, so I decided to abandon the easy library approach and tried instead to use a bit-banging solution, borrowing from code found at Sparkfun and on the Arduino site.
After a while, I had the code ported to the new smaller display format and working well...
The display is fast compared to the ponderous old 'Hitachi' LCD device on the far side of the I2C-to-parallel module that piggybacks on the LCD.
Unfortunately, there was cost in porting the code - I had to lose the automated CQ calls in order to generate enough memory space to fit everything in. Still - this is a luxury I can do without.
The test set-up for development (on a breadboard) is seen here...
I did the coded development on a spare UNO and just had a tuning plug-in connected (so I could drive the user interface).
Once ported over to the Occam's Dirk rig itself, the whole system is now pretty small - ready to be packaged in a small "trail-friendly" enclosure...
For reference (mine as much as yours!) here's the allocation of the I/O resources on the Occam's Dirk rig, with the new Nokia display...
0 | (Comms) |
1 | (Comms) |
2 | RotEncoder |
3 | RotEncoder |
4 | leftButton |
5 | rightButton |
6 | ditPin |
7 | dahPin |
8 | str8Pin |
9 | sideTonePin |
10 | RxMute |
11 | SCLK (Display) |
12 | SDIN (Display) |
13 | TxKey |
A0 | RESET (Display) |
A1 | DC (Display) |
A2 | SCE (Display) |
A3 | RotEncSwPin |
A4 | I2C |
A5 | I2C |
I ran the display successfully with its reset line connected (via level conversion) to the Arduino reset but, since I had already been forced to abandon the automated CQ calls in software, I decided I may as well use the I/O line that was assigned to the switch that used to trigger them for an explicit software-controlled reset function for the display. If ever I reinstate the automated calls (or need an I/O line for another purpose) I can go back to the hardware reset.
Once I have had opportunity to tidy up the code (and if there is any interest) I might be persuaded to release a copy of this new version of the software. Certainly, my initial impression is that the cost of the pin-count congestion and the code congestion might even be worth it - the display looks and responds very nicely.
...-.- de m0xpd