In general, the new code should be faster when writing state, but slower when reading it. The old code would update two files when saving state, the new code only updates one. However, the new code has to check which file is the newest one, and it also reads that file twice to verify the checksum. Only a presets.ini with many entries would be big enough that you would notice the difference though.
Unfortunately, it crashed on the very first edit I made in Edit Mode and freezes on any subsequent attempts to make any saves. Not sure what info youād like, but on several attempts any edit that saves freezes the board immediately and I need to remove power to restart and no changes are evident.
Hmm, my board is not in a saber, so using edit mode is a bit diffucult.
Does it also crash with using the workbench to change stuff? Or is it just edit mode?
It wonāt let me connect to Workbench, Console is giving this error
app.html:1294 Uncaught (in promise) DOMException: Failed to execute 'open' on 'USBDevice': An operation that changes interface state is in progress.
at RunUSB (https://profezzorn.github.io/lightsaber-web-bluetooth/app.html:1294:20)
So, I havenāt been able to reproduce the problem yet.
I can see that your presets.ini is quite messed up, but the reading code just ignores it and reads the presets.tmp file instead, which works just fine.
I did manage to trigger one crash because of having a zero style, so I fixed that problem.
I will keep trying. In the meantime, can you post or send your config file?
Just to add, I deleted all .ini files and .tmp files, reformatted the SD can tried again and as soon as I made the first edit in Edit Mode it freezes. With āEdit Styleā it freezes as soon as we change the style because we have to save the change immediately, but the āEdit Colorā allows you to change colors fine, but as soon as you click to save it also freezes immediately.
Thanks Prof. I look forward to learning, and helping others learn, how. Please let us know when updated Presets.ini documentation is ready. Thanks for all you do.
Iām getting some crashes now, but the debugger wonāt show me anything sane about whatās causing the crashes. I think that means that the stack is trashed. The most likely cause for a trashed stack is simply using too much stack memory, so Iāll investigate that.
The new writing code stores a 512-byte buffer on the stack, so maybe that is whyā¦
So I checked in a change that disables the buffering I added when writing files.
This should reduce stack space usage by ~512 bytes, which should make it close to what it used to be I hope. Does it work better now?
I ran through all of the edits (and choreography mode) that save the various.ini files on a few different presets and it all seems to be working as expected. I also checked with and without KEEP_SAVEFILES_WHEN_PROGRAMMING and had no issues.
The very first save on any file takes a second or two longer (or at least it feels like it takes longer) but other than that it all seems to be running well.
If thereās anything specific you need me to test through let me know? But it seems to be working well for me.