3 ms·

I would recommend thinking long and hard if you really need a file system on a microcontroller. What do you intend to use the file system for? If it's only for

by crest 3y ago

I would recommend thinking long and hard if you really need a file system on a microcontroller. What do you intend to use the file system for? If it's only for read-only assets like images or sounds use a linker script to collect them into a sorted set. If you want to write logs a ring buffer is faster, simpler and more resilient to corruption. Configuration settings are small enough and don't too frequently in most systems so a ring buffer or just a pair of double buffered flash pages with a checksum and version counter can be enough. LittleFS is tries to hit a sweet spot that only exists on MCUs with NOR flash and relatively much RAM and fast CPU cores. The problem is that it's complex compared to the alternatives. The two most common alternatives I can think of are FAT which will wear out flash given half a chance and SPIFFS which is simpler and slower than LittleFS. FAT is a terrible file system for writing on a MCU, but because of its history as the file system for floppy disks it's still supported by every desktop operating system. This makes it perfect to allow users to edit configuration files stored on a microSD or replace assets like background images without having to use specialised tools. The annoying answer: it depends.

HocusLocus 3y ago
Great points. I just want to toss out an example of why you might want an OS to use with flash of decent size to do wear leveling on everything. The classic example I give is a media player subject to power interruption and you don't want to include an internal battery in the design for graceful powerdowns, so the player needs to save a checkpoint of play state every ~5 seconds so the device can resume intuitively. Such as indexing back to your position in a 40 hour audiobook. You're also going to have menu navigation and a combination of changing settings and device local media library changes. And now comes along some Internet angle so there are C libraries that implement browser functions and that means cache and cookie writing. And software updates. Ring buffers are smart but there's a whole lot of writing going on here! It would be great to code everything in high levels so if it emulates properly on a desktop, once it's pushed into the devices (say a generous 128GB flash with 28GB reserved for the system) the devices will have a 20 year lifespan with no batteries to fail or leak.

by crest 3y ago

HocusLocus 3y ago

Great points. I just want to toss out an example of why you might want an OS to use with flash of decent size to do wear leveling on everything. The classic example I give is a media player subject to power interruption and you don't want to include an internal battery in the design for graceful powerdowns, so the player needs to save a checkpoint of play state every ~5 seconds so the device can resume intuitively. Such as indexing back to your position in a 40 hour audiobook. You're also going to have menu navigation and a combination of changing settings and device local media library changes. And now comes along some Internet angle so there are C libraries that implement browser functions and that means cache and cookie writing. And software updates. Ring buffers are smart but there's a whole lot of writing going on here! It would be great to code everything in high levels so if it emulates properly on a desktop, once it's pushed into the devices (say a generous 128GB flash with 28GB reserved for the system) the devices will have a 20 year lifespan with no batteries to fail or leak.