Microcontroller boards

Boards

Planned for Beta 0.0.1: the microcontroller boards Raspberry Pi Pico (RP2040), STM32 NUCLEO-G071RB and ESP32-C3. One more microcontroller board, to be announced.

The final list of targets will be confirmed at launch, and target names may change before then.

Nano and Edge

• Nano. The smallest profile will need no heap and no operating system. Every agent, mailbox, timer and buffer will have a capacity fixed when you build, and a full mailbox or collection will return an explicit result instead of growing.
• Edge. An optional heap, storage, networking and TLS will be available on small networked boards. Each will be off until you switch it on, with its memory cost shown in the memory report, and code that needs an option you have not switched on will fail when you build.

What your program can use

Hardware access will cover GPIO, clocks, UART, interrupts and defined panic behaviour:

• Pins (GPIO). A pin will belong to one part of your program at a time.
• Clocks and timers. A clock that only moves forward, and timers that will stay correct when the hardware counter wraps around.
• Serial ports (UART). Input and output over the board's serial connection.
• Interrupts. An interrupt will wake the agent that waits for it, and the work done inside the interrupt will stay small and bounded.
• Panics. A panic will stop the program in a defined way: the board's outputs will go to the safe state its board support defines, and the fault will be reported where the board can report it.

Concurrency on microcontrollers will be safe, with bounded mailboxes, timers, cooperative scheduling, supervision and restarts. See Concurrency.

The names of the operations for pins, clocks and serial ports will be published when the standard library is final.

Honest limits

• Cooperative scheduling. On Nano boards, agents will take turns on one processor core. A handler will run until it waits, so a long computation will delay the others; scheduling alone will not guarantee a deadline.
• Bounded recursion. Recursion whose depth cannot be bounded will be refused on the smallest boards. See Limits.
• No models on the board. Models will not run on a microcontroller. Prompt-driven agents will reach a model through a gateway, described below.
• Per-board peripherals. Each board's support will list the capabilities it provides. Using one the board does not have will fail when you build, before anything is flashed.

Building firmware and memory reports

ael build (command names may change before launch) will build a firmware image for a board:

ael target install stm32g071-nucleo
ael build --target stm32g071-nucleo -o build/sensors --release --memory-report

Firmware images will come with RAM, flash and stack reports:

• The report will break memory down by what you declared: agents, mailboxes, timers and buffers, as well as the runtime's own share.
• Each figure will say whether it is exact, a safe upper bound or measured on a device. Anything that cannot be known will be shown as unknown, never as zero.
• You will be able to make a build fail when a required figure is unknown or the program does not fit the budget you set, with a reserve kept free. The option's name will be published with the final build options.

Building will never flash a device.

Flashing and monitoring

You will flash and monitor supported boards from the command line, using each board's standard flashing tools:

ael devices
ael flash --target stm32g071-nucleo --device <device> --artifact build/sensors
ael monitor --device <device>

• ael flash will write exactly the firmware image you name to the one device you select, after checking that the device is the board the image was built for and that the image is intact. Flashing will never happen by itself.
• A device will take one operation at a time, and an interrupted flash will leave a clear state and a way to recover.
• Boards will need their makers' flashing tools installed; ael doctor will report any that are missing. "Nothing else to install" will hold for desktop and server programs only.

Flashing a board and Monitoring a device describe the commands in full.

Prompt-driven agents through a gateway

Prompt-driven agents will run on small devices through a gateway, and each device will keep its safe local behaviour when offline.

• On the board, each prompt-driven agent will be a small stub: it will send typed input to the gateway and wait for a compact typed result. Deterministic work on the device will keep running as usual.
• On the gateway, a program on a desktop or server target near your devices, such as a Linux single-board computer, will keep the system prompts, model bindings, credentials and conversation history. None of them will be stored on the board.
• Fixed size. Messages between a board and its gateway will have a fixed maximum size, so they always fit the board's memory.
• Checked on the board. Every result will pass your own typed checks on the board, such as ranges, freshness and the device's current state, before it can reach hardware. A prompt, a gateway or a model's answer will never be able to grant a new hardware permission.
• Offline. When the gateway or the model is unreachable, too slow or answers with something invalid, the device will do what you declared: return a typed error, keep a last safe bounded action, or go to a safe state.

Updating a prompt on the gateway and updating firmware will be coordinated through one plan; see Deployment and rollback.

Related

• Planned targets: every target and profile.
• Building a program: the build options.
• Listing devices: finding the device to flash.
• Logging and monitoring: logs on boards and watching a device.