Build a programming/testing rig

[amcewen]

To make programming easier, and to allow simple (initially) testing it would be useful to have a programming/testing rig.

This can use the openfixture setup with some pogo pins for the jig, hooked up to a Raspberry Pi. A physical interface with short test and full test buttons, coupled with obvious red/green failed/passed indicator lights would be good, but we can start with running something from the command line when sshed into the Pi.

Short Test

This would program a board and run the tests we'd do before shipping it

1. Pull latest code
2. Build code
3. Short pin 0 to ground
4. Power up the board, so it goes into programming mode
5. Record the MAC address for the board (get this info as early as possible, obviously so we can log results against it)
6. Program the board over serial
7. Reset board
8. Check that the LED strip is functioning (have a few LEDs connected via the test pads? Parse the data from the test pads directly?)
9. Check that the LED power status LED is lit
10. Look for WLED WiFi access point
11. Connect to the WiFi access point
12. Change the colour of the LEDs with the web UI
13. Configure WiFi settings
14. Check that the WiFi status LED goes solid
15. Check that the WLED WiFi access point is no longer present
16. Turn power off via the web UI
17. Check that the LED power status LED goes off
18. Set MQTT settings via the web UI
19. Check that the Network status LED goes on
20. Perform factor reset on the board
21. Check that Network status LED is off
22. Check that LED strip is reset to default colour
23. Check that WLED WiFi access point is present again
24. Log the results - MAC address, software version, test results
25. Power off board
26. Illuminate pass/fail indicator

Long Test

This is more to test the latest version of the software, as part of a CI setup. It would run through the Short Test procedure and add additional tests in between steps 19 and 20 to exercise the software more.

[amcewen]

Got the Ansible script finished (I expect) for building and uploading with Platform.IO. Running platformio run -v -e nodemcuv2 -t upload --upload-port=/dev/ttyAMA0 will compile and upload the code to a board, but takes ~7 minutes, so I think we should split it into a platformio command to build the code, and then a separate "upload prebuilt binary" running outside of Platform.IO so it doesn't spend an ages checking through dependencies.

[amcewen]

Building the full image from scratch on the Pi took 174 minutes in the test I just ran, so we should do that less often than for every upload 😁

Uploading with esptool.py --port /dev/ttyAMA0 write_flash 0x00000 build_output/firmware/travis_esp8266.bi takes 59 seconds, so that's much better for the upload script. I'm not sure all the parameters are correct for that esptool.py upload though, as the board doesn't seem to be running the code once it's uploaded.

[amcewen]

esptool.py --before default_reset --after hard_reset --chip esp8266 --port "/dev/ttyAMA0" --baud 115200 write_flash 0x0 WLED/build_output/firmware/my-babys-got-led.bin seems to successfully upload the code.

Building the platform.io buildfs target doesn't seem to compile everything, so I'm not sure how to build it without also trying an upload at the end (I'm probably missing something)

[amcewen]

Tested the rig from #21 and it's working nicely.

Had problems with the power switching, have spun that out as #24. Also worked out that the Pi is far too slow to build the software for doing any debugging using it 😁

[amcewen]

Have ordered some 4N35 opto-isolators to allow wiring up the reset button to the Pi.