DRV-201 · Device Drivers

I2C & SPI Drivers

Client drivers for the two buses embedded hardware is built from, including regmap and error recovery.

Practitioner 3 days in person6 half-days online Max 14 in person

Who this course is for

Embedded engineers writing client drivers for the sensors, converters and peripherals that hang off I2C and SPI — the buses most embedded products are actually built from.

Prerequisites

DRV-110/DRV-120 level: device model plus device treeC and kernel module build experienceLab board with real I2C/SPI peripherals provided

Course outline

Day 1 — I2C client drivers

  • Adapters, clients and 7/10-bit addressing
  • Transfer semantics: SMBus functions vs raw i2c_transfer
  • Repeated start, clock stretching and what they look like on the wire
  • i2c_driver, ID tables and DT instantiation
  • Why detection is discouraged: declare, do not probe the bus

Day 2 — SPI client drivers

  • Controllers, chip selects and modes 0–3
  • spi_message and spi_transfer: full and half duplex
  • DT properties: reg, spi-max-frequency, cs-gpios
  • Throughput reality: message setup cost and when the bus collapses
  • spi_sync vs spi_async and their completion semantics

Day 3 — regmap and bus recovery

  • regmap_init for I2C and SPI: one API over both buses
  • Register caching, volatile registers and cache sync
  • regmap debugfs and tracepoints for visibility
  • Bus errors: NAKs, retries, timeouts and recovering a wedged bus
  • Correlating a logic-analyser capture with driver code

Hands-on labs

Labs follow the academy model — 35% principles, 20% guided investigation, 45% engineering studio. Every claim you make in a lab is backed by a trace, a counter or a measurement you captured yourself. How we teach

  1. Lab: Write an I2C client driver for a lab-board sensor; read its ID registers and prove you are talking to the right chip
  2. Lab: Implement an SPI device driver in the correct mode and measure real throughput against spi-max-frequency
  3. Lab: Convert raw bus calls to regmap and use its cache and debugfs to cut redundant traffic measurably
  4. Lab: Capture your driver's transactions on a logic analyser and annotate each transfer against a line of code
  5. Lab: Recover from an injected bus fault (stuck SDA, misconfigured CS) without a reboot and document the procedure

This course uses lab hardware. In-person cohorts get boards on the desk; online cohorts get remote board access over SSH and JTAG.

Capstone project

Deliver a complete client driver for a lab-board peripheral — DT node, regmap-based register access, a polled read path and an evidence pack: logic-analyser captures matched to code, an error-injection matrix, and a written recovery procedure for a wedged bus that you have actually exercised.

What you leave with

  • Working I2C and SPI client drivers on real hardware
  • regmap as your default register-access layer, including debugging
  • Logic-analyser skills tied directly to driver code
  • Bus error-recovery patterns that do not require a reboot
  • A DT-plus-driver template for the next peripheral on your board

How it runs

Every course follows the same model: 35% principles, 20% guided investigation, 45% engineering studio. You leave with working code, raw measurements and an evidence-based report — not a certificate of attendance. Read the methodology or see a full sample lesson.

Material is adapted to your kernel version, hardware and workload before a private delivery. For public cohorts, the environment is provided and configured.

Questions

Who is this course for?

Embedded engineers writing client drivers for the sensors, converters and peripherals that hang off I2C and SPI — the buses most embedded products are actually built from. It sits at practitioner level within the Device Drivers track.

What do I need to know already?

Specific prerequisites for this course: DRV-110/DRV-120 level: device model plus device tree; C and kernel module build experience; Lab board with real I2C/SPI peripherals provided. We confirm levels before the cohort starts and adapt if a group is stronger or weaker than expected.

Can this run privately for my team?

Yes. Any course runs on-site at your offices anywhere, or live online for a distributed team, with labs adapted to your hardware and codebase.

What is the difference between in-person and online?

In person is 3 full days with hardware on your desk, capped at 14. Online is 6 half-day sessions across about two weeks so you can keep working, capped at 20, with remote lab access.

Do you invoice companies?

Yes. Purchase orders are accepted and invoicing is available in USD, EUR, GBP, SAR and CAD.

Upcoming dates

DatesWhereSeatsEarly birdRegular
18 Oct – 20 Oct 20263 full days RiyadhIn person · KAFD Conference Centre 7 of 14 —SAR 7,880
25 Oct – 27 Oct 20263 full days Kuwait CityIn person · Al Hamra Tower 12 of 14 —KWD 650
25 Oct – 27 Oct 20263 full days MuscatIn person · Knowledge Oasis Muscat 7 of 14 —OMR 810
1 Nov – 8 Nov 20266 half-days Gulf bandLive online · 09:00–13:00 GMT+3 17 of 20 —US$1,500
2 Nov – 4 Nov 20263 full days OttawaIn person · Kanata North Tech Park 12 of 14 —CAD 2,860
2 Nov – 9 Nov 20266 half-days Europe bandLive online · 09:00–13:00 CET 6 of 20 —US$1,500
9 Nov – 11 Nov 20263 full days TorontoIn person · MaRS Discovery District 7 of 14 CAD 2,570until 10 OctCAD 2,860
9 Nov – 11 Nov 20263 full days LondonIn person · Shoreditch Works 12 of 14 GBP 1,480until 10 OctGBP 1,640
9 Nov – 16 Nov 20266 half-days Americas bandLive online · 13:00–17:00 ET 11 of 20 US$1,350until 10 OctUS$1,500
16 Nov – 18 Nov 20263 full days BerlinIn person · Factory Görlitzer Park 7 of 14 EUR 1,740until 17 OctEUR 1,930

Dates shown for the next few months. If nothing fits, tell us where and when — cohorts are added on demand, and private delivery can be scheduled any week.

More in Device Drivers