Compiler error while trying to port LVGL to Renesas RL78

Get started
1

Description

Hi everybody! I’m a newbie here. I’ve tried LVGL on the simulator and it looks amazing, so I’m trying to see if it’s possible to make it run on a Renesas RL78 R5F100LL.
The problem is that I’m stuck during the compilation phase at an error given by the compiler, which reports a lot of “shift count is too large” errors. I’m using IAR Embedded Workbench for RL78.

By looking at the source I can see why, for example if I open the file lvgl/src/core/lv_obj.h there’s an enumeration which shifts 1s up till 30 position:

enum {
    LV_OBJ_FLAG_HIDDEN          = (1 << 0),  /**< Make the object hidden. (Like it wasn't there at all)*/
    LV_OBJ_FLAG_CLICKABLE       = (1 << 1),  /**< Make the object clickable by the input devices*/
    LV_OBJ_FLAG_CLICK_FOCUSABLE = (1 << 2),  /**< Add focused state to the object when clicked*/
    LV_OBJ_FLAG_CHECKABLE       = (1 << 3),  /**< Toggle checked state when the object is clicked*/
    LV_OBJ_FLAG_SCROLLABLE      = (1 << 4),  /**< Make the object scrollable*/
    LV_OBJ_FLAG_SCROLL_ELASTIC  = (1 << 5),  /**< Allow scrolling inside but with slower speed*/
    LV_OBJ_FLAG_SCROLL_MOMENTUM = (1 << 6),  /**< Make the object scroll further when "thrown"*/
    LV_OBJ_FLAG_SCROLL_ONE      = (1 << 7),   /**< Allow scrolling only one snapable children*/
    LV_OBJ_FLAG_SCROLL_CHAIN    = (1 << 8),  /**< Allow propagating the scroll to a parent*/
    LV_OBJ_FLAG_SCROLL_ON_FOCUS = (1 << 9),  /**< Automatically scroll object to make it visible when focused*/
    LV_OBJ_FLAG_SNAPABLE        = (1 << 10), /**< If scroll snap is enabled on the parent it can snap to this object*/
    LV_OBJ_FLAG_PRESS_LOCK      = (1 << 11), /**< Keep the object pressed even if the press slid from the object*/
    LV_OBJ_FLAG_EVENT_BUBBLE    = (1 << 12), /**< Propagate the events to the parent too*/
    LV_OBJ_FLAG_GESTURE_BUBBLE  = (1 << 13), /**< Propagate the gestures to the parent*/
    LV_OBJ_FLAG_ADV_HITTEST     = (1 << 14), /**< Allow performing more accurate hit (click) test. E.g. consider rounded corners.*/
    LV_OBJ_FLAG_IGNORE_LAYOUT   = (1 << 15), /**< Make the object position-able by the layouts*/
    LV_OBJ_FLAG_FLOATING        = (1 << 16), /**< Do not scroll the object when the parent scrolls and ignore layout*/

    LV_OBJ_FLAG_LAYOUT_1        = (1 << 23), /** Custom flag, free to use by layouts*/
    LV_OBJ_FLAG_LAYOUT_2        = (1 << 24), /** Custom flag, free to use by layouts*/

    LV_OBJ_FLAG_WIDGET_1        = (1 << 25), /** Custom flag, free to use by widget*/
    LV_OBJ_FLAG_WIDGET_2        = (1 << 26), /** Custom flag, free to use by widget*/

    LV_OBJ_FLAG_USER_1          = (1 << 27), /** Custom flag, free to use by user*/
    LV_OBJ_FLAG_USER_2          = (1 << 28), /** Custom flag, free to use by user*/
    LV_OBJ_FLAG_USER_3          = (1 << 29), /** Custom flag, free to use by user*/
    LV_OBJ_FLAG_USER_4          = (1 << 30), /** Custom flag, free to use by user*/
};

This code assumes that an int is 32-bit I guess, but the library is advertised to support 16-bit architecture, right?
In the porting documentation there’s no reference about the 16-bit vs 32-bit CPU architecture and I couldn’t find anyone with this problem. Am I missing something?

Thanks

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

Custom PCB board with Renesas RL78 R5F100LL 16-bit MCU

What do you want to achieve?

Porting LVGL and see if it runs on it.

What have you tried so far?

Compile the source using IAR EW RL78.

Screenshot and/or video

image_2021-10-26_20-58-14
image_2021-10-26_20-58-142562×1440 706 KB

2

(cc @kisvegabor)

I think this is the first time an issue like this has been reported with enums. I am not 100% sure of the best way to fix this (and add a CI test to catch similar problems in the future). Does it help to try something like (1L << 30L)?

3

Thanks for the report.
LVGL really should work with 16 bit MCUs too.

Can you test if LV_OBJ_FLAG_USER_4 = 0x40000000 is working? I’m afraid the size of enums is only 16 bit.

4

I’ve tried to comment LV_OBJ_FLAG_USER_4 = (1<<30) and use instead LV_OBJ_FLAG_USER_4 = 0x40000000 and it took it as good, but the other enumerations were still not ok.
From the IAR development manual:

The compiler will use the smallest type required to hold enum constants, preferring 
signed rather than unsigned.

So the problem seems to rather be the 1 that is 16-bit wide.
Adding the L suffix to all the 1s indeed work (the suffix on the other number isn’t necessary).

Now, after eliminating the examples and disabling LVGL’s own dynamic memory functions, it compiles successfully.

5

If it’s enough to add L could you send a Pull request to fix the enums where required?

What was the problem with the examples and the built-in memory manager?

6

Sorry for the delay I was on vacation.
So yeah adding L to the 1s of the enum was enough to make the compiler happy.

It seems that the examples contains static arrays which are just too big for the compiler to handle, while I still have to find out why LVGL’s own memory manager is not compilable in the current state. This evening I’ll keep investigating.

I though to send a pull request when I’ll make it run on the RL78, but if you prefer to have separate requests I can just send the one with the 1s :slight_smile:

7

LV_ATTRIBUTE_LARGE_RAM_ARRAY in lv_conf.h can help to add a prefix to large array.

I PR with the the 1s only, would be already very useful, so please send one if you have some time for it. :slight_smile:

8

I wouldn’t be surprised if this limitation causes more unexpected issues at runtime. According to this quote of the C99 standard, a C99-compliant environment only needs to support arrays up to 65536 bytes in length. That number matches perfectly with a pointer being 16-bit, so I suspect the RL78 is using 16-bit pointers.

What screen size are you planning on using?

9

Ok I sent the pull request of the 1s.

Now I’ll try to play with LV_ATTRIBUTE_LARGE_RAM_ARRAY.

@embeddedt Yeah I suspect that too. I’m planning on using a size of 320x240. The MCU is already capable of handling this display but it is all hand made and with very little abstraction.
I’m just trying to see if it’s possible to make this MCU run LVGL, because I’m curious xD

Thank you very much for the help guys! I really appreciate it :slight_smile:

EDIT: LV_ATTRIBUTE_LARGE_RAM_ARRAY cannot help, the arrays are just too big to handle.
Specifically I’m referring to the arrays in animimg files (these are the only three files which the compiler refuses to compile).

1 Like
10

Thank you! :slight_smile:

I’ve pushed a fix to LVGL to exclude these images if ANIMIMG is not enabled.