An Arduino Yún and an ATM12864D Display

In the beginning of the year I received an Arduino Yún from good friends as a birthday gift. Fitted with both an Atmel Atmega32u4 as well as a small Linux module running some spin of OpenWRT. I'm not sure what it's final use will be, or if it will move from project to project as an intermediary solution until I get boards fabbed for the real deal. After all that is part of what the selling point of the Arduino platform is. I'm crunching down basic C on the AVR though, ditching the Arduino software/firmware platform, I can not stand it. I want to be able to flip bits on the metal. And somebody will say "oh, C, he uses a high-level language…" and another will chime in with "oh, digital electronics…" and so on. Everybody has their level of comfort. In the microcontroller world mine is C, and occasionally ASM.

Years ago I bought a graphical LCD display, way before oleds and whatnot were starting to become common in the hobbyist crowd. 128x64 pixels, monochrome white foreground on blue background. KS0107+KS0108 drivers. I never got it to work very good, I—with relative little experience at the time—were bound to bodge the connection of at least some of the 20 pins it needed power and signals on. Or get the timing wrong. Or both. Then there was the fact that not many of my few projects actually needed or could take advantage of a graphical display. A button and/or a RS232 connection to a computer usually were enough.

Now with the Arduino+Linux module, and for that matter, more experience, what if I tried to tackle the display again? I set out with the goal of reading the serial output from the Linux module and pushing it onto the LCD, effectively making the AVR+LCD a serial console for the Linux module.
After a very brief search it seemed that the Arduino was not made with writing a whole byte to a range of pins in paralell (like PORTD=0x2a) in mind, and at that time I decided that enough is enough, and purged the Arduino stack and switched to C. When writing this post I did some searching again, and of course it seems to be the case that one can use e.g. PORTD=0x2a in the Arduino stack. Oh well, switching to C is something I wanted to do in the first place, so it does not really matter.

Then came the second and third setback, the Arduino headers I wanted to use do not map to consecutive bits of the various AVR ports, mitigating the benefit of being able to write a byte to a port in one go. And for that matter, some of the pins I wanted to use were tied up in special nets connecting the AVR to the Linux module. This is the reason I dead-bugged the 74LS164 shift register in the previous post.

It's so pretty! And neat! Hm, actually, for a random wiring job I think it's not that bad…

The datasheet of the display (ATM12864D) is pretty helpful, apart from one single point that had me quite confused. The pinout lists a D/I signal, and the longer description had me believe that it was an internal signal (e.g. between the KS0107-KS0108 chips or whatever) that for some reason was routed to the external interface as well. The command table on the other hand, lists an RS signal, absent from the pinout, and used to differentiate between display pixel data, and instructions (hmm… D/I…). I've seen no comment about this elsewhere on the net, so in the case anyone is as confused as I was, and happens to stumble upon this post I'll state it explicitly: For this particular display, the RS signal listed in the command table is the D/I signal listed in the pinout.

Pair programming, now it's the cat's turn at the keyboard.
I also have the chance of getting my projects ESD tested. For free.

After a while of still not getting any consistent behaviour from the display notice that I have soldered the data bus cable the wrong way. After a while of putting off having to resolder the cable, by mirroring every byte written, in software, the thought strikes me. Hey! I can clock out the data to the 164 LSB first instead of MSB first!

It seems that the stereotypes are true…

Now with the ability to get arbitrary grahics data to the display I notice that a column is dead, constant off, unless I hold a finger on the unpopulated C12/13 pads on the back of the display, in which case it turns constant on.
Very irritating, but if I tailor the font routine and offsets etc. I can make so it is at the part of the text matrix that is the space between letters and always off.

After a while of fiddling around with trying to find out the correct baud rate for communicating with the Linux module (it's 250k by the way) I figured that maybe the display updating routine was too slow to run each time a byte is received, and moved reception to an interrupt routine, left updating the display to the main loop. Success!

Boot messages!