Digistump Forums

The Oak by Digistump => Oak Support => Topic started by: cpetito on February 06, 2016, 09:26:15 pm

Title: OAK TFT driver?
Post by: cpetito on February 06, 2016, 09:26:15 pm
Does anyone know if / where there is a hardware-specific library for the Oak TFT Color LCD Shield?  Thanks!
Title: Re: OAK TFT driver?
Post by: digistump on February 07, 2016, 04:02:27 pm
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
Title: Re: OAK TFT driver?
Post by: cpetito on February 08, 2016, 06:43:28 am
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!
Title: Re: OAK TFT driver?
Post by: postuma on May 25, 2016, 05:16:38 pm
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.

(https://dl.dropboxusercontent.com/u/1564974/ILI9341_2.4_TFT.jpg)

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?
Title: Re: OAK TFT driver?
Post by: exeng on May 25, 2016, 06:20:14 pm
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.
Title: Re: OAK TFT driver?
Post by: PeterF on May 25, 2016, 11:46:02 pm
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

Title: Re: OAK TFT driver?
Post by: PeterF on May 26, 2016, 02:25:49 am
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!  8) ;D

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  :o  :-[

Pinout:

LCDOak
VCCVCC
GNDGND
CS6
RESETVCC
D/C1
SDI (MOSI)7
SCK9
LED47R + VCC
SDO (MISO)8

Edit: Duly noted exeng... attaching VCC to GND is not recommended... correced! lol
Title: Re: OAK TFT driver?
Post by: exeng on May 26, 2016, 07:46:48 am
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. ;D
Title: Re: OAK TFT driver?
Post by: postuma on May 26, 2016, 06:09:06 pm
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!

Title: Re: OAK TFT driver?
Post by: exeng on May 26, 2016, 07:18:52 pm
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.
Title: Re: OAK TFT driver?
Post by: PeterF on May 27, 2016, 01:13:51 am
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 (http://www.ebay.com/itm/120pcs-Dupont-Wire-Female-to-Female-Male-to-Male-Male-to-Female-Jumper-Cable-/181846678573?hash=item2a56e81c2d:g:lbgAAOSw3ydViBG4) 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! ;)

Title: Re: OAK TFT driver?
Post by: postuma on May 27, 2016, 09:02:58 am
 :D

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  :P
Title: Re: OAK TFT driver?
Post by: PeterF on May 28, 2016, 08:15:17 pm
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 ;)



(https://c3.staticflickr.com/8/7298/26710663794_72c87afa15_n.jpg) (https://flic.kr/p/GGk8L7)
Title: Re: OAK TFT driver?
Post by: postuma on May 29, 2016, 05:49:39 pm
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 ...
Title: Re: OAK TFT driver?
Post by: PeterF on May 30, 2016, 12:49:25 am
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...).
Title: Re: OAK TFT driver?
Post by: postuma on June 04, 2016, 12:31:03 pm
Yes, I know. That's what I tried to say with my two previous posts. I must look like a real :o.

Anyway, got the screen up and running:

(http://www.ars-informatica.ca/eclectic/wp-content/uploads/2016/06/bike-computer-tft.jpg)

That's just the layout. Next, porting everything from my Digispark Pro version of my bike computer (http://digistump.com/board/index.php/topic,1938.msg8693.html#msg8693).
Title: Re: OAK TFT driver?
Post by: PeterF on June 04, 2016, 05:59:09 pm
As long as you don't take offence to me promptly ROFTLMAO then no comment from me!  ;D

... other than "Wow! That looks great!" ... and here I am with a TFT that just says Remote Temperature in green print, and the temperature below in yellow print, and spinning cursor in the corner to indicate that the Oak is still alive 'n kicking... and thinking that is pretty good stuff!  ;D  :o  :-X

Will be very interesting to see your progress... look forward to seeing more posts as you progress!  :)
Title: Re: OAK TFT driver?
Post by: emardee on June 27, 2016, 01:16:06 am
Having the same problem that others had earlier in the thread... namely that my screen is pure white with no graphics showing.

I'm using the tft oak kit from digistump.
I've soldered the shield directly to the screen, (so it can't be flaky jumpers on a breadboard as the cause! - but could be a dry joint I guess?)
I'm trying the sketch from:
     Arduino 1.6.5r5 > File Menu > Examples > Adafruit ILI9341 > graphicstest_esp8266
Is that the correct sketch to work from, or is there an Oak version of that sketch in another location?
I couldn't see any changes needing to made in that sketch, so loaded as is (ie no changes)
Also tried it with the 3rd "delay(0)" changed to "delay(1)" (as suggested by postuma).

Any other ideas?
A different sketch to try? (different version of that same sketch from different location?)
A setting I needed to change in the sketch that I missed (I've checked DC 1 and CS 6, but they were already in sketch correctly)?
Something else obvious?

Running Oak firmware v1.0.1 (in case this makes a difference)

Thanks in advance...

Mike

Title: Re: OAK TFT driver?
Post by: PeterF on June 27, 2016, 04:06:27 am
Hi Mike,

Since you've soldered it, I don't think even a dry joint would be a deal-breaker problem at this point.

Only thing I can suggest is to ask is the Arduino IDE picking the right Adafruit_ILI9341 library? Are you getting any warning messages about multiple libraries and it picking one over the other? And if so, is it picking the standard Adafruit one over the one that was distributed with the Oak... (although if you have a current version of the standard library I don't think it really makes any difference)...

Pete
Title: Re: OAK TFT driver?
Post by: emardee on June 28, 2016, 02:36:13 am
PeterF

Thanks for the reply.

Here's the sketch I am using (in case anyone spots an obvious rookie error!):

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

// Use hardware SPI (on Uno, #13, #12, #11) and the above for CS/DC
Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC);
#define SERIAL_OUT Serial

unsigned long testFillScreen() {
  unsigned long start = micros();
  tft.fillScreen(ILI9341_BLACK);
  tft.fillScreen(ILI9341_RED);
  tft.fillScreen(ILI9341_GREEN);
  tft.fillScreen(ILI9341_BLUE);
  tft.fillScreen(ILI9341_BLACK);
  return micros() - start;
}

unsigned long testText() {
  tft.fillScreen(ILI9341_BLACK);
  unsigned long start = micros();
  tft.setCursor(0, 0);
  tft.setTextColor(ILI9341_WHITE);  tft.setTextSize(1);
  tft.println("Hello World!");
  tft.setTextColor(ILI9341_YELLOW); tft.setTextSize(2);
  tft.println(1234.56);
  tft.setTextColor(ILI9341_RED);    tft.setTextSize(3);
  tft.println(0xDEADBEEF, HEX);
  tft.println();
  tft.setTextColor(ILI9341_GREEN);
  tft.setTextSize(5);
  tft.println("Groop");
  tft.setTextSize(2);
  tft.println("I implore thee,");
  tft.setTextSize(1);
  tft.println("my foonting turlingdromes.");
  tft.println("And hooptiously drangle me");
  tft.println("with crinkly bindlewurdles,");
  tft.println("Or I will rend thee");
  tft.println("in the gobberwarts");
  tft.println("with my blurglecruncheon,");
  tft.println("see if I don't!");
  return micros() - start;
}

unsigned long testLines(uint16_t color) {
  unsigned long start, t;
  int           x1, y1, x2, y2,
                w = tft.width(),
                h = tft.height();

  tft.fillScreen(ILI9341_BLACK);
  delay(0);

  x1 = y1 = 0;
  y2    = h - 1;
  start = micros();
  for(x2=0; x2<w; x2+=6) tft.drawLine(x1, y1, x2, y2, color);
  x2    = w - 1;
  for(y2=0; y2<h; y2+=6) tft.drawLine(x1, y1, x2, y2, color);
  t     = micros() - start; // fillScreen doesn't count against timing

  tft.fillScreen(ILI9341_BLACK);
  delay(0);

  x1    = w - 1;
  y1    = 0;
  y2    = h - 1;
  start = micros();
  for(x2=0; x2<w; x2+=6) tft.drawLine(x1, y1, x2, y2, color);
  x2    = 0;
  for(y2=0; y2<h; y2+=6) tft.drawLine(x1, y1, x2, y2, color);
  t    += micros() - start;

  tft.fillScreen(ILI9341_BLACK);
  delay(0);

  x1    = 0;
  y1    = h - 1;
  y2    = 0;
  start = micros();
  for(x2=0; x2<w; x2+=6) tft.drawLine(x1, y1, x2, y2, color);
  x2    = w - 1;
  for(y2=0; y2<h; y2+=6) tft.drawLine(x1, y1, x2, y2, color);
  t    += micros() - start;

  tft.fillScreen(ILI9341_BLACK);
  delay(0);

  x1    = w - 1;
  y1    = h - 1;
  y2    = 0;
  start = micros();
  for(x2=0; x2<w; x2+=6) tft.drawLine(x1, y1, x2, y2, color);
  x2    = 0;
  for(y2=0; y2<h; y2+=6) tft.drawLine(x1, y1, x2, y2, color);

  return micros() - start;
}

unsigned long testFastLines(uint16_t color1, uint16_t color2) {
  unsigned long start;
  int           x, y, w = tft.width(), h = tft.height();

  tft.fillScreen(ILI9341_BLACK);
  start = micros();
  for(y=0; y<h; y+=5) tft.drawFastHLine(0, y, w, color1);
  for(x=0; x<w; x+=5) tft.drawFastVLine(x, 0, h, color2);

  return micros() - start;
}

unsigned long testRects(uint16_t color) {
  unsigned long start;
  int           n, i, i2,
                cx = tft.width()  / 2,
                cy = tft.height() / 2;

  tft.fillScreen(ILI9341_BLACK);
  n     = min(tft.width(), tft.height());
  start = micros();
  for(i=2; i<n; i+=6) {
    i2 = i / 2;
    tft.drawRect(cx-i2, cy-i2, i, i, color);
  }

  return micros() - start;
}

unsigned long testFilledRects(uint16_t color1, uint16_t color2) {
  unsigned long start, t = 0;
  int           n, i, i2,
                cx = tft.width()  / 2 - 1,
                cy = tft.height() / 2 - 1;

  tft.fillScreen(ILI9341_BLACK);
  n = min(tft.width(), tft.height());
  for(i=n; i>0; i-=6) {
    delay(0);
    i2    = i / 2;
    start = micros();
    tft.fillRect(cx-i2, cy-i2, i, i, color1);
    t    += micros() - start;
    // Outlines are not included in timing results
    tft.drawRect(cx-i2, cy-i2, i, i, color2);
  }

  return t;
}

unsigned long testFilledCircles(uint8_t radius, uint16_t color) {
  unsigned long start;
  int x, y, w = tft.width(), h = tft.height(), r2 = radius * 2;

  tft.fillScreen(ILI9341_BLACK);
  start = micros();
  for(x=radius; x<w; x+=r2) {
    for(y=radius; y<h; y+=r2) {
      tft.fillCircle(x, y, radius, color);
    }
  }

  return micros() - start;
}

unsigned long testCircles(uint8_t radius, uint16_t color) {
  unsigned long start;
  int           x, y, r2 = radius * 2,
                w = tft.width()  + radius,
                h = tft.height() + radius;

  // Screen is not cleared for this one -- this is
  // intentional and does not affect the reported time.
  start = micros();
  for(x=0; x<w; x+=r2) {
    for(y=0; y<h; y+=r2) {
      tft.drawCircle(x, y, radius, color);
    }
  }

  return micros() - start;
}

unsigned long testTriangles() {
  unsigned long start;
  int           n, i, cx = tft.width()  / 2 - 1,
                      cy = tft.height() / 2 - 1;

  tft.fillScreen(ILI9341_BLACK);
  n     = min(cx, cy);
  start = micros();
  for(i=0; i<n; i+=5) {
    tft.drawTriangle(
      cx    , cy - i, // peak
      cx - i, cy + i, // bottom left
      cx + i, cy + i, // bottom right
      tft.color565(0, 0, i));
  }

  return micros() - start;
}

unsigned long testFilledTriangles() {
  unsigned long start, t = 0;
  int           i, cx = tft.width()  / 2 - 1,
                   cy = tft.height() / 2 - 1;

  tft.fillScreen(ILI9341_BLACK);
  start = micros();
  for(i=min(cx,cy); i>10; i-=5) {
    start = micros();
    tft.fillTriangle(cx, cy - i, cx - i, cy + i, cx + i, cy + i,
      tft.color565(0, i, i));
    t += micros() - start;
    tft.drawTriangle(cx, cy - i, cx - i, cy + i, cx + i, cy + i,
      tft.color565(i, i, 0));
  }

  return t;
}

unsigned long testRoundRects() {
  unsigned long start;
  int           w, i, i2,
                cx = tft.width()  / 2 - 1,
                cy = tft.height() / 2 - 1;

  tft.fillScreen(ILI9341_BLACK);
  w     = min(tft.width(), tft.height());
  start = micros();
  for(i=0; i<w; i+=6) {
    i2 = i / 2;
    tft.drawRoundRect(cx-i2, cy-i2, i, i, i/8, tft.color565(i, 0, 0));
    delay(0);
  }

  return micros() - start;
}

unsigned long testFilledRoundRects() {
  unsigned long start;
  int           i, i2,
                cx = tft.width()  / 2 - 1,
                cy = tft.height() / 2 - 1;

  tft.fillScreen(ILI9341_BLACK);
  start = micros();
  for(i=min(tft.width(), tft.height()); i>20; i-=6) {
    i2 = i / 2;
    tft.fillRoundRect(cx-i2, cy-i2, i, i, i/8, tft.color565(0, i, 0));
    delay(0);
  }

  return micros() - start;
}


void setup() {
  SERIAL_OUT.begin(115200);
  SERIAL_OUT.println("ILI9341 Test!");

  tft.begin();

  // read diagnostics (optional but can help debug problems)
  uint8_t x = tft.readcommand8(ILI9341_RDMODE);
  SERIAL_OUT.print("Display Power Mode: 0x"); SERIAL_OUT.println(x, HEX);
  x = tft.readcommand8(ILI9341_RDMADCTL);
  SERIAL_OUT.print("MADCTL Mode: 0x"); SERIAL_OUT.println(x, HEX);
  x = tft.readcommand8(ILI9341_RDPIXFMT);
  SERIAL_OUT.print("Pixel Format: 0x"); SERIAL_OUT.println(x, HEX);
  x = tft.readcommand8(ILI9341_RDIMGFMT);
  SERIAL_OUT.print("Image Format: 0x"); SERIAL_OUT.println(x, HEX);
  x = tft.readcommand8(ILI9341_RDSELFDIAG);
  SERIAL_OUT.print("Self Diagnostic: 0x"); SERIAL_OUT.println(x, HEX);

  SERIAL_OUT.println(F("Benchmark                Time (microseconds)"));

  SERIAL_OUT.print(F("Screen fill              "));
  SERIAL_OUT.println(testFillScreen());
  delay(500);

  SERIAL_OUT.print(F("Text                     "));
  SERIAL_OUT.println(testText());
  delay(3000);

  SERIAL_OUT.print(F("Lines                    "));
  SERIAL_OUT.println(testLines(ILI9341_CYAN));
  delay(500);

  SERIAL_OUT.print(F("Horiz/Vert Lines         "));
  SERIAL_OUT.println(testFastLines(ILI9341_RED, ILI9341_BLUE));
  delay(500);

  SERIAL_OUT.print(F("Rectangles (outline)     "));
  SERIAL_OUT.println(testRects(ILI9341_GREEN));
  delay(500);

  SERIAL_OUT.print(F("Rectangles (filled)      "));
  SERIAL_OUT.println(testFilledRects(ILI9341_YELLOW, ILI9341_MAGENTA));
  delay(500);

  SERIAL_OUT.print(F("Circles (filled)         "));
  SERIAL_OUT.println(testFilledCircles(10, ILI9341_MAGENTA));

  SERIAL_OUT.print(F("Circles (outline)        "));
  SERIAL_OUT.println(testCircles(10, ILI9341_WHITE));
  delay(500);

  SERIAL_OUT.print(F("Triangles (outline)      "));
  SERIAL_OUT.println(testTriangles());
  delay(500);

  SERIAL_OUT.print(F("Triangles (filled)       "));
  SERIAL_OUT.println(testFilledTriangles());
  delay(500);

  SERIAL_OUT.print(F("Rounded rects (outline)  "));
  SERIAL_OUT.println(testRoundRects());
  delay(500);

  SERIAL_OUT.print(F("Rounded rects (filled)   "));
  SERIAL_OUT.println(testFilledRoundRects());
  delay(500);

  SERIAL_OUT.println(F("Done!"));

}


void loop(void) {
  for(uint8_t rotation=0; rotation<4; rotation++) {
    tft.setRotation(rotation);
    testText();
    delay(1000);
  }
}

The warning I get upon compiling is:

Quote
WARNING: library SPI claims to run on [esp8266] architecture(s) and may be incompatible with your current board which runs on [oak] architecture(s).

I am expecting that since the sketch is called: "graphicstest_esp8266", that the warning is acceptable in this case.

The only other thing I forgot to mention was that the activity LED on the Oak does a slight flicker... eg it is mostly on, but is very faintly dimming slightly in flickers.... which I presume is a sign that the Oak is processing something for the screen, just that the screen isn't displaying it.

Any ideas how I can check which the culprit is.... I'm guessing it is one of these:

Any thoughts?

Thanks

Mike
Title: Re: OAK TFT driver?
Post by: PeterF on June 29, 2016, 07:49:23 pm
I don't have time to look at the code atm, but since it is essentially just the graphicstest_esp8266 with some delays IIRC your earlier posting, then I don't think that would be the issue.

On my Oak Arduino setup (which doesn't know about any of my other Arduino libraries...), I also get the

Code: [Select]
WARNING: library SPI claims to run on [esp8266] architecture(s) and may be incompatible with your current board which runs on [oak] architecture(s).
so I think that is normal. The P1 led blinking is because it shares one of the LCD display pins, and should be blinking or lit when the display is doing something - I think it is either the enable or clock pin...
Title: Re: OAK TFT driver?
Post by: emardee on June 29, 2016, 08:12:52 pm
Thanks for the comments.

I've confirmed I'm using the right example sketch that others have used.

I re-read the reason for changing the delay(0) to delay(1) and it was only needed by someone earlier in the thread where their oak froze at a certain point in the code... since that isn't my problem, that shouldn't make a difference, so I've left that alone now.

Very unlikely to be a wrong library being used, since there are no other boards installed on this copy of Arduino IDE.

I think therefore I've either got a bad TFT board from Digistump, or I'd soldered the shield up badly.

No I've narrowed that down, it should be easy enough to prove if I've shorted something out, or something has a dry joint. Failing that it looks like I got a bad TFT.

Will do some troubleshooting and if necessary get in touch with Erik.

Thanks for helping me narrow down the cause! Much appreciated.

Mike
Title: Re: OAK TFT driver?
Post by: saperlot on July 20, 2016, 04:52:55 am
Did you came to a conclusion?
mine also don't work.

Title: Re: OAK TFT driver?
Post by: saperlot on July 22, 2016, 04:23:56 am
I checked all the signals,
sampled with 24Mhz and i see that the signals look very screwed up. So i checked the frequency of the SPI. And it must be running at 80Mhz. According to that defining in Adafruit_ILI9341.cpp:
Code: [Select]
#ifdef ESP8266
SPISettings spiSettings = SPISettings(ESP8266_CLOCK, MSBFIRST, SPI_MODE0);
#else

So i changed it to 8000000, trying to run the SPi at 8Mhz. Now i see the signals looks ok, i got a reasonable clock and MOSI but no MISO.
--> no response from the tft.
I'm using the connecting shield. No connection error.

Well, i have no clue what's wrong.

Title: Re: OAK TFT driver?
Post by: emardee on July 22, 2016, 05:28:26 am
I paused my investigations expecting Particle IDE to be released any day (would make investigating this much easier as I'm not normally near the one machine I have with Arduino IDE installed on... so web based IDE would be awesome for me) but that that hasn't been released yet, so I didn't get back to investigating.

Interested to hear of others with problems though, as there might be a common problem between ours.

Are you using the Oak TFT shield?  Which library & Sketch example are you using?
Title: Re: OAK TFT driver?
Post by: saperlot on July 28, 2016, 07:17:20 am
Are you using the Oak TFT shield?  Which library & Sketch example are you using?

Yes the oak TFT shield.
I use the provided library and example from the OAK package. (Adafruit ILI9341/graphictest_esp8266)
Title: Re: OAK TFT driver?
Post by: saperlot on August 03, 2016, 08:59:34 am
Well, shouldn't the 2.2'' TFT use the ILI9340 Driver????
Adafruit states that this is for their 2.2TFT and the ILI9341 is for their 2.8'' tft.

So, i don't want to start porting the ili9340 library until i got a statement that this chip is inside the 2.2'' TFT.

Title: Re: OAK TFT driver?
Post by: emardee on August 03, 2016, 03:01:43 pm
Wrong driver chip and therefore library could certainly be the cause of problems. Is there an easy way to tell which library the screen needs?
Title: Re: OAK TFT driver?
Post by: PeterF on August 03, 2016, 06:12:44 pm
Whilst the adafruit displays use a variety of LCD driver chips (ILI9340/ILI9341/ST7735R/HXD8357D), all of the red TFT LCD boards I have enocuntered so far all work with the Adafruit_ILI9341 library, so I'd presume they are all using ILI9341 driver chips. This is for the 2.2" LCD I got with the Oak, as well as some 1.8" and 2.8" displays I bought on ebay. I am using the Oak TFT shield, but I didn't solder the display directly on, only headers. I then use an extension to link to the display. I can swap out any of the three displays when using the graphicstest_esp8266 code without any changes, and all three sizes work flawlessly (just change the display when the Oak is not powered!).

Interestingly enough, in a discussion about which library to use to control the displays, Paul Stoffregen (one of the people contributing to Arduino) commented that at least on the older Adafruit display with ILI9340, the same code work with either [ILI9340 or ILI9341] controller chip.

I am using the 1.0.5 Arduino IDE Oak board package, Arduino 1.6.10, and sketchbook that has only Oak related code and a couple of custom libraries. There is no other copy of the Adafruit_ILI9341 library installed in this sketchbook, so there is no change it is using a different version (thus also no warning in the compile log about the IDE auto-magically picking between multiple libraries - and getting it wrong). And the example is working just fine in my case.

If you are thinking about trying the Adafruit_ILI9340 library... you may not need to do much. Both the Adafruit_ILI9340 and Adafruit_ILI9341 libraries have been updated with ESP8266 support (although I haven't had any need to test that out myself yet) since Erik starting working on the Oak, so may actually be fully compatible already - at most they might need to be tricked into thinking they're being compiled for an Oak instead of a ESP8266.
Title: Re: OAK TFT driver?
Post by: saperlot on August 04, 2016, 04:49:46 am
Thanks PeterF for your explanation.

I now got a clean installation of Arduino 1.6.10 and with a clean installation of oak 1.0.5. Compiled the example without modification --> Display stays white.
I don't think that the problem is related to my soldering. Every connection is made and i also got no short circuits.
Also when i look at the signals, they are clear and it runs at 8Mbit. I don't see any response from the Display at all. BUt the example given does make a read out at the beginning. So i'm still not sure what is wrong.
I guess i have to give up and trash this tft.

 
Title: Re: OAK TFT driver?
Post by: PeterF on August 04, 2016, 05:19:32 am
Sorry I can't help more there. It certainly seems that way, especially when you consider the 'scope signals look clean. I'd at least put it to one side, and get another display to check it isn't a dud, otherwise there's something really fishy goin' on!  At around AUD$7, they're cheap enough to have a couple spares :D

I like your setup, looks very compact - I certainly hadn't through about mounting on the back-side of the shield. Then again, I wanted to keep the Oak modular, and with the the pins and sockets on the shield the display wouldn't have plugged in. Very nice though!

For giggles, I reflashed the graphicstest_esp8266 sketch onto my Oak with display again, after changing two lines (10- changed Serial to Particle, 262 - removed the baud rate from begin), and this was the output I captured on OakTerm (as I was too lazy to wire up the usb serial adapter to that Oak). The Oakterm otuput is slightly easier to read, so I attached a screenshot.

Code: [Select]
[22:17:26] ILI9341 Test!
[22:17:27] Display Power Mode: 0xCE
MADCTL Mode: 0x24
Pixel Format: 0x2
Image Format: 0x0
Self Diagnostic: 0xE0
Benchmark Time (microseconds)
Screen fill 251136
Text 45268
[22:17:32] Lines 439842
[22:17:34] Horiz/Vert Lines 22091
Rectangles (outline) 15380
[22:17:35] Rectangles (filled) 521709
[22:17:36] Circles (filled) 153340
Circles (outline) 191100
Triangles (outline) 139500
[22:17:38] Triangles (filled) 217757
[22:17:44] Rounded rects (outline) 67701
Rounded rects (filled) 592739
[22:17:45] Done!
Title: Re: OAK TFT driver?
Post by: emardee on August 04, 2016, 06:00:53 am
Peter,

Anything special to look out for when hunting a replacement TFT to try? (I'll probably get a larger one to test). Do you get them from Ebay? Aliexpress?

Any tips to get good ones (or to avoid duff ones!)

If it proves to be a duff screen shipped to us, I'm sure Erik will replace them, as he's good like that. Seems increasingly likely with a few of us seeing the same white screen problem. But I'll hold my verdict until I get a replacement to test.

Mike
Title: Re: OAK TFT driver?
Post by: saperlot on August 04, 2016, 06:47:45 am
just ordered new ones from banggood.

http://www.banggood.com/2_2-Inch-SPI-TFT-LCD-Display-Module-240-X-320-ILI9341-51AVRSTM32ARMPIC-p-1026628.html

May they also have larger ones.

Cheers.
Title: Re: OAK TFT driver?
Post by: PeterF on August 04, 2016, 04:59:13 pm
No, nothing that I can think of really. Just check that the description somewhere says ILI9341 so you can at least get your money back if they send you an incompatible one ;)

I've bought most of mine through ebay. This was the 2.8" one (http://www.ebay.com.au/itm/LCD-Touch-Panel-240-x-320-2-8-SPI-TFT-Serial-Port-Module-With-PBC-ILI9341-Red-/252146934434?hash=item3ab520e2a2:g:9ZYAAOSwaB5Xlgil). My 2.2" came from Erik. And the 1.8" one I bought isn't listed anymore, but you can find others if you want one that small. It was the first one I got, and was expensive compared to the others you can get now... $15.28 for 1.8" compared to $7-8 for 2.2"!!!!

I've seen some code that purports to do lcd driver identification, but can't see anything that looks like it would help with this type of screen - stuff I've seen so far seems to be for the other displays with many, many i/o pins. What I have seen so far indicates that a white screen means the lcd driver chip hasn't been initialised, so indicates either the wrong driver chip, or a faulty one.
Title: Re: OAK TFT driver?
Post by: emardee on August 04, 2016, 05:30:40 pm
Was going to ask you if this 2.8" touch panel tft looked OK (http://www.ebay.co.uk/itm/LCD-Touch-Panel-240-x-320-2-8-SPI-TFT-Serial-Port-Module-With-PBC-ILI9341-Red-/281846711140?hash=item419f5f8364:g:t0YAAOSwZVlXk~Ni), but I see it looks identical to the one you just suggested (and mine is about a dollar cheaper)... so I'll grab one.

Thanks

Mike