Device driver header files should follow the same layout strategy. The first section (public) in the header file should be the application programmer interface. The second section (protected) should be the internal high level member functions. The third section (protected) should be the device specific data structures (registers), control and status codes followed by the internal member data and functions. The device driver specific section should be as complete as possible and use naming from the product documentation.
In many cases the device driver is connected to a specific bus module such as TWI or SPI. The device driver should inherit from the TWI/SPI::Driver class and implement the low level access protocol using the device driver support functions. This layer is then used to implement the higher level functions which are exposed in the application/sketch programmer interface.
Device driver header files should follow the same layout strategy. The first section (public) in the header file should be the application programmer interface. The second section (protected) should be the internal high level member functions. The third section (protected) should be the device specific data structures (registers), control and status codes followed by the internal member data and functions. The device driver specific section should be as complete as possible and use naming from the product documentation.
In many cases the device driver is connected to a specific bus module such as TWI or SPI. The device driver should inherit from the TWI/SPI::Driver class and implement the low level access protocol using the device driver support functions. This layer is then used to implement the higher level functions which are exposed in the application/sketch programmer interface.