Hardware Examples
Developer-Owned Hardware Integration
Keep GPIO, sensors, actuators and device drivers outside generated LVGL while using generated Runtime SDK APIs and UserEvents.
Who owns each layer
| ForgeUI owns | Developer-owned code owns |
|---|---|
| Editable UI | GPIO and electrical behavior |
| Generated native LVGL | Sensors and actuators |
| Generated Runtime SDK | Bus and device drivers |
| Genuine UserEvent contract | Tasks, services and product logic |
Physical input to ForgeUI UI
c
/* Developer-owned task, in the correct LVGL execution context/lock */
FG_Set_Indicator1(button1_pressed);
FG_Set_Indicator2(button2_pressed);Example 01 reads GPIO2 and GPIO4 in developer-owned code and projects their state through generated setters. It never looks up or mutates the indicator's private LVGL object.
ForgeUI UI to physical output
c
void FG_On_LED1_Toggle_Changed(bool checked)
{
hardware_example_01_set_led1(checked);
}The generated event adapter calls this hook only for a genuine user change. The developer-owned body delegates to the hardware module, which owns GPIO3. The second channel follows the same pattern on GPIO5.
Regeneration-safe workflow
- —Name components deliberately and consume exact declarations from generated headers.
- —Keep private LVGL objects and generated 90_Studio_Export.* replaceable.
- —Keep customised UserEvent bodies concise and delegate hardware work.
- —Place GPIO, drivers, tasks and long-lived state in developer-owned modules.
- —Review generated CMake and source-control diffs after regeneration.
- —Build, flash and verify both UI and physical hardware behavior.