Hi guys,
so I was playing around with ILI9341 on arduino uno and mega and tried different libraries but it was just slow (especially clearing the screen). So then I tried Due and it was still slow. I found some great libraries like ILI9341_t3 for teensy and SdFat that supports DMA transfers in Due so I decided to put them together and utilize DMA for pushing the pixels.
I also wanted some custom big fonts which do not look like a minecraft art so I also ported the GLCD's gText (although not fully yet).
The result is ILI9341_due library which you can find at ILI9341_due.
A few videos:
Difference in speed between normal, extended and DMA mode (the delays between tests have been removed)
Rendering of a 255px-high font (gText)
BMP loading from an SD card (sdFatTftBitmap demo)
Arcs demo
Last but not least I want to thank developers who created all that great libraries.
Update:
As of version 0.94.000, the library can also be used on Arduino AVR boards like Uno, Mega, Pro Mini, Nano,...
Read the github.io page for some more information.
Video of SdFatTftBitmap example sketch demonstrating loading images from an SD card. The images were converted to RGB565 format using BMP24toILI565 tool (provided with the lib). One image loads and displays in around 190ms (using half speed for SD card SPI as the full speed did not work for me, probably because the SD card pins were connected to Due via a breadboard).
MarekB:
Video of SdFatTftBitmap example sketch demonstrating loading images from an SD card. The images were converted to RGB565 format using BMP24toILI565 tool (provided with the lib). One image loads and displays in around 190ms (using half speed for SD card SPI as the full speed did not work for me, probably because the SD card pins were connected to Due via a breadboard).
Most likely because the level shifting resistors on the TFT PCB weren't removed. you may want to give it a shot.
Now, full speed on a standard Arduino is 8MHz, that's not t even close to full speed on a Due, so I am curious what were the actual SPI clock multiplier settings.
Good stuff otherwise, with a bit of luck someone will port this to the ILI9327 3.5"
Yeah, the resistors, I remembered that I red about it somewhere some time ago so I tried to short-circuit them yesterday and I managed to run the sketch at SD card SPI clock divider set to 2 (TFT SPI clock divider set to 2 as well). That decreased the time to load and show an image to about 130ms (vs 190ms when SD SPI clock divider is set to 4 and TFT SPI clock divider set to 2). But at that speed I was getting artifacts, like some of the pixels (even whole lines) were of wrong color. So I started to mess around with the breadboard and connections and instead of improving the situation I made it worse and ended up with 'File open failed' errors and could not make it work again. So I reverted back to SD card SPI clock divider of 4 and TFT SPI clock divider of 2 which is stable (that's the settings I used for the video).
Can you send me a link to that 3.5" TFT, the ones I found seem to have a parallel interface and not a serial one (or maybe they have both?).
Btw. all the videos work fine for me, try again or try my github page.
MarekB:
Yeah, the resistors, I remembered that I red about it somewhere some time ago so I tried to short-circuit them yesterday and I managed to run the sketch at SD card SPI clock divider set to 2 (TFT SPI clock divider set to 2 as well). That decreased the time to load and show an image to about 130ms (vs 190ms when SD SPI clock divider is set to 4 and TFT SPI clock divider set to 2). But at that speed I was getting artifacts, like some of the pixels (even whole lines) were of wrong color. So I started to mess around with the breadboard and connections and instead of improving the situation I made it worse and ended up with 'File open failed' errors and could not make it work again. So I reverted back to SD card SPI clock divider of 4 and TFT SPI clock divider of 2 which is stable (that's the settings I used for the video).
Can you send me a link to that 3.5" TFT, the ones I found seem to have a parallel interface and not a serial one (or maybe they have both?).
Btw. all the videos work fine for me, try again or try my github page.
Lets see...
On the Due, the system clock can be divided by values from 1 to 255. The default value is 21, which sets the clock to 4 MHz like other Arduino boards.
So with the above 21 x 4 = 84Mhz Clock.
If you are using DIV2 you are effectively driving the SD/TFT at 42MHz.
Sure I can: This is the display. I have the 8bit version from the same seller, but could order the SPI as well (or find a way to re-wire mine in SPI mode)
The first link is working OK today, perhaps some issue with my ISP yesterday.
DMA kicks ass! The rest is useless, I can get my UNO to run faster, using direct port manipulation with an 8 bit display.
Nice work. I got your library working almost working. Well almost, because "graphicstestWithStats" reports an error:
Arduino: 1.5.5 (Linux), Board: "Arduino Due (Programming Port)"
graphicstestWithStats.ino:22: fatal error: ILI9341_due\fonts\Arial_bold_14.h: No such file or directory
compilation terminated.
I also get this error:
Arduino: 1.5.5 (Linux), Board: "Arduino Due (Programming Port)"
graphicstestWithStats.ino:24: fatal error: Streaming.h: No such file or directory
compilation terminated.
Any ideas? I am using Arduino 1.5.5 on Ubuntu. Again: "graphicstest" works perfect.
olikraus:
ok, got the first include fixed, by adding the full path. But "Streaming.h" is still unknown. In fact i did not find such include file on my harddisk.
Oliver
Hi Oliver, comment it out, I use Streaming.h so I can write "Serial << var1 << " " << var2 << " " << var3" instead of many rows of print(...). I sometimes forget to comment out the include. Also make sure all Serial outputs that use << are commented out (I mainly use it for debugging). It should then compile fine.
EDIT:
I noticed that I am actually using << to write the stats on screen so I replaced it with print(...) and removed Streaming.h. You can grab the latest version of that sketch from github.
olikraus:
ok, got the first include fixed, by adding the full path. But "Streaming.h" is still unknown. In fact i did not find such include file on my harddisk.
Based on this http://www.tomshardware.co.uk/answers/id-2015753/error-0xc000007b-fix.html you are probably missing Microsoft C Runtime Packages. I originally created this tool in c++ in a hope that linux people won't have much trouble making it compile under linux (if somebody already done that, please send me the files and I can include it on git).
So to solve your problem, either try installing that C Runtime Packages or wait a few days and I can do a C# version of this app which shall run fine on win8.
Btw. I also plan to add image batch conversion so you don't have to run it one by one.
EDIT: I added a .NET version of BMP24toILI565 on GitHub, see if that helps.
I spend some time to analyse SdSpi.h. I finally ended up to add SdSpi to ucglib (my own graphics lib).
Regarding speed, my results are a litle bit different.
With the standard SPI.h library, results are this:
ILI9341, Arduino Due, HW SPI Text: 12.4 Box: 22.4 Gradient: 16.5
With SdSpi.h and some optimization, i get this:
ILI9341, Arduino Due, HW SdSpi Text: 13.9 Box: 38.0 Gradient: 19.7 with multibyte transfer
My text and gradient speed test do not show much improvement over SPI.h. This means, that the original SPI.h library is already quite good. Main improvement is there in those cases, when multiple bytes need to be transmitted. Here speed is almost doubled.
Yeah, sending byte by byte through DMA will not speed things much. You need to "render" to a buffer (e.g. line by line) and send it in bulk to gain speed.
I do not know how you render gradients but if you would have a buffer for one line, fill it with gradient and then send the whole buffer then I am sure you would gain some speed.
Yes, indeed. For the "gradient" feature, the colors are calculated on the fly and the data is sent pixel by pixel to the SPI subsystem. This does not benefit much from the SdSpi.h at the moment. Writing to an intermediate buffer would probably improve speed.
My biggest fear has been, that ucglib is very slow compared to your library, but i think this is not the case. For some graphics primitives (like box and polygon), there is a good improvent with SdSpi, but for text rendering, results are comparable. But it also shows, that the Arduino SPI library could be optimized for the Due.
MarekB:
... or wait a few days and I can do a C# version of this app which shall run fine on win8.
Btw. I also plan to add image batch conversion so you don't have to run it one by one.
EDIT: I added a .NET version of BMP24toILI565 on GitHub, see if that helps.
The fixes dont´n work for me :~
Operating system suggestions to use BMP24toILI565?, 32 or 64 bits?
I assume you have BMP24toILI565.exe and images you want to convert in the same folder. In the console window you then type "BMP24toILI565 yourimage.bmp" (without the quotes). You should see something like this:
EDIT:
Just uploaded a new version of BMP24toILI565 which can do batch conversion. So you do not have to do the above steps. Just copy BMP24toILI565.exe into folder with the images and run the exe. It will convert all the .bmp images in that folder.
I assume you want to run it on Uno, Mega or similar so your question is a bit off-topic for this thread. Start a new thread and I'll put my asnwer there.
