Skip to content

HardFOC core library

HardFOC Core Drivers

Every HardFOC device driver and the platform layer they run on, collected as git submodules at pinned commits. One repository to add to a project; each driver keeps its own repository, tests and documentation site.

Driver catalogue Using the drivers Source on GitHub

A product needs a dozen drivers that must agree on one platform interface and move together. hf-core-drivers pins a set of driver commits that build together, plus the two platform repositories they share: the MCU interface layer and the board pin maps. hf-core consumes it and compiles only the drivers a board turns on.

Layer diagram: board HALs and products build on hf-core, whose handlers use the device drivers in hf-core-drivers/external and the platform layer in hf-core-drivers/internal, which drive the chips.Layer diagram: board HALs and products build on hf-core, whose handlers use the device drivers in hf-core-drivers/external and the platform layer in hf-core-drivers/internal, which drive the chips.
One umbrella, one submodule per chip
Figure description and sources

From top to bottom. Board HALs and products build on hf-core, whose handlers adapt each driver to the platform. hf-core-drivers holds the device drivers under external/ (one per repository, names read from .gitmodules) and the platform layer under internal/. The drivers talk to the chips through interfaces that the platform layer implements for the MCU.

Drawn from: .gitmodules submodule paths; figure module docs/diagrams/figures/umbrella.py.

What you get

  • One submodule per chip. Motor controllers, solenoid drivers, encoders, IMUs, ADCs, sensors, expanders, PMIC, EEPROM and secure element. See the driver catalogue.
  • A platform layer. internal/hf-internal-interface-wrap (MCU peripheral interfaces) and internal/hf-pincfg (board pin maps). See Platform layer.
  • Drivers with no platform code. Each driver talks to a small interface class; the board provides it. See How a driver is built.
  • Pinned, reviewed versions. A submodule bump is a pull request here. See Updating submodules.
  • One coding standard. Naming, errors, memory and documentation rules shared by every driver. See Coding standards.

Where to go next