prepare png file for arduino tft display free sample

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

Displaying a custom image or graphic on a LCD display is a very useful task as displays are now a premium way of providing feedback to users on any project. With this functionality, we can build projects that display our own logo, or display images that help users better understand a particular task the project is performing, providing an all-round improved User Experience (UX) for your Arduino or ESP8266 based project. Today’s tutorial will focus on how you can display graphics on most Arduino compatible displays.

The procedure described in this tutorial works with all color displays supported by Adafruit’s GFX library and also works for displays supported by the TFTLCD library from Adafruit with little modification. Some of the displays on which this procedure works include:

While these are the displays we have, and on which this tutorial was tested, we are confident it will work perfectly fine with most of the other Arduino compatible displays.

For each of the displays mentioned above, we have covered in past how to program and connect them to Arduino. You should check those tutorials, as they will give you the necessary background knowledge on how each of these displays works.

For this tutorial, we will use the 2.8″ ILI9325 TFT Display which offers a resolution of 320 x 340 pixels and we will display a bitmap image of a car.

As usual, each of the components listed above can be bought from the links attached to them. While having all of the displays listed above may be useful, you can use just one of them for this tutorial.

To demonstrate how things work, we will use the 2.8″ TFT Display. The 2.8″ TFT display comes as a shield which plugs directly into the Arduino UNO as shown in the image below.

Not all Arduino displays are available as shields, so when working with any of them, connect the display as you would when displaying text (we recommend following the detailed tutorial for the display type you use of the above list). This means no special connection is required to display graphics.

Before an image is displayed on any of the Arduino screens, it needs to be converted to a C compatible hex file and that can only happen when the image is in bitmap form. Thus, our first task is to create a bitmap version of the graphics to be displayed or convert the existing image to a bitmap file. There are several tools that can be used for creation/conversion of bitmap images including, Corel Draw and Paint.net, but for this tutorial, we will use the Paint.net.

Our demo graphics today will be a car. We will create the car on a black background and use a white fill so it’s easy for us to change the color later on.

The resolution of the graphics created should be smaller than the resolution of your display to ensure the graphics fit properly on the display. For this example, the resolution of the display is 320 x 340, thus the resolution of the graphics was set to195 x 146 pixels.

Your graphics could also include some text. Just ensure the background is black and the fill color is white if you plan to change the color within your Arduino code.

With the graphics done, save both files as .bmp with 24bits color.It is important to keep in mind that large bitmaps use up a lot of memory and may prevent your code from running properly so always keep the bitmaps as small as possible.

Image2Code is an easy-to-use, small Java utility to convert images into a byte array that can be used as a bitmap on displays that are compatible with the Adafruit-GFX or Adafruit TFTLCD (with little modification) library.

All we have to do is to load the graphics into the software by clicking the “Choose file” button and it will automatically generate a byte array equivalent to the selected bitmap file.

Paste the bit array in the graphics.c file and save. Since we have two graphics (the car and the text), You can paste their data array in the same file. check the graphics.c file attached to the zip file, under the download section to understand how to do this. Don’t forget to declare the data type as “const unsigned char“, add PROGEM in front of it and include the avr/pgmspace.h header file as shown in the image below.  This instructs the code to store the graphics data in the program memory of the Arduino.

With this done, we are now ready to write the code. Do note that this procedure is the same for all kind of displays and all kind of graphics. Convert the graphics to a bitmap file and use the Img2code utility to convert it into a hex file which can then be used in your Arduino code.

To reduce the amount of code, and stress involved in displaying the graphics, we will use two wonderful libraries; The GFX library and the TFTLCD library from Adafruit.

The GFX library, among several other useful functions, has a function called drawBitmap(), which enables the display of a monochrome bitmap image on the display. This function allows the upload of monochrome only (single color) graphics, but this can be overcome by changing the color of the bitmap using some code.

The Adafruit libraries do not support all of the displays but there are several modifications of the libraries on the internet for more displays. If you are unable to find a modified version of the library suitable for your the display, all you need do is copy the code of the drawBitmap() function from the GFX library and paste it in the Arduino sketch for your project such that it becomes a user-defined function.

The first two are thex and y coordinates of a point on the screen where we want the image to be displayed. The next argument is the array in which the bitmap is loaded in our code, in this case, it will be the name of the car and the text array located in the graphics.c file. The next two arguments are the width and height of the bitmap in pixels, in other words, the resolution of the image. The last argument is the color of the bitmap, we can use any color we like. The bitmap data must be located in program memory since Arduino has a limited amount of RAM memory available.

As usual, we start writing the sketch by including the libraries required. For this procedure, we will use the TFTLCD library alone, since we are assuming you are using a display that is not supported by the GFX library.

Next, we specify the name of the graphics to be displayed; car and title. At this stage, you should have added the bit array for these two bitmaps in the graphics.c file and the file should be placed in the same folder as the Arduino sketch.

With that done, we proceed to the void loop function, under the loop function, we call the drawbitmap() function to display the car and the text bitmap using different colors.

The last section of the code is the drawBitmap function itself, as earlier mentioned, to use the drawbitmap() function with the Adafruit TFTLCD library, we need to copy the function’s code and paste into the Arduino sketch.

Plug in your screen as shown above. If you are using any other display, connect it as shown in the corresponding linked tutorial. With the schematics in place, connect the Arduino board to your PC and upload the code. Don’t forget the graphics file needs to be in the same folder as the Arduino sketch.

That’s it for this tutorial guys. The procedure is the same for all kinds of Arduino compatible displays. If you get stuck while trying to replicate this using any other display, feel free to reach out to me via the comment sections below.

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

To do this, we will useLCD image converter.You can find it here :https://sourceforge.net/projects/lcd-image-converter/Resize your imageto the size of your screen (240x240)

Hello, this tutorial is a follow up of the 2 other ones about the 2.4″ TFT LCD Shield with Arduino UNO, so the first one was about Interfacing and fixing the touch function problem also inverted axis, then the second one was about using simple function to draw different shapes and how to create a touch button to activate some functions…

But today we’re about the reading of images from SD card and showing them on the screen, first don’t forget to plug your SD card with your computer and format it as FAT32 then transfert your images don’t forget that they should be “BMP” format, Bitmaps 24 !! To have a correct image the resolutions should be 240*320, little explanation:

This is the library that worked for me:if you use this library but when trying with example codes it shows you a white screen, you should definitely look for the library that suits you.

Here are the codes I’ve used in the video in.ino format, don’t forget to change the name of the files you’re using. Don’t forget to check the tutorial in case you need some help.

About: STEMpedia is a place bringing project-making tools at one place- kits, online courses, coding platforms, controller app and tons of free learning resources.

Many times to make any user interface or nicely display content, we use icons/images. In this Instructable, you will be displaying icons or logos or images on your TFT screen from Arduino with using ATmega (microcontroller used in Arduino) Flash memory. It does not require any SD Card to store bitmap images or USB connection to send image data. We will convert images from any image format like .bmp, .jpg, .jpeg, .png to its hexadecimal equivalent to be stored in flash memory of arduino mega (ATmega2560).

All microcontroller has Flash memory, where the codes are stored permanently. Arduino Mega has comparatively good amount of Flash memory, ie 256 KB of which 8 KB used by bootloader. We will be doing two things:Monochrome icons/images: The icons or images will be displayed with single color, but takes very less memory. Just 1bit for one pixel.

Colored icons/images: It depends on the TFT screen used, for eg. 1.8" SPI TFT with ST7735 driver has 16bit color. Images or icons will just look like your phone screen, but it takes lots of space. it takes 16bits (2bytes) for each pixel (16times more!!).

It requires a TFT screen compatible with arduino, few jumper cables (dupont wires), breadboard and is recommended to use 3.3V -5V level shifters (but it works without it also :P ). But we have used evive . It has all the things required to do this without any additional wiring!! Hence it helps in avoiding the repetitive task for bread-boarding. evive uses the most commonly used 1.8" SPI based TFT (ST7735R driver) having 160px by 128px along with Arduino Mega 2560 R3. Also has internal logic level shifters for ideal usage.

https://sourceforge.net/projects/lcd-image-convert...This tool has all the options for large varieties of screens available. You can even draw your own icon!!.

Also we may need to use some image resizing tool as most of the images available on internet are of very large size as compared to hoscreen. Option for Image Resizer:

If you are using the tool mentioned in last step, Please look at the images. It has lots of options to resize image for our usage. We can easily enter the value of "height" or "width" in pixels!.

Once you have the image ready, next step is to convert the image to some form of numbers as actually all images are represented by array/matrix of numbers. Since we are not going to use SD card to save images or logos or icons as its irritating everytime to have a micro SD card for this purpose, we will now convert images to hexadecimal. Then we will store it in Arduino Flash Memory.

Using the LCD_Image_Converter tool, we will get the image in hexadecimal form.Load the image usign File->Open->"SelectUrImage" If you want to edit image, use the editing tools.

Copy all the numbers!! (Here each pixel is stored in its binary form as image is monochrome. If the pixel is filled, then it will be 1 or else it will be 0)

Other option is to go for colored images (remember that it takes lot of Arduino Flash memory). Based on the TFT screen you will have to select some options like color format (1.8" SPI TFT SR7735R uses 16 bit colors: R5G6B5)Load the image usign File->Open->"SelectUrImage" If you want to edit image, use the editing tools.

Copy all the numbers!! (Here each pixel is stored in a 16bit hexadecimal number. From LSB (lowest significant bit), first 5 represent "blue", then 6 digits represent "green" and rest 5 are for red.)

Case 2: Since there is no direct function in Adafruit GFX library, we will have to write our own code for this. We will have to traverse pixel by pixel to draw image/icon.

This type of icons are very useful for making automation systems having a display bar. Such icons provide intuitiveness to users for your projects or machines.

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 and is available here. I have been reluctant to support yet another font format but this is an amazing library which is very easy to use. It 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, however the ESP8266 does not have sufficient RAM. 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:

The following is now deprecated due to the number of issues it can cause in certain circumstances. For ESP32 ONLY, the TFT configuration (user setup) can now be included inside an Arduino IDE sketch providing the instructions in the example Generic->Sketch_with_tft_setup are followed. See ReadMe tab in that sketch for the instructions. If the setup is not in the sketch then the library settings will be used. This means that "per project" configurations are possible without modifying the library setup files. Please note that ALL the other examples in the library will use the library settings unless they are adapted and the "tft_setup.h" header file included. Note: there are issues with this approach, #2007 proposes an alternative method.

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.

Support for the ESP32-S2, ESP32-S3 and ESP32-C3 has been added (DMA not supported at the moment). Tested with v2.0.3 RC1 of the ESP32 board package. Example setups:

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.

The use of PIO for SPI allows the RP2040 to be over-clocked (up to 250MHz works on my boards) in Earle"s board package whilst still maintaining high SPI clock rates.

DMA can now be used with the Raspberry Pi Pico (RP2040) when used with both 8 bit parallel and 16 bit colour SPI displays. See "Bouncy_Circles" sketch.

The library now supports the Raspberry Pi Pico with both the official Arduino board package and the one provided by Earle Philhower. The setup file "Setup60_RP2040_ILI9341.h" has been used for tests with an ILI9341 display. At the moment only SPI interface displays have been tested. SPI port 0 is the default but SPI port 1 can be specifed in the setup file if those SPI pins are used.

The library now provides a "viewport" capability. See "Viewport_Demo" and "Viewport_graphicstest" examples. When a viewport is defined graphics will only appear within that window. The coordinate datum by default moves to the top left corner of the viewport, but can optionally remain at top left corner of TFT. The GUIslice library will make use of this feature to speed up the rendering of GUI objects (see #769).

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.

A Sprite is notionally an invisible graphics screen that is kept in the processors RAM. Graphics can be drawn into the Sprite just as they can be drawn directly to the screen. Once the Sprite is completed it can be plotted onto the screen in any position. If there is sufficient RAM then the Sprite can be the same size as the screen and used as a frame buffer. Sprites by default use 16 bit colours, the bit depth can be set to 8 bits (256 colours) , or 1 bit (any 2 colours) to reduce the RAM needed. On an ESP8266 the largest 16 bit colour Sprite that can be created is about 160x128 pixels, this consumes 40Kbytes of RAM. On an ESP32 the workspace RAM is more limited than the datasheet implies so a 16 bit colour Sprite is limited to about 200x200 pixels (~80Kbytes), an 8 bit sprite to 320x240 pixels (~76kbytes). A 1 bit per pixel Sprite requires only 9600 bytes for a full 320 x 240 screen buffer, this is ideal for supporting use with 2 colour bitmap fonts.

One or more sprites can be created, a sprite can be any pixel width and height, limited only by available RAM. The RAM needed for a 16 bit colour depth Sprite is (2 x width x height) bytes, for a Sprite with 8 bit colour depth the RAM needed is (width x height) bytes. Sprites can be created and deleted dynamically as needed in the sketch, this means RAM can be freed up after the Sprite has been plotted on the screen, more RAM intensive WiFi based code can then be run and normal graphics operations still work.

Drawing graphics into a sprite is very fast, for those familiar with the Adafruit "graphicstest" example, this whole test completes in 18ms in a 160x128 sprite. Examples of sprite use can be found in the "examples/Sprite" folder.

If an ESP32 board has SPIRAM (i.e. PSRAM) fitted then Sprites will use the PSRAM memory and large full screen buffer Sprites can be created. Full screen Sprites take longer to render (~45ms for a 320 x 240 16 bit Sprite), so bear that in mind.

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.

The .vlw files must be uploaded to the processors FLASH filing system (SPIFFS, LittleFS or SD card) for use. Alternatively the .vlw files can be converted to C arrays (see "Smooth Font -> FLASH_Array" examples) and stored directly in FLASH as part of the compile process. The array based approach is convenient, provides performance improvements and is suitable where: either use of a filing system is undesirable, or the processor type (e.g. STM32) does not support a FLASH based filing system.

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.

You can take this one step further and have your own setup select file and then you only need to replace the Setup.h line reference in User_Setup_Select.h to, for example:

The library was intended to support only TFT displays but using a Sprite as a 1 bit per pixel screen buffer permits support for the Waveshare 2 and 3 colour SPI ePaper displays. This addition to the library is experimental and only one example is provided. Further examples will be added.

This post is an introduction to the Nextion display with the Arduino. We’re going to show you how to configure the display for the first time, download the needed resources, and how to integrate it with the Arduino UNO board. We’ll also make a simple graphical user interface to control the Arduino pins.

Nextion is a Human Machine Interface (HMI) solution. Nextion displays are resistive touchscreens that makes it easy to build a Graphical User Interface (GUI). It is a great solution to monitor and control processes, being mainly applied to IoT applications.

The Nextion has a built-in ARM microcontroller that controls the display, for example it takes care of generating the buttons, creating text, store images or change the background. The Nextion communicates with any microcontroller using serial communication at a 9600 baud rate.

To design the GUI, you use the Nextion Editor, in which you can add buttons, gauges, progress bars, text labels, and more to the user interface in an easy way. We have the 2.8” Nextion display basic model, that is shown in the following figure.

The best model for you, will depend on your needs. If you’re just getting started with Nextion, we recommend getting the 3.2” size which is the one used in the Nextion Editor examples (the examples also work with other sizes, but you need to make some changes). Additionally, this is the most used size, which means more open-source examples and resources for this size.

To get started with Nextion, first you need to install Nextion Editor. Go to https://nextion.itead.cc/, select the Resources tab, Download > Nextion Editor and install Nextion Editor. You can either download the .zip file or the .exe file.

Connecting the Nextion display to the Arduino is very straightforward. You just need to make four connections: GND, RX, TX, and +5V. These pins are labeled at the back of your display, as shown in the figure below.

You can power up the Nextion display directly from the Arduino 5V pin, but it is not recommended. Working with insufficient power supply may damage the display. So, you should use an external power source. You should use a 5V/1A power adaptor with a micro USB cable. Along with your Nextion display, you’ll also receive a USB to 2 pin connector, useful to connect the power adaptor to the display.

The best way to get familiar with a new software and a new device is to make a project example. Here we’re going to create a user interface in the Nextion display to control the Arduino pins, and display data.

The user interface has two pages: one controls two LEDs connected to the Arduino pins, and the other shows data gathered from the DHT11 temperature and humidity sensor;

We won’t cover step-by-step how to build the GUI in the Nextion display. But we’ll show you how to build the most important parts, so that you can learn how to actually build the user interface. After following the instructions, you should be able to complete the user interface yourself.

Additionally, we provide all the resources you need to complete this project. Here’s all the resources you need (be aware that you may need to change some settings on the user interface to match your display size):

Open Nextion Editor and go to File > New to create a new file. Give it a name and save it. Then, a window pops up to chose your Nextion model, as show in the figure below.

We’ll start by adding a background image. To use an image as a background, it should have the exact same dimensions as your Nextion display. We’re using the 2.8” display, so the background image needs to be 240×320 pixels. Check your display dimensions and edit your background image accordingly. As an example, we’re using the following image:

Here you can select the font height, type, spacing and if you want it to be bold or not. Give it a name and click the Generate font button. After that, save the .zi file and add the generator font by clicking yes.

At this moment, you can start adding components to the display area. For our project, drag three buttons, two labels and one slider, as shown in the figure below. Edit their looks as you like.

All components have an attribute called objname. This is the name of the component. Give good names to your components because you’ll need them later for the Arduino code. Also note that each component has one id number that is unique to that component in that page. The figure below shows the objname and id for the slider.

You should trigger an event for the touchable components (the buttons and the slider) so that the Arduino knows that a component was touched. You can trigger events when you press or when you release a component.

To do that, select one of the buttons, and in the event window, select the Touch Release Event tab, and put a tick on the Send Component ID option. Repeat this process for the other button, and the slider.

Our second page will display data from the DHT11 temperature and humidity sensor. We have several labels to hold the temperature in Celsius, the temperature in Fahrenheit, and the humidity. We also added a progress bar to display the humidity and an UPDATE button to refresh the readings. The bBack button redirects to page0.

Notice that we have labels to hold the units like “ºC”, “ºF” and “%”, and empty labels that will be filled with the readings when we have our Arduino code running.

Once the GUI is ready, you need to write the Arduino code so that the Nextion can interact with the Arduino and vice-versa. Writing code to interact with the Nextion display is not straightforward for beginners, but it also isn’t as complicated as it may seem.

A good way to learn how to write code for the Arduino to interact with the Nextion display is to go to the examples folder in the Nextion library folder and explore. You should be able to copy and paste code to make the Arduino do what you want.

The first thing you should do is to take note of your components in the GUI that will interact with the Arduino and take note of their ID, names and page. Here’s a table of all the components the code will interact to (your components may have a different ID depending on the order you’ve added them to the GUI).

Here you use the page ID, the component ID and their name – just check the table above with all the components. To define a text you use NexText, to define a button you use NexButton, for a slider you use NexSlider and for the progress bar you use NexProgressBar.

For the slider (h0), you have the following function that writes the current slider position on the tSlider label and sets led2 brightness accordingly:

Finally, you need a function for the bUpdate (the update button). When you click this button the DHT temperature and humidity sensor reads temperature and humidity and displays them on the corresponding labels, as well as the humidity on the progress bar. That is the bUpdatePopCallback() function.

In the setup(), you need to attach the functions created to the corresponding events. For example, when you click on the bOn button, the bOnPopCallback function will be triggered.

In this post we’ve introduced you to the Nextion display. We’ve also created a simple application user interface in the Nextion display to control the Arduino pins. The application built is just an example for you to understand how to interface different components with the Arduino – we hope you’ve found the instructions as well as the example provided useful.

In our opinion, Nextion is a great display that makes the process of creating user interfaces simple and easy. Although the Nextion Editor has some issues and limitations it is a great choice for building interfaces for your electronics projects. We have a project on how to create a Node-RED physical interface with the Nextion display and an ESP8266 to control outputs. Feel free to take a look.

image2cpp is a simple tool to change images into byte arrays (or your array back into an image) for use with Arduino and (monochrome) displays such as OLEDs.

In this Arduino touch screen tutorial we will learn how to use TFT LCD Touch Screen with Arduino. You can watch the following video or read the written tutorial below.

For this tutorial I composed three examples. The first example is distance measurement using ultrasonic sensor. The output from the sensor, or the distance is printed on the screen and using the touch screen we can select the units, either centimeters or inches.

The next example is controlling an RGB LED using these three RGB sliders. For example if we start to slide the blue slider, the LED will light up in blue and increase the light as we would go to the maximum value. So the sliders can move from 0 to 255 and with their combination we can set any color to the RGB LED,  but just keep in mind that the LED cannot represent the colors that much accurate.

The third example is a game. Actually it’s a replica of the popular Flappy Bird game for smartphones. We can play the game using the push button or even using the touch screen itself.

As an example I am using a 3.2” TFT Touch Screen in a combination with a TFT LCD Arduino Mega Shield. We need a shield because the TFT Touch screen works at 3.3V and the Arduino Mega outputs are 5 V. For the first example I have the HC-SR04 ultrasonic sensor, then for the second example an RGB LED with three resistors and a push button for the game example. Also I had to make a custom made pin header like this, by soldering pin headers and bend on of them so I could insert them in between the Arduino Board and the TFT Shield.

Here’s the circuit schematic. We will use the GND pin, the digital pins from 8 to 13, as well as the pin number 14. As the 5V pins are already used by the TFT Screen I will use the pin number 13 as VCC, by setting it right away high in the setup section of code.

As the code is a bit longer and for better understanding I will post the source code of the program in sections with description for each section. And at the end of this article I will post the complete source code.

I will use the UTFT and URTouch libraries made by Henning Karlsen. Here I would like to say thanks to him for the incredible work he has done. The libraries enable really easy use of the TFT Screens, and they work with many different TFT screens sizes, shields and controllers. You can download these libraries from his website, RinkyDinkElectronics.com and also find a lot of demo examples and detailed documentation of how to use them.

After we include the libraries we need to create UTFT and URTouch objects. The parameters of these objects depends on the model of the TFT Screen and Shield and these details can be also found in the documentation of the libraries.

Next we need to define the fonts that are coming with the libraries and also define some variables needed for the program. In the setup section we need to initiate the screen and the touch, define the pin modes for the connected sensor, the led and the button, and initially call the drawHomeSreen() custom function, which will draw the home screen of the program.

So now I will explain how we can make the home screen of the program. With the setBackColor() function we need to set the background color of the text, black one in our case. Then we need to set the color to white, set the big font and using the print() function, we will print the string “Arduino TFT Tutorial” at the center of the screen and 10 pixels  down the Y – Axis of the screen. Next we will set the color to red and draw the red line below the text. After that we need to set the color back to white, and print the two other strings, “by HowToMechatronics.com” using the small font and “Select Example” using the big font.

Next is the distance sensor button. First we need to set the color and then using the fillRoundRect() function we will draw the rounded rectangle. Then we will set the color back to white and using the drawRoundRect() function we will draw another rounded rectangle on top of the previous one, but this one will be without a fill so the overall appearance of the button looks like it has a frame. On top of the button we will print the text using the big font and the same background color as the fill of the button. The same procedure goes for the two other buttons.

Now we need to make the buttons functional so that when we press them they would send us to the appropriate example. In the setup section we set the character ‘0’ to the currentPage variable, which will indicate that we are at the home screen. So if that’s true, and if we press on the screen this if statement would become true and using these lines here we will get the X and Y coordinates where the screen has been pressed. If that’s the area that covers the first button we will call the drawDistanceSensor() custom function which will activate the distance sensor example. Also we will set the character ‘1’ to the variable currentPage which will indicate that we are at the first example. The drawFrame() custom function is used for highlighting the button when it’s pressed. The same procedure goes for the two other buttons.

So the drawDistanceSensor() custom function needs to be called only once when the button is pressed in order to draw all the graphics of this example in similar way as we described for the home screen. However, the getDistance() custom function needs to be called repeatedly in order to print the latest results of the distance measured by the sensor.

Here’s that function which uses the ultrasonic sensor to calculate the distance and print the values with SevenSegNum font in green color, either in centimeters or inches. If you need more details how the ultrasonic sensor works you can check my particular tutorialfor that. Back in the loop section we can see what happens when we press the select unit buttons as well as the back button.

Ok next is the RGB LED Control example. If we press the second button, the drawLedControl() custom function will be called only once for drawing the graphic of that example and the setLedColor() custom function will be repeatedly called. In this function we use the touch screen to set the values of the 3 sliders from 0 to 255. With the if statements we confine the area of each slider and get the X value of the slider. So the values of the X coordinate of each slider are from 38 to 310 pixels and we need to map these values into values from 0 to 255 which will be used as a PWM signal for lighting up the LED. If you need more details how the RGB LED works you can check my particular tutorialfor that. The rest of the code in this custom function is for drawing the sliders. Back in the loop section we only have the back button which also turns off the LED when pressed.

In order the code to work and compile you will have to include an addition “.c” file in the same directory with the Arduino sketch. This file is for the third game example and it’s a bitmap of the bird. For more details how this part of the code work  you can check my particular tutorial. Here you can download that file:

Several ways exist to display bitmap images, pictures so to say, on a screen attached to an Arduino, ESP8266 or ESP32. In the present project we convert a color picture into a c-array that is either included in a sketch or saved in a file that is called from within a sketch. The screen used is a 1.3 inch, 240*240 pixel TFT display with ST7789 controller and SPI interface. Because the file size of a 240*240 color bitmap is way too large to fit program memory in an Arduino Uno we are using an ESP32 microcontroller board: ESP32-WROOM-32. The 1.3”, 240*240 TFT is one of my favorite displays, not only because of its 65,536 available colors (16 bits per pixel, RGB565) but also because of its fast SPI interface which is meticulously supported by Bodmer’s TFT_eSPI.h library.

Compared with current LCD displays and OLED displays, TFT type screens offer the luxury of nearly unlimited color. While it is possible on OLED displays to show pictures, the constraint with this type of display is that pictures are always presented in monochrome. A TFT display shows images as crisp and colorful as your smartphone’s screen does. Of course your smartphone has more pixels than the humble 240*240, which necessitates some cropping and scaling. In this project I started with a big, 2521*1688 pixels jpg image downloaded from Wikipedia.

To possess a TFT screen is one thing, making it work, that is: showing color pictures, needs some investment in ideas, time and effort. As graphical functions are called via a supporting library the selection of a competent library is of prime importance. Another issue is the communication protocol between microcontroller and display. Among the available libraries the TFT_eSPI.h library offers superior support for a variety of controllers / microcontroller board / TFT display configurations, including the configuration used in the current project.

TFT_eSPI can be installed via the Library Manager in the Arduino IDE (Tools → Manage Libraries). Additional Configuration: see section Software. Install the most recent version.

Figure 1 shows the wiring diagram. Wiring is straightforward: the VCC pin of the display breakout board is connected to the 3.3V pin of the ESP32. GND is connected to GND. Of the remaining display pins only four are necessary. Pins marked ‘SCL’ and ‘SDA’ (on other SPI displays sometimes labeled as SCLK and MOSI) are connected to pins D18 and D23 of the ESP32. Pin ‘RES’ on the TFT display is connected to pin D4 of the ESP32, and pin ‘DC’ of the display goes to pin D2 of the ESP32. Pin ‘BLK’ of the TFT is not connected.

The example here, shown in figure 1, is a picture of a ladybug. The image was acquired via a search on Wikipedia. Its credentials are: Gilles San Martin from Namur, Belgium – Coccinella magnifica, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=7694675. The original picture is beautiful, but it is also huge compared with my humble TFT: 2521*1688, format: jpg.

Resulting after all the photo editing was a 173 kB BMP image file (‘ladybug.bmp’) with dimensions 240*240 and in True Color = R5G6B5, 16-bit color depth (64k colors).

Once the proper size, color depth and format had been obtained the moment had arrived to convert the picture into c-array format. This is the format recognized and processed by the Arduino compiler.

A very convenient program to convert BMP image files to c-array format is ‘lcd-image-converter’. This is a Windows program, freely available on the internet. What one needs to do in lcd-image-converter is shown in figures 2 and 3.

First thing to do is to start the program, provide a name for the project (‘ladybug’) and check the conversion parameters. This is done via Options, Conversion. Be sure that Block Size is 16 bit, byte order ‘Little Endian’ (figure 2).

Via ‘File’ and ‘Convert’ the end result is produced: a file named ‘ladybug.c’ (file size here: 638 kb). This file is in ascii format. Its contents can be inspected with an ascii editor (Notepad, Notepad++, Gedit).

There are two ways to work with a c-array in a sketch: the ‘internal’ option, that is that the c-array is copy-pasted into the sketch, and the ‘external’ option, that includes a call from the sketch to a file located in the same folder as the sketch. Both options have pros and cons. Here we will provide both options.

0x4b41, 0x4321, 0x4321, 0x4301, 0x42e1, 0x4301, 0x4301, 0x4b41… ……..and so forth until the final pixels……. 0x8ccd, 0x84ad, 0x848c, 0x848c, 0x846c, 0xa571, 0xa571, 0xa571

The essential image c-array data can be placed into a separate file while all data are ‘imported’ at compilation time via a simple ‘include’ instruction inside the sketch. This has the advantage of a clean sketch that is easy to edit. The data file needs to be saved in the same folder as the sketch.

0x4b41, 0x4321, 0x4321, 0x4301, 0x42e1, 0x4301, 0x4301, 0x4b41… ……..and so forth until the final pixels……. 0x8ccd, 0x84ad, 0x848c, 0x848c, 0x846c, 0xa571, 0xa571, 0xa571

which is identical to the content of the 16-bit instruction in the ‘inclusive’ sketch. The 57,600 pixels remain neatly packed in a separate file. A sketch is supplied at the end of this article.

This library is extremely versatile, with many graphical functions, while it supports a great number of combinations of microcontroller boards and display controllers. The great difference between TFT_eSPI.h and alternative libraries, e.g. Adafruit_GFX.h and U8glib.h is that the so-called ‘constructor’ is absent.

The idea in TFT_eSPI is that all necessary parameters presented to the library are in a series of instructions bundled in a User_Setup.h file. As its name implies such a file is configurable by the end user. User_Setup.h contains calls to an array of drivers. Look around in the library’s folder named ‘User_Setups’. This folder is a playground for folks who like to experiment with all sorts of microcontrollers and displays. A superb idea!

– open User_Setup_Select.h and uncomment the line calling one of the pre-configured configuration files. In the present microcontroller-graphical controller combination this is a modified Setup24_ST7789.h.

After experimenting first with breadboards and jumper wires I decided to take a 7×9 cm soldering prototyping board and some pin sockets to solder a small robust bench that accommodates the ESP32-WROOM and the 2402*40 TFT (figure 4). Further software testing was done with this bench. Results were excellent. The TFT_eSPI library supports the ESP32 / ST7789 240*240 SPI TFT without any problem and, very important: very fast. I made and tested a variety of c-array coded images in a range of formats (e.g., 80*160; 128*128 and so on). They were all displayed very well on the small square screen. Condition is that the data file name is 8-character limited. One of these extra images, a picture of a dog called ‘bastien’, was cropped at 240*380 pixels and converted into a c-array (file size of the c-array: 1 MB). The sketch calling this c-array was perfectly compiled. Only the left part of the image was shown on screen with the instruction ‘tft.pushImage (0,0,240,240, bastien);‘, and the same happened when the instruction was changed into ‘ tft.pushImage (0,0,240,380,bastien);‘. This means that the TFT_eSPI library handles images benevolently. The instruction ‘’tft.pushImage (0,0,120,120, bastien);‘ produced an image on the left lower quadrant of the display, and this image contained the left lower quadrant of the bitmap picture.

An interesting option is to place several external c-array.h files into progmem in order to produce a slideshow. I tried this with two 240*240 pixel images of the famous portrait of Che Guevara; one named ‘che-red.h’ and the other ‘che-grey.h’. With a simple delay () instruction a display time between successive images can be set. A series of calls to several more external c-array image files is possible as well. Here the prospect of animation looms. The successful compilation of a 240*380 pixel c-array image tempts me to investigate how far the the envelope of the ESP32 microcontroller can be pushed with images of increasing size. Such a project can easily be entertained on my previously assembled benches that accommodate bigger SPI- or parallel displays (up to 3.95”. 320*480 pixel TFTs *, **). Another attractive project is to use a card reader to transfer images with lightning speed, pixel after pixel, from an image file on SD card to the TFT display.

When most people hear the term “JPEG decoding,” they will usually assume that it’s something really difficult, something that requires lots of processing power and complicated mathematics, something that is impossible – or at least impractical – on relatively cheap and slow 8-bit microcontroller platforms like the Arduino. In this article, we’ll learn how to take JPEG photo using an Arduino-controlled camera, turn the photo into lots and lots of pixels, and to transmit all of them via serial port to our PC – or wherever we like!

Even though what is described above is entirely possible, it is worth mentioning why exactly are we going into all the trouble of decoding a JPEG photo. After all, there’s an SD module listed in the hardware requirements above, and you’d ask “Can we just store the photo on the SD card as aphoto.jpegfile?” Sure, that is actually an important part of the entire process, but try to look at this from a different perspective: What if we want to send that photo somewhere using a slow, somewhat unreliable connection? If we simply chopped up the JPEG photo into packages and send them via a slow connection, we risk that some of them might get corrupted, while others may get lost entirely. When that happens, we most likely won’t be able to restore the original photo from the corrupted data.

However, when we decode the JPEG into bitmap, and then send the actual pixels, we risk nothing. If some of the data gets corrupted or lost during the transmission, we will still have an image, only with the corrupted data somehow discolored, misplaced, or simply missing. Granted, it’s not the same picture we originally started with, but it still carries most of the original information and is still “human-readable”. Now that we knowwhywe’re doing this, let’s take a look athowwe can approach this method.

Before we start decoding JPEG photos, first we have to take the photos. Since our ultimate goal is to take a photo, store it on a SD card and then send it somewhere. Let’s start with a simple setup that will allow us to do this.

Since we need quite a bit of RAM to decode the photos, we’ll be using Arduino Mega. Also, there’s an added bonus in the form of four separate hardware serial ports on Mega, so we can use portSerial1to communicate with the camera, and portSerialto communicate with our PC.

You probably noticed there’s a simple resistor voltage divider on the camera RX line. This is because the logic level of the VC0706 chip is 3.3 V (even though the supply voltage is 5 V), but the logic level of Arduino Mega is 5 V. Here’s a friendly advice: always use at least a voltage divider on the RX line when interfacing 5 V Arduino with 3.3 V modules. It’s much quicker than waiting until a new module arrives. The SD card reader is connected directly by SPI interface.

Now that the hardware is set up, we need to get the code sorted out. Since the library for SD cards is already a part of the standard Arduino IDE installation, we can check the SD card off the list.

Now, the Arduino will take a picture every 10 seconds or so until we run out of space on the SD card. But since the photos are typically around 48 kB, and I’m currently using 2 GB SD card, we have enough space for more than 43,000 photos. It seems reasonable to say that we don’t need that many. But now that we have some photos taken, we can now move on to the fun stuff: turning them from JPEG-compressed hard-to-manage gibberish into a simple array of pixels!

Before we start decoding, let’s take a quick look at how exactly the picture data are stored inside a JPEG file. If you don’t really care about this, please feel free to skip the next three paragraphs. If you actually know a thing or two about graphics and compressions – unlike me – you could also skip this part, as well. The following text is simplified to an extent.

When we talk about storing any sort of picture data, there are two basic approaches: lossless or lossy compression. The difference between the two is clear: when image is encoded using lossless compression, PNG for example, every pixel is exactly the same as when you started at the end of the process. This is great for things like computer graphics, but unfortunately, it comes at a cost of increased file size. On the other hand, with lossy compression like JPEG, we lose some details but the resulting file size is much smaller.

The way this is achieved in JPEG can be somewhat challenging to grasp since it involves a little something called “discrete cosine transformation”, but the main principle is actually pretty simple. First, the picture is converted from RGB color space into YCbCr. We all know RGB color space – it stores colors as values of red (R), green (G) and blue (B). YCbCr is quite different – it uses luminance (Y – basically the original image in grayscale), blue-difference chroma component (Cb – “blueness” of the picture) and red-difference chroma component (Cr – “redness” of the picture).

The way JPEG achieves the reduction in file size is actually closely related to the way human eyes process colors. Take a look at the three pictures of the Y, Cb and Cr components in the above picture. Which one looks more like the original picture? That’s right, the grayscale one! This is because the human eye is much more sensitive to luminance than to the other two components. JPEG compression uses this in a very clever way that allows it to reduce the amount of information in the Cb and Cr components while keeping the original Y component. This leads to a picture that is much smaller than the original file, and because most the compressed information was in the components human eyes aren’t too sensitive towards, you can barely notice the difference of a compressed picture in comparison to an uncompressed one.

Now let’s run a code that does the actual magic of turning JPEG into an array of pixels. Fortunately, there is a library that does exactly that – Bodmer’s JPEGDecoder (available onGitHub) which is based on an excellent picojpeg library by Rich Geldreich (also onGitHub). Even though JPEGDecoder was originally written to display images on TFT display, with a few minor tweaks it will work just fine for us.

Using the library is fairly simple: we give it the JPEG file, and the library will start generating arrays of pixels – so called Minimum Coded Units, or MCUs for short. The MCU is a block of 16 by 8 pixels. The functions in the library will return the color value for each pixel as 16-bit color value. The upper 5 bits are the red value, the middle 6 are green and the lower 5 are blue. Now we can send these values by any sort of communication channel we like. I’m going to use Serial port so that we can easily receive the data later. The following Arduino sketch decodes an image, then sends the 16-bit RGB value for each pixel in the MCU and repeats this for all the MCUs in the image file.

Header packet: This packet starts with the string “$ITHDR” and contains basic information about the image we will be sending: height and width in pixels, number of MCUs pre row and column and finally the original filename. For each image we want to send, we will send one header packet.

Now we have a code that will decode and send picture files, but there’s still one core feature missing: right now, there’s nothing listening for those data at the other end. This means it’s time to start up Processing again!

I covered a little bit of Processing inArduino Hexapod PART 3: REMOTE CONTROL to write an app that allowed us to easily control the hexapod. For a quick refresher: Processing is a Java-based language that is primarily focused on drawing stuff. This makes it perfect for what we need to do, which is displaying pixels! This program does just that.

When you run this program with the Arduino connected, and then press any key on your keyboard, you will (hopefully) see the dull, boring gray background being gradually replaced by the image that was originally stored on the SD card. And since the replacement is done pixel by pixel, the entire process has a sort of old-school, dial-up-modem style of loading the image!

The original image is 640 pixels wide and 480 pixels tall for a total of 307,200 pixels. Each of these pixels is represented by 2-byte color value, that is a total of 614,400 bytes – or 600 kilobytes – to transfer. This leaves us with the final speed of about 10 kB/s. That’s not that terrible for a “protocol” that we just made up on the go, isn’t it? Also, it shows you why image compression is so useful. The original JPEG file was only around 48 kB, while the decoded bitmap takes 600 kB. If we were to transfer the JPEG file, we would be done with it in less than 5 seconds, even when using our extremely simple “protocol.” Of course, we most likely wouldn’t be able to retrieve any data in case the transfer fails – which is something that cannot happen now.

Finally, we have proven what this article started with: processing images on Arduinoispossible and can be even useful in certain situations. We can now snap pictures using a serial camera, decode them, send them over a serial port and then receive them on the other side! Consider this article your short intro into image processing on Arduino.

As usual, there is a lot of things that can be improved. One major addition could be to encrypt our messages using AES, which is fairly easy to implement, even on Arduino. Security is usually dangerously overlooked on Arduino, so we might focus a bit more on that in another project.

Whatever you are currently celebrating, Christmas, Hanukkah, Jul, Samhain, Festivus, or any other end-of-the-civil-year festivities, I wish you a good time! This December 25th edition of the Nextion Sunday Blog won"t be loaded with complex