Passing data to/from the UI.....how?

How to
1

Is there any document which describes how to set up the ui as its being created to receive and send data outside the ui? It should not require changes to the generated ui code,otherwise it becomes a development nightmare.

What have you tried so far?

Searched and asked AI.

Others

  • **SquareLine Studio version: v1.5.1
  • Operating system: win 10
  • Target hardware: ESP32
  • LVGL: 9.2.2.
2

Apparently through Events and Actions | SquareLine Studio
I tried, but I couldn’t. :man_shrugging:
You will still have to make changes to the source code. I’ve been studying EEZ Studio for several days now. In EEZ Studio are two other solutions besides calling the function on an event. Using global variables and the EEZ Flow method.

3

We’ve had good luck checking the “don’t export” function call checkbox, then implementing these ourselves without editing SLS’s exported codebase.

The component hook file is the only file we’ve had to replace.

4

The way I interpret the call function is it is in response to a ui event. But what about the other way? Lets say I’m displaying a screen full of real time data. How do you pass the data to be displayed, without altering the generated ui code?

5

I see how to do it. if you look in ui.h, you will see all the variables declared. Its all a maddening mess of layered typedefs, but you can change any of these extern variables outside of of the ui code. There are various functions in the ui code that can be used to make the changes. For example:

lv_label_set_text(ui_Label_mylabel, stringbuffer);

I have done it and it worked. I need to play with it a lot more to be comfortable with it.

The name of the variable is derived directly from “Name” field of the element in SLS

1 Like
6

Just make sure to change them only from the same UI thread.

7

Can you be more specific? What is the concern?
Currently, as a test, I randomly change the position of elements on the screen in an animated fashion in a while loop in main.c. No issues yet.

8

LVGL is not generally thread safe. Mostly, in two ways that have caused problems before for me:

  • Problem 1 is the heap: even a simple lv_mem_monitor() from one thread may crash when another thread calls lv_mem_alloc() or lv_mem_free(). You can swap out LVGL’s allocator to call a thread-safe heap, like libc.
  • Problem 2 is read-modify-write. When one thread calls lv_obj_add_flag(obj, FLAG1) and another calls lv_obj_add_flag(obj, FLAG2), the resulting object flags could be FLAG1, or FLAG2, or FLAG1|FLAG2

The above issues often cause strange behaviour that can be difficult to debug and reproduce. Other approaches that don’t have these issues:

  • Could do all UI updates on the UI thread(or use main thread as UI thread).
  • Can add a mutex that UI thread holds while running, other threads need lock it before updating UI.

Read more here

1 Like