displaybus.h: note the different #include strategies.
Yes, these strategies feel a lot like heading into uncharted territory, because I can't find notable textbook examples on how to select between various "classes" at compile time. Nevertheless, it works fine, binaries are small and fast and as such it can't be _that_ wrong.
This commit is contained in:
parent
90fbdd314a
commit
fe398d84ce
10
displaybus.h
10
displaybus.h
|
|
@ -5,6 +5,16 @@
|
||||||
|
|
||||||
Here we map generic calls to the display bus to calls to the actually used
|
Here we map generic calls to the display bus to calls to the actually used
|
||||||
bus.
|
bus.
|
||||||
|
|
||||||
|
This is a slightly different #include strategy than the one used for display
|
||||||
|
and fonts. Instead of including a selected .c file and having the same
|
||||||
|
function names in each included .c file, we map functions with simple,
|
||||||
|
generic named inline funtions to get what we want. This allows to re-use
|
||||||
|
functions used elsewhere. For example SPI functions, which are used for SD
|
||||||
|
card reading and some temperature sensors, too.
|
||||||
|
|
||||||
|
The other approach, in turn, needs no mapping and can use variables, too,
|
||||||
|
but allows to use the functions in one place, only.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
#ifndef _DISPLAYBUS_H
|
#ifndef _DISPLAYBUS_H
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue