This is an old revision of the document!

Zephyr Device Drivers

Brief

A custom driver will probably involve:

Driver C source code	The structure does not seem to be unified. Most drivers are stored in a flat structure under `zephyr/drivers/<type>/<type>_<device>.c/h` but some, at least sensors, are stored in a tree structure: `zephyr/drivers/sensor/<mfr>/<device>/<device>.c/h` or similar. It's seemingly random..
KConfig source file	Placed together with the C source, declaring the CONFIG_* that CMakeLists.txt will listen for
CMakeLists.txt entry	Either a `zephyr_library_sources_ifdef(CONFIG_MY_AWESOME_DRIVER my_awesome_driver.c)` or a `add_subdirectory_ifdef(CONFIG_MY_AWESOME_DRIVER my_awesome_driver)` depending on file structure in the drivers folder
Device tree binding file	`zephyr/dts/bindings/<feature>/<compatible>.yaml`
Possibly som API header	`zephyr/include/zephyr/drivers/<type>/<device>.h` if not using any of Zephyrs generic API
Preferrably some sample code	Somehow sorted under `zephyr/samples/`

Using it will involve

Device tree entry	in a device tree overlay file, the line `compatible: my,awesome-driver` will tell Zephyr what C driver to use and what device tree binding to use when validating the entry
KConfig config	An entry in you projects settings along the lines `CONFIG_MY_AWESOME_DRIVER=y`

The connections between the different files are:

Device tree	`compatible="my,awesome-driver`	Can be several entries on this line, not sure exactly what happens then. I think it can be used to have common C drivers but separate binding files
Device tree binding	`compatible: "my,awesome-driver"`	Also the file is named my,awesome-driver.yaml but it has no magic meaning like the rest, this is just by convention
C Source	`#define DT_DRV_COMPAT adi_ad5691`	This is used during the building step somehow to tie the source code in