From fe398d84cef81af1ffb54e9ec1fee564837d3c4a Mon Sep 17 00:00:00 2001 From: Markus Hitter Date: Sun, 1 May 2016 18:16:04 +0200 Subject: [PATCH] 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. --- displaybus.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/displaybus.h b/displaybus.h index fb5eafc..574bd47 100644 --- a/displaybus.h +++ b/displaybus.h @@ -5,6 +5,16 @@ Here we map generic calls to the display bus to calls to the actually used 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