large external flash partitioned with "best guess" which turned out to be way wrong 6 years later. migrating partitions is not fun.
External storage must be encrypted, verified, and unique. So someone can't take the external flash off one device and solder it to a target device. Which means synchronizing between internal nvstorage and external
Large ( multiple page size writes/reads/erasures ) take 100s of ms. The drivers (again, written 6 years ago) assume that no one would ever want to interrupt those writes.
What we ended up with is a stack of tech with some nasty tradeoffs. I think the only off-the-shelf software is the encryption and serialization. The rest is custom (which had to be thrown out when changing RTOSes), built on assumptions by non-domain experts
Interesting. The header size seems big for low-resources embedded systems (e.g. with only 256 bytes of EEPROM). I'd rather use a file identifier (e.g. a 8-bit number) to identify what a file is doing instead of arbitrary names.
It's one of those things that every embedded dev kind of cobbles together on their own as they discover the limit of struct arrays stored in EEPROM.
Except this one actually seems worse in some ways, because to find a file you have to keep following what is effectively a single linked list of file headers until you find the file you need.
The authors even acknowledge this is just a copy of tar's approach, and even acknowledge that that was in turn done this way due to a lack of random seeking on tape systems at the time. But a microcontroller's EEPROM/SPI/... data is nothing like this? You can just do arbitrary seeks. So I'm not sure what they were going for here.
One of my pet peeves is people using the letter "u" to mean micro. Its a greek letter mu, "μ", and seeing as the entire thing is capitalised here, it could also be "Μ" (uppercase greek mu, not uppercase latin M)
The problem is that µ is usually hard to type (unless you have a Greek keyboard or a custom keyboard mapping). This said, although I tolerate stuff like "47 uF" in electronic schematics (also because legacy software didn't even allow the µ symbol), I definitely find horrible to see stuff like "us" instead of "µs" in an article.
As a (very) frequent "µ" user (and several others like ± and Δ and °) I've had the alt codes memorised for ages but having recently, out of necessity and a bit of a nomad lifestyle, moved to a "tenkeyless" keyboard (the horror), I simply macroed it, but I find it refreshing that some keyboard layouts simply include it. I have an obscure pocket 8-bit with an even more obscure OS written in Sweden that also has µ.
Seems simple and useful for light use cases
What we're running into at my work:
large external flash partitioned with "best guess" which turned out to be way wrong 6 years later. migrating partitions is not fun.
External storage must be encrypted, verified, and unique. So someone can't take the external flash off one device and solder it to a target device. Which means synchronizing between internal nvstorage and external
Large ( multiple page size writes/reads/erasures ) take 100s of ms. The drivers (again, written 6 years ago) assume that no one would ever want to interrupt those writes.
What we ended up with is a stack of tech with some nasty tradeoffs. I think the only off-the-shelf software is the encryption and serialization. The rest is custom (which had to be thrown out when changing RTOSes), built on assumptions by non-domain experts
Interesting. The header size seems big for low-resources embedded systems (e.g. with only 256 bytes of EEPROM). I'd rather use a file identifier (e.g. a 8-bit number) to identify what a file is doing instead of arbitrary names.
I feel like with less than 1000 bytes the situations where you wouldn't want to directly manage every byte are quite rare. What is your project?
I don't think there's anything novel here?
It's one of those things that every embedded dev kind of cobbles together on their own as they discover the limit of struct arrays stored in EEPROM.
Except this one actually seems worse in some ways, because to find a file you have to keep following what is effectively a single linked list of file headers until you find the file you need.
The authors even acknowledge this is just a copy of tar's approach, and even acknowledge that that was in turn done this way due to a lack of random seeking on tape systems at the time. But a microcontroller's EEPROM/SPI/... data is nothing like this? You can just do arbitrary seeks. So I'm not sure what they were going for here.
The implementation is also full of obvious bugs that will cause crashes or hangs or worse when operating on an untrusted or simply just corrupted filesystem: https://github.com/clisystems/utfs/blob/5f1a6f049a0ca5435afb...
One of my pet peeves is people using the letter "u" to mean micro. Its a greek letter mu, "μ", and seeing as the entire thing is capitalised here, it could also be "Μ" (uppercase greek mu, not uppercase latin M)
The problem is that µ is usually hard to type (unless you have a Greek keyboard or a custom keyboard mapping). This said, although I tolerate stuff like "47 uF" in electronic schematics (also because legacy software didn't even allow the µ symbol), I definitely find horrible to see stuff like "us" instead of "µs" in an article.
I just googled it to type my comment. And if you're using it enough to need quick access, you can do alt + 0181 on your numpad on a windows system
As a (very) frequent "µ" user (and several others like ± and Δ and °) I've had the alt codes memorised for ages but having recently, out of necessity and a bit of a nomad lifestyle, moved to a "tenkeyless" keyboard (the horror), I simply macroed it, but I find it refreshing that some keyboard layouts simply include it. I have an obscure pocket 8-bit with an even more obscure OS written in Sweden that also has µ.
That's what I do, actually, although I use Alt+230 because I remember the code from CP437.
And it's option-m on a Mac.
Might be AltGr-m on Linux (didn't try).
... that's weird. It's alt gr+ m on every recent finnish keyboard, apparently it's not on us ones?