This moves the dither macros outside of the PixelController::init_binary_dithering() function so that Doxygen doesn't get confused. This requires duplicating the preprocessor conditional, but since macros aren't scoped to the function regardless I don't see it as an issue.
These probably should be replaced with constants scoped to the function, but that's not a change I want to make right now. Adding a \todo note.
There are no intended functional changes in this commit.
This also includes the addLeds() functions for the third party libraries supported by CFastLED: SmartMatrix, OctoWS2811, and WS2812Serial.
Unfortunately Doxygen has not quite figured out how to handle \copydoc with overloaded functions that have template parameters, so the per-addLeds() comments are limited to the brief. The section header with the parameter names will have to suffice.
If this doesn't exist then there's no issue, but because it *does* for the purposes of document symbol recognition it's causing problems.
Doxygen is complaining that it can't evaluate an expression properly in noise.cpp, as this is compared to an integer and it's defined as blank. To fix the issue this defines it as "0", so the integer comparison works, fails, and everyone is happy. Or at least happy enough to not publish warnings in the document generation log.
This isn't important to document since it's used immediately after creation and nowhere else. And since Doxygen isn't processing it properly, there's no reason to keep the comment block around.
These functions are only used at the lower level for parallel output hardware. They can certainly stay documented, but there's no reason to highlight them in the general user documentation.
Note that this creates another preprocessor block for Doxygen. Doxygen doesn't seem to know how to document a preprocessor macro if it's defined in the Doxyfile and not in the code itself.
This was a big one, but all of the color utilities are now thoroughly documented and organized.
There are a few repeated messages in the color palettes classes, as Doxygen was having issues locating symbols for the constructors with array arguments (e.g. `const CRGB rhs[16]`) and the `operator CRGB*` arguments (possibly due to the spaces?). But those are small enough it's not worth worrying about.
This adds a DOXYGEN exclusive preprocessor block (and associated define in the Doxyfile) so the parser can find the config symbols that are commented out by default.
The GCC attribute was confusing Doxygen's function signatures and is for optimization purposes - it isn't necessary for understanding what each function does.
Fixed a bug in the LPD6803Controller class. Multiple diodes at the end of the LEDS array did not work correctly, no data was sent from the array to the LPD6803.
