Build with ForgeUI. Help shape what comes next.
Build against semantic FG_Set_* and FG_Get_* APIs, receive genuine user interaction through FG_On_* hooks, and keep product logic in regeneration-safe developer-owned layers.
Generated LVGL C. Developer-owned application logic.
Design visually and simulate generated UI with real LVGL before connecting hardware. Use the exact runtime setters in 90_Studio_Export.h and implement generated 95_UserEvents.c hooks to connect application state. Build & Flash runs your ESP-IDF firmware on supported hardware; custom C stays in the firmware workflow.
Developer portal
Documentation and project paths
Start with the public guide, open the detailed code maps when you need implementation depth, or continue to a project contribution area.
Device workflow
One authoritative serial source
The local ForgeUI backend owns one serial connection. MONITOR exposes its raw output; the read-only I/O parser derives recognised state from that same stream without becoming a second COM-port owner.
ESP-IDF Build / Flash
BUILD presents the existing authoritative ESP-IDF pipeline, live progress, stop, clear and auto-scroll.
Open guide →Raw MONITOR
Port enumeration, selectable baud and raw ESP32-P4 output, with safe port release before flashing.
Open guide →Read-only I/O parser
Recognised runtime patterns become compact insight without commands, hardware control or guessed values.
Open guide →Working product
Studio, generated runtime and target output
A concise view of the current workflow. Detailed architecture, ownership and validation records remain in the Documentation Centre.
Physically proven integration
Hardware Examples keep device behavior developer-owned
ForgeUI owns the editable UI, generated LVGL, Runtime SDK and genuine UserEvents. Developer code owns GPIO, sensors, actuators, bus/device drivers and physical behavior.
GPIO2 Button 1 → FG_Set_Indicator1(bool)
Developer-owned GPIO and debounce code projects physical state into the ForgeUI UI through the generated Runtime SDK. GPIO4 and Indicator 2 follow the same pattern.
Open guide →FG_On_LED1_Toggle_Changed(bool) → GPIO3
A genuine generated touchscreen UserEvent delegates to developer-owned output code. GPIO5 and LED 2 follow the same pattern; private generated LVGL objects remain untouched.
Open guide →Stock C6 → verified HTTPS → Live Weather
Hardware Example 04 proves association, DHCP, DNS, TCP 443, certificate-verified TLS, HTTP 200, current conditions, multi-day forecast, network time, Fi icons and dynamic local backgrounds.
Open guide →u-blox NEO-8 → UART1 → live GPS/GNSS
Hardware Example 05 proves live checksum-valid NMEA, 2D/3D fix handling, position fields and checksum-valid UBX-MON-VER request/response on GPIO3/GPIO4.
Open guide →Contribution areas
Ways to Contribute
Choose the layer you understand. Each contribution should include the evidence needed to review it safely.
Studio Development
React, TypeScript, editor workflow and UI systems.
Open guide →Embedded Runtime
ESP-IDF, LVGL, FreeRTOS and device integration.
Open guide →Board Support
Displays, touch controllers, BSPs and hardware ports.
Open guide →Components
Reusable interactive controls and generated APIs.
Open guide →Documentation
Guides, examples, troubleshooting and API reference.
Open guide →Testing
Browser, export, build, flash and physical hardware validation.
Open guide →Design
Themes, icons, workflows and embedded HMI usability.
Open guide →Example Projects
Real product demonstrations and reproducible starter projects.
Open guide →Pull request workflow
Start Contributing
Fork the product repository into your own GitHub account. Keep the branch focused and state exactly what you validated.
- Fork the repository
- Create a focused branch
- Read the relevant docs
- Make the change
- Add or update tests
- Validate locally
- Open a pull request
- Respond to review
git clone <your-fork-url>
git checkout -b feat/my-feature
git add .
git commit -m "feat: add my feature"
git push -u origin feat/my-featureReview baseline
Contribution Principles
A browser implementation is only one layer. Embedded changes must remain coherent through persistence, export, build and hardware.
Keep the change reviewable
Keep changes focused, follow existing naming and architecture, avoid unrelated refactors and document new behaviour. Never commit secrets.
Supply engineering evidence
Add tests, identify the hardware exercised, preserve proven behaviour and separate experimental results from officially supported features.
Respect ownership boundaries
Generated UI belongs in the Studio-managed layer. Product behaviour belongs in developer-owned hooks and normal ESP-IDF components.
Open guide →Complete the full path
Component definition → Studio palette → Canvas → Inspector → Preview → persistence → LVGL export → generated API → tests → docs.
Open guide →