CTE TFT Shield v1.04 ILI9325 2.4" display and UTFT_DUE library compatability

Other Hardware Displays
1

I have the following display + shield http://www.sainsmart.com/sainsmart-2-4-tft-lcd-touch-panel-sd-card-slot-shield-for-arduino-mega2560.html and an arduino DUE.
On the shield PCB itself it says for DUE. The display has a ILI9325 controller.

I installed the UTFT library from Electronics - Henning Karlsen

With a bit of tweaking I managed to get the display to work (quite well I might add).
There is also a UTDT_DUE library which I downloaded to try out but have been unable to get this to work.

The related post is #14 of New UTFT Libray with Arduino ARM spport - Arduino Due - Arduino Forum

Are they talking about a different "inter" (made by coldtears?) shield that connects to the LCD which wires the lcd more efficiently hence the speed increase or am I missing something else?

With the working UTFT library I had to uncomment a line #define CTE_DUE_SHIELD (which makes perfect sense) and I had to define the following display UTFT myGLCD(ITDB24,25,26,27,28);

In the UTFT_DUE (the supposed faster library) I see to NO #define CTE_DUE_SHIELD in any of the header files to enable (so I added in several places/files just in case) but still nothing.

Any help would be greatly appreciated.

2

I suspect I need this >> http://www.ebay.co.uk/itm/2-4-inch-TFT-LCD-module-320x240-ILI9325-touchpad-PCB-adapter-arduino-AVR-STM32-/120992686604 can anyone confirm? Has anyone used this?

3

I'm not certain I understand your post and ultimately what your question may be... Let's see if I can summarize:

You bought a shield and lcd to use with your Due. After configuring the UTFT library with your specific configuration, everything works.

So now you're on a quest to make it run... Faster. Correct so far?

If so, why now are referring to a second lcd? It appears to be identical to what you've already purchased with the same resolution and controller so I don't see where this would change your outcome.

It is the shield that determines the pinout/port connections to the Due, not the lcd and its attachment board which typically uses a standard 40 pin configuration that (almost) never changes.

Coldtears did develop an lcd shield specifically for the Due. It re-aligned the mcu I/O pins from the Mega 2560 port configuration to the Due specific port configuration. This significantly reduces the number of instructions required to write data to the lcd which can have a rather large impact on lcd drawing speed.

I would suggest that you find a Coldtears Due shield auction listing and use the links in that to find their documentation which will lead you to a schematic. Compare that to your SainSmart shield and see if the pin outs are the same. If not, the Coldtears shield might improve drawing speed, if they both use the same PORTC and PORTD of the Due, the performance should be the same.

4

You were spot on with all your assumption (I can't have explained myself that badly..)

However, I posted the link to the second display only because of the shield (which has a different pinout) but as the display is soldered to the shield, might have to purchase the lot.

I would suggest that you find a Coldtears Due shield auction listing and use the links in that to find their documentation which will lead you to a schematic. Compare that to your SainSmart shield and see if the pin outs are the same. If not, the Coldtears shield might improve drawing speed, if they both use the same PORTC and PORTD of the Due, the performance should be the same.

That is the shield that that is in the listing of the second LCD is it not? (The free PCB adaptor) which then plugs in to the CTE TFT shield.

5

It was my distracted reading, not your message, very sorry about that.

I would not consider the free pcb a shield - you still need a Due lcd shield in addition to the lcd and the board underneath it. The board closest to the lcd does not establish the connections to the Arduino, the shield board does that.

The connection path is:

LCD -> board #1 -> board #2 -> Arduino

Board 1 provides a touchscreen controller and perhaps a voltage regulator, it terminates with a 2x20 pin header.

Board 2 (the shield) provides level shifting (for non-Due Arduinos) and routes the 2x20 pin lcd signal connector to the appropriate Arduino pins.

You need to compare the shields to understand if the are different.

6

I already have the converter shield for the DUE, it came with LCD number 1. (see first link)
The free PCB is what would you consider the board underneath the lcd is it not?
The picture of LCD number 2 is confusing as the free pcb looks too small to support the entire lcd however the other picture of the lcd attached to the shield shows a bigger PCB?

I have a feeling that lcd 1 (although it works) is not optimal for connecting to the DUE as it also connects to other AVR arduinos with no modifications. SO I thought that free PCB reconfigures the connection to be more "DUE" specific (disregarding connections to other arduino boards)

Thing is, I am little disappointed by the DUEs performance and feel that a lot of the issue is due (no pun intended) to trying to make everything compatible with the 8bit AVRs hardware wise, so, If I know the hardware connections from LCD to DUE are optimal, I can then concentrate on modifying the SW to run the LCD better. A 32-bit ARM M3 should be able to write to a display in parallel mode in its sleep with a decent refresh rate. Who knows, the UTFT_DUE library might already do what I'm trying to achieve. (no one has a definitive answer on this) but I can't verify until I get the correct hardware that works with the UTFT_DUE lib.

edit:- I also took a quick peek at UTFT lib (the generic one) and noticed that my display was configured in 8-bit mode when 16bit should be possible. Maybe hardware related again. (I know that 8bit in this case would not be such a hit in performance but could be one of many of the penalties running in this config if you get my drift)

7

What/where is this UTFT_DUE library you speak of? I take it this is some modified version of Hennings original? What is the nature of the modifications? What aspects of the library have seen speed improvements?

Regards,

Graham

PS avr_fred, I am taking a break with the font ic problem, I hope you don't mind if I get in touch again when I am ready to continue with it? Thanks

Edit: Ok since this post I found UTFT_DUE, it was an early version modified by Coldtears. With UTFT v2.00 upwards, are not the original modifications in UTFT_DUE now incorporated into the mainstream library directly from Henning?

8

Edit: Ok since this post I found UTFT_DUE, it was an early version modified by Coldtears. With UTFT v2.00 upwards, are not the original modifications in UTFT_DUE now incorporated into the mainstream library directly from Henning?

I did think of that but then that doesn't coincide with the UTFT_DUE library not working with my setup unless there is a hardware difference that might not be able to be incorporated with UTFT v2.00?

I only assume there are improvements with UFTF_DUE because UTFT is quite slow (even though its a brilliant library) because I think it caters for too many variables of Arduino Boards and TFT lcds.

A DUE attached to and LCD in parallel mode should be able to achieve 30fps or even 60pfs, correct me if i'm wrong.

9

Ah, now I see what is going on here... He says as he slaps his forehead...

The reason the UTFT_DUE library does not work with your configuration is simple. It assumes you have a Coldtears Electronics (CT) LCD and shield. You have half of the needed pieces.

Your SainSmart (SS) Due shield appears to be a copy of the CT Due shield which is verified by the fact the standard UTFT library works with the CT shield define turned on. But, you do not have a CT lcd.

The CT LCD's contains an spi flash chip that contains images and fonts that you do not have. The UTFT_DUE library demos assumes that chip is present and it does not check - so the software crashes. No display, just a white screen of death.

The second LCD you're mentioning will not change the situation. While the seller is Coldtears, it appears to be a low cost kit without the optional ic. Check their other auctions for the LCD's with their "font ic".

You are running as fast as is possible with the standard version of UTFT with the COLDTEARS DUE SHIELD define enabled. The specific UTFT_DUE library might me marginally faster but probably not worth the cost of a new CT lcd.

What hurts UTFT performance wise is all of the conditional code that is in place to get to the code required by your specific controller and interface method. While UTFT_DUE cuts out a lot of this excess baggage, it still is not as fast as some other approaches. Specifically, have a look at the ILI9325 thread where the Due communicates via dma spi with the controller. This shows what the Due performance should be... and the manual bit-banging methods of UTFT simply pale by comparison.

There was another thread awhile back that demo'ed the hardware support of an SSD1289 lcd controller. That was a real eye-opener. Performance gains of 100 x faster was possible iirc.

10

coldtears:
Here is the modified UTFT library with a newly routed shield for DUE,
all Data pins are routed to PORTC and all command pins are routed to PORTD
only 4 instructions are needed per write strobe.

Filling the screen 800x480 once will take 212ms
Filling the screen 800x480 with an image directly reading from SPI flash using 42Mhz speed with DMA will take 312ms

This should be the maximum ability of DUE as i think should be the mostly optimized.
Of course, any chance to make it faster will be appreciated. ]:smiley:

http://www.youtube.com/watch?v=6EvJUABbedQ

The library is here
http://coldtears.lin3.siteonlinetest.com/files/Arduino_DUE_TFT_library.zip

So in the words of coldtears, everything being optimal, only expecting 3fps with the modified library ... I appreciate your display is only 20% of the stated number of pixels which would imply a potential maximum of 15fps would it not?

Consider yourself corrected :wink: :stuck_out_tongue:

Regards,

Graham

11

avr_fred:
There was another thread awhile back that demo'ed the hardware support of an SSD1289 lcd controller. That was a real eye-opener. Performance gains of 100 x faster was possible iirc.

https://www.youtube.com/watch?v=JXcVw8dwxPw this video? Yeah, seems quick but is this not load of a flash chip also?

12

What you'll hurts UTFT performance wise is all of the conditional code that is in place to get to the code required by your specific controller and interface method. While UTFT_DUE cuts out a lot of this excess baggage, it still is not as fast as some other approaches. Specifically, have a look at the ILI9325 thread where the Due communicates via dma spi with the controller. This shows what the Due performance should be... and the manual bit-banging methods of UTFT simply pale by comparison.

I know what you are saying, I even tried said display with DMA SPI and was astounded at the speed, but this should not compare with a parallel driven display with a proper libraray.

At the end of the day, I was expecting to see this kind of speed or faster >> https://www.youtube.com/watch?v=slPUV2Sv5-A (note, he does not use a full frame buffer which the DUE could as it has more RAM)

Maybe its down to the clock frequency?

13

nibbly:
https://www.youtube.com/watch?v=JXcVw8dwxPw this video? Yeah, seems quick but is this not load of a flash chip also?

No, not what I was referring to. The thread is here: SSD1289 speed ups on a mega with assembler

I was off on my speed up factor for the Mega version. I did not have the time to get a Due version running and the OP kinda dropped out after a short time so the trail went cold in short order once this thread popped up around the same time.

14

I'll probably get one of these >> http://www.ebay.co.uk/itm/like/151351467028?limghlpsr=true&hlpv=2&ops=true&viphx=1&hlpht=true&lpid=108&chn=ps&device=c&adtype=pla&crdt=0&ff3=1&ff11=ICEP3.0.0-L&ff12=67&ff13=80&ff14=108&ff19=0

Some examples of that it can do >>

15

Hi nibbly,

The youtube clips are impressive! I appreciate the clockspeed of the disco is 160Mhz, but even so, that makes the DUE look SH*T in terms of graphics performance!! I have to admit, for £22 for board and display is a BARGAIN!! Makes you wonder if somebody could come up with a ST32 hardware defines file for arduino IDE? such that all the existing arduino libraries could be used...........

Keep us posted how you get on....

Regards,

Graham

16

160MHz is its overclocked speed. Even at default speed (about the same as the DUE) it pastes the DUE on LCD performance. Just had a quick look at the code at it looks like the STM32 is using a built in hardware memory interface to communicate to the LCD. I looked on the DUE processor data sheet but unfortunatelly don't see anything similar. :frowning:

17

Hi nibbly,

180 Mhz is not overclocked, it is the correct speed for that model of cpu, and you are correct, it does have built in TFT controller (and other stuff).

The STM32F429/439 lines offer the performance of the Cortex-M4 core (with floating point unit) running at 180 MHz while reaching lower static power consumption (Stop mode) versus STM32F405/415/407/F417.

Performance: At 180 MHz, the STM32F429/439 deliver 225 DMIPS/608 CoreMark performance executing from Flash memory, with 0-wait states thanks to ST’s ART Accelerator. The DSP instructions and the floating point unit enlarge the range of addressable applications.

Power efficiency: ST’s 90 nm process, ART Accelerator and the dynamic power scaling enables the current consumption in run mode and executing from Flash memory to be as low as 260 µA/MHz at 180 MHz. In Stop mode, the power consumption is 120 µA typical, which is 3 times lower versus STM32F405/415/407/F417.

Graphics: The new LCD-TFT controller interface with dual-layer support takes advantage of Chrom‑ART Accelerator™. This graphics accelerator is performing content creation twice as fast as the core alone. As well as efficient 2-D raw data copy, additional functionalities are supported by the Chrom-ART Accelerator such as image format conversion or image blending (image mixing with some transparency). As a result, the Chrom-ART Accelerator boosts graphics content creation and saves processing bandwidth of the MCU core for the rest of the application.

Integration:
•Audio: 2 dedicated audio PLL, 2 full duplex I²S and a new serial audio interface (SAI) supporting time division multiplex (TDM) mode
•Up to 20 communication interfaces (including 4x USARTs plus 4x UARTs running at up to 11.25 Mbit/s, 6x SPI running at up to 45 Mbit/s, 3x I²C with a new optional digital filter capability, 2x CAN, SDIO)
•Analog: two 12-bit DACs, three 12-bit ADCs reaching 2.4 MSPS or 7.2 MSPS in interleaved mode
Up to 17 timers: 16- and 32-bit running at up to 180 MHz
•Easily extendable memory range using the flexible 90 MHz memory controller with 32-bit parallel interface, and supporting Compact Flash, SRAM, PSRAM, NOR, NAND and SDRAM memories
•Analog true random number generator
•The STM32F439 integrates a crypto/hash processor providing hardware acceleration for AES-128, -192 and -256, with support for GCM and CCM, Triple DES, and hash (MD5, SHA-1 and SHA-2)

The STM32F429 and STM32F439 portfolio provides from 512-Kbyte Flash to 2-Mbyte dual-bank Flash, 256-Kbyte SRAM and from 100 to 216 pins in packages as small as 5 x 5.1 mm. With such memory integration, the need for external memory is reduced, allowing smaller, safer and low-emission PCB designs.

Maybe the Arduino team should look at the M4 core next? All those goodies built in would be an amazing piece of kit, while still keeping the bare-metal approach of arduino which is lost once you get to raspberry pie, beagle bone etc.

Regards,

Graham

PS, the built in TFT controller is rated upto 1024x768 !!! edit: depends where you look, some places say 1280x1024, I have seen SXGA quoted as 15 fps, while the lower resolutions are 30fps!

The LCD Module (STM32F4DIS-LCD) consists of a 3.5 inch LCD and a driver board. This module is designed for to be used with the STM32F4DIS-BB base board.

Signal system: CMOS 1.3 Megapizel
Resolution: Up to 1280 * 1024
Supports still photos
Frame rate: 15 fps for SXGA, 30 fps for VGA and CIF