fixup! fixup! fixup! doc/doxygen: add build system doc page for BOARD…

…, CPU, FEATURE

- aabadie: addres adding more details on `FEATURE` variables and
location

doc/doxygen/src/board-cpu-features.md

@@ -2,9 +2,28 @@
 FEATURES                                                             {#features}
 ========
 
-`FEATURES_PROVIDED` are available hardware (including BSP) features
-(e.g.:`periph_hwrng`, `periph_uart`)  or characteristics (e.g:`arch_32bits`) of
-a board.
+What is a `FEATURE`
+-------------------
+
+A `FEATURE` is a mean of specifying valid/invalid dependencies and configurations.
+
+Whenever a `FEATURE` is used there should be at some level a hardware requirement,
+whether this is a _radio_, a _bus_ of a specific core architecture.
+
+This is not a hard line, in some cases the line can be harder to establish than
+others. There are complicated cases like `netif` since a network interface could
+be fully implemented in software as a loop-back.
+
+It's also important to note that a `FEATURE` does not mean there is a `MODULE`
+with the same name. There could be many implementations for the same `FEATURE`.
+The fact that many `FEATURES` translate directly into a `MODULE` is only by
+convenience.
+
+e.g.
+
+    # all periph features correspond to a periph submodule
+    USEMODULE += $(filter periph_%,$(FEATURES_USED))
+
 
 Providing a `FEATURE`
 ---------------------
@@ -22,32 +41,37 @@ For a `FEATURE` to be provided by a `board` it must meet 2 criteria, and for
     - e.g.: `nucleo-l152re/include/periph_conf.h` specified wiring between `PORT_Ax`
              and `SPI1`
 
-What is a `FEATURE`
--------------------
+All the `FEATURES_%`
+--------------------
 
-A `FEATURE` is a mean of specifying valid/invalid dependencies and configurations.
+- `FEATURES_PROVIDED` are available hardware (including BSP) features
+  (e.g.:`periph_hwrng`, `periph_uart`)  or characteristics (e.g:`arch_32bits`) of
+  a board.
 
-Whenever a `FEATURE` is used there should be at some level a hardware requirement,
-whether this is a _radio_, a _bus_ of a specific core architecture.
+- `FEATURES_CONFLICT` are a series of `FEATURES` that can't be used at the same
+  time for a particular `BOARD`.
 
-This is not a hard line, in some cases the line can be harder to establish than
-others. There are complicated cases like `netif` since a network interface could
-be fully implemented in software as a loop-back.
+- `FEATURES_REQUIRED` are `FEATURES` that are needed by a `MODULE` or `APPLICATION`
+  to work.
 
-It's also important to note that a `FEATURE` does not mean there is a `MODULE`
-with the same name. There could be many implementations for the same `FEATURE`.
-The fact that many `FEATURES` translate directly into a `MODULE` is only by
-convenience.
+- `FEATURES_OPTIONAL` are "nice to have" `FEATURES`, not needed but useful. If
+  available they are always included. 
 
-e.g.
+- `FEATURES_BLACKLIST` are `FEATURES` that can't be used by a `MODULE` or `APPLCIATION`.
+  They are usually used for _hw_ characteristics like `arch_` to easily resolve
+  unsupported configurations for a group.
 
-    # all periph features correspond to a periph submodule
-    USEMODULE += $(filter periph_%,$(FEATURES_USED))
+- `FEATURES_USED` are the final list of `FEATURES` that will be used by an `APPLCIATION`
+
+Where to define `FEATURES_%`
+----------------------------
 
-`FEATURES` are also currently the way of performing optional inclusion in `RIOT`,
-i.e.: include only if present. This is done by `FEATURES_OPTIONAL`, `FEATURES` that
-will be used only if provided by the `BOARD`.
+- `FEATURES_PROVIDED`, `FEATURES_CONFLICT` and `FEATURES_CONFLICT_MSG ` are
+   defined in `Makefile.features`
 
+- `FEATURES_REQUIRED`, `FEATURES_OPTIONAL`, `FEATURES_BLACKLIST` are defined by
+   the application `Makefile` (`examples/%/Makefile`, `tests/%/Makfile`, etc.)
+   or in `Makefile.dep`
 
 CPU/CPU_MODEL                                                             {#cpu}
 =============