Hey .. some months ago I wanted to run some WS2811 pixels with an

Archive FastLED Archive
1

Hey … some months ago I wanted to run some WS2811 pixels with an ATMEGA 328 at 3V3, 8MHz but FastSPI_LED2 at first didn’t want me to. I got some warnings (“no enough clock cycles available for”) and the sketch didn’t compile.
I investigated and figured out matching timing-parameters to run WS2811-pixels configured for 400kHz (SlowMode via shorting pins 7 & 8 - normally they are configured for 800kHz). I enhanced FastSPI_LED2 accordingly and here comes the patch (against RC4):
— SNIP — 8< —
diff -rupN old/FastSPI_LED2/FastSPI_LED2.h new/FastSPI_LED2/FastSPI_LED2.h
— old/FastSPI_LED2/FastSPI_LED2.h 2013-10-08 10:14:40.000000000 +0200
+++ new/FastSPI_LED2/FastSPI_LED2.h 2013-10-21 18:01:00.000000000 +0200
@@-22,6 +22,7 @@ enum EClocklessChipsets {
TM1804,
TM1803,
WS2811,

  • WS2811_400,
    WS2812,
    WS2812B,
    NEOPIXEL,
    @@-100,6 +101,7 @@ public:
    case WS2812B:
    case NEOPIXEL:
    case WS2811: return addLeds(new WS2811Controller800Khz<DATA_PIN>(), data, nLedsOrOffset, nLedsIfOffset);
  •   	case WS2811_400: return addLeds(new WS2811Controller400Khz<DATA_PIN>(), data, nLedsOrOffset, nLedsIfOffset);
  }
    }

@@-116,6 +118,7 @@ public:
case WS2812B:
case NEOPIXEL:
case WS2811: return addLeds(new WS2811Controller800Khz<DATA_PIN, RGB_ORDER>(), data, nLedsOrOffset, nLedsIfOffset);

  •   	case WS2811_400: return addLeds(new WS2811Controller400Khz<DATA_PIN, RGB_ORDER>(), data, nLedsOrOffset, nLedsIfOffset);
  }
    }

diff -rupN old/FastSPI_LED2/chipsets.h new/FastSPI_LED2/chipsets.h
— old/FastSPI_LED2/chipsets.h 2013-10-09 23:30:05.000000000 +0200
+++ new/FastSPI_LED2/chipsets.h 2013-10-21 17:55:04.000000000 +0200
@@-245,6 +245,15 @@ class WS2811Controller800Khz : public Cl
#warning “No enough clock cycles available for the UCS103”
#endif

+// WS2811_400 - 640ns, 640ns, 1100ns
+template <uint8_t DATA_PIN, EOrder RGB_ORDER = RGB>
+class WS2811Controller400Mhz : public ClocklessController<DATA_PIN, NS(640), NS(640), NS(1100), RGB_ORDER> {};
+template <uint8_t DATA_PIN, EOrder RGB_ORDER = RGB>
+class WS2811Controller400Khz : public ClocklessController<DATA_PIN, NS(640), NS(640), NS(1100), RGB_ORDER> {};
+#if NO_TIME(640, 640, 1100)
+#warning “Not enough clock cycles available for the WS2811 at 400 kHz”
+#endif
+
// 750NS, 750NS, 750NS
template <uint8_t DATA_PIN, EOrder RGB_ORDER = RGB>
class TM1803Controller400Khz : public ClocklessController<DATA_PIN, NS(750), NS(750), NS(750), RGB_ORDER> {};
— SNAP — >8 —

2

This is the second set of 400khz timings I’ve had submitted that aren’t quite in spec (they should add up to 2.5μs per bit). Did you pull the timings from experimentation or data sheet?

3

These originally come from simply doubling the values for WS2811 I found in RC2 (320,320,550) and what should i say … they’re working just fine.

4

The RC2 numbers were wrong - and caused all sorts of problems for people with WS2811’s from different manufacturers (to make it worse, the underlying code also did not time properly to the timing values, compounding the error). If anything, the RC4 values should be doubled, but while the total bit time in the WS2811 data sheets i’ve seen is always 2.5µs per bit, the specific timings of high vs. low for 1/0 have been different (and i’ve seen multiple sets of values in the data sheets).

I haven’t actually gotten 400khz WS2811’s in hand to test and find the variation with them. It looks like the only places they’re available are if you buy your own WS2811 circuits and hook them up to leds manually. The WS2812 data sheets appear to ditch the 400khz mode entirely. (Also, the 400Mhz definition lines are vestigial, they were a typo in the first RC that I left around for people who were using old code while I updated, but these chipsets definitely don’t run at 400Mhz! :slight_smile:

5

Allright … the 400MHz lines are out … I’ll test new with doubled RC4 values and report back … ok?

6

Thanks! I hate testing timing sensitive code like this in the blind (so to speak). But i’ve been bitten by including code that works for one person in the past, so i’m cautious about it.

7

Ok. (800,800,900) seems to work with WS2811 at 400kHz with an ATMEGA328 at 5V,16MHz … unfortunately I currently am unable to test an 328 at 3V3, 8MHz. I will try to test this scenario later on.

8

Ok, if it does i’ll toss them in for now. The WS2811, for all its popularity, has been a clusterfuck when it comes to getting information. I ran across at least four sets of data sheets with wildly different timing specifics (all 1.25µs per bit, but the times for hi vs low were different). All of which appeared to be problematic for the WS2812’s. Thankfully, WS2812 data sheets seem to have converged, and it appears that those numbers give an accurate baseline to use for the 11’s as well. (Which one would hope, since the 12’s are supposedly just 11’s mated with a 5050 rgb led)

9

Right … consistent datasheets can be fun to work with … as inconsistent ones can be a pita … I now also tested with an 328 at 3V3, 8MHz i just dug up in my partsbox and so far it’s looking good too! =)