Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ESP32 Different pins cause boot loop #621
Hardware: NodeMCU32s or Wemos32, really doesn't matter much. I use the same sketch across a number of different ESP32 dev boards.
I've been working on a modular sketch where I can specify a code in the beginning of the sketch and it will generate a different output for a different product (all of which are controlled by the same phone BLE software)
Well, I hit a number of just strange and arbitrary issues that I had to tinker with to get it to work, but I isolated one for certain. Notice in DEVICE_TYPE == 2, I have those pins commented out? Well if I use those pins (like i initially planned) the device gets stuck with all kinds of RMT errors and bootloop errors. But if I use the same pins as defined in DEVICE_TYPE == 1 / 2, the sketch processes fine and runs great.
Basically, the pin definition crashes FastLED.show() which I'm calling from a task. If you guys need to see any more of my code, let me know but I have 100% isolated the boot looping issue to those 3 pins.
Either way, It would really be nice to have some kind of compilation level error handled for this rather than chasing down Core 0 panics.
`#if DEVICE_TYPE == 0
const uint8_t MAX_BRIGHTNESS = 255,
//Definitely check the pinout on these. I was not consistent in wiring the first few sets.
const uint8_t MAX_BRIGHTNESS = 255,
const uint8_t MAX_BRIGHTNESS = 140,
Hi! I am working on rewriting the fastpin.h definition for ESP32, but I've noticed that even now is does not have pin instantiations for pins above 32, but that does not cause any compilation error.
@focalintent Can you give me some guidance on what the fastpin interface needs to provide in order to work properly?
It does cause a compilation error if you try to use pin 32 or above for a bit-banged SPI chipset or if you just try to use/instantiate one on your own - e.g. in a bit of code:
What do you mean on what the interface needs to provide? The FastPin interface in there for esp32 has all the methods that it needs - it's just all the i/o registers only refer to the i/o registers for the low 32 pins, 0-31.
setInput/setOutput - flag whether the pin is for input or output
the variations on hi/lo/fastset that take a port register are mostly used for some optimizations on some platforms, but having them just call through like they are is fine.
hival/loval are another optimization for setting pin values when interrupts are disabled, they get the current value of the GPIO register tweaked for setting the instantiated pin hi or low
port gives the regular GPIO register
@focalintent I think my question is more about what parts of the interface are needed and by what other code. The RMT implementation of the clockless support does not need any of the FastPin methods because only the RMT peripheral accesses the pins.
Here are my main questions:
What methods are needed by other parts of FastLED (presumably, the clocked chips)? Are the 32 bit masks used anywhere outside of the ESP platform support?
Given that the ESP chip is pretty fast, do I need to worry a lot about performance? In other words, can I just call the convenience methods in the ESP core that do these things?
Please implement the full class - I don't know off the top of my head which of the methods are used by what other parts of the code - but what i don't want to do is start tracking with platforms aren't implementing what parts of fastpin - and for now you can probably just call the convenience functions (though that will likely slow down the speed of the bit-bang'd spi output a fair bit), so i would prefer that it be done right at the register level (also there's a backlog of other led chipset types that will likely require some level of pin level twiddling and timing again)
the mask method on FastPin is used by the bitbang'd SPI output so it's still needed (how it's implemented internally is ¯_(ツ)_/¯ - it doesn't have to be the template parameter, though I found having it as a template parameter made a bunch of things easier in the implementation of the templated class) -- I would imagine the pins above pin32 are just on a separate set of GPIO registers, right? Like _GPB1 instead of _GPB0 or some such?
Pretty much. Here is the definition of the digitalWrite function from the ESP core:
Yeah - trying to access register variables as template parameters got a bit ugly/tricky really fast - especially to get them to be effectively treated as constants at compile time. (In an ideal world, if the implementation of FastPin is done properly, it will be a write to a register (the MASK value usually) and then a store of that register value to a constant address. (On AVR this actually compiles down to a single instruction - which is a constant write directly to an i/o register))