* Add a new "connection_mode" argument to http_request. This can be TLS_MODE or TCP_MODE
* Fix a bug where assumptions about json parsing don't hold up
* Check for TCP_STATE_CLOSED and bail early from connect_to_server
This slightly reckless extension to ppwhttp adds support for wildcard routes, eg:
/get_led/<int:index>
Which will serve URLs in the form:
/get_led/10
/get_led/22
etc.
The wildcard includes <type:key>, attempting to match the behaviour of Flask.
Only type "int" is supported currently.
/get_led/<index> - would set data["index"] to a string
/get_led/<int:index> - would attempt to parse the URL part to an int, and would not serve eg: /get_led/hi
See plasma_ws2812_http.py for example usage.
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.
Add the init required for the 320x240 2.0" LCD.
Add an option to set baudrate, 320x240 needs 74MHz for 60FPS
Add library and example for 320x240 2.0 LCD.
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.