Stm32f407vet6 black board and ili9341 tft lcd display

Get started
1

Description

Has anyone ported LittlevGL over for the stm32f407vet6 “black” board and an ili9341-based QVGA display? I’ve been looking online for a couple of hours and I’ve not found anything that seems to be it.

What MCU/Processor/Board and compiler are you using?

stm32f407vet6 “black board” and an ili9341-based 3.2 inch tft LCD touch-screen display.
gnu arm-cross compiler on OS X Catalina. (Compiler works - tested)

What do you want to achieve

Ultimately? I need LittlevGL working on that board (or a vgt) to create something.
Right now - just trying to get a demo working on the device so I can then create my actual code.

What have you tried so far?

Searching the Internet for a port.

3 Likes
2

A few days ago I have started with lvGL and I’m using the same board and mbed:

But it is in an early experimantal state and I have not published the porting yet. Give me a little more time and I will push it to github.
I have ported also mbed-os for this board, there you have a OS with or without RTOS and support for standard devices like GPIO, UART, SPI, I2C and more. I have written also a SDIO driver for using a SD card with mbed. This is not yet tied to lvGL, but should be easy because the stdio is working with this driver.
I’m using this board with the AdafruitGFX lib and FSMC driver, the lib has a drawBitmap function that matches exactly the needs for the lvGL driver. So I left the AdafruitGFX for initialising the FSMC and ILI9341 and copied the necessary part to the lvGL driver. So both gfx libs can be used.

mbed has an C++ API, so a C++ wrapper is the only thing I’m missing in lvGL. If you want to start with mbed, this is a good entry:
https://os.mbed.com/docs/mbed-os/v5.14/introduction/index.html#getting-started
and
https://os.mbed.com/users/hudakz/code/STM32F407VET6_Hello/shortlog/
The online compiler is good for starting also, but the offline CLI is much more powerful. It is written in Python and also availible for MacOS.

3

OK. I’ll look into that. I was hoping to avoid the overhead of an OS since this is a single-purpose device, but I’ll see how much program memory it takes. I’ll report back on my progress. We’re on Fall break at the university (I’m a professor) so I have a couple of days where I can focus on this.

Thanks!

4

MBEDCli crashes on Catalina. I’m going to see if I can find a way around the issue. I’m still going to look at what you’ve done to see if I can adapt it to avoid MBED because I can create code on the command line and in Eclipse and have it work, so I just need to find a way to make lvGL work.

5

I have uploaded my repo, you can find it here:

About mbed-cli problem:
the MacOS installer looks old, what happens when you run ‘mbed-cli --version’? If a version is shown, you can update it by ‘pip install -U mbed-cli’. When an error is shown instead, try the manual installation:
https://os.mbed.com/docs/mbed-os/v5.14/tools/manual-installation.html

About my program:
The driver uses the init from the AdafruitLib, using FSMC. You will find it here:


Also the initialisation of the ILI9341 is done there. The ILI9341 can be set to update a window in the display, that matches perfect to the needs for lvGL. With FSMC, the setWindow command must be sent and then the stream of data is written to the data address. FSMC generates the WR and CLK pulses, so writing to the display is very fast. In FSMC init are settings for the timing. This code was adopted from the STM32duino.

The driver for the touch display is in


using the code from the lv_indev samples. The constants for calibration may need to be adjusted.
In main.cpp are a few demo or tutorial functions commented out, you can activate them to get the lvGL demo screens.
Using the lv_handler_task in an own OS task was not working reliable, the documentation says a mutex must be used. A simple solution was to use the lv functions in the main thread.
Other stuff in main is for controlling a stepper motor, it can be kicked off, I left it as a sample for threads.

6

Yes, because otherwise two threads will concurrently access an lvgl structure, which is not supported.

In my experience, because of the way LittlevGL events work, you can probably do everything on a single thread (unless you really need to change some object from another thread).

Lots of other event-driven systems (including websites) operate largely or entirely off a single thread.

7

I agree, a rtos can introduce very random faults or deadlocks, so going an easy and safe way is better.
In my sample, I added a splash screen that should show for 2 seconds and then starting the main screen. Calling only a sleep after creating a screen did not show it, so I added the lv_handler_task in the delay. Or is there some update call that draws immediately?

8

Please show a code sample. It’s easier to understand than a vague description. Something like this should work (deliberately using generic function names for clarity):

static void task_a(void)
{
    mutex_lock(&lv_mutex);
    show_splash_screen();
    mutex_unlock(&lv_mutex);
    os_sleep_ms(2000);
    mutex_lock(&lv_mutex);
    show_main_screen();
    mutex_unlock(&lv_mutex);
}
static void task_b(void)
{
     while(1) {
         mutex_lock(&lv_mutex);
         lv_task_handler();
         mutex_unlock(&lv_mutex);
         os_sleep_ms(10);
     }
}
9

yes, I understand. I’m not sure what I want to use finally. Now I’ve this sleep function that periodically calls the lv_handler:


At the end of main, it will call this function running in an endless loop. So the lv_handler will execute everything in the main context. IO and a controller can run in tasks with higher prio than main.

10

You are missing the use of a mutex around lv_task_handler.

11

the lv_task_handler and lv functions are only called from the main task. The other task was not started, that was confusing. I have removed the unused code.

1 Like
12

Thank you, everyone! I’m going to look at this tonight. For some reason, I did not receive an email telling me that your messages were here. This would really help me out. I was about to post another question asking which functions I needed to implement in LVGL to do this myself.

13

Hi Jojo,

I’m getting errors. mbed is complaining that I have python3. I did the manual install and it worked just fine, but now I’m receiving cryptic error messages from mbed.

querist@questor Test-lvgl % mbed compile -v -m STM32F407VE_BLACK -t GCC_ARM
[mbed] WARNING: Python 3 is not yet fully supported: Python errors may occur when compiling, testing and exporting
---
[mbed] Working path "/Users/querist/Documents/src/arm/stm32_code/Test-lvgl" (program)
[mbed] ERROR: "/Library/Frameworks/Python.framework/Versions/3.7/bin/python3" returned error.
       Code: 2
       Path: "/Users/querist/Documents/src/arm/stm32_code/Test-lvgl"
       Command: "/Library/Frameworks/Python.framework/Versions/3.7/bin/python3 -m pip list -l"
       Tip: You could retry the last command with "-v" flag for verbose output
---

Running it with the -v flag does not provide any additional information. I’m sorry to bug you with this, but I’m trying to make this work and I was hoping you’d have an idea.

I’ve upgraded pip to no avail.

Thanks

14

hi, it looks like a probem with python installation, there I’m not the best expert, but I will try to help.
the mbed-cli should run with python 3 as well. Could you try ‘pip install -r requirements.txt’, executed in ‘./test-lvgl/mbed-os’ dir?
And what version is reported for ‘mbed-cli --version’? An update is possible with ‘pip install mbed-cli -U’

Another suggeston about the python3 installation on MacOS is here:

15

I ran the pip and it installed quite a few packages, then trying the compile returned the same error.

I’m running mbed-cli 1.10.1

16

ok, then python, mbed-cli and the requirements should be fine. Then there may be a problem with calling gcc from python? Is some other command like ‘mbed status’ also working?
could this be some hint?

17

OK - it compiles now after reinstalling PIP and some other gymnastics, but nothing shows up on my display. Are you using an ILI9341 board? Does the board just plug into the TFT header on the BLACK board or is it connected some other way?

18

yes, it is for the 3,2" display with ILI9341. How do you transfer the program, can you also use a debugger?
The first printf will print the message over the USART pins PA9 / PA10 with 115200 Bps…

19

Unfortunately, I have no simple means to do the debugging. I have a cheap ST-Link v2 clone that I’m using for transferring the programs (and I know it works because I’ve programmed the device before) but I don’t know how to use it with a debugger.

What I can tell you is that when I press the buttons on the board (K0, K1) the led changes how it is flashing, so I’m sure that the software is loaded. It is just not showing anything on my display. The only non power/ground pins on this device are the two I use to transfer the programs - SWCLK and SWDIO, and two others RST and SWIM. The other six pins are two GND, two 3.3v pins and two 5.0v pins. I’m afraid I’m mainly a software guy. I’m trying to learn hardware.

20

The board should be supplied only with 5 V. Connect the 3.3 V only to the Vtarget at the debug probe, not to an 3.3 V power output from the probe.
Maybe you can try to use VSCode and the Cortex debug extension, that is also multi platform and supports STLink debugging.