I think I need to set up some kind of semi-permanent testing rig for doing a major release of the library. I’ve got six arm platforms to test against/support (k26, k20, sam3x8, nrf51822, stm32, REDACTED) and 5 distinct avr platforms that need to be tested (328p@16Mhz, 328p@8Mhz, 32u4, 16u2, attiny8) against at least two separate versions of arduino.
Those 11 platforms (16 if you count the dual build environments needed for the avr variants) need to be tested against up to four different types of led support (or 20-ish specific led chipsets supported, if I want to be fully complete).
This isn’t even including things like OctoWS2811, SmartMatrix, or DMX based drivers.
Maybe some kind of a patch-bay-ish setup… The need to do this kind/level of testing is going to delay the next major push to the FastLED 3.1 branch that I have (which has all the new platform work merged into it), this time around it is going to go very slowly, I think.
If I didn’t just take 2 weeks off from work for vacation, it’d be tempting to take a week off just to build this testing rig.
Wow sounds like a lot of work. Do you have any idea to automate testing?
Perhaps you can meas the voltage on the LED pixel (the red, green, blue pins come from the IC) and compare this with your send value (or id this not work, because of timings of the dithering?)
@Jurgen_Skrotzky that wouldn’t work, because its not a voltage but a data stream (with or without clock). Each chip controls the led via PWM, and so a discrete voltage measurement wouldn’t validate your timings.
You could write a stub that pretended to be a “smart pixel” of a given type, and it could validate the timings. The test suite would then have to validate each type of supported LED, and have a fixed set of scenarios. The stub would validate each scenario.
@Stuart_Taylor this is what I mean with timing, because of the pulsed data signal.
The idea of writing a stub for each type is great. Do you know if there is something similar out there?
Maybe set up a checklist and a new branch, and let the community help? I volunteer. I can test APA102 and NeoPixel on Teensy 3.1, Spark Core, Arduino Uno, Trinket Pro, and Gemma. And SmartMatrix, of course.
Honestly, building a checker wouldn’t help me at all, - I can just have X strips of leds hooked up and do visual checks. The irritating part is the wiring multiple MCUs, pins, usb cables for programming, etc… etc… etc… Writing/tetsing/debugging a WS2812 reader, and an SPI reader for the various led chipsets, as well as more esoteric setups like octows2811, smartmatrix, etc… would massively increase the workload, and not really directly benefit anyone else. Even if I had that, I’d still have to do the rounds of building, uploading, and testing - at least with using physical leds, I have something pretty to look at while it’s working.
It’s mostly just the keeping a dedicated one of everything for testing in a singular area, pre-boarding and wiring it all up, being good about not grabbing those bits for other projects, etc… Also, I want it to be wired up for quick/easy tossing of a logic probe on any of the bits that are being a problem, as well as wired to my bench supply so I can juggle. Then it’s just making sure I go through the various test bits. (That said, I do have an outline for a test app that will at least make this go quicker)
