Animation on LCD with Uno.

Hi all. New person here. I have been fooling with my Uno and a 2.4 inch tft lcd for a while now, and I was finally able to get it to display 24-bit bmp images. My goal for this project is to get this thing to display the images in a quick enough sequence that an animation results, but as of right now the thing takes a while to load the images.

From all the research I have done thus far, it seems that getting the uno to load images that are smaller (16-bit or 8-bit) would speed things up some, but I have yet to find anything solid.

Is this goal attainable? I'm learning all that I can sitting at my computer for hours reading and trying things out, but I admit I am not well-versed in writing (or reading) code. I'm picking up on things here and there.

Anyway, I could use some guidance here if anyone has the time or can point me in the right directions.

Thank you.

Hi and welcome.

Please post a link to details of your display, and the code you have so far. Use code tags (the </> icon).

It may be that your display can only accept 24-bit images. In this case, using 8 or 16-bit images will not be any faster, perhaps slower, because the Arduino will have to convert them back to 24-bit.

Another possible way to speed up the animation would be to update only the parts of the image that have changed between frames. This is advanced coding and beyond your skill level of today.

Another option may be to use a faster Arduino such as Due, Teensy 3 or Maple Mini. To give you an idea of the difference in speed between a "normal" Arduino and these faster types, look at these videos. The display is not colour, but it does have a spi interface, which i expect your colour display also has.

Nano 3 (same speed as Uno): Conway's Game Of Life/Gosper's Glider Gun - YouTube

Maple Mini: Conway's Game Of Life/Gosper's Glider Gun - YouTube

Paul

Sorry for the delay. Here is the TFT LCD that I have:
http://www.ebay.com/itm/151850499828?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Specifications:
2.4'' diagonal LCD TFT display
240x320 resolution, 18-bit (262,000) color
8 bit digital interface, plus 4 control lines
5V compatible! Use with 3.3V or 5V logic
4-wire resistive touchscreen
Size: approx. 70mm x 51mm
Color: Red
Net Weight: 28g

And here is the code that I am using:

// Modified TFTbmp sketch from Adafruit_TFTLCD Library for
// TFT shield LCD 2.4" Chip ILI9341
// http://www.electronicavm.net
// @iPadNanito

#include <Adafruit_GFX.h>    // Libreria de graficos
#include <Adafruit_TFTLCD.h> // Libreria de LCD 
#include <SD.h>              // Libreria de tarjeta SD
#include <SPI.h>             // Libreria bus SPI 

#define LCD_CS A3   // Definimos los pines del LCD
#define LCD_CD A2   // para poder visualizar elementos graficos
#define LCD_WR A1
#define LCD_RD A0
#define LCD_RESET A4

// Los pines del puerto SPI vienen configurados por libreria, por lo que 
// solamente debemos colocar el pin correspondiente al Chip Select del
// bus SPI correspondiente a la conexion con la tarjeta SD
#define SD_CS 10  

// En la tarjeta SD debemos colocar imagenes en formato BMP de 24 Bits!
// Otro tipo de formato de imagen no se puede visualizar por pantalla. 

Adafruit_TFTLCD tft(LCD_CS, LCD_CD, LCD_WR, LCD_RD, LCD_RESET);  // Instancia LCD 

void setup()
{
  Serial.begin(9600); // Iniciamos el puerto serie para comprobar 
                      // la comunicacion con la tarjeta microSD
                      
  tft.reset();
  
  tft.begin(0x9341); // Iniciamos el LCD especificando el controlador ILI9341. 

  Serial.print(F("Inicializando tarjeta SD..."));
  
  if (!SD.begin(SD_CS)) // Si se produce un error al intentar acceder
  {                     // a la tarjeta SD, lo mostramos por el Serial Monitor
    Serial.println(F("Error!"));
    return;
  }
  Serial.println(F("OK!"));
  
}

void loop()
{
   tft.setRotation(0); // Establecemos la posicion de la pantalla Vertical
   
   bmpDraw("1.bmp", 0, 0); // Mostramos una imagen en las coordenadas 0,0
   
   delay(1000);
  
   tft.setRotation(3); // Establecemos la posicion de la pantalla Horizontal
   
   bmpDraw("2.bmp",0,0); // // Mostramos otra imagen en las coordenadas 0,0
   
   delay(1000);  
}

// Esta funcion abre un archivo Windows bitmap (BMP) y lo muestra por 
// pantalla en las coordenadas especificadas. Se puede acelerar el 
// proceso de muestreo leyendo muchos pixeles a la vez en lugar de 
// leer pixel a pixel, incrementando el tamaño de la siguiente variable 
// BUFFPIXEL, utilizaremos mas memoria RAM del Arduino pero se realizará
// la carga de la imagen mas rapido.
// Un buffer de 20 pixeles es un valor equilibrado. 

#define BUFFPIXEL 20

void bmpDraw(char *filename, int x, int 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 in buffer (R+G+B per pixel)
  uint16_t lcdbuffer[BUFFPIXEL];  // pixel out buffer (16-bit 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();
  uint8_t  lcdidx = 0;
  boolean  first = true;

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

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

  // Parse BMP header
  if(read16(bmpFile) == 0x4D42) { // BMP signature
    Serial.println(F("File size: ")); Serial.println(read32(bmpFile));
    (void)read32(bmpFile); // Read & ignore creator bytes
    bmpImageoffset = read32(bmpFile); // Start of image data
    Serial.print(F("Image Offset: ")); Serial.println(bmpImageoffset, DEC);
    // Read DIB header
    Serial.print(F("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
      Serial.print(F("Bit Depth: ")); Serial.println(bmpDepth);
      if((bmpDepth == 24) && (read32(bmpFile) == 0)) { // 0 = uncompressed

        goodBmp = true; // Supported BMP format -- proceed!
        Serial.print(F("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 column...
            // Time to read more pixel data?
            if (buffidx >= sizeof(sdbuffer)) { // Indeed
              // Push LCD buffer to the display first
              if(lcdidx > 0) {
                tft.pushColors(lcdbuffer, lcdidx, first);
                lcdidx = 0;
                first  = false;
              }
              bmpFile.read(sdbuffer, sizeof(sdbuffer));
              buffidx = 0; // Set index to beginning
            }

            // Convert pixel from BMP to TFT format
            b = sdbuffer[buffidx++];
            g = sdbuffer[buffidx++];
            r = sdbuffer[buffidx++];
            lcdbuffer[lcdidx++] = tft.color565(r,g,b);
          } // end pixel
        } // end scanline
        // Write any remaining data to LCD
        if(lcdidx > 0) {
          tft.pushColors(lcdbuffer, lcdidx, first);
        } 
        Serial.print(F("Loaded in "));
        Serial.print(millis() - startTime);
        Serial.println(" ms");
      } // end goodBmp
    }
  }

  bmpFile.close();
  if(!goodBmp) Serial.println(F("BMP format not recognized."));
}

// These read 16- and 32-bit types from the SD card file.
// BMP data is stored little-endian, Arduino is little-endian too.
// May need to reverse subscript order if porting elsewhere.

uint16_t read16(File f) {
  uint16_t result;
  ((uint8_t *)&result)[0] = f.read(); // LSB
  ((uint8_t *)&result)[1] = f.read(); // MSB
  return result;
}

uint32_t read32(File f) {
  uint32_t result;
  ((uint8_t *)&result)[0] = f.read(); // LSB
  ((uint8_t *)&result)[1] = f.read();
  ((uint8_t *)&result)[2] = f.read();
  ((uint8_t *)&result)[3] = f.read(); // MSB
  return result;
}

With a 24-bit bmp on the micro sd card, the sketch loads the image fine. According to what I have read about the LCD shield I am using, the shield loads 24-bit images from the sd card and converts it to 16-bit before putting it on the screen. I was wondering if it is possible to skip that step, have the images already in 16-bit on the sd card, and have the sketch load the 16-bit files.

Thank you for the help.

Do you have any schematic layout to make a connection. i will try in real time in my lab.. provide all the data which is needed to do this project i will try and give a solution.

tripptofan:
I was wondering if it is possible to skip that step, have the images already in 16-bit on the sd card, and have the sketch load the 16-bit files.

Maybe. This is just an idea, I have never done this. I believe it is possible to read the data back from the display. Maybe you could write a new "Screen Capture" function in your sketch which reads the data from the display in its final format and writes this to a new file on the SD card. Like the screen capture button on a PC. Then you can call this Screen Capture function in your current sketch, at the points where you want to capture the image. This would run even more slowly than before, but it would create a number of new files on the SD card containing the images you want. Then you would write a completely new sketch that would load the data from the files, in sequence, and write this directly to the display, without using the lcd/graphics libraries.

Your best bet is to do a bunch of pre-processing on a PC first.

For example, take the initial image and convert it into the correct format for the display (so you don't have to process each pixel on the Arduino). Then, instead of including the entire next "frame", determine just what parts have changed (maybe break it down into 4x4 or 8x8 chunks) and only include those chunks. That way, the Arduino just writes the changed chunks rather than the entire image. You will obviously have to come up with some sort of data format to store this data for easy processing by the Arduino. This also allows you to get rid of all the header checking, cropping, endian conversion, row padding logic, etc.

The basic idea is to do all the work once at encoding time so that the decoding/display time is minimal. BTW, this is a very simplified version of what video codecs like MPEG do.

For this to work, there can't be a lot of differences between each frame. It would work best with traditional cell animate generated on a computer. If the original images are digitized from some other source (video, camera, scanner, etc.), there may be subtle changes in almost every pixel even if the frames look the same.

--Doug