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.
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.
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.
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.
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?
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.
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.
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.
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.
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:
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?
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.
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.