ili9486 tft display arduino library bodmer made in china

I don"t actually have a display at present. I purchased a 7in one some months ago. It had an LT7381 controller and was supplied with a Hunda LT7381 library for Arduino and some basic display design software. However, I couldn"t get the hardware to work despite it being described as Arduino compatible. As it turned out, it also didn"t display anything when used with the supplied USB adaptor and design software for the PC, so it may have been faulty anyway. I posted something at the time but the controller is quite new and there was not much feedback. I ended up sending it back and getting a refund although it still cost me to send it back to china.

The reason I posted was because the project is now at the stage where the LCD display really needs to be added and I intended to get advice before making another purchase. In the meantime I have been working on the project using a 20x4 display.

Thank you for that information. Since I am using an ESP8266, it sounds like I need to look for a board that uses SPI for the display. From what I can tell, it seems that some of the cheap ones from china only use SPI only for the SD card which further confuses things.

I don"t posses an Arduino shield which is why I was trying to ascertain whether I need something like that. What is their purpose? A lot of photos show the display plugged into one and then into typically a Mega 2560. I don"t understand what the purpose of the shield is? Is it just a convenient way to provide a means of fitting the board to an Arduino with level shifting? SPI needs only 4 wires. Can"t these be connected directly to the ESP SPI pins?

I bought a TFT LCD similar to yours (3,6 Zoll TFT LCD-Touchscreen-Modul für Arduino Mega2560 3651857 2022 – €27.59). It works with ILI9481, ILI9486 and R61581 (following Henning Karlsen"s UTFT). The PCB has an XPT2046 on it.

I tried your library but the image is mirrored. In Henning"s library I could fix it changing the Memory Access Control (0x36) from 0x0A to 0x4A and the image was OK. So I changed the value in your library but it didn"t help - it is still mirrored.

I also tried to get access to the touch screen with your library TFT_touch. I used your modified TFT_HX8357 for ILI9486 and run the example TFT_Touch_Calibrate_v2.

The message on the display still is mirrored and touching the display on the cross has no effect. Without touching anything, after a few seconds, I get the following message on the serial monitor

I have bought a few of these 4" screens from amazon that are advertised as having the ILI9486 driver. Im not sure if the driver chip is hidden in the glass or the flex, but I can not see it, to check what it really is. The first were £4.79 delivered, the others £3.79 but now they are getting cheaper :o

Ive started with the TFT_eSPI libarary set up as a ILI9486 connected to an esp32, using the suggested pins for the connections. The screen lights up full white, and the examples run with an extreme white balance - a hard to notice that its not just white.

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:

ILI9341_2, ST7735, ILI9163, S6D02A1, RPI_ILI9486, HX8357D, ILI9481, ILI9486, ILI9488, ST7789, ST7789_2, R61581, RM68140, ST7796, SSD1351, SSD1963_480, SSD1963_800, SSD1963_800ALT, ILI9225, GC9A01.

By default, this library setup will work for NodeMCU using a ILI9341 driver. But in our case, we are using ESP32, so some of the setups have to be changed.

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

This new library is a standalone library that contains the TFT driver as well as the graphics functions and fonts that were in the GFX library. This library has significant performance improvements when used with an UNO (or ATmega328 based Arduino) and MEGA.

Examples are included with the library, including graphics test programs. The example sketch TFT_Rainbow_one shows different ways of using the font support functions. This library now supports the "print" library so the formatting features of the "print" library can be used, for example to print to the TFT in Hexadecimal, for example:

To use the F_AS_T performance option the ILI9341 based display must be connected to an MEGA as follows:MEGA +5V to display pin 1 (VCC) and pin 8 (LED) UNO 0V (GND) to display pin 2 (GND)

In the library Font 0 (GLCD font), 2, 4, 6 and 8 are enabled. Edit the Load_fonts.h file within the library folder to enable/disable fonts to save space.

TFT_ILI9341 library updated on 1st July 2015 to version 12, this latest version is attached here to step 8:Minor bug when rendering letter "T" in font 4 without background fixed

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

A library for driving self-timed digital RGB/RGBW LEDs (WS2812, SK6812, NeoPixel, WS2813, etc.) using the Espressif ESP32 microcontroller"s RMT output peripheral.

LiquidCrystal fork for displays based on HD44780. Uses the IOAbstraction library to work with i2c, PCF8574, MCP23017, Shift registers, Arduino pins and ports interchangably.

The most powerful and popular available library for using 7/14/16 segment display, supporting daisy chaining so you can control mass amounts from your Arduino!

A simple library to display numbers, text and animation on 4 and 6 digit 7-segment TM1637 based display modules. Offers non-blocking animations and scrolling!

Monochrome LCD, OLED and eInk Library. Display controller: SSD1305, SSD1306, SSD1309, SSD1312, SSD1316, SSD1318, SSD1320, SSD1322, SSD1325, SSD1327, SSD1329, SSD1606, SSD1607, SH1106, SH1107, SH1108, SH1122, T6963, RA8835, LC7981, PCD8544, PCF8812, HX1230, UC1601, UC1604, UC1608, UC1610, UC1611, UC1617, UC1638, UC1701, ST7511, ST7528, ST7565, ST7567, ST7571, ST7586, ST7588, ST75160, ST75256, ST75320, NT7534, ST7920, IST3020, IST3088, IST7920, LD7032, KS0108, KS0713, HD44102, T7932, SED1520, SBN1661, IL3820, MAX7219, GP1287, GP1247, GU800. Interfaces: I2C, SPI, Parallel.

True color TFT and OLED library, Up to 18 Bit color depth. Supported display controller: ST7735, ILI9163, ILI9325, ILI9341, ILI9486,LD50T6160, PCF8833, SEPS225, SSD1331, SSD1351, HX8352C.

In this article, you will learn how to use TFT LCDs by Arduino boards. From basic commands to professional designs and technics are all explained here.

In electronic’s projects, creating an interface between user and system is very important. This interface could be created by displaying useful data, a menu, and ease of access. A beautiful design is also very important.

There are several components to achieve this. LEDs,  7-segments, Character and Graphic displays, and full-color TFT LCDs. The right component for your projects depends on the amount of data to be displayed, type of user interaction, and processor capacity.

TFT LCD is a variant of a liquid-crystal display (LCD) that uses thin-film-transistor (TFT) technology to improve image qualities such as addressability and contrast. A TFT LCD is an active matrix LCD, in contrast to passive matrix LCDs or simple, direct-driven LCDs with a few segments.

In Arduino-based projects, the processor frequency is low. So it is not possible to display complex, high definition images and high-speed motions. Therefore, full-color TFT LCDs can only be used to display simple data and commands.

In this article, we have used libraries and advanced technics to display data, charts, menu, etc. with a professional design. This can move your project presentation to a higher level.

In electronic’s projects, creating an interface between user and system is very important. This interface could be created by displaying useful data, a menu, and ease of access. A beautiful design is also very important.

There are several components to achieve this. LEDs,  7-segments, Character and Graphic displays, and full-color TFT LCDs. The right component for your projects depends on the amount of data to be displayed, type of user interaction, and processor capacity.

TFT LCD is a variant of a liquid-crystal display (LCD) that uses thin-film-transistor (TFT) technology to improve image qualities such as addressability and contrast. A TFT LCD is an active matrix LCD, in contrast to passive matrix LCDs or simple, direct-driven LCDs with a few segments.

In Arduino-based projects, the processor frequency is low. So it is not possible to display complex, high definition images and high-speed motions. Therefore, full-color TFT LCDs can only be used to display simple data and commands.

In this article, we have used libraries and advanced technics to display data, charts, menu, etc. with a professional design. This can move your project presentation to a higher level.

Size of displays affects your project parameters. Bigger Display is not always better. if you want to display high-resolution images and signs, you should choose a big size display with higher resolution. But it decreases the speed of your processing, needs more space and also needs more current to run.

After choosing the right display, It’s time to choose the right controller. If you want to display characters, tests, numbers and static images and the speed of display is not important, the Atmega328 Arduino boards (such as Arduino UNO) are a proper choice. If the size of your code is big, The UNO board may not be enough. You can use Arduino Mega2560 instead. And if you want to show high resolution images and motions with high speed, you should use the ARM core Arduino boards such as Arduino DUE.

In electronics/computer hardware a display driver is usually a semiconductor integrated circuit (but may alternatively comprise a state machine made of discrete logic and other components) which provides an interface function between a microprocessor, microcontroller, ASIC or general-purpose peripheral interface and a particular type of display device, e.g. LCD, LED, OLED, ePaper, CRT, Vacuum fluorescent or Nixie.

The display driver will typically accept commands and data using an industry-standard general-purpose serial or parallel interface, such as TTL, CMOS, RS232, SPI, I2C, etc. and generate signals with suitable voltage, current, timing and demultiplexing to make the display show the desired text or image.

The LCDs manufacturers use different drivers in their products. Some of them are more popular and some of them are very unknown. To run your display easily, you should use Arduino LCDs libraries and add them to your code. Otherwise running the display may be very difficult. There are many free libraries you can find on the internet but the important point about the libraries is their compatibility with the LCD’s driver. The driver of your LCD must be known by your library. In this article, we use the Adafruit GFX library and MCUFRIEND KBV library and example codes. You can download them from the following links.

You must add the library and then upload the code. If it is the first time you run an Arduino board, don’t worry. Just follow these steps:Go to www.arduino.cc/en/Main/Software and download the software of your OS. Install the IDE software as instructed.

By these two functions, You can find out the resolution of the display. Just add them to the code and put the outputs in a uint16_t variable. Then read it from the Serial port by Serial.println(); . First add Serial.begin(9600); in setup().

First you should convert your image to hex code. Download the software from the following link. if you don’t want to change the settings of the software, you must invert the color of the image and make the image horizontally mirrored and rotate it 90 degrees counterclockwise. Now add it to the software and convert it. Open the exported file and copy the hex code to Arduino IDE. x and y are locations of the image. sx and sy are sizes of image. you can change the color of the image in the last input.

Upload your image and download the converted file that the UTFT libraries can process. Now copy the hex code to Arduino IDE. x and y are locations of the image. sx and sy are size of the image.

In this template, We converted a .jpg image to .c file and added to the code, wrote a string and used the fade code to display. Then we used scroll code to move the screen left. Download the .h file and add it to the folder of the Arduino sketch.

In this template, We used sin(); and cos(); functions to draw Arcs with our desired thickness and displayed number by text printing function. Then we converted an image to hex code and added them to the code and displayed the image by bitmap function. Then we used draw lines function to change the style of the image. Download the .h file and add it to the folder of the Arduino sketch.

In this template, We created a function which accepts numbers as input and displays them as a pie chart. We just use draw arc and filled circle functions.

In this template, We added a converted image to code and then used two black and white arcs to create the pointer of volumes.  Download the .h file and add it to the folder of the Arduino sketch.

In this template, We added a converted image and use the arc and print function to create this gauge.  Download the .h file and add it to folder of the Arduino sketch.

while (a < b) { Serial.println(a); j = 80 * (sin(PI * a / 2000)); i = 80 * (cos(PI * a / 2000)); j2 = 50 * (sin(PI * a / 2000)); i2 = 50 * (cos(PI * a / 2000)); tft.drawLine(i2 + 235, j2 + 169, i + 235, j + 169, tft.color565(0, 255, 255)); tft.fillRect(200, 153, 75, 33, 0x0000); tft.setTextSize(3); tft.setTextColor(0xffff); if ((a/20)>99)

while (b < a) { j = 80 * (sin(PI * a / 2000)); i = 80 * (cos(PI * a / 2000)); j2 = 50 * (sin(PI * a / 2000)); i2 = 50 * (cos(PI * a / 2000)); tft.drawLine(i2 + 235, j2 + 169, i + 235, j + 169, tft.color565(0, 0, 0)); tft.fillRect(200, 153, 75, 33, 0x0000); tft.setTextSize(3); tft.setTextColor(0xffff); if ((a/20)>99)

In this template, We display simple images one after each other very fast by bitmap function. So you can make your animation by this trick.  Download the .h file and add it to folder of the Arduino sketch.

In this template, We just display some images by RGBbitmap and bitmap functions. Just make a code for touchscreen and use this template.  Download the .h file and add it to folder of the Arduino sketch.