Hello,
since many of you experienced with SSD1963 controllers, I wanted to ask you, how long it takes the AVR for updating the complete screen once (800x480, 480x272)?
Thank you for your help!
Think about it. 800x480 words. If you are using a 16-bit parallel interface, it is two writes to 8 bit PORTs and one strobe. An OUT is 1 cycle so you have at least 4 cycles per pixel. (providing your data and control lines are on OUT addressible ports)..
Of course, a single colour can mean that you already have the data on the PORTs. You just need 2 cycles for the strobe.
In practice, you actually need to read meaningful data from somewhere for you to have different coloured pixels. LPM instructions are 2 cycles each. No AVR has got enough flash for a whole frame. So you would be reading data from microSD or external memory.
Most Arduinos are 16MHz. I make this 40ms for a fillScreen() and 160ms for a discrete picture() if you unroll loops and can read unlimited memory. It is unlikely that any Arduino sketch or library could ever achieve the maximum speed. These displays are pretty big. Do the sums on a 240x320 display. It is a lot more manageable.
David.
If you can't come up with a useful answer don't bother trying to boggle with science. You are WILDLY off the mark with your calculations anyway.
I don't personally have an SSD1963 based display but I do have an 800480 display with a different controller (CPLD), in answer to your question, on a MEGA to draw a full 800480 image from SD card takes a really long time, in the region of 4 - 4.5 seconds. I upgraded to a DUE which is MUCH better 
Regards,
Graham
Oops. FillScreen() is 800x480x2 cycles @ 62.5ns per cycle is 48ms and not 40ms.
The question was about the "fastest" theoreitical speed.
If you are fetching the data from a microSD card, it is the disk time + 192ms.
Where is my calculation wildly off the mark? Yes, it is made with unrolled loops. Most libraries will attempt to unroll at least 16 pixels at a time. Once you do this level of inrolling, the loop control overhead becomes insignificant.
David.
I am not convinced he was asking about theoretical maximums.......... So I gave an ACTUAL example which ACTUALLY takes seconds , NOT milliseconds!
If you have enough time on your hands to do tedious calculations, put your time to some practical use and write us all a library that will display images from SD quicker than mine......... I for one would be grateful!
Regards,
Graham
The raw pixel data for 800x480 is 768000 bytes. The theoretical maximum for reading a microSD or SPI dataflash chip is 768ms @ 8MHz SCK frequency. If you are using a filesystem there is a certain amount of overhead managing the sectors.
If you wrote your own library, you would have done these calculations at the design stage. No one expects to achieve the absolute maximum, but at least you know the limit. Rereading the original question, that seems to be what the OP wanted to know.
In practice you may want to display standard 24-bit BMP files from a FAT32 filesystem. This means a file size of about 1152000 bytes. i.e. longer to read. Some ARMs can read a microSD high speed interface in hardware. The ARM will do the colour conversion more efficiently than an AVR.
David.
Are you deliberately trying to be obtuse or what?
My library 'UTFT_SdRaw' uses SdFat as the underlying filesystem, and I have built in variable size buffering depending on available RAM (AVR/ARM), the results being an 800*480 image with a 1600 byte buffer on AVR takes 4.6 seconds, the same image on ARM with a 32000 byte buffer takes 900ms. What are trying to say? I don't feel you are answering the original poster's question!!!!
Graham