Uses the correct? default Content-Type and encoding for HTTP.
Parses the Content-Type header *before* decoding the content body.
Handles JSON type gracefully.
Decodes the response body accoding to the encoding header.
This is a bit of a fudge, and was only tested against the Cheerlights API.
Detects JSON content type, parses out the content length and truncates the response body to length.
Should probably do this *before* decoding from utf-8.
Updates cheerlights.py API example to support XML, JSON and TEXT endpoints.
Creates a new ppwhttp library to hide the implementation detail of HTTP clients/servers from the examples.
Adds a new example - plasma_ws2812_http.py - showing how to expand rgb_http.py to use a WS2812 pixel strip.
Adds "secrets.py" and moves WIFI connection information there. ppwhttp will throw an error if it's missing.
This covers an edge case where pixels are updated intermittently - such as the once that happens when clearing before a Python soft reset.
Under normal circumstances users should `start` the LED strip and allow it to continuously update.
We chased a bug with handling/clearing interrupts on Encoder into the depths of madness, finding that a Debug build would magically fix the bug.
Turns out it was probably just us being a little aggressive with the poor little MS51-based Encoder driver.
* Fix delays to be more delayey.
* Replace big 'ol loop and boolean with straight up checks and an early exit- the bit-addressed regs are never going to change
A bytearray allocated in Python would point to uninitialised bytes, missing the SOF byte and brightness for APA102 pixels.
Add a blunt loop over the MicroPython buffer, calling "brightness" for each RGB element to ensure the SOF byte and brightness are initialized.
Adds an ifdef guard around `pio_sm_unclaim` that prevents it being called when MicroPython cleans up/finalizes classes.
For some reason this appeared to be causing a hardfault.