Neopixel examples are problematic

[ianrrees]

In #750 I've been working on updating PyGamer to the current HAL, and I'm finding that the WS2812 / neopixel is a tricky problem to solve generically. In the timer-based WS2812 driver, there's a fundamental issue with the time it takes to toggle a GPIO varying between platforms, and also being comparable to the protocol's timing margins. The SPI driver relies on behaviours of the provided SpiBus which aren't described by the trait (nor reliably provided by our current implementation).

So, it's not really clear to me how we should proceed here. A few ideas:

1. With Spi implementation enhancements #751 point 2 in place, it might be feasible to get the WS2812 SPI driver to work well enough for a demo with a few asterisks like only working on release profile (the status quo). I think we'd need to modify the driver so that it shifts out 3 bytes of WS2812 data (12 SPI bytes, because each bit of WS2812 data is synthesized from 4 bits on SPI) per call to SpiBus::write() - this would minimise the variation in bit timing to any particular WS2812, and hopefully it doesn't matter as much for the data between WS2812s.
2. When the timer+GPIO driver is updated to use embedded-hal 1.0 DelayNs (in progress), we could possibly introduce a parameter for the time that a GPIO write takes, to allow tuning for the particular board.
3. At least on the PyGamer, another option is to use the TCC peripheral to generate the WS2812 bit timing. Going this route might provide a good example of driving a peripheral directly, which could help for people who want to use peripherals/features which aren't provided by the HAL.