Hi all,
I was wondering, is there a display (shield) that has RAM or layers?
I am looking for something similar to what you did on the good old Amiga and other old vintage computers. You would write to a layer, then when it was finished you would swap the layer, with the current one. This process was (nearly) instantaneous. This way a whole screen of text would be replaced by a whole new one, no flickering, no delay...
I was wondering, as displaying graphics and text is so slow on Arduino, is there no display (or driver) that does this?
Would an Arduino with more SRAM help? I regularly use Atmega1284P with 16K SRAM, twice that of a Mega2560 and 8x that of the 328P/Uno.
Here's one of 1284P boards I offer, other form factors at my website http://www.crossroadsfencing.com/BobuinoRev17/
Something has to control the display, and I suspect the best you can do is move the problem rather than fix it. A better approach is to reduce the problem, perhaps.
david_prentice:
What type of display? e.g. 16x2, OLED, TFT, ...
What size of image? e.g. 16x2 characters, 240x320 pixels, ...
What speed of drawing is acceptable?
For the moment I am using an ILI9341 240x320.
I use either ucgLib or GFX lib from adafruit.
The characters I use are 8x8 or 16x16 monospaced.
Acceptable speed... Difficult question. I was hoping there would be boards or screens with a Buffer or GPU build in.
I found the gameduino online but it is out of stock everywhere I checked.
If you could write text to a 'background screen' or ram. then give the screen a command to swap current screen with the new one, you might achieve LIGHTSPEED! or that is how the end user would experience it at least...
Nick_Pyner:
Something has to control the display, and I suspect the best you can do is move the problem rather than fix it. A better approach is to reduce the problem, perhaps.
How would you move the problem?
or reduce it?
What you have to do now is write to the screen pixel by pixel. The libraries I have examined so far, all write to the screen via SPI or even I2C (which is slow). On top of that you have to do it twice. Once to remove the text you have already written (usually with a box in background color) and once to write new text.
I would imagine it would not be difficult to add some RAM, write to that, and have the screen just pull everything off that RAM. The screen could refresh itself from let's say two RAM locations and redraw would look instantaneous.
CrossRoads:
Would an Arduino with more SRAM help? I regularly use Atmega1284P with 16K SRAM, twice that of a Mega2560 and 8x that of the 328P/Uno.
Here's one of 1284P boards I offer, other form factors at my website Cross Roads Electronics
I don't think that would help as I think the bottle neck is the communication with the board, not the speed or memory of the Arduino, or am I mistaken?
If you are only writing text to your TFT display, the Arduino has got plenty enough RAM to store 1000 characters of text.
And any reasonable library can draw the whole screen's worth of text in a few milliseconds. (Obviously UTFT is slow)
Your ILI9341 has either got SPI or Paralel interface. Both are pretty fast.
If you wanted to swap two 240x320 photos "instantly", you would need an external memory to hold the "other" image. e.g. SPI Flash memory chip or an SD card.
If you wanted an external parallel RAM, you would need a MEGA2560 or other MCU with a parallel interface.
david_prentice:
If you are only writing text to your TFT display, the Arduino has got plenty enough RAM to store 1000 characters of text.
even so, you need to communicate it to the shield/screen. I don't think there is an option in the libraries I used so far to print a letter directly from ram...
never encountered something like LCD.print(F("blabla"));
but even then, the variable need not be in RAM the instructions to write a letter does... I think that would require an entire rewrite of the library, no?
I have checked buffered output of text on a Arduino Due with a HVGA 480x320 3.2 TFTLCD Shield.
I used a monochrome pixel buffer and Adafruit_GFX to write to it.
Data is sent to the display through the TFT_HX8357_Due library using a 255 words color pixel buffer and the pushColors() method.
This approach avoids flicker, but the update takes ~260ms and is noticeable.
The disadvantage of this approach is that color is monochrome, the foreground color selected at the time of "updateToTarget()".
Colored graphics could be added by direct calls to the TFT_HX8357_Due target, after the call to "updateToTarget()".
My "Buffered_GFX" class is in preliminary state, needs cleanup and setRotation() and so on, not ready to post.
Next I will try a Wemos D1 mini with 2.8" TFT LCD Shield combination.
or that is how the end user would experience it at least...