@willpuckett made a phenomenal discovery which is that we can DOUBLE our available memory by reformatting the way that the memory is allocated on the ESP32.
It’s a big improvement which opens the doors to lots of future upgrades, and we’re pushing edge of the amount of memory we have available currently so it seems like the right thing to do.
Unfortunately, because we need to re-map the memory locations we can’t do a regular upgrade by going into the UI and uploading a new firmware. Instead we need to plug in a USB cable and run the update that way.
On PC that’s pretty straight forward, it just requires double clicking the “full_install.bat” file.
On Mac it’s a little harder. We need to run the “full_install.sh” file, but to run a .sh file on Mac is pretty complicated. It requires opening the terminal, navigating to the right folder using “cd” and then running ./full_install.sh I don’t think that’s an insurmountable obsticle, but I’d love to make it easier if we can.
Does anyone have any ideas for how we could make running that script easier for folks?
Here’s a copy of the Mac installer if you want to give it a try:
I believe we can drop a double clickable automator script into the posix folder and hace the python build script copy it into the archive… I’ll give it a go this weekend.
Way to make a guy feel old, @bar - “my” first computer ran BASIC (or whatever other single program one loaded after entering bootstrap code on the front panel switches, word by laborious binary word), and my first operating system was CP/M. To me, the command line is old familiar lore.
Clicking “OK” results in the installer running, eventually leaving the user with a prompt to connect to fluidterm after successful installation which the user can ctrl-c out of or just close the window. If that works, I can PR the two additional lines, or if we need to just run the script and exit, it would be nice to at least show an “installation successful, press any key to close…” dialog…
I’m not sure if it’s something anybody would try doing, but usually my rule of thumb is that if I can think about it, someone will do it… Once Maslow is repartitioned (by running full-install.whatever), users can’t ‘downgrade’ firmware to older versions without again repartitioning to the older scheme…
In order to more clearly delineate this boundary, it seems it could be worthwhile to use a breaking/major semver-ish number… So instead of V0.89 use V0.9 or even V1.0…
I’m not sure if it’s something anybody would try doing, but usually my rule of
thumb is that if I can think about it, someone will do it… Once Maslow is
repartitioned (by running full-install.whatever), users can’t ‘downgrade’
firmware to older versions without again repartitioning to the older scheme…
I think the new image can’t go on the old partition because it is too small, but
I don’t see why the old image can’t go on the new (larger) partition.
someone needs to check
In order to more clearly delineate this boundary, it seems it could be
worthwhile to use a breaking/major semver-ish number… So instead of V0.89
use V0.9 or even V1.0…
I would agree with a v1.0 version, even if it is a one-way transition.
If a user has iterm2 installed, a .sh file will automatically open in it, which was the case on my computer… But I wanted to test in terminal.app as well. It will NOT automatically open a .sh file.
I added a full-install.command file that will open on vanilla macOS in terminal simply by double clicking, doesn’t even require clicking “ok”.
I just did a flash & repartition using full-install.command. I then connected to Maslow, changed the wifi, and uploaded a test file to the file system. 4-panel_plain.png (the test file) shows up in the file browser.
I then downgraded to V0.70 and going to the file browser, the image IS NOT THERE, although the browser does show 2MB size…
Upgrading back to HEAD, 4-panel_plain.png is back in the file browser.
Also, some errors in the console after the downgrade, some missing keys, but also 3 more that didn’t appear to be key related…
The nvs and otadata partitions are in the same place and same size, and app0 starts at the same place, but even a here lie dragons seems like it’s probably an understatement, and a LOT of headache will probably be avoided by emphasizing that the only way back and forth between pre and post partition versions is via the full-install.whatever path…
It seems like there could also be some reason in doing the repartition with NO other changes involved, which would prevent any regressions being simultaneously introduced, and give people a place to “downgrade” to from any subsequent updates… Again, I’m just not sure how many people are doing this sort of thing (downgrading) in reality, and if it’s even worth being concerned about…
Ideally I think we would do the re-partition before we changed the calibration process. That is sort of two big and unrelated things happening at once.
If a need comes up we always have the option to re-build an earlier version with the new partition and offer a downgrade to any earlier version (plus the re-partition).
