ili9486 tft display arduino library bodmer price

An excellent new compatible library is available which can render TrueType fonts on a TFT screen (or into a sprite). This has been developed by takkaO, I have created a branch with some bug fixes here. The library provides access to compact font files, with fully scaleable anti-aliased glyphs. Left, middle and right justified text can also be printed to the screen. I have added TFT_eSPI specific examples to the OpenFontRender library and tested on RP2040 and ESP32 processors, the ESP8266 does not have sufficient RAM due to the glyph render complexity. Here is a demo screen where a single 12kbyte font file binary was used to render fully anti-aliased glyphs of gradually increasing size on a 320x480 TFT screen:

Support has been added in v2.4.70 for the RP2040 with 16 bit parallel displays. This has been tested and the screen update performance is very good (4ms to clear 320 x 480 screen with HC8357C). The use of the RP2040 PIO makes it easy to change the write cycle timing for different displays. DMA with 16 bit transfers is also supported.

Smooth fonts can now be rendered direct to the TFT with very little flicker for quickly changing values. This is achieved by a line-by-line and block-by-block update of the glyph area without drawing pixels twice. This is a "breaking" change for some sketches because a new true/false parameter is needed to render the background. The default is false if the parameter is missing, Examples:

New anti-aliased graphics functions to draw lines, wedge shaped lines, circles and rounded rectangles. Examples are included. Examples have also been added to display PNG compressed images (note: requires ~40kbytes RAM).

Frank Boesing has created an extension library for TFT_eSPI that allows a large range of ready-built fonts to be used. Frank"s library (adapted to permit rendering in sprites as well as TFT) can be downloaded here. More than 3300 additional Fonts are available here. The TFT_eSPI_ext library contains examples that demonstrate the use of the fonts.

Users of PowerPoint experienced with running macros may be interested in the pptm sketch generator here, this converts graphics and tables drawn in PowerPoint slides into an Arduino sketch that renders the graphics on a 480x320 TFT. This is based on VB macros created by Kris Kasprzak here.

The RP2040 8 bit parallel interface uses the PIO. The PIO now manages the "setWindow" and "block fill" actions, releasing the processor for other tasks when areas of the screen are being filled with a colour. The PIO can optionally be used for SPI interface displays if #define RP2040_PIO_SPI is put in the setup file. Touch screens and pixel read operations are not supported when the PIO interface is used.

An Arduino IDE compatible graphics and fonts library for 32 bit processors. The library is targeted at 32 bit processors, it has been performance optimised for RP2040, STM32, ESP8266 and ESP32 types, other processors may be used but will use the slower generic Arduino interface calls. The library can be loaded using the Arduino IDE"s Library Manager. Direct Memory Access (DMA) can be used with the ESP32, RP2040 and STM32 processors with SPI interface displays to improve rendering performance. DMA with a parallel interface (8 and 16 bit parallel) is only supported with the RP2040.

For other processors only SPI interface displays are supported and the slower Arduino SPI library functions are used by the library. Higher clock speed processors such as used for the Teensy 3.x and 4.x boards will still provide a very good performance with the generic Arduino SPI functions.

"Four wire" SPI and 8 bit parallel interfaces are supported. Due to lack of GPIO pins the 8 bit parallel interface is NOT supported on the ESP8266. 8 bit parallel interface TFTs (e.g. UNO format mcufriend shields) can used with the STM32 Nucleo 64/144 range or the UNO format ESP32 (see below for ESP32).

The library supports some TFT displays designed for the Raspberry Pi (RPi) that are based on a ILI9486 or ST7796 driver chip with a 480 x 320 pixel screen. The ILI9486 RPi display must be of the Waveshare design and use a 16 bit serial interface based on the 74HC04, 74HC4040 and 2 x 74HC4094 logic chips. Note that due to design variations between these displays not all RPi displays will work with this library, so purchasing a RPi display of these types solely for use with this library is NOT recommended.

A "good" RPi display is the MHS-4.0 inch Display-B type ST7796 which provides good performance. This has a dedicated controller and can be clocked at up to 80MHz with the ESP32 (125MHz with overclocked RP2040, 55MHz with STM32 and 40MHz with ESP8266). The MHS-3.5 inch RPi ILI9486 based display is also supported, however the MHS ILI9341 based display of the same type does NOT work with this library.

Some displays permit the internal TFT screen RAM to be read, a few of the examples use this feature. The TFT_Screen_Capture example allows full screens to be captured and sent to a PC, this is handy to create program documentation.

The library supports Waveshare 2 and 3 colour ePaper displays using full frame buffers. This addition is relatively immature and thus only one example has been provided.

The library includes a "Sprite" class, this enables flicker free updates of complex graphics. Direct writes to the TFT with graphics functions are still available, so existing sketches do not need to be changed.

The "Animated_dial" example shows how dials can be created using a rotated Sprite for the needle. To run this example the TFT interface must support reading from the screen RAM (not all do). The dial rim and scale is a jpeg image, created using a paint program.

The XPT2046 touch screen controller is supported for SPI based displays only. The SPI bus for the touch controller is shared with the TFT and only an additional chip select line is needed. This support will eventually be deprecated when a suitable touch screen library is available.

The library supports SPI overlap on the ESP8266 so the TFT screen can share MOSI, MISO and SCLK pins with the program FLASH, this frees up GPIO pins for other uses. Only one SPI device can be connected to the FLASH pins and the chips select for the TFT must be on pin D3 (GPIO0).

The library contains proportional fonts, different sizes can be enabled/disabled at compile time to optimise the use of FLASH memory. Anti-aliased (smooth) font files in vlw format stored in SPIFFS are supported. Any 16 bit Unicode character can be included and rendered, this means many language specific characters can be rendered to the screen.

The library is based on the Adafruit GFX and Adafruit driver libraries and the aim is to retain compatibility. Significant additions have been made to the library to boost the speed for the different processors (it is typically 3 to 10 times faster) and to add new features. The new graphics functions include different size proportional fonts and formatting features. There are lots of example sketches to demonstrate the different features and included functions.

Configuration of the library font selections, pins used to interface with the TFT and other features is made by editing the User_Setup.h file in the library folder, or by selecting your own configuration in the "User_Setup_Selet,h" file. Fonts and features can easily be enabled/disabled by commenting out lines.

Anti-aliased (smooth) font files in "vlw" format are generated by the free Processing IDE using a sketch included in the library Tools folder. This sketch with the Processing IDE can be used to generate font files from your computer"s font set or any TrueType (.ttf) font, the font file can include any combination of 16 bit Unicode characters. This means Greek, Japanese and any other UCS-2 glyphs can be used. Character arrays and Strings in UTF-8 format are supported.

It would be possible to compress the vlw font files but the rendering performance to a TFT is still good when storing the font file(s) in SPIFFS, LittleFS or FLASH arrays.

Anti-aliased fonts can also be drawn over a gradient background with a callback to fetch the background colour of each pixel. This pixel colour can be set by the gradient algorithm or by reading back the TFT screen memory (if reading the display is supported).

The common 8 bit "Mcufriend" shields are supported for the STM Nucleo 64/144 boards and ESP32 UNO style board. The STM32 "Blue/Black Pill" boards can also be used with 8 bit parallel displays.

Unfortunately the typical UNO/mcufriend TFT display board maps LCD_RD, LCD_CS and LCD_RST signals to the ESP32 analogue pins 35, 34 and 36 which are input only. To solve this I linked in the 3 spare pins IO15, IO33 and IO32 by adding wires to the bottom of the board as follows:

If the display board is fitted with a resistance based touch screen then this can be used by performing the modifications described here and the fork of the Adafruit library:

If you load a new copy of TFT_eSPI then it will overwrite your setups if they are kept within the TFT_eSPI folder. One way around this is to create a new folder in your Arduino library folder called "TFT_eSPI_Setups". You then place your custom setup.h files in there. After an upgrade simply edit the User_Setup_Select.h file to point to your custom setup file e.g.:

You must make sure only one setup file is called. In the custom setup file I add the file path as a commented out first line that can be cut and pasted back into the upgraded User_Setup_Select.h file. The ../ at the start of the path means go up one directory level. Clearly you could use different file paths or directory names as long as it does not clash with another library or folder name.

An Arduino IDE compatible graphics and fonts library for Mega with a drivers for the HX8357B, HX8357C, ILI9481 and ILI9486 based TFT displays with a 16 bit parallel interface. This library will not run on an UNO and it does not support 8 bit UNO shields.

The library contains proportional fonts, different sizes can be enabled/disabled at compile time to optimise the use of FLASH memory. The library has been tested with the Mega.

In addition to the default fonts (1, 2, 4, 6, 7 and 8) the library includes and supports the encoded Free Fonts from the new Adafruit_GFX library. Unlike the Adafruit_GFX library these fonts can be automatically rendered with background and padding to over-write and erase old text, see the examples.

The library is based on the Adafruit GFX library and the aim is to retain compatibility. Significant additions have been made to the library to boost the speed for the Mega processor and to add new features. The new graphics functions include different size proportional fonts and formatting features. There are a significant number of example sketches to demonstrate the different features.

Configuration of the library font selections and other features is made by editting the User_Setup.h file in the library folder. Fonts and features can easily be disabled by commenting out lines.

This HX8357B based display does appear to have a bug in the silicon of the driver chip as it sometimes generates spurious pixels on the display. The only way around this is to redraw the whole screen occasionally to wipe out the duff ones, this is most noticeable for intensive updates in small screen areas (e.g. in ring meter sketch). So my suggestion is to go for the next revision driver, the HX8357C with 3" TFT which does not exhibit the same problem:

I started with an Arduino DUE board that I"ve added WiFi and SD breakout modules to. I have a 2.8" TFT display that works fine using this GitHub - marekburiak/ILI9341_due: Arduino Due and AVR (Uno, Mega, Nano, Pro Mini,...) library for interfacing with ILI9341 SPI TFTs and JPEGDecoder. Unfortunately, this display has bad color distortion at various viewing angles so I"d like to replace it with slightly larger 3.5" 320x480 displays.

I have a WaveShare 3.5" that supposedly uses ILI9486 and appears a bit better at various viewing angles, but I"ve only gotten it working using ILI9488 from GitHub - jaretburkett/ILI9488: Arduino Library for the ILI9488 TFT controller for 4 wire SPI - mostly because I can"t find a ILI9486_DUE type of library...I believe that HX8357 can work, but I ran into trouble using it. While I can use Bodmer"s TFT_HX8357_Due version, it"s missing the ILI9486 driver that got merged into the regular TFT_HX8357 version. I can"t use the regular TFT_HX8357 since I"m on a due. (Should I be trying to merge these two?) The sample code provided with the display isn"t for due either (https://www.waveshare.com/wiki/3.5inch_TFT_Touch_Shield) but I"d rather work with something closer to what I"m used to if I can also.

The WaveShare mostly works for me; I am able to draw background colors, write text, and so on using the ILI9488 driver. This is the code that"s specifically giving me trouble with ILI9488 and the JPEGDecoder library:

I"ve tried both of the methods above and the first line (pushColor) produces distorted grey blocks with a slight resemblance of the original JPG, whereas the latter (pushColors) simply produces no output to the TFT for me.

This is all probably pretty vague, but I"m hoping someone a bit more familiar with this sort of thing can help steer me in the right direction... Should I be trying to modify the pushColor/pushColors functionality of the ILI9488 driver, or should I be using a different driver? Should I try merging the ILI9486 driver from TFT_HX8357 into TFT_HX8357_DUE? Should I be trying to use the ILI9341_DUE driver that I had working with the 2.8" display but adapting it to these WaveShare 3.5" displays?

Surely the TFT_MISO line will tri-state properly. After all, it works fine on ILI9341. You should disable the SPIREAD_EN bit (7) after you have used SPIREAD_CMD (0xFB) to read an internal register.

It should be easy enough to read the ID of the ILI9488 on the Red board. Or to do some write-only diagnostics to distinguish it from RM68140, R61581, ILI9481, ILI9486, ...

Hi ! Upping this thread as i have a problem with what looks like the board described by bodmer. I have been at this for like a month and cannot figure out what it is.

The board is a 3.5" TFT touchscreen, on an arduino due, bought from fasttech. Pics are the same... Seller writes this is an ili9486 controler , but the mcufriend read ID code says this is an ILI9341 or 9488. And i could not make it work with mcufriend_kbv, all i get is a blank screen, serial says ID = 0x414.

Here is the display i get when running only the testrect example, after filling the screen with black (notice on the left how it actually started to fill the screen with black, but failed after a couple lines and a half)

Anyway now I commented that line, beacuse I am not interested in speed right now. But now the problem seems to be the programation code. the error message is as follows: ( I am using Arduino 1.8.7)

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:101:37: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:106:42: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:118:39: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:121:42: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:151:40: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:163:39: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:176:37: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:183:38: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:188:38: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:193:38: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:198:38: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:205:39: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:210:39: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:215:39: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:220:39: warning: ISO C++ forbids converting a string constant to "char*" [-Wwrite-strings]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino: In function "void drawBMP(char*, int, int, boolean)":

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:267:40: warning: converting to non-pointer type "int" from NULL [-Wconversion-null]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino: In function "void drawRAW(char*, int16_t, int16_t, int16_t, int16_t)":

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2\ILI9341_draw_bitmap_v2.ino:377:40: warning: converting to non-pointer type "int" from NULL [-Wconversion-null]

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2/ILI9341_draw_bitmap_v2.ino:355: undefined reference to `FatFile::close()"

C:\Users\ADMIRAL\Videos\arduino\Libraries\Adafruit_ILI9341_AS\examples\ILI9341_draw_bitmap_v2/ILI9341_draw_bitmap_v2.ino:338: undefined reference to `FatFile::read(void*, unsigned int)"

A number of display resolutions are supported. Assembled 480 x 320 TFT’s that have an SPI interface are rare. The 480 x 320 display supported by the library is an ILI9486 display designed for the Raspberry Pi by Waveshare. Clones are available 3.5″ and 4.0″ for circa $15. This RPi board design uses a 16 bit shift register (2x 74HC4094), a counter (1 x 74HC4040) and a hex inverter (74HC04). Many other RPi interface designs are sold that are not of this design so be careful if you are looking to buy a display!

Performance is reasonable but the display circuit design limits the SPI clock rate to 20MHz. An image in the library “Tools” folder of the library shows a hack to add a write strobe that boosts the speed for block writes (e.g. clear 480×320 screen in 24ms) and faster rendering Run Length Encoded fonts (1.2ms for 72 pixel height digit). The hack also delays the Write strobe from the 74HC4040 just enough to let the circuit run at a higher 27MHz SPI clock rate too.

The ILI9341 is typically a 320 240 TFT, these display drivers are good and almost work at 80MHz SPI clock rate (data sheet spec. is 25MHz). Expect some duff pixels at 80MHz but they seem to work reliably at 40MHz.

TFT LCDs are the most popular color displays – the displays in smartphones, tablets, and laptops are actually the TFT LCDs only. There are TFT LCD shields available for Arduino in a variety of sizes like 1.44″, 1.8″, 2.0″, 2.4″, and 2.8″. Arduino is quite a humble machine whenever it comes to process or control graphics. After all, it is a microcontroller platform, and graphical applications usually require much greater processing resources. Still, Arduino is capable enough to control small display units. TFT LCDs are colorful display screens that can host beautiful user interfaces.

Most of the smaller TFT LCD shields can be controlled using the Adafruit TFT LCD library. There is also a larger TFT LCD shield of 3.5 inches, with an ILI9486 8-bit driver.

The Adafruit library does not support the ILI9486 driver. Actually, the Adafruit library is written to control only TFT displays smaller than 3.5 inches. To control the 3.5 inch TFT LCD touch screen, we need another library. This is MCUFRIEND_kbv. The MCUFRIEND_kbv library is, in fact, even easier to use in comparison to the Adafruit TFT LCD library. This library only requires instantiating a TFT object and even does not require specifying pin connections.

TFT LCDs for ArduinoUser interfaces are an essential part of any embedded application. The user interface enables any interaction with the end-user and makes possible the ultimate use of the device. The user interfaces are hosted using a number of devices like seven-segments, character LCDs, graphical LCDs, and full-color TFT LCDs. Out of all these devices, only full-color TFT displays are capable of hosting sophisticated interfaces. A sophisticated user interface may have many data fields to display or may need to host menus and sub-menus or host interactive graphics. A TFT LCD is an active matrix LCD capable of hosting high-quality images.

Arduino operates at low frequency. That is why it is not possible to render high-definition images or videos with Arduino. However, Arduino can control a small TFT display screen rendering graphically enriched data and commands. By interfacing a TFT LCD touch screen with Arduino, it is possible to render interactive graphics, menus, charts, graphs, and user panels.

Some of the popular full-color TFT LCDs available for Arduino include 3.5″ 480×320 display, 2.8″ 400×200 display, 2.4″ 320×240 display and 1.8″ 220×176 display. A TFT screen of appropriate size and resolution can be selected as per a given application.

If the user interface has only graphical data and commands, Atmega328 Arduino boards can control the display. If the user interface is a large program hosting several menus and/or submenus, Arduino Mega2560 should be preferred to control the TFT display. If the user interface needs to host high-resolution images and motions, ARM core Arduino boards like the DUE should be used to control the TFT display.

MCUFRIEND_kbv libraryAdafruit TFT LCD library supports only small TFT displays. For large TFT display shields like 3.5-inch, 3.6-inch, 3.95-inch, including 2.4-inch and 2.8-inch TFT LCDs, MCUFRIEND_kbv library is useful. This library has been designed to control 28-pin TFT LCD shields for Arduino UNO. It also works with Arduino Mega2560. Apart from UNO and Mega2560, the library also supports LEONARDO, DUE, ZERO, and M0-PRO. It also runs on NUCLEO-F103 and TEENSY3.2 with Sparkfun Adapter. The Mcufriend-style shields tend to have a resistive TouchScreen on A1, 7, A2, 6 but are not always in the same direction rotation. The MCUFRIEND_kbv library can be included in an Arduino sketch from the library manager.

The 3.5-inch TFT LCD shield needs to be plugged atop the Arduino board. The Mcufriend-style shields are designed to fit into all the above-mentioned Arduino boards. The shields have a TFT touch screen that can display colorful images and interfaces and a micro SD card reader to save images and other data. A 3.5-inch TFT LCD touch screen has the following pin diagram.

How project worksThe code fills a rectangle, then draws a rectangle within which text “EEWORLDONLINE” is displayed. Then, lines, circles, rectangles, and squares are drawn on the screen. The project ends with a greeting and a message.

In my searches for an appropriate board I realized that Arduino compatible 2.4 inch touch TFTs with SPI interface have almost the same price as 3.5 inch 480×320 touch TFT display modules for RPi. I decided to buy one of these.

Also, the nature of the ILI9341 SPI commands e.g to set individual pixels by sending address then value, is very inefficient, especially as the default Adafruit library does not buffer these transfers into one larger SPI transfer.

Most TFT controllers can be configured for 8-bit SPI. The minimum write-cycle is marginally faster with 8080 parallel-interface. The minimum read-cycle is faster with SPI than parallel. OTOH, SPI is easily controlled with DMA.

As far as I know, RPi drives the display as “frame buffer”. It means, it has a complete image buffer in RAM and writes it as a whole frame always all over again with high speed to the display. So it does not need to change the window coordinates, no switch between command and data select. That’s why it can really work with DMA.

I have a custom made PCB I am using for these tests, which has a maple mini on one side and the ILI9341 display on the other, so that the wires (pcb tracks) are quite short ( approx 3 cm)

Using double buffering would allow the best use of DMA ( if we had a completion callback) as calculation of line, pixel and text drawing must be taking almost as much time as the SPI data transfer to the display

I was having a look at those numbers, and I’m surprised too at getting the same speed with DMA and without, but I also noticed you can’t run the display at the max SPI speed.

A while back when porting the sd-fat library I did some tests with and without DMA at slower SPI speeds, and noticed pretty much the same, up to a certain point DMA was not faster than normal.

If I remember right, I did some test with the ILI library where it would only use DMA if the line to draw was longer than N pixels, and use the normal transfer for smaller lines, and found the minimum number of pixels for DMA to make a difference. Still the gains over using DMA all the time at full speed were not significant, but did show that normal transfers were faster if under a number of bytes.

Victor, the tests ran at 36 MHz, but the display was partially corrupted. Before any optimization, the corruption was not that significant that after. If I speed-optimize the register writing, than i have more problems, randomly.

It looks a lot like they may be salvaged from old mobile phones, I had similar issues with the Nokia 5110 displays from eBay as a lot of them are not actually “new” (as advertised), they are salvaged and are often not even cleaned so were covered in whatever grime was in the mobile phone form years of use

Your comparison makes only sense if you compare same graphicstest software running on the same controller board (MM or blue pill) controlling same display controller (ILI9341?), driving same display resolution (320×240) in two different modes (parallel and serial at maximum possible speed).

stevestrong wrote:If you look on the scope screenshot (second blue/cyan block), you will observe that the SPI stream is continuous, no need for the controller to generate extra WR strobe between consecutive pixel data. This is managed by the hardware serial->parallel circuit on the display board.

This would provide a “sprite” transfer capability, cut out from a single source containing image and transferred through DMA to the display at the desired destination position. With little modifications, this could be used for fixed/variable font rendering too.

The ILI9486 specifies a WR cycle time of 50 ns min. (twc in datasheet, page 212), thus you are limited to 20 MHz on the 8080 interface side. The limit will be the HCT chips at the given VCC.

From fbtft sources, the RPi looks like it is driving this display @ 32 MHz, but this is using a full continuously refreshed frame buffer, so a glitch won’t be as noticeable as it will be redrawn on next frame anyway.

That’s interesting! I wonder which other ILI controllers have the same. That could make for really fast display drivers even with small buffers, and minimal cpu usage.

Just had a look at the ILI9341 datasheet, and supports a mode without D/C line, I guess there is some track cutting and soldering involved to reconfigure the display. Looks like the serial mode without DC line in the ILI9341 is serial 9bit, which complicates things in other ways

Yes, because of this, fast TFT screen circuits are using 8 or 16-bit parallel modes, since the controller built-in 3 or 4-wire SPI modes are getting roughly the same toggling speed, you get transfer performance divided by 8 or 16.

And although the RaspPi is driving the SPI @ 32 MHz which is above the guaranteed maximum frequency, it is still in the typical achievable ones, and as again the Pi is using a full frame buffer with continuous refresh, a glitch will get unnoticed, whereas the way the Arduino TFT library uses it is completely different, and pushing the transfer frequency to the limits will result in corrupted displays (if in data mode) or may hang the controller (if in register mode).

So my first guess is that Bodmer’s library is using the SPI library. And the SPI library limits SCK frequency to 40MHz. Edit. Bodmer’s User_Setup.h file specifies maximum 40MHz for SCK

The AVR SPI peripheral always has “gaps”. The AVR USART_MSPI peripheral can achieve full speed with no gaps. Of course you need a good Arduino SPI library to get the best out of the hardware.

Bodmers said that he gets occasional glitches with SCK=80MHz. I was running my standard “graphictest_kbv.ino” sketch through a GLUE class. I did not observe any glitches. I am familiar with where gliches can occur from my parallel targets.

The current SPI lib of Arduino_STM32 is already “gap-less” in non-DMA mode. That’s why all graphic test (except one) without DMA performs equal or better than with DMA, due to lacking DMA overhead.

I cannot see how any RPi would work correctly with this display at 40MHz, without any HW hacks. I saw blogs where rather 16MHz was suggested to be used, this sounds a lot more realistic. Also, there are several versions of such boards, maybe there are others with better characteristics/controllers.

Otherwise I see myself forced to remove the HC chips from the display board and drive the display with 16 bits parallel directly from BP (using PB0..15).

An “unreadable” display does not really interest me. However, it would be interesting to see just how fast your shift registers will work. After all, the 16-bit parallel could be driven up to 10x faster.

David, my original intention was just to have one display which is SPI driven. I have already one 240×320 display which is 8 bit parallel driven, and, of course, is much faster than this one. Here, I am limited by the serial->parallel converter.

Sorry. tDST is the data setup time before the active edge of /WR in the 8080 parallel interface. (ST7789 nomenclature. The ILI9486 datasheet might use a different acronym)

As far as I can see, a stock HC4040 is going to produce the WR signal before the HC4094 has loaded the shift register. i.e. it will be wrong for the ILI9486 and also wrong for the HC4094 to latch the shift register.

Still, there is one clock period delay at 36MHz between WR and data. That means, the color data is sampled as being is shifted one bit left. For example, if I want a red color (0x8000), the display controller will get 0x0001 sampled because of this one clock period propagation delay of WR edge relative to the parallel shifted data.

The chip works >150MHz internally, when routed you can mess with counters, shift registers and whatever logic you want at 80-90Mhz sure. The logic guys need is about 10 lines of verilog, or, with schematic capture the same schematics as above, as the library includes dozens components like those the guys use now for the tft (almost all ttl/cmos standard chips people mess with).

The trick is when you want to change something in the schematics – wiring or add a component or invert a signal, or fully change your design, you do it on the screen and then just flash – the same process as with arduino. The XC9536XL family has got flash memory for the wiring, programmble via jtag.The dev cycle is about 1-2minutes to change and run. And the chip is 100% routable so you can connect your tft to whatever pins you want – it always fits your new design/schematics to existing pin layout on the pcb (or in other words – your design can be always routed to any i/o pin setup you want).

Here is a 32bit freqmeter/periodmeter/counter in an XC9572XL I did 5y back for arduino forum as an example. It includes 2x16bit counters and 2x16bit shift registers and some logic (arduino had read the freq measured off the chip serially, only 7 pins used). The ring oscillator (3 invertors in loop) there did 150MHz freq.

I am still thinking where should the SPI initialization take place: outside the ILI9486 driver, in setup phase, before or within the driver begin() function?

I am still thinking where should the SPI initialization take place: outside the ILI9486 driver, in setup phase, before or within the driver begin() function?

Compiling the code from github produces some errors (not a problem), but one of them is the following – which is an apparent mismatch with SPI.cpp in hardware\Arduino_STM32\STM32F1\libraries\SPI\src.

The core of the issue (apart from my mis-paste from the core SPI library) seems to be that I was using the SPI library from Roger’s master repo, rather than Steve’s amended one.

I have used the SPI example in the STM32 library to test the SPI communication and the display responds always with the pattern 0x55, does it mean the communication is OK? I have disconnected it and I have got 0xFF!!! Looked fine to me!!

Well! Afterwards I could run the ILI9486 example program and got the run times statistic quite similar to the one in beginning of this post (see below!)

The problem is, that the display is just flashing white synchronously to the test sequences. After doing some debugging with Atollic , I could not detect any error.

I have followed all the hints above, but I could not run any demo on this display. The device I have bought looks exactly the same as yours at the beginning of this post. I have tried your example with no positive results. Obviously there is a serial parallel converter on the board, that why it is a write only device. I have tried ILI9481 and ILI9486 . If the controller is not ILI9486, what might it be?

It looks as if your display was made by WaveShare. So there is probably a schematic. So it should be easy to guess how the hardware needs to be driven.

Most 320×480 controllers are MIPI compliant. And probably start up by themselves. Just Reset, Display Off, Wake up, Display On. (with some pauses)

Finally I have got it done! I have found out the right initialisation sequence. The SPI frequency is crucial. The display works only in the range between 12MHz and 32MHz only. Any frequency out of this range lead to white flashing on the screen!

Hi. After spending a lot of time and seeing that the pin connection was correct, I decided to change the 5v power supply of the display and then the sketch of REG_ID showed that “reg (0x0000) 45 35” (though the remaining registers were all like 00 00).

There are several versions of Adafruit_TFTLCD library that have been hacked for an LGDP4535. There are probably some original ones too. As far as I know, they will only run on a Uno or Mega.

Anyway, I have one of these generic 3.5inch RPi LCDs. The above library works perfectly for running the LCD. The XPT_2046 library also works perfectly for driving the touch panel. BUT the two do not work together. Display calls break the touch panel, and vice-versa.

Did you enabled DMA? With DMA I have some artefacts with the graphic tests (not only with this display) It’s on my todo list to investigate the problem (maybe too much speed for the controller).

I do not own/use diff tools, because I don’t need them regularly (I just use notepad++ with the compare plugin on windows or XCode on OSX for such things (private)). It’s always better to post the whole code/library as *.zip or *.rar file as Attachments otherwise many people will cry “How to use this?” -especially under windows (there is no “patch” without further installing something)

The teensy library is MUCH slower – maybe the errors caused by to high speed (SPI or low level pin manipulations) – It should be not to difficult to find the problem as we have two – almost same – libraries