LVGL on Teensy 4: Upgrade to v8

(Cross-posted from pjrc forum)
This for SKPang (I’d be grateful if you could send me a message: .)

I’m doing LVGL on Teensy 4.0; ILI9488, 480x320 SPI LCD. Everything was going swimmingly under LVGL v7.11, but yesterday I allowed Arduino to upgrade to v8.0.2. Of course everything broke – a series of compiler errors which are getting more difficult to address. It’s unclear to me, SKPang, which parts of your v7 code I need to keep, which to update (e.g., all or parts of lv_conf.h) I’ve never ported a graphics subsystem but I’ve given it a little thought and I’d expect it to be reasonably portable, even across major versions.

I’ll be happy to publish working lvgl code public if we get there.
I can hassle through the errors but first I thought I’d ask the experts if this will be fruitful or if it’s a huge job best left to the likes of … you – in which case, I’ll revert to v7.11 and move on.

I don’t want to post “complete source code” or compiler errors – it’s just way too much. If it helps, here are snippets of current compilation errors:

  1. It can’t find the default font:

define LV_FONT_DEFAULT &lv_font_montserrat_14

^ (points to lv_font_montserrat_14
MetronomeApp.cpp:16: error: #include expects “FILENAME” or
I saw a note saying to be sure everything is defined in lv_conf.h. I’ll start searching there for this one

  1. The next 3 errors might be more pernicious. Some #include file linking the driver missing? Or is it just dropping the leading “lv_”? :

R:\QTRNM-QFSV\Teensy\LCD\LCD.ino: At global scope:
LCD:38: error: ‘lv_disp_buf_t’ does not name a type
static lv_disp_buf_t disp_buf;
LCD: In function ‘void setup()’:
LCD:132: error: ‘disp_buf’ was not declared in this scope
lv_disp_buf_init(&disp_buf, buf, NULL, LV_HOR_RES_MAX * LV_VER_RES_MAX / 10);
LCD:132: error: ‘lv_disp_buf_init’ was not declared in this scope
lv_disp_buf_init(&disp_buf, buf, NULL, LV_HOR_RES_MAX * LV_VER_RES_MAX / 10);
LCD:139: error: ‘lv_disp_drv_t {aka struct _lv_disp_drv_t}’ has no member named ‘buffer’
disp_drv.buffer = &disp_buf;

Again, thanks. Your insights greatly appreciated.


/*A static or global variable to store the buffers*/
static lv_disp_draw_buf_t disp_buf;

/*Static or global buffer(s). The second buffer is optional*/
static lv_color_t buf_1[MY_DISP_HOR_RES * 10];
static lv_color_t buf_2[MY_DISP_HOR_RES * 10];

/*Initialize `disp_buf` with the buffer(s). With only one buffer use NULL instead buf_2 */
lv_disp_draw_buf_init(&disp_buf, buf_1, buf_2, MY_DISP_HOR_RES*10);

As far as I know LVGL drivers need static.
Learn more: Display interface — LVGL documentation

Here’s some reading on the topic of porting from V7 to V8 from people who have done it.

Miguel_0101, Jupeos, Thank you very much. Inspired by your hazy purple icon, and despite recommendations elsewhere to just give up and stick with V7, for now, I plan to “bite the bullet and go for it.” I place my trust in this community.
Miguel: with your suggestions and looking at lvgl\examples\arduino\LVGL_Arduino.ino, I’ve solved many compiler errors in my setup “sketch”. But this remaining error remains a mystery. The compiler says (I think this is one error…) :

In file included from c:\users\w7\documents\arduino\libraries\lvgl\src/misc/lv_log.h:16:0,
from c:\users\w7\documents\arduino\libraries\lvgl\lvgl.h:25,
from C:\Users\w7\Documents\Arduino\libraries\lvgl\src/lvgl.h:17,
from R:\QTRNM-QFSV\Teensy\LCD\LCD.ino:8:
c:\users\w7\documents\arduino\libraries\lvgl\src\font\lv_font.h: In function ‘const lv_font_t* lv_font_default()’:
c:\users\w7\documents\arduino\libraries\lvgl\src\lv_conf_internal.h:918:31: error: ‘lv_font_montserrat_14’ was not declared in this scope
# define LV_FONT_DEFAULT &lv_font_montserrat_14 (I added the “” to keep this line from being huge!
^ (this points at lower-case lv)
c:\users\w7\documents\arduino\libraries\lvgl\src\font\lv_font.h:248:12: note: in expansion of macro ‘LV_FONT_DEFAULT’
^ (this points to upper-case LV)

Line 16 of lv_log.h is:
#include “…/lv_conf_internal.h”

This doesn’t look like anything I’m in control of. Do I need to declare the default theme? I can’t figure out where there might be an example to fix this.

It seems that LV_FONT_MONTSERRAT_14 is not set to 1 in your lv_conf.h file, which means that this font is not enabled (which is why you get the error).

I don’t use Arduino, so I can’t provide a more specific suggestion of where the file is, but I believe you should still be able to modify it somewhere.

1 Like

Embeddedt: Thanks so much for your help. Arduino’s a bit foreign to me as well. But at first I was sure you were onto it! The following is the entire “FONT USAGE” section of lv_conf.h , In the 6th line, the editor thinks the comment-ender, “*/” is part of the link/url, so the entire #define block appears as commented out, down to and including "/Demonstrate special features/ ".



/*Montserrat fonts with ASCII range and some symbols using bpp = 4

    #define LV_FONT_MONTSERRAT_8 0
    #define LV_FONT_MONTSERRAT_10 0
    #define LV_FONT_MONTSERRAT_12 0
    #define LV_FONT_MONTSERRAT_14 1
    #define LV_FONT_MONTSERRAT_16 0
    #define LV_FONT_MONTSERRAT_18 0
    #define LV_FONT_MONTSERRAT_20 0
    #define LV_FONT_MONTSERRAT_22 0
    #define LV_FONT_MONTSERRAT_24 0
    #define LV_FONT_MONTSERRAT_26 0
    #define LV_FONT_MONTSERRAT_28 0
    #define LV_FONT_MONTSERRAT_30 0
    #define LV_FONT_MONTSERRAT_32 0
    #define LV_FONT_MONTSERRAT_34 0
    #define LV_FONT_MONTSERRAT_36 0
    #define LV_FONT_MONTSERRAT_38 0
    #define LV_FONT_MONTSERRAT_40 0
    #define LV_FONT_MONTSERRAT_42 0
    #define LV_FONT_MONTSERRAT_44 0
    #define LV_FONT_MONTSERRAT_46 0
    #define LV_FONT_MONTSERRAT_48 0

/Demonstrate special features/
#define LV_FONT_MONTSERRAT_28_COMPRESSED 0 /bpp = 3/
#define LV_FONT_DEJAVU_16_PERSIAN_HEBREW 0 /Hebrew, Arabic, Perisan letters and all their forms/
#define LV_FONT_SIMSUN_16_CJK 0 /1000 most common CJK radicals/

/Pixel perfect monospace fonts/
#define LV_FONT_UNSCII_8 0
#define LV_FONT_UNSCII_16 0

/*Optionally declare custom fonts here.
*You can use these fonts as default font too and they will be available globally.

/Always set a default font/
#define LV_FONT_DEFAULT &lv_font_montserrat_14

/*Enable handling large font and/or fonts with a lot of characters.
*The limit depends on the font size, font face and bpp.
Compiler error will be triggered if a font needs it./

/Enables/disables support for compressed fonts./

/Enable subpixel rendering/
/Set the pixel order of the display. Physical order of RGB channels. Doesn’t matter with “normal” fonts./
#define LV_FONT_SUBPX_BGR 0 /0: RGB; 1:BGR order/

Adding a space between t and * fixes that (for the editor) but the compiler isn’t satisfied. I inserted a newline to be sure, but still get the same error. Here’s a snippet from lv_conf_internal.h – which I think is a pre-processed, all-inclusive header? :








(Sorry that presents so bad!) Looks to me like it should have what it needs. If I try changing to montserrat_12 as follows:


/Always set a default font/
#define LV_FONT_DEFAULT &lv_font_montserrat_12

I get EXACTLY the same error about montserrat_14, which leads me to conclude that lv_conf.h isn’t in-control of this. lv_conf_internal.h looks exactly the same as before.

lv_conf_internal.h is a file which is autogenerated by us before releases. It holds the default options which are applied if lv_conf.h is not found. If changing something in lv_conf.h is not affecting the errors, the most likely cause is that lv_conf.h is not in the include path. You can test this by adding an #error test directive to the top of lv_conf.h and checking whether the build fails with a reference to that error. If it does not, you can be 100% sure that the include path is the problem.

1 Like

Thanks! I figured this out. This is for any Teensy (actually, any Arduino) developers who run into this problem…
My work path is [drive]:[project]\Teensy[codebase]
But lvgl “lives” at C:\Users[MyName]\Documents\Arduino\libraries
It turns out there were 4 lv_conf.h files, at both of the above, plus at both places, a level down (in lvgl.) Deleting/renaming files one-by-one, I determined that the controlling file is at …\libraries.
The business about a space between the url and the closing comment is apparently a red herring; I can’t re-create that error. Onward! Your help makes all the difference!

It’s been reported to us before… usually the editor has its own simplified parser which fails to track edge cases like this properly. However, the compiler should not be affected.