Most recent activity
-
- 3 comments
- 1,133 views
-
Hi! I would like to ask how long the Bangle.js external Flash storage lifetime is, in terms of page write cycles. Thanks!
-
- 14 comments
- 3,319 views
-
I believe StorageFile now allocates at least 40kB for each file on Bangle.js - so it probably isn't that efficient for you!
Oh wow that's pretty crazy. By using normal 'Storage' files we could probably reduce the production of un-erased flash pages by 40-fold, so compaction happens 40 times less frequently. Thanks!
-
Actually have you tried just install default apps from the app loader, and then trying again? I guess it's possible that the Storage got corrupted somehow and this is causing continued compaction errors. Starting from scratch might help.
Yeah I've tried that, it still gives the same errors.
While it shouldn't be the cause of your problems, I'm not sure that's actually going to be the best way of doing things. Internally Storagefile allocates a big chunk of data in order to do appends, so honestly I'd have thought you would be better off just writing to a standard 'Storage' file directly in the first place...
Either just keep everything in RAM if possible, or maybe use Storage.write with the offset functionality: http://www.espruino.com/Reference#l_Storage_write
Hmm... I have thought about that as well. I was concerned that
Storage.write()might repeatedly rewrite the same page until the 4096 bytes are filled. Is that a problem, and if it is would it be more / less of a problem than using StorageFile? -
@Gordon I'm not sure if this is correct (I am not familiar with Espruino internals after all), most code execution on our app run during event handling, and the errors that occurred with Morphing Clock also only happened during events like button presses, so perhaps the event handlers are not updated regarding the callbacks' locations in storage?
Also, I managed to replicate the problem manually with the following steps:
- Open Morphing Clock
- Open a StorageFile and write some arbitrary data
- Erase said StorageFile
- Call
require('Storage').compact() - Press BTN1
which throws the following exception:
Uncaught ReferenceError: "fffa" is not defined at line 1 col 3 W+CHARP;var d=new Date();g.reset();g.setFont("6x8");g.setFontAlign... ^ in function called from system at line 1 col 1 fffaff ?[204] ?[204] ?[204] ?[204] ffafffff ?[204] ?[204] ?[204] ?[204] ?[204] ?[204] ?[204] ?[204] ffffa?[204] ?[204] ?[204] ?[204]... - Open Morphing Clock
-
As for the code, I will try to ask for permission, but the day is over at my timezone so most likely I wouldn't get a reply before Monday.
-
Which exception was that? "attery" is not defined?
So just to be clear, you ran require('Storage').compact() and there weren't errors, but then when you long-pressed BTN3 you started seeing errors, even though the app worked fine before the storage compact?
Yes. To be clear, I was on the morphing clock app just so our own app wouldn't be running during compaction (as the instructions above seem to only ask to run the app after compaction). The error I saw was indeed the above
"attery" is not defined. It didn't break the app per se, only the current running instance of the app. I did another reset and it worked fine. For context I had ~300 files (260-512 bytes each) in storage, in total probably < 200 kB.How did you check the contents of the file? By loading it again with the IDE?
Or was it just that you saw \ff in the stack traces from errors?
By opening the file using the storage tool in the IDE. Just to be clear this is our own app's file, this and the
"attery" is not definederror (which happened while running morphing clock) were two separate issues. I knew it was \ff because the file viewer in the IDE was showing hex alongside ASCII.By the way I did the above compaction steps again, and this time a different error (once again from the morphing clock app):
Uncaught ReferenceError: "fffa" is not defined at line 1 col 3 W+CHARP;var d=new Date();g.reset();g.setFont("6x8");g.setFontAlign... ^ in function called from system at line 1 col 1 fffaff ?[204] ?[204] ?[204] ?[204] ffafffff ?[204] ?[204] ?[204] ?[204] ?[204] ?[204] ?[204] ?[204] ffffa?[204] ?[204] ?[204] ?[204]...It happened after I moved my hand, instead of after long pressing BTN3.
If you can actually reliably get the file corrupted by running compact then that's great - if you can send me the steps (privately if you need to keep your code private) such that I can reproduce it then it'll be much easier for me to fix.
The corruption is not actually reliable. It only happened the first time I tried running compaction. The next three times were fine. That said every time I did it the morphing clock app seems to throw errors, so that one is reliable.
As for the replication steps:
- Run our app, and start logging. Since I haven't yet sent you the code, the way this works is using a combination of StorageFile and normal fixed-length files. StorageFile (in base64) is used to allow for appending, and once that StorageFile reaches a given size limit (currently 349) the content is converted to binary and moved to a fixed-length "checkpoint" file.
- Leave it running until it starts throwing errors continually.
- Reset Bangle.js and go back to the morphing clock app.
- Perform the compaction steps above while running morphing clock
- I'm not sure what will fail here. 3 times out of 4, long-pressing BTN3 throws an error, and 1 out of 4, moving the device throws an error.
- Run our app, and start logging. Since I haven't yet sent you the code, the way this works is using a combination of StorageFile and normal fixed-length files. StorageFile (in base64) is used to allow for appending, and once that StorageFile reaches a given size limit (currently 349) the content is converted to binary and moved to a fixed-length "checkpoint" file.
-
Oh and I forgot to mention that after storage compaction the same errors still occur.
Ah that sounds very robust, thanks!