Esp bitbang interrupt workaround

[willmmiles]

This patch attempts to work around hard WDT resets on ESP8266 with too-long strands by periodically permitting interrupts to trigger when bit-banging. If interrupt processing delays exceed the reset interval, the update is retried, up to a (currently fixed) limit. Interrupts are only checked in between pixel elements, so while a strand update may be incomplete, no flashes of strange colors should occur.

Essentially the goal is ensure that the microcontroller remains stable even if the full update can't be successfully completed. I can't speak for others, but I'd rather a partial update than a crash. If there are some unreachable pixels, that provides a "soft" failure mode for people who are trying to strech their micro too far, rather than the system just seeming randomly flaky when network activity and pixel updates collide.

[willmmiles]

Thanks for the thorough review, and being generally receptive to this approach. I'll update my submission based on your recommendations.

I particularly appreciate your validation of the specific timings -- actually I'm surprised the WS2812s could tolerate 150us, I thought I read in the datasheet that their latch interval was supposed to be only 50us! I'd missed entirely that the maximum interpixel delay ought to be less than the complete reset interval in many cases. One complication there is that the retry sequence will need to wait the whole reset time if it misses the latch time - it might be cleaner to return to a loop in the outer code instead.

+1 on making the whole approach optional with compile-time resolution. I'm a little worried about the combinatoric explosion of flavors (esp32/8266, inverted/not, interrupts/no). I'm going to think on this for a bit and run some tests on the templating before resubmitting.

[Makuna]

actually I'm surprised the WS2812s could tolerate 150us, I thought I read in the datasheet that their latch interval was supposed to be only 50us!

I am sorry, I typed the wrong units. Its 150ns not 150us. That is 0.150us. But from the playing around with the old interpixel delays code, we found many that also supported at least10us of no signal between pixels. Didn't test how far it extended though. So, this change would be useful to some.

I generally don't recommend the BitBang methods on ESPs at all.

[willmmiles]

Next draft of updated code pushed. Some high level comments:

• All the speed classes now export a TLatch indicating the longest allowable spacing in between pixels. I looked through a pile of datasheets and made some guesses for the devices I don't have; please update them based on your empircal experience.
• A TLatch of zero leaves interrupts disabled.
• I wrapped the critical section function such that the loop is in the Update() function, instead; this will ensure that ResetTimeUs is not violated. I did not adjust the reset time delay with the time spent processing interrupts in neoEspBitBangWriteSpacingPixels; that optimization could be added later if it ends up mattering to someone.
• The retry count is currently just a literal - it should probably be made a symbolic constant. I suppose it could be another template argument, either...
• I followed your recommendation regarding the final set of method typedefs. I'm not 100% happy with this -- there are a lot, now -- but I can't think of a perform compile time binding that doesn't either expect client code to explicitly resolve templates, or use a bunch of macros to build the typedefs.
• I removed the middle template layer which wrapped the underlying function call. It seemed to me that it shouldn't matter much which layer looks up the values from the speed and inversion arguments. I tried a bunch of tests on ESP32 and ESP8266 and the resulting Update() assembly was the same with and without the middle layer, so I'm pretty confident it won't hurt. Anything there was being done outside of the critical section anyways, since it's all in the neoEspBitBangWriteSpacingPixels function now.
• NeoEspBitBangSpeedIntertek was using the TInterPixel value. Since I repurposed this functionality in neoEspBitBangWriteSpacingPixels, this will result in an observable change in timings.
• I have not updated the name of neoEspBitBangWriteSpacingPixels to reflect that it no longer perfoms spacing, in the interests of reducing code churn. I can do that if you'd like.