Signed-off-by: Jérôme Benoit <jerome.benoit@grenouille.com>

Music not included this time, sadly.

- Colors from an image lookup table
- Tweaks to brightness, speed, initial conditions

- Respect Micah coding style is order to simplify the merge.

Signed-off-by: Jérôme Benoit <jerome.benoit@grenouille.com>

Signed-off-by: Jérôme Benoit <jerome.benoit@grenouille.com>

Signed-off-by: Jérôme Benoit <jerome.benoit@grenouille.com>

Signed-off-by: Jérôme Benoit <jerome.benoit@grenouille.com>

I will need to maintain several fcserver installations and that patch will
help me to do so.

I've not tested yet a from scratch cloning and building but as far as
the directories for each submodule is not is the main repository, the
code is doing the right thing for that case ;-)

Signed-off-by: Jérôme Benoit <jerome.benoit@grenouille.com>

This moves all RX packet processing into interrupt context, removing the queueing bottleneck that previous firmwares experienced. Before this change, we could handle at most ~3 packets before they would start NAK'ing due to lack of buffer space until the next main loop iteration pulled additional packets into the fbNew buffer. Now packets can immediately go into fbNew unless there's a pending frame finalization. This vastly improves the efficiency of the USB protocol, and we need far fewer NAKs.

I'd been assuming that the OS always copied our USB transfer buffer at submit-time. Turns out that this is true for Linux but not for Windows or Mac. This caused tearing when fcserver received a new frame while previous frame(s) were still queued in the USB host controller.

Fixed this by copying to a per-transfer buffer on Windows and Mac. Linux is unaffected. We avoid performing an additional copy there.

This was a doc typo, Fadecandy uses the standard OPC command number of 0x00.

Fixes issue 21.