EEZ Flow alternative

[mvladic]

I understand that for some users EEZ Flow is not ideal solution because of various reasons:

• It is implemented in C++
• It generates source code that is opaque, i.e. there is a binary blob and runtime engine (eez-flow.cpp) that interprets what is inside that blob.
• Consumes more memory (both flash and ram) than full native code
• Visual programming is not for all

When EEZ Flow is not used, only option is to implement event handlers in native code. Big problem with this is that it can't be tested in Studio simulator.

What can be alternative way to implement event handlers so that it can be tested in Studio and later converted to clean C code?

These are some options:

• EEZ Flow Lite, which will have some restrictions compared to existing EEZ Flow, so it can be converted to clean C code.
• Scripting language which can be interpreted in Studio and converted to C code. For example, In this toy project I created toy scripting language (similar to TypeScript).
• Something like I described here. I think something similar exists in SquareLine Studio.
• Blockly?

I want to know your opinion about this?

[Xinyu-Sheng]

If EEZ Studio could generate native LVGL C code—meaning no dependency on a runtime interpreter or binary blobs—while preserving its current visual programming capabilities, and integrate a cross-platform LVGL simulator (e.g., based on SDL) that runs the actual generated LVGL project instead of simulating logic, it would fundamentally eliminate inconsistencies between simulation and real-world behavior.

Moreover, if the generated C code is human-readable and debuggable, and users are allowed to embed custom C code snippets directly within Flow nodes (not just via Action nodes), development flexibility and efficiency would be greatly enhanced.
The current approach of inserting code through Action nodes works, but inline code within flowchart nodes would be far more intuitive and convenient.

This combination—visual design + native code generation + real LVGL simulation—might well be a promising direction for the future evolution of EEZ Flow.

[mvladic]

To avoid any confusion, the EEZ Studio does not simulate the LVGL API but instead uses the actual LVGL library compiled with Emscripten - the result is WASM (web assembly) which can be run inside Electron (web platform) application such as EEZ Studio.

What you're asking for – to be able to insert any C inline code – isn't that simple, because it would require a C interpreter. Or, another way to implement this is to use an external C compiler, and every time the Run button is pressed, generate the code, invoke the C compiler (i.e., Emscripten), and then run the generated WASM. However, this would inevitably slow down the launching of the project (Run) within the Studio. One possible way to accomplish this is to use Podman as a way to install all required tools for C compilation.

Currently, EEZ Flow allows too much flexibility (multiple lines connected to the same node input, multiple lines coming from the same node output). Because of that it is very very difficult to generate clean (human readable) C code. Hence, I wrote that we need EEZ Flow Lite that will forbid such flexibility, but it will be possible to generate straightforward C code.

[Xinyu-Sheng]

I realize now that I didn’t explain the “inconsistency” clearly in my earlier comments. It’s not about visual differences, but rather two deeper issues:

1. Memory behavior inconsistency:
   I used list.append to dynamically grow an array of structs. When I declared the struct array as a local variable and then called append, it worked fine in the EEZ Studio simulator—but crashed on real hardware with an unhelpful error (eventually traced to a null pointer). The root cause was that append requires the list to be a global variable due to scope/lifetime limitations in the generated runtime. This is extremely confusing for users who expect consistent semantics between simulation and real execution.

2. Action side-effect invisibility:
   Any LVGL state changes made inside a custom C action (e.g., updating the UI language via i18n ) are not reflected in the EEZ simulator. The simulator has no awareness of these low-level C-side mutations, so the preview becomes misleading. This breaks the trust developers place in the simulation environment.

Suggestion:
Consider embedding a real LVGL simulator directly into EEZ Studio. Provide a “Run in Full Simulator” button—yes, it may be slower, but it would guarantee bit-identical behavior between development and deployment. Users could choose between:

• Fast visual preview (current mode), and
• Accurate behavioral simulation (new mode).

Additionally, EEZ Flow Lite could adopt a programmer-centric model: use actual C/C++ control flow (if/for/while) as first-class constructs, rather than hiding logic behind opaque blocks. This would make program behavior more predictable, easier to debug, and align better with how embedded developers think.

Looking forward to hearing your thoughts!

[mvladic]

I agree with your opinion. "Running in Full Simulator" would be a great addition to the Studio. Also, EEZ Flow Lite that can be both interpreted inside Studio and that can generate clean C code is also something that should be goal so that normal "Run" is even more realistic.

As a side note, let me tell you that I already have a tool to do quick testing of the eez-project's using real LVGL SDL simulator. Here is how it looks:

As I usually work on Windows, I'm using WSL (Windows Subsystem for Linux) to do the compilation. I needed to prepare Ubuntu image under WSL to have all required components (mainly Emscripten) to be able to build the projects. This is not portable solution, so I'm experimenting with the Docker Desktop. I tried also Podman Desktop, but found that Docker Desktop is easier to use. Here is how it looks the similar tool that uses Docker Desktop:

I'm not quite satisfied with the Docker as it is slower than previous WSL solution.

Anyway, I will continue to investigate this and hopefully I will integrate something like this into Studio.

[mvladic]

FYI I created an issue for “Run in Full Simulator”: #896

[mvladic]

FYI Full Sim is now implemented (#896) and it is in master branch. It will be released in version 0.26.0