2 ms·
I would imagine if embedded devices are being assembled and configured with filesize concerns, then exFAT would be the natural implementation they would opt for
by bilekas 6y ago
I would imagine if embedded devices are being assembled and configured with filesize concerns, then exFAT would be the natural implementation they would opt for.
Or do you mean updating/transitioning legacy embedded?
The spec doesn't mention backwards compat, but does mention as a goal
>Retain the simplicity of FAT-based file systems.
I would like to test out if an input embed system is exFAT compat. And what might be required to update.
- wongarsu 6y agoEmbedded devices often have a lifespan measured in decades. And for short-lived devices like consumer all-in-one printers (~4 years) it's not like every new model has a new firmware written from scratch. They get whatever the last model had, with a few updates for new device features. That might include exFAT, or it might not.
- numpad0 6y agoI believe the implication is SD card/USB drive support on microcontrollers without an OS. SD under 32GB uses FAT32 so you can’t drop supports, and FAT32 stack is often already pushing the maximum ROM size, so no room is left for a novel filesystem. Lots of developers aren’t themselves proficient at writing filesystem code as well, and there aren’t as many copy-pastable exFAT implementations as there are for FAT32. So unless they know what they’re doing and unless it’s critical to their product, the majority won’t easily move onto exFAT. As for the use within the device “firmware”, the user defined program is usually just a giant baremetal a.out in the middle of the ROM at a specified address, so no FS is involved there.