Print
Go Down
Pages: [1] 2 3 ... 47

Topic: ILI9341(new)SPI library for Due supporting DMA transfer(Uno, Mega,.. compatible) (Read 214473 times) previous topic - next topic

MarekB

Sep 09, 2014, 12:48 pm Last Edit: Jun 13, 2015, 12:23 am by MarekB
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 http://marekburiak.github.io/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.

MarekB

#1
Sep 10, 2014, 10:57 am
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).

http://www.youtube.com/watch?v=4adTpVc_Qog

casemod

#2
Sep 10, 2014, 10:13 pm
Quote from: MarekB on Sep 10, 2014, 10:57 am

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).

http://www.youtube.com/watch?v=4adTpVc_Qog


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" ;)

BTW: Your first video doesn't work?

MarekB

#3
Sep 11, 2014, 10:57 am
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.

casemod

#4
Sep 11, 2014, 06:35 pm Last Edit: Sep 11, 2014, 06:39 pm by casemod Reason: 1
Quote from: MarekB on Sep 11, 2014, 10:57 am

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.  :smiley-eek-blue:

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)

http://www.ebay.com/itm/3-5-inch-SPI-TFT-lcd-shield-for-Arduino-UNO-BANAN-PI-RASPBERRY-PI-PCDUINO-/301305413682?pt=LH_DefaultDomain_0&hash=item462733c032

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.

olikraus

#5
Sep 11, 2014, 10:07 pm
Hi MarekB

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.

Thanks, Oliver

casemod

#6
Sep 11, 2014, 10:16 pm
I find Linux and Windows versions quite different.

I have a few projects that refuse to compile on the windows compiler, when they work fine on Linux.

TFTLCDCyg

#7
Sep 11, 2014, 11:04 pm
Quote from: olikraus on Sep 11, 2014, 10:07 pm

...
graphicstestWithStats.ino:22: fatal error: ILI9341_due\fonts\Arial_bold_14.h: No such file or directory
compilation terminated.
...


In windows, the path-line to the font folder is:

#include "C:\Users\(User)\Documents\Arduino\libraries\ILI9341_due\fonts\Arial_bold_14.h"



Thanks MarekB
ft81xmania.com/comunidad/

olikraus

#8
Sep 11, 2014, 11:39 pm
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

TFTLCDCyg

#9
Sep 12, 2014, 12:08 am
Windows 8 pro, 64 bits

Error 0xc000007b with BMP24toILI565    :~

Any idea to fix this?

ft81xmania.com/comunidad/

MarekB

#10
Sep 12, 2014, 12:37 am Last Edit: Sep 12, 2014, 01:24 am by MarekB Reason: 1
Quote from: olikraus on Sep 11, 2014, 11:39 pm

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.

casemod

#11
Sep 12, 2014, 12:43 am
Quote from: olikraus on Sep 11, 2014, 11:39 pm

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



I believe this is the right library:

http://arduiniana.org/libraries/streaming/

MarekB

#12
Sep 12, 2014, 12:50 am Last Edit: Sep 12, 2014, 02:30 pm by MarekB Reason: 1
Quote from: TFTLCDCyg on Sep 12, 2014, 12:08 am

Windows 8 pro, 64 bits

Error 0xc000007b with BMP24toILI565    :~

Any idea to fix this?




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.

olikraus

#13
Sep 12, 2014, 04:50 pm
Hi

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.

Oliver

MarekB

#14
Sep 12, 2014, 05:33 pm Last Edit: Sep 12, 2014, 05:36 pm by MarekB Reason: 1
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.
Print
Go Up
Pages: [1] 2 3 ... 47