The miniz is used for zlib compression. But because that library has some bugs related to a smal window sizes (we need 4096), I had to make some patches to the library. The miniz library happens to also be part of esp-idf. To distinguish between our version and the esp-idf version, I created a `namespace Miniz` around our version. But nevertheless, the esp-idf version is called when I'm calling Miniz::tdefl_init and Miniz::tdefl_compress . Why??
Anyway, renamed tdefl_init and tdefl_compress to tdefl_initOEPL and tdefl_compressOEPL to get it working. This is ugly. If somebody has a better solution, please let me know!
- adds tag serial debug in webflasher and power up/down buttons
- fixes bug where esp32-s3 connected via usb cdc slows down when no terminal connection is present
- fix: ghost tags reporting a different channel id than the AP are now ignored
- webflasher now ramps up/down power to prevent spikes
- bugfix: C6 doesn't get reset anoymore by the watchdog during flashing
- bugfix: C6 could go in flash mode unintended
- a failed connection during swd write blocks is now reported back instead of silently ignored
- added 4 areas of Sweden to day ahead price content
- new context menu option 'Delete all inactive tags' (only when right clicking on an inactive tag).
- adjusted some timings
- added webinterface for tag flasher
- added tcp transport for communicating with tag flasher (OTG USB also still works)
- added content 'timestamp', makes use of preloaded images and buttons on the 2.9" M3
- webinterface is now aware of C6 and flasher capabilities
- AP can run without ieee801.15.4 radio (i.e. flasher only) by shorting FLASHER_AP_TXD and FLASHER_AP_RXD
- added tcp transport option to OEPL-Flasher.py (serial also still works)
- added new environment OpenEPaperLink_Mini_AP_v4
- lots of finetuning and bug fixes
Pretty complex change here: pending images/commands are now queued.
A command (like LED flasher) will not overwrite a pending image anymore. Also, sending multiple preloaded images is possible.
Also works (at least, as far as I could test) in combination with Multi AP and mirroring tags ('display a copy' content type).
It you want to test this: don't forget to upload the changed files in /www (the pending icon is now displaying the amount of queued messages). Timing improvements will follow later (only one message can be transmitted every checkin. If multiple messages are queued, at this moment, you have to wait until the next checkin which takes 40-60 sec).
This comes also with the advantage of better stability if you upload multiple images to the same tag in succession. Before queuing, if was possible to replace the image between sending the pending message and the image transfer to the tag, causing md5 mismatches and instability.
Solves #47
