Improve PC port feature support (Win32/Linux)

[kuba2k2]

This PR adds the following improvements to the "PC" build of openHASP:

• [x] building without MQTT (fix)
• [x] storage support (OS filesystem) + printing config directory path
• [x] config.json support
• [x] Win32: GDI port (without SDL2)
• [x] single void setup()/void loop() entrypoints for PC and Arduino builds
• [x] Linux/Win32: threaded LVGL task
• [x] Linux: fbdev port
• [x] Linux: mouse and touchscreen support
• [x] Linux: support LCD backlight control
• [x] Linux: specify fbdev and evdev paths in config.json
• [ ] set max framerate in config.json
• [x] Linux/Win32: command console support (stdin)
• [x] Linux/Win32: execute shell commands, process output
• [ ] support "action" tag for all controls
• [ ] replace %xyz% values in commands specified in "action" tag (optional, build-time-disabled by default)
• [ ] command scheduling
• [x] Linux/Win32: MQTT on a separate thread (Paho async)
• [x] submit lv_drivers PR: https://github.com/fvanroie/lv_drivers/pull/1

---

It is worth noting that MQTT parameters cannot be passed in the command line arguments now - it's configured in config.json, as usual on ESP32 devices. If desired, I can try to restore that possibility, although I doubt that anyone was using it "in production" - the PC port wasn't really ready for that, due to lack of config.json support.

The PR also adds some code quality improvements:

• HASP_TARGET_ARDUINO, HASP_TARGET_PC macros instead of defined(WINDOWS) || defined(POSIX)
• logging output alignment fixes, unifying sources of _chip_model, _core_version
• fixed memory corruption (out-of-bounds read) caused by incorrect usage of memcpy()
• used implicit (auto) type instead of useconds_t to fix building on Alpine Linux (musl libc)
• clang-formatted code here and there

---

EDIT:

I've tested all these changes on windows_sdl_64bits, windows_gdi_64bits, linux_sdl_64bits and linux_fbdev_64bits. I haven't tested on ESP32, since I don't have a working setup at hand. Even though I haven't changed nearly anything in the ESP32 implementation, testing on actual hardware would be appreciated.

[kuba2k2]

Hi @fvanroie The PR should be ready for review now :slightly_smiling_face:

[fvanroie]

These seem like additional features, not related specifically to the PC port enhancement:

• [ ] Linux/Win32: execute shell commands, process output
• [x] support "action" tag for all controls
• [x] replace %xyz% values in commands specified in "action" tag (optional, build-time-disabled by default)
• [x] command scheduling

[kuba2k2]

I can move them to a separate PR (PRs?). Say the word and I'll do it 😃 The "shell" feature is specific to the PC port however, because it executes operating system commands in the Linux/Windows console shell, and ESP doesn't have that.

[kuba2k2]

The following commits have been reverted:

• Allow changing LVGL refresh and animation period
• Support event data substitution in action commands
• Implement command scheduling
• Allow publishing MQTT message even with action tag

Hopefully that makes the PR a bit easier to review.

[fvanroie]

OK, we're testing this PR, most looks good. One issue encountered is that images on ESP32 don't seem to load anymore, which I think has to do with the path separator change.

edit: it looks like the removal of lv_fs_if_init(); is the problem.

[kuba2k2]

I don't think it's possible. The change I introduced isn't even compiled on Arduino builds. It was previously set to backslash, which wouldn't even make sense on ESP32 as backslashes are almost exclusively used by Windows. Besides, my changes here are only related to jsonl loading, which doesn't change the image loading process.

[kuba2k2]

Re:

edit: it looks like the removal of lv_fs_if_init(); is the problem.

That is possible. I assumed that the test code was there for the unfinished PC port, I didn't realize that it actually gets compiled on ESP32 as well. The config.json reading part shouldn't be necessary nevertheless.

[fvanroie]

That is possible. I assumed that the test code was there for the unfinished PC port, I didn't realize that it actually gets compiled on ESP32 as well. The config.json reading part shouldn't be necessary nevertheless.

The LVGL filesystem driver is needed on all platforms. That check is/was there for testing if the lvgl filesystem driver was working, as config.json should be there. It didn't really server any other purpose. So, the check isn't necessary but the lv_fs_if_init(); certainly is.

[kuba2k2]

Corrected - that should fix the issue on ESP32.

[kuba2k2]

Thanks :smiley: