# 3. Driver Interfaces have start()/stop()

Date: 2022-10-04

## Status

Accepted

## Context

Drivers need to perform some actions with either a peripheral or dependent objects (e.g., registering callbacks) before they can be usable.

## Decision

Many drivers require specific initialization, configuration, etc. to be useful. Or they may require configuration of dependent objects to do their job - such as configuring a Timer object or registering a callback.

Some of this stuff - especially registering a callback - seems like a natural fit for the constructor. The problem is that you'll hit the static initialization order fiasco. For example, you'll register a timer callback, but then the timer module will be initialized AFTER that, clearing out the callbacks already registered in the array.

To avoid this, drivers will support two common interfaces:

- `start()`, which performs initialization/configuration actions
- `stop()`, which disables/de-initializes the device

All actions with potential side effects should happen in `start()`, not the constructor.

## Consequences

Drivers need to be started (via `.start()`) before they are used by dependent code. For many devices, this happens in the `bsp.cpp` `initialize_board()` routine.