Cores, tiles & the PAL

A tile system is a handful of parts with clear jobs: one Core that thinks, peripheral tiles that sense and act, the buses that connect them, and a thin software stack — drivers plus a Platform Abstraction Layer — that lets the same code drive that hardware anywhere.

The shape of a system

Every tile system has the same topology: a single Core and one or more peripheral tiles, all sharing a small number of buses. The Core carries the microcontroller and runs your firmware; the peripherals sense and actuate but don’t think. The Core is the bus master and orchestrates everything.

Because the bus is shared, adding a capability is mostly a matter of dropping another tile on the same lines — no new wiring scheme, no custom PCB. Each tile has a bus address (or a chip select on SPI), so the Core can talk to each one individually.

Anatomy of a tile

A tile is a complete subsystem in a standard 4×4 mm package with ten pads on a 0.8 mm pitch. Those pads carry everything the tile needs behind one common interface:

• Power — supply and ground.
• Bus lines — the I²C / I³C / SPI signals it shares with the Core.
• Control & events — enable / reset, and interrupt or data-ready pads the tile uses to signal the Core.

The catalog lists each tile’s exact pad map, interfaces, and the part it’s built around. The standardized package is what lets one tile carry a design from breadboard to production unchanged.

Drivers know the tile

Talking to a peripheral chip means knowing its registers, data formats, init sequence, and quirks. Each tile ships that knowledge as an open-source, platform-agnostic driver — C code named for the tile, e.g. tile_sense_bp for the Sense.BP barometric-pressure tile. The driver exposes a clean API (tile_sense_bp_init, tile_sense_bp_read_pressure, …) and hides the register-level work.

Crucially, a driver contains no processor-specific code. It never writes an STM32 register directly. When it needs to move bytes on a bus, it asks the layer below.

The PAL ports drivers to any host

That layer is the Platform Abstraction Layer (PAL). It’s a small interface — “do an I²C write,” “do a SPI transfer,” “delay” — that the driver calls and a host implements. The driver knows what bytes to send; the PAL knows how to send them on this particular processor.

In the C SDK you grab the PAL for a bus and hand it to the driver:

// one PAL per bus, auto-cached
tiles_pal_t *pal = core_tiles_pal(&core_i2c1);
tile_sense_bp_init(&bp, pal, 0x5D);

Today the PAL targets the STM32-based Cores. Because the driver only ever talks to the PAL, porting the entire driver library to another host is a matter of implementing that one interface — ports for ESP32, Arduino, and nRF are on the way. The same tile_sense_bp driver then runs unchanged on all of them.

How a reading flows

When your firmware reads a sensor tile, the request travels down the stack and back:

• Your code calls the tile driver (tile_sense_bp_read_pressure).
• The driver decides which registers to read and asks the PAL to do the I²C transfer.
• The PAL drives the Core’s I²C peripheral; the tile answers on the bus.
• The driver converts the raw bytes into real units (integer milli-units — no floats) and hands them back to you.

Where to go next