Peripherals and I/O

Buses, devices, expanders, analog and digital pins - and the poll loop that reads them.

Beyond the panel and the touch controller, a board has sensors, expanders, analog inputs and plain digital pins. The Buses, Devices and I/O tabs describe them, and the generator writes hardware.h and hardware.cpp to bring them up and read them on a schedule. Nothing here ever draws: the readings go into caches that variables read.

Buses

The Buses tab declares I2C and SPI buses beyond the display's. An I2C bus has SDA, SCL, a clock in kHz and an internal pull-up option (weak - fit 4.7 kΩ externals for anything but the shortest run). An SPI bus has SCK, MOSI, an optional MISO, a clock in MHz and the SPI mode. The first bus of a kind becomes Wire or SPI in the generated code, the next Wire1 or SPI1, and so on up to what the MCU has. A device attached to a bus that shares pins with the display's bus is legitimate and not flagged.

Devices

The Devices tab adds peripherals. Each has a Type, a Bus, an I2C address or a CS pin depending on the bus, and a Poll interval - how often hw_poll() reads it, independently of everything else, so a slow sensor never holds up a fast one or the display. Below those comes the device's own configuration: every register the driver library exposes, applied once in hw_init() after the device reports present.

A device that fails to answer at boot is marked absent, its variables keep their initial values, and the sketch says so on the serial monitor rather than hanging. Each device's library is listed in LIBRARIES.md with the Library Manager search string.

Configuration worth knowing about

• BME280 / BMP280 - mode, per-channel oversampling, IIR filter, standby, and the sea-level reference the altitude channel is computed from. The oversampling group is emitted as one setSampling() call.
• SCD4x - temperature offset, altitude and automatic self-calibration. Changing these requires the measurement to be stopped and restarted, which the generated code brackets.
• ADS1115 - programmable gain and data rate; the channel readings are in volts after the gain is applied.
• INA219 - the shunt calibration preset.
• MPU6050 - accelerometer and gyro ranges, filter bandwidth, cycle mode.
• DS3231 - square-wave output, the 32 kHz pin, and set on boot, which writes the compile time into the clock on first run. Its Unix time channel is what a chart's time axis reads.
• PCA9685 and NeoPixel are outputs: they have no readable channels, and are driven by the Write to peripheral action or a Widget → variable binding.
• SD card - besides its size channels, this is the device that makes SD card available as the asset filesystem.

I/O extenders

Port expanders that add digital pins over I2C or SPI. Add one on the I/O tab with its bus and address (or CS pin), and digital I/O entries can then be placed on its pins instead of the MCU's. Each pin's direction is set by the entry that uses it, and the generated ext_<name>_write() and _read() helpers are guarded by the expander's presence.

The validator errors on an extender pin outside the part's width, on two entries claiming the same pin, and on an entry pointing at an extender that has been deleted. The same rules cover a display reset, touch reset or backlight routed through an extender (see Boards and displays).

The CH422G, TCA9554 and PCA9555 need no library: each is a few I2C register writes, and the generator writes a small driver class into hardware.cpp for them. The PCF and MCP parts use their Arduino libraries, listed in LIBRARIES.md as usual.

Analog inputs

An Analog input is an MCU ADC pin read and scaled. Fields:

The ADC pins per MCU come from the catalogue - the ESP32 has 16, the S3 20, the C3 6, the RP2040 4 - and a pin that is not one of them is an error. The STM32 and ESP32-P4 entries currently have no ADC pins listed, so analog inputs are not offered on them.

Digital I/O

A Digital input or output on an MCU pin or an extender pin:

Inputs are debounced in hw_poll() and exposed to variables as a Boolean; the Digital input changes and Digital input held automation triggers watch them. Outputs are driven by the Set digital output action. "Active" respects the active-low setting throughout, so a relay module that switches on LOW is described once and reads correctly everywhere.

What the generated code does

hardware.cpp declares one driver object per device and the bus objects they sit on. hw_init() begins each bus, probes each device, applies its configuration and records whether it answered. hw_poll(), called from app_poll() every loop, checks each device's own timer and reads it when due into a cache struct. Reads are cheap to ask for and never block on a slow part - a BME280 polled every two seconds costs nothing to a label refreshed ten times a second. The Refresh inputs now action forces every timer due at once.