Introduction

This library provides best-guess platform detection for a range of single-board computers and (potentially) other platforms. It was written primarily for use in Adafruit_Blinka, but may be useful in other contexts.

Platform detection is divided into “chip” and “board” detection, with the latter generally dependent on the former. Platform info is gathered from:

• Python’s sys.platform

• Various files on Linux systems:

  • /proc/cpuinfo (for processor info, Raspberry Pi hardware revisions, etc.)

  • /proc/device-tree/compatible (for 96Boards info)

• Beaglebone EEPROM board IDs

• Distribution-specific files such as /etc/armbian-release.

Dependencies

This driver depends on:

• Python 3.7 or higher

Installing from PyPI

On supported GNU/Linux systems like the Raspberry Pi, you can install the driver locally from PyPI. To install for current user:

pip3 install Adafruit-PlatformDetect

To install system-wide (this may be required in some cases):

sudo pip3 install Adafruit-PlatformDetect

To install in a virtual environment in your current project:

mkdir project-name && cd project-name
python3 -m venv .env
source .env/bin/activate
pip3 install Adafruit-PlatformDetect

Usage Example

from adafruit_platformdetect import Detector
detector = Detector()
print("Chip id: ", detector.chip.id)
print("Board id: ", detector.board.id)

# Check for specific board models:
print("Pi 3B+? ", detector.board.RASPBERRY_PI_3B_PLUS)
print("BBB? ", detector.board.BEAGLEBONE_BLACK)
print("Orange Pi PC? ", detector.board.ORANGE_PI_PC)
print("generic Linux PC? ", detector.board.GENERIC_LINUX_PC)

Custom boards and System-on-Module carriers

On Linux, an administrator can select a board definition by creating /etc/blinka-board. This works independently of the module’s vendor or generation, including Raspberry Pi Compute Modules, compatible third-party modules, and other System-on-Module (SoM) designs. The file must contain one public constant name from adafruit_platformdetect.constants.boards, with optional surrounding whitespace. For example, a CM4/CM4S carrier that matches the Pi 4B pin mapping can use:

RASPBERRY_PI_4B

This is a system-wide board override, like a persistent BLINKA_FORCEBOARD: choose only a definition compatible with the actual module and carrier. Sharing a connector layout does not make different chips’ GPIO mappings interchangeable. The override does not validate electrical compatibility, change chip detection, configure peripherals, or load device-tree overlays. BLINKA_FORCEBOARD takes precedence during initial detection and can select a different board for an individual process, including when using a USB adapter. Non-Linux platforms do not consult this file.

If the file is missing, unreadable, empty, or does not name a known public board constant, normal board detection is retained. Detection is cached on each Detector instance; restart the application after changing the file.

This mechanism does not add support for new carrier boards by itself. A carrier with a new pin mapping still needs a board constant and appropriate family memberships in PlatformDetect, plus a board definition and routing in Blinka. Carrier-specific Blinka routing must precede matching generic board-family entries. Do not put a Python module path or an unregistered carrier name in the file.

Contributing

Contributions are welcome! Please read our Code of Conduct before contributing to help this project stay welcoming.

Documentation

For information on building library documentation, please check out this guide.