In this exercise, we will use, connect, and control the ILI934X TFT controller via the SPI interface. We will use a 2.8” Adafruit TFT screen shield. The shield is compatible with the arduino-compatible-interface available on Nordic DK’s, which simplifies the hardware connections.
The image below shows the 2.8” TFT screen that we are using in this exercise.
2.8” TFT Screen Shield (Back)
2.8” TFT Screen Sheild (Front)
Although the module also supports the capacitive touch, we will only use it as a display screen in this exercise. To use this screen, we will be using the overlay that is extracted from the shield Devicetree structure. The module is based on the ILI9431 TFT Controller.
The ILI9341 controller is a 262K color single-chip SoC driver for a TFT screen with a resolution of 240×320 RGB dots. It is comprised of a 720-channel source driver, a 320-channel gate driver, and has 172 kilobytes of GRAM (graphic memory) for display data.
Looking at the datasheet of the controller, the controller supports many different types of interfaces, e.g. with the 8086 based systems, and also provides serial interfaces for microcontrollers and supports a different number of lines (e.g data lines). The serial interface itself supports both a 3-wire and 4-wire interface. However, the configuration of the ILI controller on the shield that we are using is for a 4-wire, 8-bit data serial interface (called type II as per the datasheet).
On the ILI9341 controller side, which should act as a slave device for our DK, the pins used for communication are: Data/Command selection input (D/CX), Chip-Select signal input (CSX), the Serial-clock input (SCL), Serial-data input (SDI) and Serial-data output (SDO). Using the D/CX signal, we can send a command or data byte to the TFT controller.
Note
Do not be confused by the naming. The screen (2.8” Adafruit shield) has a TFT controller on it. However, this (screen) will act as an SPI slave and our DK will be the SPI master.
Serial Interface
As the ILI9341 controller supports several interfaces, the selection is made by setting the IM[3:0] pins. On the shield, these pins are configured to be “1110” which refers to the Serial interface type II that offers 8-bit bi-directional communication and uses 5 following lines:
D/CX (Data / Command selection)
CSX (Chip enable signal)
SCL (Serial clock input)
SDI (Serial data input)
SDO (Serial data output)
The figure below is taken from the datasheet of the ILI9341 TFT controller and shows the timing diagram for SPI communication, sending a command, and reading data afterward.
ILI9341 controller SPI communication
The figure below shows the setup for SPI connection where parallel-data lines are grounded and not used. This is the configuration used on the shield.
TFT Shield: ILI9341 controller configuration on the shield
As the shield supports the SPI interface and easily fits onto the Nordic DK, we don’t need to worry about these connections, we just need to setup the overlay.
The write mode of the interface means that the host writes the command or data to the ILI9341. If the D/CX bit is “low,” then the transmission byte is interpreted as a command byte. If the D/CX bit is “high”, then the transmission byte is treated as a data byte and is stored in the display data RAM or in the command register as a parameter. Any instruction can be sent in any order to ILI9341, and the MSB is transmitted first. A falling edge on CSX enables the serial interface and indicates the start of data transmission. The figure below shows the data format for the 4-wire serial interface.
All of the details about the shield and the TFT controller could not be described here. For further information on that, please refer to their datasheet / technical documentation. Here, we will focus on the use of TFT for our exercise.
ILI Commands
The full list of commands supported by the ILI controller is listed in the datasheet. We will mention some of the important commands that we will use in the exercise:
Display OFF (0x28): The command is used to enter into DISPLAY OFF mode. In this mode, the output from the Frame Memory is disabled, and a blank page is inserted. The figure below shows the effect of the command. The contents of the Frame Memory will stay the same.
Display ON (0x29): The command is used to recover from the DISPLAY OFF mode. In this mode, the output from the Frame Memory is enabled. The figure below shows the effect of the command. The contents of the Frame Memory will stay the same.
Column Address Set (0x2A): The command is used to define the column address of the Frame Memory area that the MCU can access. After the command byte, we need to send 4 bytes as command parameters. These 4 bytes are SC_UpperByte, SC_LowerByte, EC_UpperByte, and EC_LowerByte, where the SC refers to the starting column, and the EC refers to the ending column. These values (of SC and EC) are used when a memory write command is issued. So basically, before writing, we need to set the area where we want to write, and this command will set the column addresses. The figure below shows the illustration of this command.
Page Address Set (0x2B): The command is just like the Column Address Set command except that it refers to the page (row) starting and ending address. The figure below shows the illustration of this command.
Memory Write (0x2C): This command is used to transfer data from the MCU to the Frame Memory. This command utilizes the SC, EC, SP and EP addresses set by the above two commands. The command follows N parameter values where each value is 18-bit color information. The flowchart below shows the use of this command along with the above two commands.
Exercise steps
Open the code base of the exercise by navigating to Create a new application in the nRF Connect for VS Code extension, select Copy a sample, and search for Lesson 5 – Exercise 2.
1. Enable drivers and increase heap
1.1 Enable the SPI and GPIO driver.
Just like in the previous exercise, we want to include the SPI and GPIo drivers by enabling the following Kconfings in the prj.conf file
CONFIG_GPIO=y
CONFIG_SPI=y
1.2 Enable the display drivers and increase the memory heap.
Include the display drivers and increase the memory heap size for storing buffers.
In the boards directory of the application, rename the overlay file to the name of the build target for the board you are using, for example nrf52840dk_nrf52840.overlay.
We have obtained the following code snippet from the shield overlay. We can see that ILI9340 and SDHC are two nodes configured under the spi3 controller. CSX pin for ILI9340 is 0x10, while the D/CX (data/command) pin for the ILI9340 is 0xf, both at arduino-header. We can also see other information like the width and height of the screen and the SCK, MOSI, MISO pins used for the spi3.
4. Create the function spi_ctrl_transmit() to transmit commands and data over SPI.
We want to create a function that takes in the SPI device pointer, a 1-byte command, optional data pointer, and length and calls the underlying GPIO and SPI functions to transmit the command to the screen.
4.1 Declare and configure the transmit buffers with command parameters.
Before sending the command, we must configure the transmit buffers for SPI accordingly. Note that the transmit buffers will point to the command byte, and we are transferring 1-byte only.
Add the following code snippet in spi_ctrl_transmit().
4.2 Set the GPIO pin for the command and write using spi_write_dt().
Next, we write the command using the transmit buffers we set in the previous step and using the spi-configuration that we received via the device struct (dev->config->spi).
First, we set the D/CX (data/command) pin (found in &config->cmd_data) to ‘1’ to say that the byte being transferred is a “command” and then we write using the spi_write_dt() function.
Add the following code snippet in spi_ctrl_transmit().
gpio_pin_set_dt(&config->cmd_data, 1);
err = spi_write_dt(&config->spi, &tx_bufs);
if (err < 0) {
LOG_ERR("spi_ctrl_transmit: Error on %s", config->spi.bus->name);
return err;
}
4.3 Transmit the data that follows the command, if any.
After the command, we need to transmit the data that follows it, if any. Therefore, we check if there is data to send (i.e. tx_data is not empty), then we transfer the whole data by (a) setting the transmit buffers (b) setting D/CX pin for data, and (c) calling spi_write_dt().
Add the following code snippet in spi_ctrl_transmit().
5. Call spi_ctrl_transmit() to transmit the column set and page set commands.
Next, in the ili_ctrl_setmem() function, we will transmit the CASET (column set) and PASET (page set) commands using the spi_ctrl_transmit() function that we have just completed.
6. In screen_write(), call spi_ctrl_transmit() to send the RAMWR command.
The last function in the ili_screen_controller.c file is screen_write(), which takes the device pointer, starting coordinates (x,y) descriptor, and buffer, and calls ili_ctrl_setmem() to set the active area and writes the buffer into the active area memory using spi_ctrl_transmit().
Call the spi_ctrl_transmit function to send the write command (RAMWR) to write pixel information to the buffer that will be displayed accordingly.
Notice that afterwards, we are setting the SPI transmit buffers and writing using spi_write_dt() function which will actually send the buffer (buf) as the command parameters.
Now is the time to complete the code in main.c. The subsequent steps should be done in the main.c file.
7. Include the header file for the ili_screen_controller module.
In order to call the functions that we defined in ili_screen_controller.c from main.c, we need to include the header file of the module, ili_screen_controller.h at the top of main.c.
Add the following line to main.c
#include "ili_screen_controller.h"
8. Write background values to screen (row by row).
The function set_background_color() takes in the device pointer for the screen and its display capabilities and sets the background color (defined as BKGCOLOR). We first set the memory buffer with the background color (greyscale) and then we want to call the screen_write() function to write this buffer to a row. We write the same buffer to all of the rows in a loop and then release the buffer memory at the end.
Add the following code snippet inset_background_color() to complete the function.
for (int idx = 0; idx < cap.y_resolution; idx += h_step) {
ret = screen_write(screen, 0, idx, &buf_desc, buf);
if (ret < 0){
return ret;
}
}
k_free(buf);
9. Display a diagonal line given a starting location (x,y).
In the draw_diagonal_line function, we want to draw a line starting at pixels (uint8_t x,uint8_t y) and of length nump (number of pixels).
First, we set a buffer for a single pixel and fill it with DLINECOLOR.
Then we want to call screen_write() in foor-loop to display the pixel at (x,y) location and then update the coordinates, to display a new pixel diagonally at the next iteration.
Add the following code snippet in draw_diagonal_line() to complete the function
for (int i = 0; i < nump; i++)
{
err = screen_write(screen, x++, y++, &buf_desc, buf);
if (er < 0) {
return err;
}
display_blanking_off(screen);
k_msleep(DELAY);
}
10. Display multiple straight lines with screen_write().
The draw_lines() function displays multiple straight lines. It takes in the starting coordinates (x,y), the size of the lines in pixels, w, the difference of pixels between respective lines, dy, and the total number of lines to draw,numl.
After setting the buffers, we want to call screen_write() in a for-loop and decrease the y-coordinate by dy so that we see multiple lines (stacked upon each other).
Add the following code in draw_lines() to complete the function
for (int i = 0; i < numl; i++)
{
err = screen_write(screen, x, y, &buf_desc, buf);
if (err < 0) {
return err;
}
y -= dy;
display_blanking_off(screen);
k_msleep(DELAY);
}
11. Draw a rectangular box, given the top left-hand corner (x,y).
In the draw_box() function, we want to draw a complete rectangular box given the top left-hand corner (uint8_t x, uint8_t y), the width uint8_t w, and the height uint8_t h.
To do this, it is only necessary with one call to screen_write(), because display_buffer_descriptor buf_desc contains information about the width and heigh of the box.
Add the following code snippet in draw_box() to complete the function
err = screen_write(screen, x, y, &buf_desc, buf);
if (err < 0) {
return err;
}
12. Obtain the screen node from the devicetree.
In main() function, we obtain the screen device instance from the node label ili9340
Add the following code snippet
screen = DEVICE_DT_GET(DT_NODELABEL(ili9340));
if (!device_is_ready(screen)) {
LOG_ERR("Device %s not found, aborting", screen->name);
return 0;
}
13. Observe that we call the previously defined functions one-by-one.
In main(), observe that we are calling the previously defined functions one-by-one:
set_background_color() – Set the background color
draw_diagonal_line() – Draw a diagonal line, 100 pixels long, starting at (20,20)
draw_lines() – Draw 25 lines, all 80 pixels wide, starting at (100,100) with 3-pixel distance
draw_box() – Draw a rectangular box, starting at (100,100)
Testing
14. Install the screen on top of the DK and turn on the DK
Install the screen as a shield on top of a Nordic DK using Arduino I/O interface. Essentially the screen will be upside up and the 6pin female connector on the shield will be connected with the 6pin male connector on the DK. See below for reference:
Nordic DK and Shield: 6pin connectors are highlighted.
Afterwards, turn ON the DK and notice that screen lights up white.
15. Build and flash the application to the board.
We see the correct output on the screen, which shows:
setting of the background color
drawing a pixelated diagonal line starting at (20,20) and of length 100 (num_pixels)
a series of lines one-by-one on top of each other starting at (100,100), i.e. a stack of 25 lines (num_lines)
displaying a rectangular box starting at (30, 130)
The log output should look similar to below
*** Booting nRF Connect SDK v2.5.2 ***
[00:00:00.405,029] <inf> Lesson5_Exercise2: Display Sample on ili9340@0: Orientation=1, Pixel-format=1, X-res=320, Y-res=240
[00:00:00.689,544] <inf> Lesson5_Exercise2: Displaying diagonal line, starting pixel (x, y) = 20, 20
[00:00:02.722,808] <inf> Lesson5_Exercise2: Last pixel (x, y)= 120, 120
[00:00:02.722,839] <inf> Lesson5_Exercise2: Displaying series of lines (1 line at a time), starting line (x, y) = 100, 100
[00:00:03.249,328] <inf> Lesson5_Exercise2: Last line (x, y)= 100, 25
[00:00:03.249,877] <inf> Lesson5_Exercise2: Displaying a rectangular box, top left corner (x,y) = 30, 130
[00:00:03.259,765] <inf> Lesson5_Exercise2: Bottom right corner (x, y) of box = 110, 170
The solution for this exercise can be found in the GitHub repository, lesson5/inter_less5_exer2_solution.
Nordic Developer Academy Privacy Policy
1. Introduction
In this Privacy Policy you will find information on Nordic Semiconductor ASA (“Nordic Semiconductor”) processes your personal data when you use the Nordic Developer Academy.
References to “we” and “us” in this document refers to Nordic Semiconductor.
2. Our processing of personal data when you use the Nordic Developer Academy
2.1 Nordic Developer Academy
Nordic Semiconductor processes personal data in order to provide you with the features and functionality of the Nordic Developer Academy. Creating a user account is optional, but required if you want to track you progress and view your completed courses and obtained certificates. If you choose to create a user account, we will process the following categories of personal data:
Email
Name
Password (encrypted)
Course progression (e.g. which course you have completely or partly completed)
Certificate information, which consists of name of completed course and the validity of the certificate
Course results
During your use of the Nordic Developer Academy, you may also be asked if you want to provide feedback. If you choose to respond to any such surveys, we will also process the personal data in your responses in that survey.
The legal basis for this processing is GDPR article 6 (1) b. The processing is necessary for Nordic Semiconductor to provide the Nordic Developer Academy under the Terms of Service.
2.2 Analytics
If you consent to analytics, Nordic Semiconductor will use Google Analytics to obtain statistics about how the Nordic Developer Academy is used. This includes collecting information on for example what pages are viewed, the duration of the visit, the way in which the pages are maneuvered, what links are clicked, technical information about your equipment. The information is used to learn how Nordic Developer Academy is used and how the user experience can be further developed.
2.2 Newsletter
You can consent to receive newsletters from Nordic from within the Nordic Developer Academy. How your personal data is processed when you sign up for our newsletters is described in the Nordic Semiconductor Privacy Policy.
3. Retention period
We will store your personal data for as long you use the Nordic Developer Academy. If our systems register that you have not used your account for 36 months, your account will be deleted.
4. Additional information
Additional information on how we process personal data can be found in the Nordic Semiconductor Privacy Policy and Cookie Policy.
Nordic Developer Academy Terms of Service
1. Introduction
These terms and conditions (“Terms of Use”) apply to the use of the Nordic Developer Academy, provided by Nordic Semiconductor ASA, org. nr. 966 011 726, a public limited liability company registered in Norway (“Nordic Semiconductor”).
Nordic Developer Academy allows the user to take technical courses related to Nordic Semiconductor products, software and services, and obtain a certificate certifying completion of these courses. By completing the registration process for the Nordic Developer Academy, you are agreeing to be bound by these Terms of Use.
These Terms of Use are applicable as long as you have a user account giving you access to Nordic Developer Academy.
2. Access to and use of Nordic Developer Academy
Upon acceptance of these Terms of Use you are granted a non-exclusive right of access to, and use of Nordic Developer Academy, as it is provided to you at any time. Nordic Semiconductor provides Nordic Developer Academy to you free of charge, subject to the provisions of these Terms of Use and the Nordic Developer Academy Privacy Policy.
To access select features of Nordic Developer Academy, you need to create a user account. You are solely responsible for the security associated with your user account, including always keeping your login details safe.
You will able to receive an electronic certificate from Nordic Developer Academy upon completion of courses. By issuing you such a certificate, Nordic Semiconductor certifies that you have completed the applicable course, but does not provide any further warrants or endorsements for any particular skills or professional qualifications.
Nordic Semiconductor will continuously develop Nordic Developer Academy with new features and functionality, but reserves the right to remove or alter any existing functions without notice.
3. Acceptable use
You undertake that you will use Nordic Developer Academy in accordance with applicable law and regulations, and in accordance with these Terms of Use. You must not modify, adapt, or hack Nordic Developer Academy or modify another website so as to falsely imply that it is associated with Nordic Developer Academy, Nordic Semiconductor, or any other Nordic Semiconductor product, software or service.
You agree not to reproduce, duplicate, copy, sell, resell or in any other way exploit any portion of Nordic Developer Academy, use of Nordic Developer Academy, or access to Nordic Developer Academy without the express written permission by Nordic Semiconductor. You must not upload, post, host, or transmit unsolicited email, SMS, or \”spam\” messages.
You are responsible for ensuring that the information you post and the content you share does not;
contain false, misleading or otherwise erroneous information
infringe someone else’s copyrights or other intellectual property rights
contain sensitive personal data or
contain information that might be received as offensive or insulting.
Such information may be removed without prior notice.
Nordic Semiconductor reserves the right to at any time determine whether a use of Nordic Developer Academy is in violation of its requirements for acceptable use.
Violation of the at any time applicable requirements for acceptable use may result in termination of your account. We will take reasonable steps to notify you and state the reason for termination in such cases.
4. Routines for planned maintenance
Certain types of maintenance may imply a stop or reduction in availability of Nordic Developer Academy. Nordic Semiconductor does not warrant any level of service availability but will provide its best effort to limit the impact of any planned maintenance on the availability of Nordic Developer Academy.
5. Intellectual property rights
Nordic Semiconductor retains all rights to all elements of Nordic Developer Academy. This includes, but is not limited to, the concept, design, trademarks, know-how, trade secrets, copyrights and all other intellectual property rights.
Nordic Semiconductor receives all rights to all content uploaded or created in Nordic Developer Academy. You do not receive any license or usage rights to Nordic Developer Academy beyond what is explicitly stated in this Agreement.
6. Liability and damages
Nothing within these Terms of Use is intended to limit your statutory data privacy rights as a data subject, as described in the Nordic Developer Academy Privacy Policy. You acknowledge that errors might occur from time to time and waive any right to claim for compensation as a result of errors in Nordic Developer Academy. When an error occurs, you shall notify Nordic Semiconductor of the error and provide a description of the error situation.
You agree to indemnify Nordic Semiconductor for any loss, including indirect loss, arising out of or in connection with your use of Nordic Developer Academy or violations of these Terms of Use. Nordic Semiconductor shall not be held liable for, and does not warrant that (i) Nordic Developer Academy will meet your specific requirements, (ii) Nordic Developer Academy will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of Nordic Developer Academy will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through Nordic Developer Academy will meet your expectations, or that (v) any errors in Nordic Developer Academy will be corrected.
You accept that this is a service provided to you without any payment and hence you accept that Nordic Semiconductor will not be held responsible, or liable, for any breaches of these Terms of Use or any loss connected to your use of Nordic Developer Academy. Unless otherwise follows from mandatory law, Nordic Semiconductor will not accept any such responsibility or liability.
7. Change of terms
Nordic Semiconductor may update and change the Terms of Use from time to time. Nordic Semiconductor will seek to notify you about significant changes before such changes come into force and give you a possibility to evaluate the effects of proposed changes. Continued use of Nordic Developer Academy after any such changes shall constitute your acceptance of such changes. You can review the current version of the Terms of Use at any time at https://academy.nordicsemi.com/terms-of-service/
8. Transfer of rights
Nordic Semiconductor is entitled to transfer its rights and obligation pursuant to these Terms of Use to a third party as part of a merger or acquisition process, or as a result of other organizational changes.
9. Third Party Services
To the extent Nordic Developer Academy facilitates access to services provided by a third party, you agree to comply with the terms governing such third party services. Nordic Semiconductor shall not be held liable for any errors, omissions, inaccuracies, etc. related to such third party services.
10. Dispute resolution
The Terms of Use and any other legally binding agreement between yourself and Nordic Semiconductor shall be subject to Norwegian law and Norwegian courts’ exclusive jurisdiction.
