OAK TFT driver?

[cpetito]

Does anyone know if / where there is a hardware-specific library for the Oak TFT Color LCD Shield?  Thanks!

[digistump]

https://github.com/Links2004/Adafruit_ILI9341

It will be included in the coming release

If you use that download then use the esp8266 example and
DC should be set to 1
CS to 6

[cpetito]

Thanks for the link!  I was getting close - was looking at the Adafruit ILI9340 library.

With the ILI9341 library and esp8266 example I did have to include the following define:

    #define min(a,b) ((a)<(b)?(a):(b))

to get it to compile under the Arduino 1.6.7 IDE.  There are references to this issue, but I didn't have time to investigate.

Looking at serial output, i see that the sketch runs, but unfortunately only the back light is on and nothing is displayed.

If I get some time today, I hook up a logic analyzer to see if the SPI is working.

Thanks for all your efforts on creating this new product!

[postuma]

I'm having similar trouble - this library seems to work, some of the time. Some of the time it doesn't but I'm not sure if it's the code or my Oak.

Using the Adafruit ILI9341 graphictest_esp8266 example, and pinouts

   DC        1                    board D/C
   CS        6                              CS
   MOSI    7                              SDI(MOSI)
   CLK      9                              SCK
   RST    10                              RESET

VIN Oak 5V. VCC on TFT 3.3V; LED backlight 3.3V, tested w 47, 100, 220 ohm resistors and without.



I get the code to start to run but it *almost* invariably hangs, usually during the "draw some lines in a pattern" part.

I wondered if it might be a problem with the difference in SPI Clock speed but the ILI9341 is rated at 10 MHz and unofficially others have managed to run it stable at 40 MHz, and even if I throttle the code i.e. with SPI.setFrequency(1000000); the problem still persists. BTW this is the only alteration I've made to the sample code.

Tried a second TFT screen of the same type, exact same problem, so unlikely it's a faulty screen.

The Oak seems to work fine when I use it for other applications - though admittedly I'm not using all the same pins.

Ideas?

[exeng]

Are you using the Oak TFT LCD shield or making the connections with jumper wires?

I've been running a sketch for the TFT LCD display successfully for quite awhile but I do recall very early on seeing the display hang when running the graphic example. At the time I was using a set of jumper wires to make the connection between the shield and the display. I wondered if I had a bad or loose connection so I changed the jumpers to 6 and 3 pin JST jumpers (to get 9 pins worth) to make the connection between the TCT LCD display and Oak shield. I purposely configured it this way so I could use the TFT LCD display with other boards.

I'm using the Adafruit IL19341 library. Here is a snippet of the beginning of the code...

Code: [Select]

#include <Adafruit_ILI9341.h>
#include <Adafruit_GFX.h>
#include <SPI.h>

// For the Adafruit shield, these are the default.
#define TFT_DC 1
#define TFT_CS 6

Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC);
...

I would check to make sure all your connections are corrected and solid. Beyond that I got nothing... Hope this helps.

[PeterF]

I noticed you're using the 2.4" version of the screen, which also looks like it has the touch controller chip on it (unless that isn't the exact screen you have... ). I haven't had any issues with the TFT display on the Oak since I started - I did basically the same and exeng - soldered on header pins with female-female jumper wires linking the shield and LCD, so no loose connections for me (other than the loose nut at the keyboard).

However, I have only been using the 2.2" version of that display, and wonder if that makes any difference at all. I do have a pair of those 2.4" displays that arrived recently... I'll give one of them a try and see if it buggers things up

btw, I don't know if it is still needed, but in addition to the code snippet exeng provided, I also have (still?) the below - other than that and some whitespace changes, my top bits are exactly the same.

Code: [Select]

#ifndef min
#define min(x,y) (((x)<(y))?(x):(y))
#endif
#ifndef max
#define max(x,y) (((x)>(y))?(x):(y))
#endif

[PeterF]

Ok, spoke too soon there... I have a larger screen yes... but it's 2.8" instead of 2.4"... I have 1.8", 2.2" and 2.8"... maybe I need to get a 2.4" so I have the full set! 

Swapping my 2.2" TFT for the 2.8" one was as easy as unplugging the old and plugging in the new - pins were even in the same order. Didn't have to change any code, as the resolution is the same, it's just a bigger screen (same as yours - 240x320). So that isn't the problem!!

I've just probed the pinout of the Oak TFT Adapter, and put together the following listing, which matches your listing except for the RST Pin, and the SDO (MISO) is also connected. The resistor used here is a 47 ohm resistor, and VCC is the 3.3v Oak supply. I've listed the connections in the order they are on the LCD, and with the same labels.

exeng - please jump in and slap me round the head if I got any of these wrong   

Pinout:

LCD	Oak
VCC	VCC
GND	GND
CS	6
RESET	VCC
D/C	1
SDI (MOSI)	7
SCK	9
LED	47R + VCC
SDO (MISO)	8

Edit: Duly noted exeng... attaching VCC to GND is not recommended... correced! lol

[exeng]

I am I missing something in your pinout list? LCD VCC to Oak GND?

No slaps necessary. You have proven yourself worthy of an exemption due to your generous, knowledgeable, and helpful posts.

[postuma]

My code does match yours.

Also, currently I have LCD VCC to power, +3.3V, not ground. Are you sure VCC should connect to ground? This goes against instinct, and the spec sheet. I did try it and got a blank screen, and flashing light on the Oak - it did not like it ...

LCD RESET I had connected to pin 10 not VCC. Don't know why exactly I used pin 10, and I had not set it High. Low I guess triggers reset, and if I let it float - my bad?

Would I trigger a significant current draw if I connect RESET to Oak's VCC? Should I use a current-limiting resistor?

So, with LCD VCC back to +3.3V, and LCD RESET to Oak VCC - still getting the same problem.

I do have it all on breadboard atm, and did think of bad jumpers. I had switched all the jumpers to new ones but the problem did not change. Tried it with plain wire connections and the problem was worse (which does suggest it's all connector related). Tried with two jumpers per pin row for Oak out to LCD ins, hoping the extra connector would help w bad connections, but really no change.

Unfortunately I don't have immediate access to either F/F jumpers or JST connectors to direct-wire the pins but I suspect this would improve/resolve the situation. I'll get some. I'm not hard-wiring anything until it works. Out of curiosity, how did you manage JST connectors when pin sequences on the two units don't match directly?

Interestingly, when I comment out the call to function testLines() in the example, it runs perfectly, flawlessly. I suspect this is a timing issue that wouldn't exist with better pin connections, but I'll dig deeper to figure it out and rule out a software issue.

Thank you to all for your comments!

[exeng]

The VCC to GND in Pete's list was (I'm pretty sure) a mistake. With that corrected the list matches how the Oak TFT LCD shield connects to the Oak. I verified this by Ohm'ing out my TFT shield. The reason we are able to use JST jumpers is because the TFT LCD shield brings out the 9 pins in the same order as the TFT LCD display board that comes with the shield. Normally the shield would have a 9 pin female header installed and the display connected directly to it, but I chose to (and I suspect Pete did too) install a 9 pin male header and use jumpers instead. Pete is in another time zone but when he checks in he'll confirm or deny this.

I take it that you are not using an Oak TFT LCD shield but rather trying to match the appropriate connections via a breadboard.

[PeterF]

Yeah, it was a mistake exeng... reformatting the list as a table to neaten it up introduced that rather poor advice which is more likely to make things to bang in a bad way...

And yes, I can confirm exeng speculations I used the LCD shield that you can get for the Oak, but have header pins on both it and the shield (instead of the female socket) and use female to female jumpers to link them. And since I also have female to male leads, I could also use direct wiring if I so desired, as since they are wire connectors, I can re-order the connections as needed. I found a pack or two of connectors like these to be invaluable... especially when you have several projects going at once...

The LCD shield only has one resistor, the 47 ohm one for the backlight, and I don't think pulling the RESET high by direct connecting it to VCC would cause any current consumption - it certainly doesn't do anything for the one I've had running for over a month now!

[postuma]

 

so it's a timing issue. While I haven't yet got direct F/F connectors (my Oak's soldered to male pins), it's only the testLines() function that causes the code to hang. Switching the third

Code: [Select]

delay(0)
statement to

Code: [Select]

delay(1)
causes it to work consistently. And it's quite speed-sensitive. Using delayMicroseconds(100) reproduces the code-hanging "feature."

You're correct to assume I'm not using the Oak TFT shield. In a future version of my project, I intend to add touch functionality, which the shield does not support, and I try to run projects off perfboard or custom PCBs after prototyping.

Now on to the actual project 

[PeterF]

If you get a chance, and are inclined to do so, can you see if delayMicroseconds(1000) / delayMicroseconds(750) / delayMicroseconds(500) / delayMicroseconds(250) work? I'd be surprised if delayMicroseconds(1000) didn't as it is basically the same as delay(1)... I would try it myself, but after a quick re-wire of my display (shown below), it is still behaving. The timing issue is probably coming from the connections through the breadboard - they are never that good for high speed data stuff.

lol... yes indeed, same plan here - I have the 2.8" display with touch screen support just waiting to be touched up

[postuma]

lol - I said delay(1) worked but delayMicroseconds(100) did not - not delayMicroseconds(1000). But since it's working as is, and I can live with a millisec delay, I'm not bothering to find out at exactly what microdelay it starts to fail ...

[PeterF]

No problem... btw... the reason I said I would be surprised if delayMicroseconds(1000) didn't work is because there are 1000 microseconds to a millisecond... so delayMicroseconds(100) is equivalent to delay(0.1)... (completely ignoring the fact that delay expects whole numbers, not decimal ones...).