Hello Everyone. First, my set up:
Fast LED v3.1.5
WS2812 string
NodeMCU v1.0 (ESP8266-12E)
Leds on Pin D8 or GPIO15
Compiling with Eclipse (Sloeber)
I recently pulled the latest from master and it broke my project. I’m now getting the error when compiling: static assertion failed: Invalid pin specified static_assert(validpin(), “Invalid pin specified”);
I’ve googled the sh*t out of it and found nothing that fixed my problem. As a hack I changed to raw pin order (FASTLED_ESP8266_RAW_PIN_ORDER), fixed all my pins, and it started working. If I change back to nothing specified or specifically define FASTLED_ESP8266_NODEMCU_PIN_ORDER I get the error.
I’ve been using Nodemcu and FastLED for about year (since ESP8266 was supported), so I know the code works with the previous versions of the library. I tried monkeying around with fastpin_esp8266.h and changed MAX_PIN to 16 instead of 10 but that didn’t help. I can clearly see D8 defined (_DEFPIN_ESP8266(8,15)) but no joy.
Any suggestions for eliminating the need for the raw pin mapping?
So - D8 is defined to a value of 15 - in which case, if you use D8 (as opposed to just 8) then that’s going to be compiled as GPIO15 - in which case you will want to use FASTLED_ESP8266_RAW_PIN_ORDER – generally speaking, you don’t want to use Dx to define the pins - just the pin number.
specifically D8 is defined as:
static const uint8_t D8 = 15;
Thanks Daniel. So just to be clear, I should be using RAW instead of NODEMCU? I’m happy to do so, but in the past not specifying anything worked fine with D8.
It did occur to me after i posted that D8 = 15 in the defines, and the pin redirection might try to treat 15 as a virtual pin and translate that to a real pin, which would not be define. I don’t know if that’s the case or not. I have not had a chance to test tonight.
Many thanks for the awesome library!
Tom
Look at all the fastled examples - they don’t use D8 as a PIN number - they just use 8 - so, if you are going to insist on using the Dx defines/constants, then you need to use the RAW ordering because the Dx defines map to the raw GPIO ordering.
Daniel - I’m not “insisting” on anything. I’m merely pointing out after a year things changed. I’m happy to press on with RAW, but it seems a little like a hack. I will futz around and report back. Thanks for all the help!