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!

Comments

How many and which PINs free?

[wittich]

Hi,

the teensy could be a Solution for my project. How many and which PINs are free after connecting the Display and the SD card reader?

Re: How many and which PINs free?

[dawnmist]

For these displays, you need to use the underside pads on the teensy to be able to have enough pins - some of the screen data lines use the underside pads.

There's 16 data lines (digital) + 5 control lines for the screen (also digital - and a 6th line that is connected to 3.3V to keep the screen in write mode), and 4 lines for the SD card. If you want to use the touch, there's either another 2 lines if you can get the SPI to share between the SD and the touch interface (I couldn't with the version of SDFat I was using), or 5 lines to talk to the touch.

That means you'll have up to 30 digital lines in use for the screen, SD and touch. 25 if you're not using the touch, and 27 if you manage to get touch and SDCard sharing the SPI port properly.

There's 34 digital input/outputs in total, so that leaves you with 4 available if you're using the touch as well on separate pins. There's also 4 analogue input ports and 1 analogue input/output port (which has a DAC to generate a "true" analogue signal) free to use.

If that's not going to be enough free, you can get alternative screens that don't need the 16 data lines. I think Adafruit have one that uses 8 data lines instead (plus a few control lines), and there are some screens that use SPI to communicate to them too.

For the 16-data-line screen using the UTFT library, the required pins are the first 8 pins of Port D, and 2 sections of 4 pins from Port B (documented at: http://forum.pjrc.com/threads/18002-Teensy-3-0-driving-an-SSD1289-with-utft?p=34719&viewfull=1#post34719 and http://www.dawnmist.net/teensy/HW_Teensy3.h - note that there is no longer any need to patch the UTFT library as the Port B/D variant has become an official part of the library).
* Port D (0-7) = DB_8=2, DB_9=14, DB_10=7, DB_11=8, DB_12=6, DB_13=20, DB_14=21, DB_15=5
* Port B (0-3,16-19) = DB_0=16, DB_1=17, DB_2=19, DB_3=18, DB_4=0, DB_5=1, DB_6=32, DB_7=25

If you want to be able to adjust the brightness, LED_BL needs to be connected to a PWM pin (I used pin 9). In the end, I found I just wanted it to be full brightness though, so it didn't really matter that much.

The SD card needs to use SD_DOUT(MISO)=12, SD_CLOCK=13, SD_DIN(MOSI)=11 if using the Teensy's native spi port. These would be the pins that would be shared with the Touch interface *if* you can get SPI sharing working properly (I think the SD library - as opposed to the SDFat library - has been adjusted so that it may work with SPI sharing now). The SD_CS (chip select) pin can be any of the other digital pins - I used pin 10 (which was the default CS0 for the SPI port).

The other pins are all free to make your own choice with.

Pin diagrams: http://www.pjrc.com/teensy/pinout.html

Good luck, and I hope you have fun with your project. :-)

Re: How many and which PINs free?

[wittich]

Hi,

thank you very much for this really all-encompassing informations!!!

With your informations I can work on my project. Thank you((-: