OK, i have updated to 2.2 and it seems like there is no change.
From serial monitor i get this repeating:
ets Jan 8 2013,rst cause:4, boot mode:(3,1)
wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x0f
csum 0x0f
~ld
I also tried #define FASTLED_ESP8266_RAW_PIN_ORDER and it will not compile, says invalid pin
It does not lock up if i use pins 4 and 5. It locks up if i use 12, 13, 14 or 16 though. (the other pins (0, 2, 15 tx, rx) are reserved for bootloader/serial
Huh - ok, that’s useful to know - is that 12/13/14/16 using raw pin order or not?
I am not sure how to tell. I have “Adafruit Huzzah ESP8266” selected in the arduino IDE, and for clock pin (for instance) i say “#define CLOCK_PIN 16”
if i do any combination of 12, 13, 14, or 16 (even with 4 or 5 as the second pin) it goes into watchdog reset.
Did you define FASTLED_ESP8266_RAW_PIN_ORDER or not?
#define FASTLED_ESP8266_RAW_PIN_ORDER
will not work. (says pin error)
Which pin gives you an error when you do that?
Ah - I see why pin 16 doesn’t work when using raw pin order. Anyway, I’m about to mostly lose cell signal, I’ll come back to this on Monday.
In file included from /Users/Michael/Documents/Arduino/libraries/FastLED/FastLED.h:40:0,
from /Users/Michael/Documents/Arduino/LED_RX/LED_RX.ino:2:
/Users/Michael/Documents/Arduino/libraries/FastLED/fastpin.h: In instantiation of ‘class FastPin<16u>’:
/Users/Michael/Documents/Arduino/libraries/FastLED/fastspi_bitbang.h:23:50: required from ‘class AVRSoftwareSPIOutput<14u, 16u, 144u>’
/Users/Michael/Documents/Arduino/libraries/FastLED/fastspi.h:30:7: required from ‘class SPIOutput<14u, 16u, 144u>’
/Users/Michael/Documents/Arduino/libraries/FastLED/chipsets.h:94:6: required from ‘class LPD8806Controller<14u, 16u, (EOrder)10u, 144u>’
/Users/Michael/Documents/Arduino/libraries/FastLED/FastLED.h:204:92: required from ‘CLEDController& CFastLED::addLeds(CRGB*, int, int) [with ESPIChipsets CHIPSET = (ESPIChipsets)1u; unsigned char DATA_PIN = 14u; unsigned char CLOCK_PIN = 16u; EOrder RGB_ORDER = (EOrder)10u; unsigned char SPI_DATA_RATE = 144u]’
/Users/Michael/Documents/Arduino/LED_RX/LED_RX.ino:15:74: required from here
/Users/Michael/Documents/Arduino/libraries/FastLED/fastpin.h:206:2: error: static assertion failed: Invalid pin specified
static_assert(validpin(), “Invalid pin specified”);
^
exit status 1
Error compiling for board Adafruit HUZZAH ESP8266.
I understand, looking foward to hearing from you monday 
enjoy your vacation
I was able to get the esp to stop locking up by adding _DEFPIN_ESP8266(16,16); to fastpin_ESP8266.h. Now if I use #define FASTLED_ESP826_RAW_PIN_ORDER, the esp will continue through the loop. If don’t use the define, the esp8266 will still lock up.
Also, the led’s do not output anything when hooked up correctly. If i swap the clock and data pins, the first led fades through red, then green, then blue just once (probably doesnt mean anything).
I am going to hook up some LPD8806 strips i got and see if they work as expected but thats gotta wait till this afternoon.
no dice on lpd8806 and pins 14 and 16.
I’m gonna try different pins and report back. I would really like to use 14 and 16 though, as I kinda maybe designed a PCB and printed/soldered before prototyping. (terrible, I know)
Seems like you cannot use GPIO16 as a GPIO. Seems like every search for GPIO16 was related to how it wasnt a gpio. Swapped 16 for 12 (12 and 14 now) and i am good to go.
Strange how before it was still locking up without pin 16 setup.
Eitherway, lesson learned, say away from GPIO 16. It’s evil.
I thought IO16 is the user port - so this pin has special features and is not usable for all functions. Sorry that you have to redesign your board. But trust me - first bread board than pcb always works
The board is still usable, i just cut the incorrect trace and soldered on a piece of wire. But its not purdy 
i’ll fix it in the next revision. Another issue is that i just read that esp8266 can’t drive a lot of leds due to interrupt issues. Not sure if that was just for the 2812’s that were being discussed or for all leds, but i’m going to be testing that soon. I need to update 512 leds.
worst case is esp01 + teensy.
That’s just the ws2812’s because they have to disable interrupts while writing out an led’s worth of data (and enable them between LEDs, but if an interrupt takes too long to run then the frame gets cut short) - but even then I’ve been able to drive a couple hundred LEDs on an active wifi network with no problems.
I can also report, that driving 512 WS2812b LEDs on ESP8266 is working fine on my setting (but it seems to be “slow”). For the SPI-based strips (WS2801, APA102, …) it should run smooth, fast and stable.
Yeah- there’s some pin weirdness going on - got the probe set up and trying some things out - some of the pins, it seems unhappy if you try to do anything with them during setup() - and some of the others appear to be always unhappy - trying to build up a map now. As for why it seems slow, well at 15ms per frame to write 512 WS2812 led data, you’re going to be stuck with a lower frame rate 