2.8" TFT touchscreen + Teensy 3.0

Not open for further replies.


Well-known member
Hello again everybody,

I have been trying to connect my Teensy 3.0 with a 2.8" TFT touchscreen from Adafruit.
The easiest to work out was how to connect the backlight, power and ground (using a separate 3.3v supply).
After that I have been able to connect the touch-sensitive part of the screen as well, and it reads x+, x-, Y+ and y- fairly well using Touch-Screen-Library (I still have to some more calibration though).

I have been running into problems when I wanted to actually display something on the screen using TFT LCD library (and the GFX library)...
Board type unsupported / not recognized

I have made a modification to the original library, so that Teensy 3 will be identified as an Arduino Uno.
I chose this id because in a post by Mr. Stoffregen I read:
'Teensy 3.0 has some AVR emulation code for PORTB, PORTD and PORTC to map bit operations to direct manipulation of the Freescale port registers. The register to pin mapping attempts to emulate Arduino Uno.'

So I changed line 50 in \libraries\TFTLCD\pin_magic.h from:
#if defined(__AVR_ATmega168__) || defined(__AVR_ATmega328P__) || defined (__AVR_ATmega328__) || defined(__AVR_ATmega8__)
#if defined(__AVR_ATmega168__) || defined(__AVR_ATmega328P__) || defined (__AVR_ATmega328__) || defined(__AVR_ATmega8__) || defined(__MK20DX128__)

Unfortunately (for me) this is not a full fix, I am still getting errors but now of a different kind.
The following is just a small portion of it, there is about 150 lines of the same errorcode.
D:\arduino-1.0.3-beta\libraries\TFTLCD\Adafruit_TFTLCD.cpp: In member function 'void Adafruit_TFTLCD::reset()':
D:\arduino-1.0.3-beta\libraries\TFTLCD\Adafruit_TFTLCD.cpp:321:3: error: no match for 'operator&' in 'PORTD & 3'
D:\arduino-1.0.3-beta\libraries\TFTLCD\Adafruit_TFTLCD.cpp:321:3: error: no match for 'operator&' in 'PORTB & 252'
D:\arduino-1.0.3-beta\libraries\TFTLCD\Adafruit_TFTLCD.cpp: In member function 'void Adafruit_TFTLCD::flood(uint16_t, uint32_t)':
D:\arduino-1.0.3-beta\libraries\TFTLCD\Adafruit_TFTLCD.cpp:418:25: error: no match for 'operator&' in 'PORTD & 3'
D:\arduino-1.0.3-beta\libraries\TFTLCD\Adafruit_TFTLCD.cpp:418:25: error: no match for 'operator&' in 'PORTB & 252'

Now this is where I am in waaaay over my head, and I'm afraid that I don't know how to fix this.
I know a bit about coding/programming, but this goes a few levels deeper than what I am used to.
For what it's worth, I am not expecting anybody to jump in and do everything for me, but I am looking for any pointers/advice on how to tackle this problem.

Also, has anybody actually tried to connect these before on a T3?

Additional information:
when I first started with this screen a few days ago, I opened a topic about this issue at Adafruit forum:

The connections for the touchscreen to the teensy I followed from pin_magic.h but I doubt wrong wiring will solve a coding problem:
// LCD Data Bit :   7   6   5   4   3   2   1   0

// Uno dig. pin :   7   6   5   4   3   2   9   8
RD- -> Analog5
WR- -> Analog6
CD -> Analog7
CS -> Analog8
RST -> Analog9

Y- -> Digital14 (which doubles as Analog0)
X- -> Analog1
X+ -> Digital17 (which doubles as Analog3)
Y+ -> Analog2
Try this. Please let me know if it works?

It might be too slow...... but a first step is getting anything to work at all.

#elif defined(__MK20DX128__)
  // Experimental definitions for Teensy 3.0
  #define write8inline(d) { \
    digitalWriteFast(8, (d) & 0x01); \
    digitalWriteFast(9, (d) & 0x02); \
    digitalWriteFast(2, (d) & 0x04); \
    digitalWriteFast(3, (d) & 0x08); \
    digitalWriteFast(4, (d) & 0x10); \
    digitalWriteFast(5, (d) & 0x20); \
    digitalWriteFast(6, (d) & 0x40); \
    digitalWriteFast(7, (d) & 0x80); \
    WR_STROBE; }
  #define read8inline() ( \
    RD_STROBE, (digitalReadFast(8)<<0) \
    | (digitalReadFast(9)<<0) \
    | (digitalReadFast(2)<<0) \
    | (digitalReadFast(3)<<0) \
    | (digitalReadFast(4)<<0) \
    | (digitalReadFast(5)<<0) \
    | (digitalReadFast(6)<<0) \
    | (digitalReadFast(7)<<0))
  #define setWriteDirInline() { \
    pinMode(8, OUTPUT); \
    pinMode(9, OUTPUT); \
    pinMode(2, OUTPUT); \
    pinMode(3, OUTPUT); \
    pinMode(4, OUTPUT); \
    pinMode(5, OUTPUT); \
    pinMode(6, OUTPUT); \
    pinMode(7, OUTPUT); }
  #define setReadDirInline() { \
    pinMode(8, INPUT); \
    pinMode(9, INPUT); \
    pinMode(2, INPUT); \
    pinMode(3, INPUT); \
    pinMode(4, INPUT); \
    pinMode(5, INPUT); \
    pinMode(6, INPUT); \
    pinMode(7, INPUT); }
  #define RD_PORT PORTC
  #define WR_PORT PORTC
  #define CD_PORT PORTC
  #define CS_PORT PORTC
  #define RD_MASK B00000001
  #define WR_MASK B00000010
  #define CD_MASK B00000100
  #define CS_MASK B00001000
Well, it seems to fix all the compilation problems, so that's definately a good thing :)

After trying to run the example I keep seeing a functioning backlight, but no display on the screen.
The Serial Monitor also stays empty.

Here I changed the example to start with a delay(10000); after initialisation and I now do get feedback from the Serial Monitor:
TFT LCD test
Using Adafruit 2.8" TFT Breakout Board Pinout
Unknown LCD driver chip: 101
If using the Adafruit 2.8" TFT Arduino shield, the line:
should appear in the library header (Adafruit_TFT.h).
If using the breakout board, it should NOT be #defined!
Also if using the breakout, double-check that all wiring
matches the tutorial.

I have changed the line to NOT define the arduino-shield, so I can only come to the conclusion that I have to recheck my connections now.
Once I find out whats wrong I'll be sure to post it here, along with any info on the speeds and such.

Thank you so much for ... well... everything!
I'm not sure if I understand this correctly, it seemed pretty straightforward when I (re)connected everything.
I keep getting the same error as above:
TFT LCD test
Using Adafruit 2.8" TFT Breakout Board Pinout
Unknown LCD driver chip: 101
If using the Adafruit 2.8" TFT Arduino shield, the line:
should appear in the library header (Adafruit_TFT.h).
If using the breakout board, it should NOT be #defined!
Also if using the breakout, double-check that all wiring
matches the tutorial.

According to the tutorial: TFT wiring
In addition to the 8 data lines, you'll also need 4 or 5 control lines.
Connect the third pin CS (Chip Select) to Analog 3
Connect the fourth pin C/D (Command/Data) to Analog 2
Connect the fifth pin WR (Write) to Analog 1
Connect the sixth pin RD (Read) to Analog 0
Connect the seventh pin RST (Reset) to the Arduino Reset line. This will reset the panel when the Arduino is Reset. You can also use a digital pin for the LCD reset but this will save us a pin.

I checked Nick Gammons Uno R3 reference sheet and can only see that Analog 0-3 are not used for any special communications protocol and should be handled as 'default' analog pins.
From this I gather that any analog pin can be used on the Teensy for the TFT control lines.

So far I have used the Analog 5-8 along with digital 23 for reset.
Since this didn't seem to work, I also tried the originally mentioned analog 0-3 with 18 for reset, still no dice.
(to try this I had to disconnect the touchscreens x,y analog connections because I had those on the same pins, will reroute those once the screen works)

At the moment I don't have a multimeter (should be here within a week) so I am unable to test the pins/connections, but there is something I'm wondering about:
Connect the third pin CS (Chip Select) to Analog 3
Should Chip Select on the screen be connected to CS# on the Teensy, or can any analog pin connect to CS on the screen?
(as far as I can tell no use of SPI is made)

On a sidenote:
Something I also noticed was that the reset should be connected to a digital pin according to the tutorial, but the graphicstest example shows it defined as an analog port.
#define LCD_RESET A4 // Can alternately just connect to Arduino's reset pin
I think the tutorial is right and the example incorrect, because on line 308 of Adafruit_TFTLCD.cpp I see:
  digitalWrite(5, LOW);
  digitalWrite(5, HIGH);
  if(_reset) {
    digitalWrite(_reset, LOW);
    digitalWrite(_reset, HIGH);
Can one use A4 as an alias for 18 on the Teensy, and does this also work the other way around, or is this simply a flaw in the example itself ?
After trying some more, I keep coming up with :
Unknown LCD driver chip: 101
I disconnected the control lines, and still get 101 returned as the identifier.

According to the tutorial:
It should be 0x9328 or 0x9325 so if you see something like 0x8328 that means that the D8 pin is not wired correctly and if you get 0x9228 then pin D0 is not wired correctly.
(Even there is no D8 pin on the screen, D0-7)

It seems that the identification hex isn't read properly...

Here I tried to disable/enlarge the 'delayMicroseconds(1);' at line 725/746 of Adafruit_TFTLCD.cpp.
This is where the functions are found that are responsible for reading the id code.
These changes don't have any effect.

Then (just to see what happens) I changed line:
Serial.println(identifier, HEX);
And now I get identifier: 257
And now I get identifier: 257

I was tired when I posted my last post and have since realized that decimal 257 == hex 101, so that was to be expected...

Over the weekend I've had a bit of time to test a little more.
I noticed that if I keep the screen powered down, the lcd chip is identified as 0
If I supply it with power, then I receive id 101, so I know that some data is being read.

To make sure it isn't background noise or anything alike, I tried to connect the CS/CD/WR/RD to different analog connections, but the id doesnt change.

According to the tutorial an id should look like: 0x9328, 0x9325 or 0x7575.
If D0/D8 on the tft are not connected properly, I should get either id 0x8328 or 0x9228.
I know that hex 101 == 0x101, so it seems that im not even close to an id, or an errorcode for that matter.

My next step was to start checking the code that handles the identification of the chip.
at line 734 of Adafruit_TFTLCD.cpp is:
uint16_t Adafruit_TFTLCD::readID(void) {

  uint16_t id;

  WR_STROBE;     // Extra strobe because high, low bytes are the same
  setReadDir();  // Set up LCD data port(s) for READ operations
  id   = read8();       // Do not merge or otherwise simplify
  id <<= 8;             // these lines.  It's an unfortunate
  delayMicroseconds(1); // artifact of the macro substitution
  id  |= read8();       // shenanigans that are going on.
  setWriteDir();  // Restore LCD data port(s) to WRITE configuration

  return id;
First i checked where
id  = read8();
gets its information from, it turns out that read8() is an alias for read8inline().
read8inline() is defined in the code you supplied, and I cannot see anything weird/wrong there.
Just for the sake of testing/trying, I replaced the read8()'s with read8inline()'s, but no change.

I tried disabling/enlarging the delayMicroseconds(), but it doesn't appear to do anything in my case.
Then I tried to disable/change the bitshifts, and this has some effect, the ID finally starts to change.
This is also where I don't follow what happens anymore, and I simply am trying numbers to see if anything works, but not actually understanding what code/signals are flowing through...
I havent been able to bitshift my way to a correct id, but for some reason I do believe that this is where the answer to my problems must lie.

id <<= 16; results in id 1
id <<= 15; = crashes the software
id <<= 14; = crashes the software
id <<= 13; = crashes the software
id <<= 12; = crashes the software
id <<= 11; = id 801
id <<= 10; = id 401
id <<= 8; = id 101 (default value)
id <<= 3; = id 9
id <<= 2; = id 5
id <<= 1; = id 3
id <<= 0; = id 1 (same result as when I disable the entire line)
anything above 16 also results in id 1

This leads me to believe that I do receive a 16bit sized id (or 2x 8bit as it should be)
The LCD-test page in the tutorial has a line at the end, which I think is pointing towards this:
Remember that the two bytes are read one after another.

The first 8 bits are received, but they are placed into an 16bit int.
Then they are shifted 8 .. spaces(?) to the left.
After that the next 8 bits are received and placed behind the first 8 bits, making a 2x8bit, thus 16bit int.

Disabling the second read8(), results in id 100 instead of 101, so there is a response in the first 8bit data.
Disabling the first read8(), results in id 1, not certain what this means yet (default value for 'empty' reading?).

I am still waiting for my multimeter, hoping I can test the connections from the screen.
Other than that I am out of ideas at the moment and probably need to take a break and come back later with a fresh state of mind :)

(disclaimer: this post contains a lot of assumptions, not so much verified facts except the results themselves)
First step is to ensure you pins are assigned correctly. Otherwise there is a risk of the display not being detected.

Adafruit is also selling a shield version of you display and I think you can use this to verify you pin assignment. With this: https://github.com/adafruit/TFTshield/blob/master/schem.png
and this: http://arduino.cc/en/uploads/Main/ArduinoUno_R3_Front.jpg you can figure out how the pin assignment is supposed to work with a shield/UNO. now you need to either replicate or map this to you Teensy.
Hi CheapB, thanks for your reply and trying to push me forward ;)

Well, unless I misunderstand completely (which has been known to happen) the pins are assigned/coded into the code that Paul provided above.

So far I have been following the connections that have been supplied for the Arduino UNO:
 // When using the BREAKOUT BOARD only, use these 8 data lines to the LCD:
// For the Arduino Uno, Duemilanove, Diecimila, etc.:
//   D0 connects to digital pin 8  (Notice these are
//   D1 connects to digital pin 9   NOT in order!)
//   D2 connects to digital pin 2
//   D3 connects to digital pin 3
//   D4 connects to digital pin 4
//   D5 connects to digital pin 5
//   D6 connects to digital pin 6
//   D7 connects to digital pin 7
// For the Arduino Mega, use digital pins 22 through 29
// (on the 2-row header at the end of the board).

Like I said above, I could very well be completely missing the picture here... feel free to be rude, I can take it ;)
I have been reading a bit more about port registers and realized that I probably have been misunderstanding things a bit here.
At the moment I do not have a full understanding of this all, and I definately need to learn more before I can expect to advance with this.
For those who are waiting on me to finish this to see the end-results, I'm sorry, it might take a while.

CheapB, feel free to say 'told you so' ;)
It was actually your links along with an explanation I googled upon which made things a bit clearer for/to me.

Instructable: Arduino is Slow and how to fix it
Arduino users know that the pins are labeled as digital 0-13 and analog 0-5.
The makers behind Arduino used this for simplicity.
The actual ATMega chip’s pins are labeled differently, however.
Each pin has an assigned letter and number.
The numbers range from 0-7.
For example, pins can be A0-A8, B0-B8, and so on.
All of the AVR 8-bit pins are labeled this way.
(added line breaks for readability)
First step is to ensure you pins are assigned correctly.
Armed with a very very very small amount of knowledge about ports and pins I made an attempt to follow your advice.
(still looking for a good ebook/website that explains it 'completely', suggestions are welcome!)

The Arduino Uno pin/port mapping is already supplied in pin_magic.h, in my first post I didnt realize this was important and (stupidly) did not include it in my quote:
// LCD Data Bit :   7   6   5   4   3   2   1   0
[I]// Uno dig. pin :   7   6   5   4   3   2   9   8[/I]
// Uno port/pin : PD7 PD6 PD5 PD4 PD3 PD2 PB1 PB0

Not sure if this is the right way to go, but I checked the T3 schematics and found the same ports but on different pins:
// LCD Data Bit :   7   6   5   4   3   2   1   0
[I]// T3 dig. pin  :   5  21  20   6   8   7  17  16[/I]
// T3 port/pin  : PD7 PD6 PD5 PD4 PD3 PD2 PB1 PB0

Reconnected the wires and made the appropriate changes to pin_magic.h (Paul's code above) to use the updated pins, but id remains 101.

Back to more reading ebooks, websites and pdf-files :)
(so much to learn in just one lifetime...)
lcd-chip is correctly being identified!

With thanks to immortalSpirit for writing up a detailed guide/howto on the subject I have made some changes to the original code (not using Paul's code, the original code was easier to convert for me).

#elif defined(__MK20DX128__)
  // Modified UNO definitions for Teensy 3.0

  #define write8inline(d) { \
   PORTD = (GPIOD_PDOR & B00000000) | ((d) & B11111111); \
  #define read8inline() (RD_STROBE, (GPIOD_PDIR&  B11111111))
  #define setWriteDirInline() { \
    pinMode(2, OUTPUT); \
    pinMode(14, OUTPUT); \
    pinMode(7, OUTPUT); \
    pinMode(8, OUTPUT); \
    pinMode(6, OUTPUT); \
    pinMode(20, OUTPUT); \
    pinMode(21, OUTPUT); \
    pinMode(5, OUTPUT); }
  #define setReadDirInline() { \
    pinMode(2, INPUT); \
    pinMode(14, INPUT); \
    pinMode(7, INPUT); \
    pinMode(8, INPUT); \
    pinMode(6, INPUT); \
    pinMode(20, INPUT); \
    pinMode(21, INPUT); \
    pinMode(5, INPUT); }

  #define write8 write8inline


It shouldn't matter which pins are used for the CS/CD/WR/RW, but here is how I defined them at the moment:
#define LCD_CS A4
#define LCD_CD A3
#define LCD_WR A2
#define LCD_RD A1
#define LCD_RESET A8
I will probably replace these with digital pins soon to free up analog ones, but thats for later.

Running the code now shows:
Using Adafruit 2.8" TFT Breakout Board Pinout
Found ILI9325 LCD driver
Benchmark                Time (microseconds)
Screen fill              1048983
Text                     149582
Lines                    909070
Horiz/Vert Lines         139519
Rectangles (outline)     98750
Rectangles (filled)      3138224
Circles (filled)         1106752
Circles (outline)        395563
Triangles (outline)      288673
Triangles (filled)       1380580
Rounded rects (outline)  195194
Rounded rects (filled)   3678096

I guess this is a good time to thank everyone for thinking along with me and being kind enough not to call me an idiot straight away (I know can be)!
I'm far from done, but I'm very happy that I finally got an correct identification.
Off to test some more :p
Last edited:
So far I can run the graphictest and tftbmp example and they show statistics about loading time/image information, but the screen stays blank.

When I run the tftbmp example, a bmp file is loaded from the SD card (succesfully) and drawn onto the display (unsuccesfully).
Found ILI9325 LCD driver
Initializing SD card...OK!

Loading image 'woof.bmp'
File size: 230456
Image Offset: 54
Header size: 40
Bit Depth: 24
Image size: 240x320
Loaded in 28303 ms

Loading image 'miniwoof.bmp'
File size: 57654
Image Offset: 54
Header size: 40
Bit Depth: 24
Image size: 120x160
Loaded in 9810 ms

Loading image 'miniwoof.bmp'
File size: 57654
Image Offset: 54
Header size: 40
Bit Depth: 24
Image size: 120x160
Loaded in 9809 ms
I did not update the library to the SdFat beta yet, so faster read speads are possible!

At the moment the image is drawn to the screen, I do see a quick flicker on the screen, but nothing is being displayed.
Last edited:
Its Alive.... ALIVE!!!


just got it working with the following code (I was very close to giving up for the time being):
#elif defined(__MK20DX128__)
// My mix of original Uno code, Paul Stoffregen's code and a cenversion to GPIO pin/port mapping, id checks out, no display on screen
// LCD Data Bit :   7   6   5   4   3   2   1   0
// T3 dig. pin  :   5  21  20   6   8   7  14   2
// T3 port/pin  : PD7 PD6 PD5 PD4 PD3 PD2 PD1 PD0

  // GPIO conversion thanks to immortalSpirit!
  #define write8inline(d) { GPIOD_PDOR = (d); WR_STROBE; }
  #define read8inline() (RD_STROBE, GPIOD_PDIR)

  // does not work, results in incorrect identification
//  #define setWriteDirInline() GPIOD_PDDR  = 0xff
//  #define setReadDirInline() GPIOD_PDDR  = 0

  // does not work, results in incorrect identification
//  #define setWriteDirInline() {GPIOD_PDDR|= B11111111;}
//  #define setReadDirInline() {GPIOD_PDDR &=~B11111111;}

  // does work, thank you Paul!
  #define setWriteDirInline() { \
    pinMode(2, OUTPUT); \
    pinMode(14, OUTPUT); \
    pinMode(7, OUTPUT); \
    pinMode(8, OUTPUT); \
    pinMode(6, OUTPUT); \
    pinMode(20, OUTPUT); \
    pinMode(21, OUTPUT); \
    pinMode(5, OUTPUT); }
  #define setReadDirInline() { \
    pinMode(2, INPUT); \
    pinMode(14, INPUT); \
    pinMode(7, INPUT); \
    pinMode(8, INPUT); \
    pinMode(6, INPUT); \
    pinMode(20, INPUT); \
    pinMode(21, INPUT); \
    pinMode(5, INPUT); }

	// MEGA macro's !!!
  #define write8            write8inline
  #define read8             read8inline
  #define setWriteDir       setWriteDirInline
  #define setReadDir        setReadDirInline
  #define writeRegister8    writeRegister8inline
  #define writeRegister16   writeRegister16inline
  #define writeRegisterPair writeRegisterPairInline  

Working TFT.jpg
(the screen was just rotating the orientation and drawing new text, so it looks a bit weird)

If there is a need for it, I'm willing to do a writeup on how to get it working, how I connected everything, and what else might be involved.
Don't think my posts above are readable while connecting and such, but on the other hand, the first few lines in the code shows how the connections made

CheapB, Paul, immortalSpirit, thank you so much for your help... without you all I wouldn't have gotten this far...
Um... Paul (can I say Paul?)... I hate to ask this of you, but would you mind taking a look at the code whenever you feel like it...

I will not send this code to Ada unless you say its ready...
If you prefer to do this yourself that is fine with me too, as far as I'm concerned you can have all the credits :)
Two days ago I connected the touch pins (X- X+ Y- and Y+) and tested the TFTPaint example which works like a charm.

I should receive a stylus in the mail within a few days, so I have been using the backside of a ballpoint pen.
This makes the text look a bit uncrisp (is that a word?), but still very readable:
Touchscreen fully activated.jpg

As far as I can tell everything is running at high speed, I do not notice any delays during writing/drawing to screen and reading from the touchsensitive pins

Something I noticed concerning screen rotation and touch sensitivity is that if you rotate the display orientation, the touch sensitive parts DO NOT rotate along.

In case anybody else needs it, below you can find the code I used to remap the X and Y coordinates of the touchscreen to the same orientation/dimensions of the display itself:
  int rotation = 3; // set rotation variable to 3
  int touchx;                 // create variable touchx for remapping
  int touchy;                 // create variable touchy for remapping
  #define TS_MINX 150   
  #define TS_MINY 120   // these values are taken directly from the TFTPaint example
  #define TS_MAXX 920  // without changing these values the coordinates of touch and screen are corresponding
  #define TS_MAXY 940  // if these numbers change, screen coordinates will not equal touch coordinates

  tft.setRotation(rotation); // set display to variable rotation

  Point p = ts.getPoint(); // set p to x/y coordinates
  touchx = map(p.y, TS_MINY, TS_MAXY, 0, tft.width()); // remap Y coordinates to X coordinates relative to the screen width
  touchy = map(p.x, TS_MINX, TS_MAXX, tft.height(), 0); // remap X coordinates to Y coordinates relative to the screen height
Hey this is excellent!
I just got my teensy3 displaying the graphicstest on my LCD. Your description here of how to do it was just fine, though it took me a couple of tries to get the wiring right (my fault, though)
I haven't done the touch part yet, that's tomorrow. But you've saved me days (at least) of messing about here.
Great to hear that my postings haven't been useless and helped you get the screen to work!
(It took me about 3 weeks until I got something displayed on the screen)

I have to say that I wouldnt have gotten the screen to work, without assistance from immortalSpirit, CheapB and PaulStoffregen!

Once I had the screen running, touch sensitivity was quite straightforward, all I had to modify for it was to match the sense with the rotation of the screens output.
I am using "rotation = 3;" permanently, the remapping code can be found 2 posts above this one.
It should also be relatively easy now to change this remapping code to different rotation layouts.

Thanks for leaving these messages, definately another reason to continue sharing my work/knowledge :cool:
Yes, touch was quite simple, I got it working yesterday. I modified the pins a little to consolidate things and leave me some spare analog pins so my pins are on:
#define YM 4   // can be a digital pin
#define XM A5  // must be an analog pin, use "An" notation!
#define YP A9  // must be an analog pin, use "An" notation!
#define XP 3   // can be a digital pin

#define LCD_CS A9 // Chip Select goes to Analog 9
#define LCD_CD A5 // Command/Data goes to Analog 5
#define LCD_WR A2 // LCD Write goes to Analog 2
#define LCD_RD A1 // LCD Read goes to Analog 1
#define LCD_RESET A8 // this can move to the reset pin but this is more breadboard friendly
I did actually verify the reset pin behaviour and it s fine on the reset pin.
And this all works. including with the SD card.
Again, great to hear it works for you with minimal modifications!

Testing the reset connection was still on my to-do list, however my to-do list has become quite large and some things just got postponed indefinately ;)
I will be moving the lcd_reset pin to the Teensy reset pin soon, now that I know it works as expected.

I got this going as well thanks to your guidance. While I was fiddling with the pinouts etc. in pinmagic, I did a couple of other things, in Adafruit_TFTLCD:
// Color definitions
#define TFTLCD_BLACK 0x0000
#define TFTLCD_BLUE 0x001F
#define TFTLCD_RED 0xF800
#define TFTLCD_GREEN 0x07E0
#define TFTLCD_CYAN 0x07FF
#define TFTLCD_ORANGE 0xFC80
#define TFTLCD_PURPLE 0x781F
#define TFTLCD_SIENNA 0xF811
#define TFTLCD_EMERALD 0x05E5
#define TFTLCD_BLUE3 0x03FF
#define TFTLCD_ROYALBLUE 0x3333
#define TFTLCD_BROWN2 0x8888
#define TFTLCD_BROWN1 0x7083
#define TFTLCD_OLIVE 0x6BC3
so that the color names don't have to be copied into each sketch and in Adafruit_GFX.h I added 3 lines to support a syntax I like:

void setTextWrap(boolean w);
inline Adafruit_GFX& operator() (uint8_t x, uint8_t y) {setCursor(x,y); return *this;} //use along w Streaming.h to support: tft(col,line)<<"a="<<a;
inline Adafruit_GFX& operator() (uint8_t x, uint8_t y,uint16_t c) {setCursor(x,y); setTextColor(c); return *this;} //use along w Streaming.h to support: tft(col,line,color)<<"a="<<a;
inline Adafruit_GFX& operator() (uint8_t x, uint8_t y,uint16_t c,uint8_t s) {setCursor(x,y); setTextColor(c); setTextSize(s); return *this;} //use along w Streaming.h to support: tft(col,line,color,size)<<"a="<<a;

int16_t height(void);
I also created a keywords.txt file:
# Syntax Coloring Map For LiquidCrystal

# Datatypes (KEYWORD1)


# Methods and Functions (KEYWORD2)

drawPixel KEYWORD2
invertDisplay KEYWORD2
drawLine KEYWORD2
drawFastVLine KEYWORD2
drawFastHLine KEYWORD2
drawRect KEYWORD2
fillRect KEYWORD2
fillScreen KEYWORD2
drawCircle KEYWORD2
drawCircleHelper KEYWORD2
fillCircle KEYWORD2
fillCircleHelper KEYWORD2
drawTriangle KEYWORD2
fillTriangle KEYWORD2
drawRoundRect KEYWORD2
fillRoundRect KEYWORD2
drawBitmap KEYWORD2
drawChar KEYWORD2
write KEYWORD2
setCursor KEYWORD2
setTextColor KEYWORD2
setTextSize KEYWORD2
setTextWrap KEYWORD2

height KEYWORD2
width KEYWORD2
setRotation KEYWORD2
getRotation KEYWORD2
setCursor KEYWORD2

# Constants (LITERAL1)

so that the Arduino IDE colorizes the text more consistently.
Again thanks for your enormous help in getting this going.

One question, Is it clear to you why some of the touchscreen pins can NOT be shared with other pins?
Just wanted to say: I just got this working and compared the speeds of this screen on a Teensy 3.1 vs a Teensy ++2.0. Holy CRAP the 3.1 is fast! The Adafruit graphics test on the Teensy ++ 2.0 takes 10,565ms to run (according to it's Serial Monitor metrics), while the Teensy 3.1 does it in 1903ms. 5.55x faster! I'm assuming it's not the full 6x faster (16mhz vs 96mhz) due to overhead of using pinMode (and probably some other stuff) for the T3.

But WOW is it fast. The ++2.0 was just barely within the realm of being acceptable for an in-system touchscreen menu. The 3.1 is just BLAZING.
Not open for further replies.