Yes, that's the reason for the 4096 byte sectors - been there! IIRC a FAT-format drive "wastes" quite a large number of sectors in the block before it starts storing data (possibly the intention was to store the OS there?). With multi-GB drives that doesn't matter, but I had just 8MB of flash, so very high overhead. Hence littleFS, which I also have running very satisfactorily in just 256KB of FRAM (I don't have big files to store); the overhead there is minimalMy code is focused on handling what MicroPython uses for FAT - FAT16, 4096 bytes per sector, 1 sector per cluster, single File Allocation Table, but should be easily modifiable for FAT12 and FAT32, different sector and cluster sizes, etc. The 4KB sector size was a bit of a surprise given it's normally 512 bytes, but that fits with the minimum Flash erase size being 4KB.
If your solution involves fatFs itself, worth checking the version you have; in theory the latest release handles time stamps, although not the 'extra' field. However there's a partially unrelated bug, easily patched - see the fatFs web site.I also discovered something I hadn't previously appreciated, that while FAT file timestamps are notorious for having only 2 second resolution to fit 'hh:mm:ss' into 16-bits. There's another byte in each directory entry (offset 13) which stores 0-199, providing the missing second and increasing resolution to 10ms. It doesn't however seem MicroPython uses that.
Statistics: Posted by stevend — Sun Jul 20, 2025 1:53 pm