Tile drivers

Every tile ships with an open-source, platform-agnostic C driver that handles its registers, data formats, and protocol — so your firmware talks to a sensor or actuator in plain calls, not register pokes. The driver runs on any Core, over any bus, through the PAL.

Overview

A tile driver is a small C library — a header plus implementation — that exposes a tile’s capabilities as functions: tile_sense_bp_get_pressure_mhpa(), tile_drive_h_set_color(), and so on. It owns the chip’s register map, init sequencing, and unit conversions, and it’s written against the Platform Abstraction Layer rather than a specific Core or bus, so the same driver works everywhere.

Each driver page in the nav documents its API, the functions exposed to Studio, and the chip capabilities it doesn’t yet cover — all generated from the driver header, so the docs track the code. To write one, see Writing a tile driver.

Conventions

Every driver follows the same handful of conventions, so once you know one you know them all:

Naming — tile_<family>_<verb>() (e.g. tile_sense_i_6p6_get_raw_6dof()). The prefix matches the tile; the verb reads like an action.
Bus-agnostic — a driver takes a tiles_pal_t * and an instance index, never a raw bus handle. The PAL adapts the Core’s I²C or SPI bus to the shape the driver expects.
Init & probe — tile_<x>_init() brings the chip up from a known state; tile_<x>_find() checks whether it’s present on the bus.
Integer units — no floats. Values come back in milli- or centi-units (mhPa, decidegc, …) so conversions are exact and cheap on every Core.
Studio exposure — functions tagged @studio expose are callable from the DSL palette. Events surface via @studio event.
Declared gaps — chip capabilities a driver doesn’t cover are recorded in the header as @studio unsupported with a severity (common / advanced / niche), and shown on the driver page — so coverage is honest and derived, never guessed.
Versioning — each driver carries a semver; a new tile hardware revision is a new driver version.