Why testing the library can be a nightmare sometimes.

Archive FastLED Archive
1

Why testing the library can be a nightmare sometimes. The chart below shows the types of LED control that the library supports (or plans to support) charted against the hardware platforms that are supported. (I could probably collapse the teensy 3.0/3.1 columns, but when I did the first version of the chart, there were enough differences that I had them separated out).

Not shown on here:

  • the digix - this is, for FastLED’s purposes, just a due with more pins exposed
  • AVR variations - probably when I start supporting UART SPI i’ll break them out, as different avr variants have different numbers of supported ports
  • Arduino Zero - another arduino arm, based on the Atmel SamD21 which, from a first skim of the datasheet, is a pretty different beast from the Sam8x3 in the due
  • any of the coming cortex-M7 platforms

(Also, note - the STM32 is the chip used in the SparkCore and the Maple, the NRF51xxx is used in the rfduino and red bear boards).

3dfdbd3f14ef2f1d8e51c34c86436bde.png
3dfdbd3f14ef2f1d8e51c34c86436bde.png1900×888 72.3 KB

2

Ah - parallel clockless support - eg 4-32 way parallel output of, say, ws2811.

3

Not sure what you mean by the problem I mentioned last time?

4

I’m still not sure what you are referring to - (right now, on the 3.1 branch the library supports 8-12 way output on the teensy 3.x and the due).

5

Oh! I know what you are referring to now - that’s something different entirely - and has to do with how I wrote the code for the ws2812 style chips. Right now the templates specialize on pin - so three pins mean three copies of the code compiled in. My goal is to change that to specialize on the port - so that if you have multiple pins on the same port you only have one copy of the code.

Nothing at all to do with parallel output. (Which can’t happen on the ATTiny anyway, as it is lacking a hardware multiply).