Screen working...finally

[dawnmist]

I received my Teensy 3.0 controllers in the mail last week, so I could finally start on version 2 of my programmable right-hand gaming keypad (designed to sit under my right hand because my mouse is on the left - my right shoulder doesn't tolerate mouse movements). I got the real time clock working, then the sd card...but for the life of me I simply couldn't get the Tft screen to work.

I was using the UTFT library for arduino by Henning Karlsen, and the tft was specified as using the Himax HX8347-A controller. Given the UTFT library was written for AVR and the Teensy 3 has an ARM chip, I went through the library and adjusted datatypes (e.g. Paul Stoffregen had warned on the Teensy 3 kickstarter that shift operations on datatypes of different sizes could produce different results to those on AVR) to try to prevent any odd results from the change from 8-bit AVR to 32-bit ARM. I completely hacked the pin read/write routines when it still wasn't working, replacing the arduino register/bitmask usage with Teensy's digitalWriteFast(). When it still wouldn't work, I added Serial.print() monitoring for EVERY pin value change so I could trace exactly what was being sent to the tft screen, pulled out a logic probe and checked that the values at the connectors matched, tried plugging in the second screen in case one was faulty...still no display.

Then I sat down with the Himax datasheet and stepped through the entire init sequence, adjusting delays between commands to match the reference implementation (on the basis that ARM is faster than AVR so it may have been a timing issue - though the Serial.print debugging should have addressed that anyway). There were 2 init commands in the library where the value set was different to the reference implementation - I tried adjusting them to the reference but the display still would not turn on (so I set them back to the library's values). All I was trying to do was set the whole screen blue with a red box on it - something that was visible and distinct, but it just wouldn't work. At that point, I decided that I either needed to get an actual register command listing for the HX8437-A controller so I could inspect exactly what the init commands were doing...or give up and replace the screens. I could understand if one was faulty...but 2? That was not happy-making.

Then this morning I finally tripped over this blog post: http://mbed.org/cookbook/TFT-LCD-with-HX8347
In particular, the comment by Mathew

"looks like this library is actually for the SSD1289, judging by the init code. Luckily my LCD is an SSD1289. Funny thing is that the eBay auction I got it from claimed it to be a HX8347."

If that was the case...maybe the reason the screen wouldn't respond to the HX8347 init code was because it wasn't actually an HX8347 chip...

So I tried changing the chip type in the initialization of UTFT to SSD1289...and BINGO! First try - screen turned on, blue background was drawn, and (very slowly due to the debugging statements) the red box was drawn on top. So I took out the debug statements, and screen draw dropped to milliseconds instead of 5-8 seconds...

All that frustration/hair tearing out was due to an incorrect specification of the controller on the tft. Just in case someone else comes across it, if you bought a 3.2" tft from ebay claiming to use the HX8347-A controller and it just won't work, try treating it as the SSD1289 controller instead - it seems that some ebay sellers have been listing their tfts as having the wrong controller chip!