Go Down

Topic: ITDB32S direct write or 'poke' display memory? (Read 1 time) previous topic - next topic

ghlawrence2000

Hey all :D

I wonder if any of the collective genious out there can help me?

I have a project that requires drawing a small portion (240x240px) of a large image (4000x4000px) to TFT. I have figured out the offset maths and produced valid screen displays, BUT it is taking approx 18 seconds to draw this 240x240px image!!! This is way too slow for what I want.

Back in my younger days of BBC Micro B programming, I remember 'peeking' and 'poking' operating system memory, which was MUCH faster than OS calls to do the same thing.....Is there anything similar on Arduino?

My current setup is a MEGA2560/ITDB32S/Touch/SD.

My present code is thus :-

void drawmap(unsigned int offsetx, unsigned int moffsetx, unsigned int msizex, unsigned int offsety, unsigned int moffsety, unsigned int msizey, char *filename)
  {
    unsigned long thisroutine, singleLine, foffset;
    byte b,g,r;
    thisroutine=millis();
    offsetx=offsetx*3;
//    myprintf("Mapref %s\n",mapref);
//    myprintf("Filename %s\n",filename);
//    myprintf("mylocation (x,y) (%d,%d)",mylocation.x,mylocation.y);
//    myprintf("maplocation (x,y) (%d,%d)",maplocation.x,maplocation.y);
//    myprintf("screenlocation (x,y) (%d,%d)",screenlocation.x,screenlocation.y);
    File dataFile = SD.open(filename);
//    file.initFAT(SPISPEED_VERYHIGH);
    if (!dataFile) {myprintf("File Open failed, or not present\n");return;}
    else
    {
//        myprintf("Opened bmp successfully!! Time taken %d ms\n",millis()-thisroutine);
//        thisroutine=millis();
        dataFile.read(&header.type,2);
        dataFile.read(&header.size,4);
        dataFile.read(&header.reserved1,2);
        dataFile.read(&header.reserved2,2);
        dataFile.read(&header.offset,4);
        dataFile.read(&infoheader.size,4);
        dataFile.read(&infoheader.width,2);
        dataFile.read(&infoheader.height,2);
        dataFile.read(&infoheader.planes,2);
        dataFile.read(&infoheader.bits,2);
        singleLine=(infoheader.width)*3;
//        myprintf("BMP Headers read in %d ms\n",millis()-thisroutine);
//        thisroutine=millis();
        for (int y=moffsety; y<moffsety+msizey; y++)
        {
          timer.run();
          foffset=((y+offsety)*singleLine)+offsetx+header.offset;
          dataFile.seek(foffset);
          for (int x=moffsetx; x<moffsetx+msizex;x++)
          {
            b=dataFile.read();
            g=dataFile.read();
            r=dataFile.read();
            myGLCD.setColor(r,g,b);
            myGLCD.drawPixel(x,240-y);
          }
        }
    }
//ticker=0;
    dataFile.close();
//    myprintf("Closed bmp successfully!!\n");
//    end of drawmap
    myprintf("Routine finished in %d ms\n",millis()-thisroutine);
}

I am using the fabulous Henning Karlson libraries, but still it is way too slow.....
The average re-draw time using the code shown is 17963ms per re-draw.....
Could anyone propose an alternative method of doing this with faster results please?

Thanks in advance!

Graham

olikraus

1) drawPixel is not the only cause for the delay. Try to optimize SD card access (for example by reading multiple bytes with one command)
2) "poke" will not work, because the display memory is not memory mapped into the controller. Display data usually is transfered via SPI or parallel interface.

Oliver

ghlawrence2000

Thanks Oliver,

         for (int x=moffsetx; x<moffsetx+msizex;x++)
         {
           dataFile.read(&mycolour,3);
           //g=dataFile.read();
           //r=dataFile.read();
           myGLCD.setColor(mycolour.r,mycolour.g,mycolour.b);
           myGLCD.drawPixel(x,240-y);
         }

The modification above made 3.5seconds improvement, it is now just about 14.4s per redraw.

Graham

Doddy

Look into the datasheet for the display - you can define a rectangle of Width/Height and then write the 16-bit RGB encoded value with auto-increment of X/Y allowing the rectangular region to be populated without having to write coordinates onto the bus. This is about as fast as you can hope for with this display. Take a look at the filled-rect function in the library to understand how to go about this.


ghlawrence2000

Thanks Doddy,

I actually tackled this from another angle. I wrote a PC console app to 'chop up' my large BMP images into overlapping 240x240 RAW images. Then just used the Henning Karlsen loadBitmap function from the UTFT suite of libraries.

The result was most satisfying at approximately 1.17 seconds per re-draw.

However this presented its own set of problems....

I will create a new thread to continue the story since it is not directly related to displays beyond this point.

Graham.


Go Up