1.8" TFT Display Problems: Testers Needed

EL Wire/Tape/Panels, LEDs, pixels and strips, LCDs and TFTs, etc products from Adafruit

Moderators: adafruit_support_bill, adafruit

1.8" TFT Display Problems: Testers Needed

Postby pburgess » Fri Mar 02, 2012 2:24 pm

Regarding a variety of bugs that users have observed: BMP loading, triangle rendering and gobbledygook on "red tab" vs "green tab" displays...

I tentatively have a version of the Adafruit-ST7735-Library that should address all of these. However, I only have a "red tab" display for testing and perhaps my selection of BMPs is only coincidentally good. So, before I go updating the repository and possibly ruin the day for a lot of people, I'm hoping a couple folks might be willing to do a dry run with this test version first, especially if you've encountered any of the aforementioned bugs before. I only have a "red tab" display on hand for testing, so I'm hoping at least one "green tab" owner is available for testing. But a mix would be ideal.

Please post a reply if interested, I'll contact you at the email address in your profile with a ZIP file and some specific instructions. Much appreciated, thanks!

This doesn't yet address the SD-card-on-Mega issue, this is purely a display-side fix.
User avatar
pburgess
 
Posts: 1332
Joined: Sun Oct 26, 2008 1:29 am

Re: 1.8" TFT Display Problems: Testers Needed

Postby deejayspinz » Fri Mar 02, 2012 3:05 pm

Perfect timing. I'd like to help out with testing. Here are a few issues I am grappling with:
(I have the red tab)


- have the screen set at tft.setRotation(1). Trying to load a bitmap (24bit) that is not 128x160 and they all come up skewed. They are the same regardless of setRotation, but I thought I would mention where mine is set. If I take the same image and rendering using a canvas size of 128-x160, it works fine. It appears thay all bitmaps have to be 128x160.

- would be nice if there was the ability to return background pixels to their previous (or a saved) state after writing to the screen. e.g. I have a background image that I want to always be there, but I want to write changing numbers over top. Eventually, the area where the numbers are goes black and stays that way.

Let me know if I can help with the above or other issues.
deejayspinz
 
Posts: 39
Joined: Fri Mar 25, 2011 6:12 pm
Location: Ontario

Re: 1.8" TFT Display Problems: Testers Needed

Postby adafruit » Fri Mar 02, 2012 5:27 pm

there is no way to do the second request - thats what an double frame image buffer is for and the arduino does not have the RAM for it - you need 40K or more of RAM
User avatar
adafruit
 
Posts: 10489
Joined: Thu Apr 06, 2006 3:21 pm
Location: nyc

Re: 1.8" TFT Display Problems: Testers Needed

Postby sdb » Fri Mar 02, 2012 7:17 pm

It could read both the static background image and the foreground image from a file and build the combination into the single framebuffer while it was reading. Both images would have to be read every time the foreground changed, but it should be doable.

Another thought... Doesn't happen to be room in progmem for the static background image?
sdb
 
Posts: 31
Joined: Thu Jan 12, 2012 3:24 am
Location: USA, ID

Re: 1.8" TFT Display Problems: Testers Needed

Postby deejayspinz » Sat Mar 03, 2012 2:09 am

Thx for passing along the updated library for testing.. Here are my findings so far:

- I can now load BMPs of any size and orient them correctly (I'm using landscape orientation). Good.
- tried both tft.initR(INITR_GREENTAB) and tft.initR(INITR_REDTAB) and I get the same results regardless of which I choose now. I have the red tabbed LCD. So, I think this is good as well.
- can load multiple BMPs of various size to the screen without issue.
- also noticed that before the update, all my BMPs would render as a horizontally mirrored image of the original graphic. This is fixed now and they are drawing as expected.
- ran the various samples and all worked fine.
- no other adverse affects with my current sketch.

So, it looks good!
deejayspinz
 
Posts: 39
Joined: Fri Mar 25, 2011 6:12 pm
Location: Ontario

Re: 1.8" TFT Display Problems: Testers Needed

Postby pburgess » Sat Mar 03, 2012 2:19 am

deejayspinz: fantastic! I appreciate your taking the time to do a thorough test. This is very encouraging, and I'm just going to wait for some "green tab" feedback before updating the repository. Thanks!
User avatar
pburgess
 
Posts: 1332
Joined: Sun Oct 26, 2008 1:29 am

Re: 1.8" TFT Display Problems: Testers Needed

Postby deejayspinz » Sat Mar 03, 2012 2:58 am

..just a follow-up. Not sure if this is a bug but I was going through bmpDraw as I wanted to control the debugging Serial.Print statements. I wrapped them all in if (debug){ } statements and found that the bitmaps would not draw for the two Serial.print statements that write out the file and header size when debug=false. If I keep the original statements (thus forcing it to write to the serial window, the bitmaps draw. If I I include them in the debug check and debug=false, then the bitmaps don't draw. However, I have the rest of the Serial.print statements wrapped and they are fine. It appears that the printing of read32(bmpFile) also executes a critical task as part of the process. The two statements in question are:

// if (debug){Serial.print("File size: "); Serial.println(read32(bmpFile));}
// if (debug){Serial.print("Header size: "); Serial.println(read32(bmpFile));}

Code snippet below. Entire bmpDraw at bottom.


Code: Select all
....
  if(read16(bmpFile) == 0x4D42) { // BMP signature
 
    // if (debug){Serial.print("File size: "); Serial.println(read32(bmpFile));}
    Serial.print("File size: "); Serial.println(read32(bmpFile));
 
    (void)read32(bmpFile); // Read & ignore creator bytes
    bmpImageoffset = read32(bmpFile); // Start of image data
    if (debug){Serial.print("Image Offset: "); Serial.println(bmpImageoffset, DEC);}
    //Serial.print("Image Offset: "); Serial.println(bmpImageoffset, DEC);
    // Read DIB header
    //if (debug){Serial.print("Header size: "); Serial.println(read32(bmpFile));}
    Serial.print("Header size: "); Serial.println(read32(bmpFile));
    bmpWidth  = read32(bmpFile);
    bmpHeight = read32(bmpFile);
...


Code: Select all
void bmpDraw(char *filename, uint8_t x, uint8_t y) {

  File     bmpFile;
  int      bmpWidth, bmpHeight;   // W+H in pixels
  uint8_t  bmpDepth;              // Bit depth (currently must be 24)
  uint32_t bmpImageoffset;        // Start of image data in file
  uint32_t rowSize;               // Not always = bmpWidth; may have padding
  uint8_t  sdbuffer[3*BUFFPIXEL]; // pixel buffer (R+G+B per pixel)
  uint8_t  buffidx = sizeof(sdbuffer); // Current position in sdbuffer
  boolean  goodBmp = false;       // Set to true on valid header parse
  boolean  flip    = true;        // BMP is stored bottom-to-top
  int      w, h, row, col;
  uint8_t  r, g, b;
  uint32_t pos = 0, startTime = millis();

  if((x >= tft.width()) || (y >= tft.height())) return;

  if (debug)
  {
    Serial.println();
    Serial.print("Loading image '");
    Serial.print(filename);
    Serial.println('\'');
  }
  // Open requested file on SD card
  if ((bmpFile = SD.open(filename)) == NULL) {
    if (debug){Serial.print("File not found");}
    return;
  }

  // Parse BMP header
  if(read16(bmpFile) == 0x4D42) { // BMP signature
 
    //CUPRIT!!!! if (debug){Serial.print("File size: "); Serial.println(read32(bmpFile));}
    Serial.print("File size: "); Serial.println(read32(bmpFile));
 
    (void)read32(bmpFile); // Read & ignore creator bytes
    bmpImageoffset = read32(bmpFile); // Start of image data
    if (debug){Serial.print("Image Offset: "); Serial.println(bmpImageoffset, DEC);}
    //Serial.print("Image Offset: "); Serial.println(bmpImageoffset, DEC);
    // Read DIB header
    //CULPRIT if (debug){Serial.print("Header size: "); Serial.println(read32(bmpFile));}
    Serial.print("Header size: "); Serial.println(read32(bmpFile));
    bmpWidth  = read32(bmpFile);
    bmpHeight = read32(bmpFile);
    if(read16(bmpFile) == 1) { // # planes -- must be '1'
      bmpDepth = read16(bmpFile); // bits per pixel
      if (debug){Serial.print("Bit Depth: "); Serial.println(bmpDepth);}
      //Serial.print("Bit Depth: "); Serial.println(bmpDepth);
      if((bmpDepth == 24) && (read32(bmpFile) == 0)) { // 0 = uncompressed

        goodBmp = true; // Supported BMP format -- proceed!
        //if (debug){
          Serial.print("Image size: ");
          Serial.print(bmpWidth);
          Serial.print('x');
          Serial.println(bmpHeight);
        //}
        // BMP rows are padded (if needed) to 4-byte boundary
        rowSize = (bmpWidth * 3 + 3) & ~3;

        // If bmpHeight is negative, image is in top-down order.
        // This is not canon but has been observed in the wild.
        if(bmpHeight < 0) {
          bmpHeight = -bmpHeight;
          flip      = false;
        }

        // Crop area to be loaded
        w = bmpWidth;
        h = bmpHeight;
        if((x+w-1) >= tft.width())  w = tft.width()  - x;
        if((y+h-1) >= tft.height()) h = tft.height() - y;

        // Set TFT address window to clipped image bounds
        tft.setAddrWindow(x, y, x+w-1, y+h-1);

        for (row=0; row<h; row++) { // For each scanline...

          // Seek to start of scan line.  It might seem labor-
          // intensive to be doing this on every line, but this
          // method covers a lot of gritty details like cropping
          // and scanline padding.  Also, the seek only takes
          // place if the file position actually needs to change
          // (avoids a lot of cluster math in SD library).
          if(flip) // Bitmap is stored bottom-to-top order (normal BMP)
            pos = bmpImageoffset + (bmpHeight - 1 - row) * rowSize;
          else     // Bitmap is stored top-to-bottom
            pos = bmpImageoffset + row * rowSize;
          if(bmpFile.position() != pos) { // Need seek?
            bmpFile.seek(pos);
            buffidx = sizeof(sdbuffer); // Force buffer reload
          }

          for (col=0; col<w; col++) { // For each pixel...
            // Time to read more pixel data?
            if (buffidx >= sizeof(sdbuffer)) { // Indeed
              bmpFile.read(sdbuffer, sizeof(sdbuffer));
              buffidx = 0; // Set index to beginning
            }

            // Convert pixel from BMP to TFT format, push to display
            b = sdbuffer[buffidx++];
            g = sdbuffer[buffidx++];
            r = sdbuffer[buffidx++];
            tft.pushColor(tft.Color565(r,g,b));
          } // end pixel
        } // end scanline
        if (debug){
          Serial.print("Loaded in ");
          Serial.print(millis() - startTime);
          Serial.println(" ms");
        }
      } // end goodBmp
    }
  }

  bmpFile.close();
  if (debug){if(!goodBmp) Serial.println("BMP format not recognized.");}
}
deejayspinz
 
Posts: 39
Joined: Fri Mar 25, 2011 6:12 pm
Location: Ontario

Re: 1.8" TFT Display Problems: Testers Needed

Postby pburgess » Sat Mar 03, 2012 4:15 am

Ayup. Though the file/header sizes are purely for informational purposes (the values aren't used by the library), it's still critical for those read32()s to take place in order to keep the file position correctly updated. So...stick 'em in temp vars, print them if debug is set, ignore them otherwise, i.e.:

Code: Select all
uint32_t fileSize = read32(bmpFile);
// ...other stuff (e.g. bmpImageoffset) happens between these two read32()s...
uint32_t headerSize = read32(bmpFile);
if(debug) {
  Serial.print("File size: ");
  Serial.println(fileSize);
  Serial.print("Header size: ");
  Serial.println(headerSize);
}
User avatar
pburgess
 
Posts: 1332
Joined: Sun Oct 26, 2008 1:29 am

Re: 1.8" TFT Display Problems: Testers Needed

Postby deejayspinz » Sat Mar 03, 2012 8:02 am

I get it... Cleaned it up by adding the two new vars as you suggested and it works fine. Thx.
deejayspinz
 
Posts: 39
Joined: Fri Mar 25, 2011 6:12 pm
Location: Ontario

Re: 1.8" TFT Display Problems: Testers Needed

Postby pburgess » Tue Mar 06, 2012 3:06 pm

Code tested, looks solid, Github has now been updated with the latest and greatest!

If you notice any oddness, please report using the "Issues" link on Github rather than here. This was admittedly an unconventional mode of testing here and was only done because it was such an extensive update to the code...so let's consider the thread closed at this point.

Thanks for all your help!
User avatar
pburgess
 
Posts: 1332
Joined: Sun Oct 26, 2008 1:29 am


Return to Glowy things (LCD, LED, TFT, EL) purchased at Adafruit

Who is online

Users browsing this forum: pburgess, VeleBookSot and 1 guest

Stuff to buy from the Adafruit store and links to product documentation!


New Products [102]

Raspberry Pi[80]
 
FLORA[23]
 
Bunnie Studios[9]
 
FPGA[1]
 
mbed[11]
Arduino[60]
 
NETduino[14]
 
BeagleBone[24]
 
Android[6]
 
XBee[10]
More Dev Boards[30]


 
BoArduino[8]
 
SpokePOV[4]
 
TV-B-Gone[4]
 
MiniPOV[3]
 
SIM reader[3]
 
Microtouch[5]
 
Clocks & Watches[18]
 
Drawdio[4]
 
Brain Machine[1]
 
Game of Life[2]
 
MintyBoost[2]
More DIY Kits[16]


 
MaKey MaKey[3]
 
Tweet-a-Watt[5]
 
Young Engineers[33]
 
Discover Electronics[2]
 
Snap Circuits[4]
 
littleBits[3]
 
Project packs[8]


 
Breakout Boards[33]
LCDs & Displays[48]
Components & Parts[69]
Batteries & Power[49]
EL Wire/Tape/Panel[52]
LEDs[109]
 
Wireless[14]
Cables[60]
 
Lasers[6]
Sensors/Parts[145]
 
Enclosures/Cases[11]
 
Solar[11]
 
RFID / NFC[13]
Prototyping[70]
 
iDevices[13]
Tools[71]
 
Wearables[39]
 
CNC[37]
 
Robotics[29]
 
3D printing[1]
 
Materials[24]


 
Stickers[41]
 
Skill badges[55]
 
Books[25]
 
Circuit Playground[7]
 
Gift Certificates[4]