Pinout

All Alp Lab modules conform to the E1M open standard, which fixes the pad-to-signal assignments at the default-function level plus GPIO as a universal secondary on every digital pad.

Form factor	Outline	Pad count	LGA pitch
E1M	35 × 35 mm	312	0.8 mm
E1M-X	45 × 65 mm	496	0.8 mm

Reference drawings

Machine-readable pinout

The canonical pinout is published as JSON in alplabai/e1m-spec:

File	Description
pinout/v1.json	E1M (35 × 35 mm) pinout, every pad's coordinate + signals
pinout/x-v1.json	E1M-X (45 × 65 mm) pinout
pinout/schema/loom-v1.schema.json	JSON Schema validating both pinouts

Consume the JSON directly in EDA tools, schematic generators, or the Alp SDK's orchestrator at scripts/alp_orchestrate.py. The schema is named Loom v1.

:::caution E1M-X pinout revision (2026-06) The E1M-X pad map changed in the June 2026 Altium export (18 pads): the ETH0/ETH1 MDI differential-pair rows were re-ordered (DA↔DD, DB↔DC, both _P/_N rows of each group), and AC62/AD62 left the reserved pool to become the dedicated DBG_TX/DBG_RX debug UART. If you cached pinout/x-v1.json or based a carrier layout on the earlier export, re-sync before routing — Ethernet MDI pairs land on different pads. The E1M (35 × 35) pinout is unaffected. See the e1m-spec CHANGELOG for the authoritative record. :::

Signal groups

The E1M interface carries the following classes (every pad declares a default function plus the alt-functions it can carry):

Power

• VBAT / VIN — main system input
• V3V3 / V1V8 — internal voltage rails (output by the SoM)
• VBAT_BACKUP — RTC / backup-domain rail
• GND — ground reference (many pads)

Communication

• SPI — multiple controllers (SPI0..SPI3)
• I²C / I³C — multiple buses (I2C0..I2C3); some pads support I³C
• UART — multiple channels (UART0..UART5)
• Debug UART — DBG_TX / DBG_RX, a dedicated debug-console channel separate from the numbered UARTs (E1M-X only, pads AC62/AD62)
• CAN / CAN-FD — CAN0
• USB — USB 2.0 (E1M) and USB 3.0 (E1M-X)
• SDIO — SDIO0, SDIO1

High-speed (E1M-X only)

• Ethernet — dual RGMII MACs + MDIO (V2N module exposes both via RTL8211FDI PHYs)
• PCIe — PCIE0, PCIE1
• MIPI CSI-2 — multiple lanes for camera input
• MIPI DSI — display output
• Parallel LCD — LCD0

Audio

• I²S / SAI — I2S0, I2S1
• PDM — PDM0 (digital microphone input)

Analog

• ADC — ADC0..ADC2
• DAC — DAC0, DAC1
• Quadrature encoder — ENC0..ENC3

Control / system

• PWM — PWM0..PWM7
• GPIO — universal secondary on every digital pad
• SWD / JTAG — debug interface
• RESET#, BOOT#, MODULE_EN, WDT_INT — system control signals
• BOARD_ID ADC — hw_rev detect (see <alp/hw_info.h>)

Default-function vs alt-function

Each pad has exactly one default function that every conformant SoM shall carry on that pad. The default is what a generic carrier should wire if it wants vendor-portable behaviour.

Beyond default + GPIO, pads may carry alt-functions chosen by the SoM vendor. These are declared in the per-SoM manifest (metadata/e1m_modules/<MPN>.yaml in the Alp SDK). Alt-functions are not part of E1M conformance — relying on them locks you to a specific SoM family.

Naming convention

Pad identifiers follow the BGA-style column-letter / row-number convention in the coordinate space of the form factor:

• A1, B2, … on E1M (35 × 35)
• A1, …, AQ15 on E1M-X (45 × 65)

Signal names match the silkscreen field of the corresponding pad in the JSON pinout.

Alp SDK access

In firmware, address peripheral instances through the portable IDs in the pinout header for your form factor:

Form factor	Header	Namespace
E1M (35 × 35)	<alp/e1m_pinout.h>	ALP_E1M_*
E1M-X (45 × 65)	<alp/e1m_x_pinout.h>	ALP_E1M_X_*

// On an E1M (35 x 35) SoM:
alp_i2c_t *bus = alp_i2c_open(&(alp_i2c_config_t){
    .bus_id     = ALP_E1M_I2C0,
    .bitrate_hz = 400000u,
});

// The same bus on an E1M-X (45 x 65) SoM — different namespace:
alp_i2c_t *bus = alp_i2c_open(&(alp_i2c_config_t){
    .bus_id     = ALP_E1M_X_I2C0,
    .bitrate_hz = 400000u,
});

The two namespaces are deliberately separate, not interchangeable aliases. E1M-X reserves more instances than E1M (for example ALP_E1M_X_GPIO_IO0..IO35 against E1M's 26), so an app written against one form factor is not source-portable to the other — the split makes that a compile error rather than a silent mis-binding. Pick the namespace that matches the form factor you are targeting.

ALP_E1M_<CLASS>_COUNT and ALP_E1M_X_<CLASS>_COUNT document the portable instance count per class within their own form-factor family. An app that uses <CLASS><N> with N below the count works across every conformant SoM in that family; higher indices are vendor-specific extensions that the runtime accepts up to the SoC's own count, but using them forfeits the "swap the SoM, no software changes" property. See the <alp/peripheral.h> reference.

:::note board.yaml pad names are unprefixed The ALP_ prefix belongs to the C API only. Connector pad names in board.yaml and in the SDK's carrier presets stay unprefixed — E1M_X_I2C2, E1M_X_GPIO_IO9, and so on. The SDK's board-header generator turns those route declarations into per-board macros that pull the matching prefixed pinout header. :::

Carrier-board design

For routing rules, decoupling, and footprint guidance, see the Design Guide.