Visual Embedded Systems Workbench
FLOWFORGE is a single file visual development environment for microcontroller projects. It lets you build embedded logic by placing components on a canvas and connecting typed signals instead of starting with handwritten firmware.
FLOWFORGE is designed around one canonical project graph. Board assignments, signal metadata, simulation, verification, generated firmware, compiler evidence, runtime telemetry, wiring documentation, debugging, and engineering deliverables all refer back to the same graph.
The v6.0 workflow is:
Design → Verify → Compile → Upload → Connect → Match → Prove
The goal is to let a simple project remain simple while still exposing the engineering evidence needed for more serious embedded work.
FLOWFORGE combines visual programming, hardware configuration, simulation, code generation, build integration, device monitoring, verification, debugging, and documentation in a single browser application.
Core capabilities include:
- Drag and drop flow based embedded programming
- Typed inputs, outputs, and signals
- Arduino and ESP32 oriented firmware generation
- Board specific GPIO assignment and pin validation
- Board and pinout visualization
- Physical wiring view
- Guided project templates
- Easy and Advanced modes
- Simulation with waveform and fault injection
- MQTT, HTTP, TCP, UDP, Modbus, CAN, LoRa, JSON, DSP, and execution nodes
- Device Studio and reusable device packages
- Generated Arduino compatible source
- Graph ↔ FLOW IR ↔ source traceability
- Build manifests and dependency manifests
- Arduino CLI and PlatformIO integration through FLOWFORGE Bridge
- Compiler diagnostics mapped back to graph nodes
- Web Serial runtime monitoring
- FF1 firmware telemetry protocol
- Hardware in the Loop test support
- Resource, bandwidth, memory, and timing analysis
- Verification suites and regression runs
- Visual debugger and signal history
- Engineering package ZIP generation
- Project migration, autosave, recovery, copy and paste, and production audits
FLOWFORGE is distributed as a single HTML file.
- Open
flowforge-v6.0.htmlin a modern Chromium based desktop browser. - Choose Easy Mode for the guided workflow or Advanced Mode for the full engineering workspace.
- Select a target board.
- Add hardware or choose Guided Start.
- Assign pins in Board & Pins.
- Connect the logic graph.
- Run Simulation and Verification.
- Run Build Preflight.
- Use FLOWFORGE Bridge for real compilation and upload.
- Connect to the running device with Web Serial.
- Verify the running firmware identity.
- Run HIL tests where applicable.
- Generate the engineering package.
No installation is required for graph design, simulation, project files, generated source, or engineering documentation.
Real compilation and firmware upload require an external toolchain or FLOWFORGE Bridge.
The Workbench is the production oriented cockpit for a FLOWFORGE project.
It presents the evidence chain as distinct stages:
DESIGN
The graph, hardware assignments, board profile, wiring, and configuration exist.
PREFLIGHT
FLOWFORGE validates graph structure, backend support, pin assignments, generated source structure, target configuration, and dependencies.
VERIFY
Simulation or a verification suite has produced project evidence.
BRIDGE
FLOWFORGE has connected to the external FLOWFORGE Bridge service.
COMPILE
A real compiler has reported a successful build.
UPLOAD
A real upload action has succeeded through the external toolchain.
CONNECT
FLOWFORGE has connected to a device using Web Serial.
MATCH
The running firmware identifies itself as the firmware generated for the current project.
PROVE
A physical Hardware in the Loop test has produced matching readback evidence.
FLOWFORGE deliberately keeps these stages separate. Browser preflight is not treated as compilation, a successful upload is not treated as runtime proof, and a serial connection is not treated as proof that the connected firmware belongs to the current graph.
Easy Mode focuses on the minimum path needed to create a working project.
The intended workflow is:
Board → Hardware → Pins → Logic → Test → Build → Upload → Monitor
Guided Start templates create normal FLOWFORGE projects. They do not use a hidden template runtime or separate graph model.
Current starter projects include examples such as:
- Button → LED
- Analog Sensor → Threshold
- Potentiometer → PWM
- Temperature Monitor
- Relay Controller
- Motor Controller
- MQTT Sensor
- Modbus Register Monitor
- Serial / TCP Gateway
- Timed Pulse
- Blank Project
Advanced engineering workspaces remain available without becoming prerequisites for simple projects.
Advanced Mode exposes the full project model through dedicated workspaces.
Major areas include:
- Project — project identity, target hardware, workflow state, graph summary, build evidence, reproducibility
- Overview — project summary and engineering status
- Explorer — diagrams, graph structure, nodes, and project organization
- Hardware — target board, modules, interfaces, and hardware usage
- Board & Pins — visual pin map and editable pin assignments
- Wiring — physical connection documentation built from canonical assignments
- Components — component and device browser
- Signals — signal dictionary and metadata
- Instrument Panel — live visual controls and measurements
- Instrumentation — recording, calibration, telemetry, and signal engineering metadata
- Types & Buses — data structures, buses, and typed interfaces
- Build — generated source, manifests, dependencies, preflight, upload, device, serial, and problems
- Debug — graph execution traversal, breakpoints, signal history, and lineage
- Deliverables — engineering package generation
- Audit — reliability and production checks
- Library — Device Library, Board Model 2.0, and Bridge distribution
- Evidence Lab — Compiler Matrix, HIL, Runtime Protocol, and Resources / Timing
- Workbench — real hardware deployment and evidence progression
The graph is the authoritative source of project behavior.
A node contains a component type, configuration, location, identity, and optional hardware assignment. Connections carry typed signals between ports.
The same graph feeds:
Graph → FLOW IR → Generated Firmware → Compiler Evidence → Runtime Telemetry
Physical pin assignments also feed:
Graph → Board Model → Wiring View → Pin Tables → Generated Firmware
FLOWFORGE avoids maintaining separate independent copies of the logical and physical system wherever possible.
FLOWFORGE distinguishes between a component existing in the editor and a component having deployable firmware semantics.
Production preflight evaluates backend status and blocks nodes that cannot be generated safely.
Implemented backend families include core GPIO and math logic plus realized networking, MQTT, JSON, Modbus, CAN/TWAI, LoRa, DSP, execution, quality, protocol, and device package behaviors where the target supports them.
Target compatibility still matters. A component can be implemented but invalid for a particular board or configuration.
FLOWFORGE does not silently convert an unsupported node into a comment and call the project deployable.
The realized Device Library contains deployable hardware definitions with typed interfaces, dependencies, configuration, simulation information, engineering warnings, and generated source handlers.
Current realized packages include:
- BME280
- ADS1115
- HC-SR04
- RC Servo
- STEP/DIR Stepper Driver
- DC Motor Driver
- Relay Module
- Rotary Encoder
- DHT22
- DS18B20
- INA219
- WS2812 / NeoPixel
- Arduino MKR ENV Shield
Device Studio can also create project specific reusable devices and export .flowdevice definitions.
A Device Studio definition with placeholder setup or loop handlers is not treated as production ready. It must contain executable handlers or a valid internal graph before production deployment can pass.
FLOWFORGE includes the MKR ENV Shield as a realized device package using the Arduino MKRENV library.
The component exposes:
- Temperature
- Relative humidity
- Barometric pressure
- Illuminance
Generated firmware initializes the shield and reads the sensor values through the MKRENV API.
The microSD feature is documented as optional hardware and is not automatically managed by the sensor node.
Older ENV Shield revisions included additional UV hardware. FLOWFORGE does not expose UV values as a universal shield capability because that hardware is revision dependent.
Board profiles describe more than a list of pin numbers.
A profile can include:
- MCU and architecture
- Arduino FQBN
- Flash and RAM
- logic voltage
- digital input and output capability
- ADC
- DAC
- PWM
- UART
- I²C
- SPI
- CAN/TWAI
- USB
- interrupt capability
- input only pins
- boot or strapping pins
- reserved pins
- power pins
- aliases
- warnings and implementation notes
FLOWFORGE retains legacy board profile names for migration while offering richer exact board profiles for new projects.
Current board support includes Arduino AVR, SAMD, Renesas, and ESP32 class targets, including:
- Arduino Uno R3
- Arduino Nano Classic
- Arduino Mega 2560
- Arduino Nano Every
- Arduino UNO R4 Minima
- Arduino UNO R4 WiFi
- Arduino Nano ESP32
- Arduino MKR WiFi 1010
- Arduino MKR WAN 1310
- ESP32 DevKit V1
- ESP32-S3 DevKitC-1
- ESP32-C3 DevKitM-1
- ESP32-C6 DevKitC-1
Compatibility aliases from earlier FLOWFORGE versions are retained so older project files continue to migrate.
GPIO assignment is part of the canonical node configuration.
Selecting a hardware node exposes its pin assignment directly in Properties. Board & Pins provides a board centered editing view and conflict visualization.
FLOWFORGE checks for issues such as:
- nonexistent pins
- incompatible pin capabilities
- pin conflicts
- reserved pins
- input only pins used as outputs
- board specific warnings
The Wiring workspace translates the same assignments into physical documentation and adds metadata such as supply, ground, connector, wire label, and module information.
Simulation runs against the project graph without claiming to emulate a microcontroller electrically or cycle accurately.
Simulation features include:
- Digital input toggles
- Analog input sliders
- Sine, triangle, saw, square, and noise waveforms
- Stuck low / stuck high faults
- Stuck analog values
- Noise injection
- Out of range injection
- MQTT message fixtures
- Modbus register and coil fixtures
- Protocol and device simulation data
Simulation evidence is separate from compiler, upload, runtime, and HIL evidence.
FLOWFORGE verification supports suites, cases, stimuli, assertions, timing conditions, quality checks, protocol checks, regression runs, evidence snapshots, and reports.
Verification is intended to answer whether the graph behaves as expected under a defined set of conditions.
Passing verification does not mean the physical device has been tested unless the evidence explicitly comes from connected hardware or HIL.
FLOWFORGE generates Arduino compatible C++ from FLOW IR.
The generator maintains node to source line mapping so compiler diagnostics can be traced back to graph nodes.
Build Preflight checks include project validity, target configuration, backend implementation status, generated source structure, dependencies, and other static conditions.
Preflight is intentionally not described as compilation.
FLOWFORGE Bridge is the localhost companion service used when real external build and deployment actions are required.
The current Bridge supports operations including:
- health and status
- serial port discovery
- board core discovery and installation
- library discovery and installation
- compilation
- upload
- serial monitoring
- compiler matrix execution
The Bridge invokes supported CLI tools using argument arrays rather than concatenated shell commands.
The v6 Bridge hardening layer includes:
- loopback only binding
- localhost/file origin controls
- optional token authentication
- request size limits
- matrix job limits
- temporary build cleanup
- explicit tool availability reporting
The HTML application can export the Bridge distribution package.
For Arduino CLI workflows, install Arduino CLI and the required board core.
For PlatformIO workflows, install PlatformIO.
If neither tool exists, FLOWFORGE Bridge reports the toolchain as unavailable. It does not manufacture a compiler result.
Compiler Matrix produces actual external compilation jobs for multiple project and board combinations.
A matrix result can record:
- target board
- FQBN
- generated source fingerprint
- project fingerprint
- compiler result
- compiler diagnostics
- flash usage
- RAM usage
- toolchain identity
A backend should not be considered fully production proven merely because browser generated source passes structural checks. Compiler Matrix exists to provide the next evidence level.
Generated firmware includes the FLOWFORGE FF1 runtime protocol.
The runtime can identify itself and report project state through records such as:
FF1|HELLO|...
FF1|STATE|...
FF1|VAL|...
FF1|EVENT|...
FF1|ERROR|...
Runtime identity includes project and source fingerprints so FLOWFORGE can distinguish the firmware generated for the current project from an unrelated device that happens to be connected over serial.
Runtime commands include identity requests, ping, digital and PWM writes, and digital or analog pin reads used by hardware testing.
FLOWFORGE uses Web Serial where supported to communicate directly with running firmware.
The runtime monitor can display signal values, quality, events, device state, telemetry history, watches, scopes, dashboards, and recorder output.
Web Serial is a device communication channel. It is not presented as a firmware flasher.
HIL tests create physical evidence by commanding hardware and reading physical responses.
The current reference HIL test supports digital GPIO loopback.
A successful HIL run requires actual connected hardware and matching runtime firmware identity.
If hardware is unavailable, FLOWFORGE records NOT RUN rather than converting simulation into physical evidence.
The Debug workspace supports graph model debugging including:
- Node breakpoints
- Step Node
- Step Cycle
- Run to Breakpoint
- Current execution node
- Watch list
- Signal history
- upstream value lineage
- execution timing
These are graph model debugging controls. They do not pretend to halt the MCU CPU unless an external hardware debugger backend explicitly exists.
FLOWFORGE can estimate engineering resource demands from the graph and compare them with available evidence.
Analysis includes:
- estimated static RAM
- sample and DSP buffers
- board memory headroom
- per node execution estimates
- loop time and target loop rate
- loop utilization
- runtime telemetry bandwidth
- serial utilization
- CAN utilization
- Modbus RTU utilization
- MQTT traffic
- HTTP traffic
- latency and blocking warnings
FLOWFORGE distinguishes between:
Estimate — static engineering model
Compile Evidence — measurements reported by the compiler
Runtime Evidence — measurements reported by running firmware
HIL Evidence — physical test observations
FLOWFORGE maintains engineering traceability across representations.
A project can trace:
Board Pin → Device → Graph Node → Signal → FLOW IR → Generated Source → Compiler Diagnostic → Runtime Telemetry
Traceability data can also be included in engineering package exports.
FLOWFORGE can generate a project handoff ZIP containing engineering artifacts such as:
- Project JSON
- FLOW IR
- Data model
- Signal dictionary
- Pin assignment table
- BOM
- Dependency information
- Dependency lock snapshot
- Build manifest
- Verification results
- Calibration records
- Generated Arduino source
- Architecture SVG
- Wiring SVG
- Documentation HTML
- Release evidence
- Compiler matrix evidence
- HIL evidence
- Runtime protocol description
- Resource/timing analysis
- Deployment session evidence
- Runtime identity evidence
- Production hardening evidence
- Bridge package metadata
The exact package contents may evolve with the project and FLOWFORGE version.
FLOWFORGE project files are JSON based and are designed to preserve stable IDs for nodes, signals, devices, diagrams, and engineering evidence.
v6.0 performs strict validation before an imported project replaces the active project.
The importer rejects malformed or dangerous structures including duplicate identities, dangling connections, unknown component types, invalid coordinates, excessive graph sizes, and unsafe prototype related properties.
Older supported FLOWFORGE project versions are migrated forward when possible.
FLOWFORGE maintains local browser recovery state.
Recovery data is validated before restoration. Corrupt recovery data is ignored rather than applied to the active project.
For important work, export the project JSON regularly. Browser local storage should not be treated as the only project archive.
FLOWFORGE uses evidence levels deliberately.
A useful mental model is:
Browser Analysis → Generated Firmware → Compiler → Upload → Runtime → HIL
Each step adds evidence that the previous step cannot provide.
Examples:
- Balanced C++ braces do not prove compilation.
- Compilation does not prove successful upload.
- Upload does not prove the running firmware matches the current project.
- Runtime identity does not prove a physical GPIO behaves correctly.
- Simulation does not substitute for HIL.
The Workbench keeps these distinctions visible.
A Chromium based desktop browser provides the broadest FLOWFORGE feature set, particularly for Web Serial.
The core visual editor, project model, simulation, code generation, documentation, manifests, and package generation do not require a connected device.
Browser support for hardware APIs varies by browser and operating system.
FLOWFORGE project files can contain configuration, network endpoints, generated source, device descriptions, and engineering metadata. Treat project files as engineering documents.
Avoid embedding production secrets directly in reusable projects whenever possible.
FLOWFORGE Bridge is intended as a localhost service. Keep it loopback bound and use the optional authentication token where appropriate.
Review generated firmware and dependencies before deployment to safety critical, security critical, high energy, hazardous, or regulated systems.
FLOWFORGE can model electrical metadata and warn about known pin or board constraints, but it cannot determine every electrical hazard from a graph.
Before connecting hardware, verify matters such as:
- logic voltage compatibility
- current limits
- power supply capacity
- grounding
- inductive load protection
- motor and relay drivers
- isolation
- connector pinout
- sensor input limits
- bus termination
- boot/strapping behavior
- board revision
- external module requirements
Generated firmware is not a substitute for electrical engineering review.
FLOWFORGE v6.0 is intentionally explicit about several boundaries.
- Browser preflight is not an external compile.
- Upload requires a real external toolchain.
- Runtime proof requires a connected device.
- HIL proof requires physical hardware.
- Board profiles cannot encode every clone, revision, shield interaction, or undocumented hardware behavior.
- Some target specific libraries and radio stacks require dedicated backends rather than being interchangeable across boards.
- The MKR WiFi 1010 uses a different Arduino networking stack than the native ESP32 WiFi backend.
- The MKR WAN 1310 onboard LoRaWAN radio is not silently treated as an external SX127x SPI radio.
- Device definitions must contain executable behavior before they can pass production backend checks.
These are deliberate evidence boundaries rather than hidden fallbacks.
For a first hardware project, use Button → LED.
- Open Guided Start.
- Choose a target board.
- Select Button → LED.
- Inspect the assigned input and output pins.
- Run simulation and toggle the input.
- Run verification/preflight.
- Inspect the generated source.
- Connect FLOWFORGE Bridge.
- Compile and upload.
- Connect using Web Serial.
- Verify firmware identity.
- Monitor the live graph.
This project exercises the complete FLOWFORGE architecture without requiring protocol libraries or external modules.
FLOWFORGE v6.0 — Real Hardware Workbench
Current generation focuses on a coherent hardware to firmware workflow with explicit engineering evidence and no silent production scaffolding.
FLOWFORGE is built around several principles:
One canonical model. The graph should remain the source of truth.
Visible transformations. The user should be able to inspect how a graph becomes FLOW IR, source, firmware evidence, and runtime behavior.
Failure is data. Unsupported hardware, missing tools, failed compilation, mismatched firmware, and failed HIL tests should be visible instead of hidden.
Simple things stay simple. A Button → LED project should not require understanding every engineering workspace.
Advanced evidence remains available. Experienced users should be able to inspect signals, dependencies, generated source, tests, runtime telemetry, resource estimates, manifests, and hardware evidence.
Do not fake the hardware. FLOWFORGE distinguishes models from measurements and browser checks from external proof.