Using images in LVGL, getting "error: expected primary-expression before '.' token"

My projects
1

I’m trying to use images in LVGL. I’ve converted it via the online converter just as the docu says.
I’ve tried this once before but moved on, but it’s time to make it work.

It gives error for the dots at the bottom. I have added include of Arduino.h as well. This is the error I get:

In file included from src\main.cpp:7:0:
src\images/SoS_Skull.c:735:3: error: expected primary-expression before '.' token
   .header.always_zero = 0,
   ^
src\images/SoS_Skull.c:736:3: error: expected primary-expression before '.' token
   .header.w = 191,
   ^
src\images/SoS_Skull.c:737:3: error: expected primary-expression before '.' token
   .header.h = 237,
   ^
src\images/SoS_Skull.c:739:3: error: expected primary-expression before '.' token
   .header.cf = LV_IMG_CF_RAW_ALPHA,
   ^

Here is the code:

const lv_img_dsc_t SoS_Skull = {
  .header.always_zero = 0,
  .header.w = 191,
  .header.h = 237,
  .data_size = 11505,
  .header.cf = LV_IMG_CF_RAW_ALPHA,
  .data = SoS_Skull_map,
};```
2

I had the same trouble. i have changed like this :

const lv_img_dsc_t wps = {
{LV_IMG_CF_TRUE_COLOR_ALPHA,
0,
2,
32,
32},
1024 * LV_IMG_PX_SIZE_ALPHA_BYTE,
wps_map
};

you have to change with your own definitions

2 Likes
3

Working nicely, thank you!!

1 Like
5

but if there are thousands of pic like this, then have repeat this action always？no other way

6

This error usually occurs if the compiler doesn’t support C99, or if the image is being compiled as a C++ file (I think Arduino forces the latter).

If you compile it as a C file you shouldn’t have issues.

7

ok, i See.

8

If you put the fields in the exact order as they are defined in the structs it should also work in cpp:

const lv_img_dsc_t SoS_Skull = {
  .header.cf = LV_IMG_CF_RAW_ALPHA,
  .header.always_zero = 0,
  .header.reserved = 0,
  .header.w = 191,
  .header.h = 237,
  .data_size = 11505,
  .data = SoS_Skull_map,
};

The font converter orders the fields sequentially for this same reason.

@embeddedt Maybe a simple re-order of the fields in the image converter could help with this issue.

The thing is that the field order is actually dependent on the endianness of the device. So that check would also be needed in the image .c file to work cross-platform.

1 Like
9

The chances of someone using a big-endian device and only having a C++ and not a C compiler are very slim. On C, the order is not an issue, as far as I know, so I don’t think it’s worth duplicating the same endianness check in the converter just to support C++.

1 Like
10

I’ve reordered the fields as you suggested and the online converter should now be updated.