Documentation

How DICEE Works

From installing the CLI to a compiled STM32 project: every step, what it does and why it exists.

DICEE targets complex projects. It adds little to trivial ones, such as an LED blinker.

DICEE is an early, experimental alpha. This page describes the current product, which will change.

This page covers what happens at each step. The reasoning behind it is in Technical Approach, and the problem it answers is in Problem and Motivation.

Watch the tutorial

Video not loading? Watch it on YouTube.

Install to firmware

Follow the flowchart below to understand the DICEE workflow end to end.

  2. $ npm install -g dicee-cli
    What happens

    Adds the dicee command globally through npm. Needs Node.js; works on macOS, Linux and Windows*.

    *Some legacy systems, or setups outside our tested range, may run into issues.

  3. $ dicee
    What happens

    Launching opens a connection from your terminal to DICEE’s hosted services. You then sign in, which readies the session for a new project.

  5. Describe the project

    What happens

    Give as much detail as you can: algorithms, features, capabilities, constraints.

    Why it matters

    This fully defines the requirements, and every later stage is derived from it.

    Select your hardware

    What happens

    Pick every component you own, including at least one MCU. The agent fills in whatever is missing.

    Why it matters

    Your parts are kept, and the design is completed around them.

  6. The agent builds the hardware design from your requirements, in three parts.

    Plant Analysis

    What happens

    Studies the physical system being sensed or driven (a motor, a heater, a greenhouse): its inputs, outputs and behavior.

    Why it matters

    Shows what must be measured and actuated, so the design rests on the real system, not on assumptions.

    Controller Design

    What happens

    Specifies how the MCU acts: the algorithms and equations that map sensor signals to actuator commands, plus the test plan used in code development.

    Why it matters

    This is where the project’s logic is mapped out. The design picks the approach the plant needs, from PID loops and transfer functions with pole/zero analysis to Kalman-style estimators or plain threshold logic with hysteresis.

    Hardware Components List

    What happens

    Every part in the design, yours plus any added to fill gaps, each verified against real specifications. Poor fits are swapped out.

    Why it matters

    The final parts list that pin resolution and code build on.

    How the model is kept grounded
    ProducesDesign for approval

  7. What happens

    The design is generated a single time. Review it, send all corrections together, and approve.

    Why it matters

    One pass keeps AI calls down and fixes the baseline for everything after.

    One pass only: write a full description

    There is no regenerate-and-approve loop yet. If the approved design misses your intent, start a new project. So give the fullest description you can: algorithms, features, capabilities, constraints, everything. A richer description brings the first design closer to what you intended.

  8. Our key feature

    What happens

    DICEE’s own solvers read the approved design, pick the modules and resolve each setting below from your chip’s official documentation. No AI model guesses any of them.

    Why it matters

    The same design always resolves to the same configuration, so an AI agent costs you none of the precision STM32Cube users expect.

    Module selectionPinsDMATriggersInterruptsClock configuration
    Why solvers, not a modelWhat the solvers guarantee
    ProducesResolved MCU configuration

  9. What happens

    Code is written against ST’s own HAL for your MCU family, in a standard STM32 project layout, across six stages.

    Why it matters

    The model can only use what that HAL defines, so every call it makes exists.

    • InitInitializes the MCU from the resolved configuration. The compiler is installed here.
    • CP 1Input circuits only, so code, wiring and hardware faults surface in isolation.
    • CP 2Output hardware (actuators), built and tested in isolation with the same approach as CP 1.
    • CP 3Input processing: filters and converts raw signals into a clean form the logic can use.
    • CP 4Implements the project’s actual logic on top of verified inputs, outputs and signal processing.
    • TerminateRemoves unwanted lines of code.
    Recommendation: after each checkpoint, flash the code, ask the agent how to test it, and verify before moving on.
    How the model is held to the HAL
  10. Compiled firmware in your workspace

    A standard STM32 project in dicee_workspace, with its design documentation alongside. You flash it with your usual tool; automatic flashing is not available yet.

Design documentation

Once your project reaches code generation, open the whole design in your browser. The documents are read-only and rebuilt from your latest design on every open. They are served from your machine, so they work offline, and are also saved as Markdown in a hidden .design_documentation folder in your project.

› /documentation

Hardware

  • Plant and environment
    What physical system is the firmware controlling, and what are its limits?
  • Components
    Which parts does the design use, and what was assumed about them?
  • Control design
    How does the controller work, from inputs to outputs?
  • Performance and tuning
    How well will it perform, and which constants can I tune?

Software

  • Microcontroller configuration
    How is the chip itself set up?

Logic

  • Connection layout
    How is the chip wired to everything else?
  • Code design document
    What rules and vocabulary does the code follow?
  • Build and verification plan
    In what order is it built, and how is each step proven?

Debugging with the agent

If the hardware misbehaves, ask the agent why. It points back to the design (plant analysis, controller design, resolved configuration) to explain the behavior, and the design documentation lets you check that reasoning yourself. The code is standard STM32, so once you know the cause you can fix it.

Why it works this way

Design before code

A mistake is cheapest to fix in the design and costliest once code exists, so the design and configuration are settled first.

The problem behind it

Faults stay local

Work is built in small increments, each compiled before the next begins, and every stage keeps its own intent, design and code. A problem traces to the stage that caused it, and you can request validation tests at any stage.

See the checkpoints

A design you can read

The whole design is available as documentation in your browser, so behavior can be checked against the decisions behind it.

Open the documentation section