Custom device drivers

A driver teaches the app about a sensor, display or module: a small C++ file pair plus a description of the icons it adds. Besides the bundled drivers, you can write your own — or have an agent write them — without changing the app.

Where drivers live

Built-in — shipped with the app. Read-only.
Project — the project’s own falang/drivers/<id>/ folder. It is part of the project: versioned with it, and it travels with the project folder to another machine.
Personal library — a drivers folder in the app’s data folder, shared by all your projects.

If the same id exists in several places, the project’s copy wins over the library’s, which wins over the built-in one. When a scheme or the Devices document uses a driver found in the library or built in, the app copies it into the project automatically the first time (a library driver, on project open and before every build), so a project keeps building even if the library changes. Only drivers the sketch uses are compiled into it.

The Drivers… dialog

Sketch → Drivers… lists every driver with its scope and status. From there you can:

Create a project driver from a small template, upload a .falang-driver.json file (a whole driver in one file) into the project or the library, and download any driver as such a file to share it.
Copy a driver between the library and the project, or replace a project copy with the library version.
Validate — checks the format, that C function names don’t clash with other drivers or Arduino’s own, that every action’s template type-checks, that the project’s existing icons still fit, and compiles a small test sketch with arduino-cli for the project’s board. A missing core or library is only a warning, not a failure.
Open folder — edit the driver’s files in your own editor; the app picks the changes up automatically. A driver that becomes invalid is marked as such, and Build blocks while the project uses an invalid driver, with the reason shown.
Delete — refused with a list of places while the project still uses the driver.

The format

A driver is a folder with driver.config.json and the .h/.cpp files it names; the same thing in one file is the .falang-driver.json bundle: { "formatVersion": 1, "config": …, "files": { "name": "text" } }. The config is plain data — nothing in it is executed:

id (kebab-case), label, notes (a plain-English description, used by agents), includes, sourceFiles and declarations (declare function … lines that tell the editor about your C++ functions — give every function a prefix unique to the driver);
actions — one per user-visible operation: id, label, notes, fields (pin, number, string, boolean, select, new-variable) and a codeTemplate with ${field} placeholders; an action with a new-variable field also sets a resultType (int , float, bool or string);
optionally device — fields and a setupTemplate: the driver can then be added in the Devices document, which calls it once in setup();
optionally locales — translations of the driver, action, field and select-option labels per language (for example “ru”); anything not translated stays in English, and notes are never translated.

Required Arduino libraries are not installed automatically — install them with arduino-cli.

Agents

The in-app AI agent can list, create and edit project drivers when you ask it to add support for a part; it validates a driver before saving it. If the driver has a device section, the agent also adds an instance of it to the Devices document (get_devices / set_devices).
A coding agent connected over MCP gets driver tools in an Arduino project: list_drivers, get_driver, validate_driver, set_driver, delete_driver and use_library_driver, plus get_devices and set_devices to add driver instances and pins to the Devices document. New driver icons are available to it immediately, and drivers you create in the app show up without restarting the agent.