Frequently Asked Questions¶
Does the PC build need Docker or containerisation?¶
No. The PC build produces a native executable (.exe on Windows, a plain binary on macOS/Linux) that embeds its own HTTP server. You run it, open a browser, and the full control UI appears at http://localhost. There is nothing to containerise: the binary is the server.
Docker would only be useful if you needed to ship a reproducible build environment to developers. For end users who just want to run the software, a single binary is simpler.
How does projectMM handle external libraries: ArduinoJSON, AsyncWebServer, rotary encoders, I2C sensor drivers...?¶
The strategy is: let the toolchain manage dependencies, and keep the projectMM core platform-independent.
On ESP32 (PlatformIO): libraries are declared in platformio.ini under lib_deps. PlatformIO downloads and links them automatically. Hardware-specific libraries (rotary encoder drivers, INA219 I2C, async web server) live here and are only compiled when targeting embedded hardware.
On PC (CMake): the build system pulls in the small number of cross-platform libraries that the core actually needs (ArduinoJSON, LittleFS, doctest). Hardware-specific libraries are not compiled because the PC does not have that hardware.
The dividing line is the Platform Abstraction Layer (PAL): anything that differs per platform is wrapped in a PAL function. Module code above PAL never includes a hardware-specific header directly.
What about SvelteKit or other frontend frameworks? The current frontend is a self-contained vanilla JS/HTML bundle compiled into the firmware. A richer framework like SvelteKit is not planned for the current release cycle. The bundle approach keeps the build simple and the binary self-hosting with no CDN dependency.
Which platforms can projectMM run on?¶
| Platform | Status |
|---|---|
| ESP32 classic (Arduino framework) | Supported |
| ESP32 (bare ESP-IDF) | Partial: builds, most PAL functions wired |
| macOS / Linux (PC build, CMake) | Supported |
| Raspberry Pi | Builds (same CMake path as PC) |
| Windows (native) | Not tested: MinGW, Cygwin, or WSL are the likely paths |
| Windows (Docker) | Unnecessary — see above |
The PC build has no real tasks/threads. Does the module loop just run in the main thread?¶
Yes, on PC all modules run in a single thread today. The FreeRTOS task helpers (pal::task_create_pinned, pal::yield, semaphores) are no-ops on PC, so setup() and then the module loop run sequentially.
This is intentional for the current release: the PC build is used mainly for fast iteration, UI development, and running the automated test suite. Multi-threaded PC execution (via pthread or std::thread) is on the roadmap for when the PC build needs real concurrency.
Where can I report bugs or ask questions?¶
Open an issue at github.com/ewowi/projectMM.