As flashing a new LittleFS in case of e.g. a changed main.js is taking time and
the provided web interface is not the fastest to navigate we are introducing a
small script to upload the whole data folder to the esp.
It can also be sourced into a shell allowing for manual file uploads to the esp.
In addition we are also adding a "push_ota.sh" script designed to show its use as
well as uploading the recenty build firmware to the esp where future commits will
allow of SDCard based updates.
Signed-off-by: Mimoja <git@mimoja.de>
So far the platform-io build-flags config option was a copy&paste
situation from one board to the next.
With the recently introduced new supported board these build-flags
are redundant and difficult to oversee.
Longterm they should ideally be partially generated to ensure a good
customizability but for now we are moving the common ones into the
base env where they can be imported by all the boards.
Signed-off-by: Mimoja <git@mimoja.de>
So far the calculated size for the tagDB in the frontend was
purely based on the size of each of its static entries.
However the data pointer as well as the json based config string
can occupy additional memory which is not accounted for.
We are therefore introducing a helper function to properly
calculate the DBs size.
Signed-off-by: Mimoja <git@mimoja.de>
We currently have two ways of undefining the PowerPin in software for the ESP32
For once we can set POWER_NO_SOFT_POWER which will lead to some helpful screen
messages _but_ will still require the definition of the FLASHER_AP_POWER pin.
The second way (which was replaced with POWER_NO_SOFT_POWER) allowed to set the
powerPin array to {-1} to indicate that the pin is undefined. This would then be
handled in pretty far down the call stack right before toggeling the pin in powerControl:
```
void powerControl(bool powerState, uint8_t* pin, uint8_t pincount) {
if (pin[0] == -1) return;
```
This however is leading to an error: pin is n pointer (here an array with additional length)
to an uint8_t which can never be -1. Therefore the check wont ever be reached and an invalid
gpio number is passed to the gpio hal.
This caused the error:
```
E (XXXX) gpio: gpio_set_level(226): GPIO output gpio_num error
```
to show up in the logs.
We are now proposing three seperate changes to mitigate this behaviour:
1) We are addng the POWER_NO_SOFT_POWER to the Wemos and the M5Stack boards default configs
for new users to find.
2) We are replacing the pin[0] check in powerControl with a check on the pincount and a
nullptr check as the zbs_interface->begin() allows for no powerPin to be passed in which
case we are dereferencing a nullptr.
3) ZBS_interface->begin() is losing its powerPin related default configurations and
sanity checks are put in place before every calling.
We have opted to do 3) in this way and not adding the checked into the ZBS_interface->begin()
function which is also passed an uint8_t pointer to keep the API of the class stable
for reuse in other projects. Changing the interface however would be ideal here
Signed-off-by: Mimoja <git@mimoja.de>
- cleanup font in flash. Don't forget to update content_template.json in the file system after updating fw.
- fix layout issue in update window
- better error handling + auto retry during fw update
- fixed spelling 'weemos' -> 'wemos_d1_mini32' in build name
Sprite rendering is the most heap hungry operation in during
content generation. This can lead to ESP panics as the exception
for the failing "new" is not handled.
To further half the required the memory we are doing it in two passes
for black and red independant. While this add a few ms to the rendering
the main time of the rendering is writing to the FS anyways so the overhead
neglectable after all.
Signed-off-by: Mimoja <git@mimoja.de>
The SPIFFSEditor.h header is being imported from the .platformio folder
while the corresponding .cpp is actually stored with the project.
To ensure we can not accidentally edit the wrong file in the future import
the header as well
Signed-off-by: Mimoja <git@mimoja.de>
The AP-Tags are not very fast at flashing. SoftSPI is fast enough for the
rare flashing.
This gives us the ability to move the AP connection to arbitrary pins.
Signed-off-by: Mimoja <git@mimoja.de>
If the flasher and the SDCard share pins the ESP will need to be reset
to bring VSPI and HSPI back into sane states. Trying to reinit them
without a reset will lead to heap corruptions.
Better safe than sorry.
Signed-off-by: Mimoja <git@mimoja.de>
When an SD Card is available it is the more interesing
metric in terms of space usage. We are therefore using
it here.
Signed-off-by: Mimoja <git@mimoja.de>
To be able to store more images and never worry about running
out of storage again we are adding support of SDCards.
We are faced with two options:
1) Remove the LittleFS code
2) Allow for both FSs but increase the app partition as we run
out of space.
We have opted for 2 for two reasons:
1) Unformated SDCards can be initialized from the littleFS
2) If the SDCard and the flasher share the same SPI pins
the SDCard needs to be completely disconnected so there needs
to be a FS in that rare case.
Performance wise the SDCard is not slowing the system down.
Writing the AP db with 70 APs takes 2.5 seconds, on the SD
only 800ms. This however is SD and setup depending.
By default the SDCard is expected on pins 18,19,23 however this
is configurable via preprocessor defines.
Globally we replace LittleFS with a new pointer to the currently
used FS allowing for hotswapping where the FS pointer is not saved.
One case which is therefore not working is the SPIFSEditor which
copies the FS interally.
Signed-off-by: Mimoja <git@mimoja.de>
Beyond around 20 APs the littleFs will no longer provide enough
space to add .pending files. The original .raw files are premarily
held to be able to send them to the web interface.
In those rare cases where this is not strictly needed we can
allow specific setups to auto-delete them.
Signed-off-by: Mimoja <git@mimoja.de>
The M5stack board offers three interesting features for use with
OpenEPaperLink:
- LCD
- SDCard slot
- Modules including a batters
Which means it can easily be used to walk around with an AP for testing
purposes.
The LCD is currely not used as the M5Stack library is so old that it collides
with newer versions of eTFT which we are importing already.
Signed-off-by: Mimoja <git@mimoja.de>
The original weemos D1 mini was one of the most popular
ESP8266 boards. To this day many designs are designed around its
formfactor.
The successor is the here added D1 mini 32. It brings the same
"core" header with 8 GPIO but also additional io.
We are adding a default config which is workable with the old
pinconfig as those are usually the only ones exposed on the
breakout boards.
