[weland]

Depending on the amount of abstraction involved, it doesn't sound impossible to do. Given sane and direct access to the controller of the underlying device, and a reasonably simple underlying device (e.g. a simple Flash device), raw reads and writes can be written in maybe two dozen instructions each. Assuming userbinator was using a reasonable macro assembler, so that the 800 lines didn't also include string comparisons and all that, 800 lines doesn't look so little. I'm not sufficiently familiar with FAT32 but given a sane enough architecture, it doesn't sound that impossible.

[userbinator]

Depends what you mean by "complete", but being able to create/read/write/delete files and directories is pretty complete to me. It doesn't take very many instructions to traverse a linked list or index an array, the two primary structures in FAT32.

Sorry I can't opensource it (being for a commercial product) but this is the approximate breakdown of that ~800 lines (I didn't count exactly, there are comments and whitespace included here too):

    70  initialisation
    140 cluster chain operations
    300 directory operations
    240 higher-level module interface
    50  data area (buffers, states, etc.)

Given sane and direct access to the controller of the underlying device, and a reasonably simple underlying device (e.g. a simple Flash device), raw reads and writes can be written in maybe two dozen instructions each.

It calls into another driver for accessing the block device, so all block read/write operations take the ~6 instructions needed for a call.

Assuming userbinator was using a reasonable macro assembler, so that the 800 lines didn't also include string comparisons and all that, 800 lines doesn't look so little.

I didn't use a macroassembler. It's for an 8-bit MCU; the final firmware image (including all the other functions of the product) is roughly 20KB.

[weland]

Aye, it's an MCU I was thinking of in the first place, where read/write operations are done through a reasonably simple Flash controller and can be abstracted in a separate driver. I have written FS drivers of fairly similar complexity, in pretty much similar space constraints. That's why I wasn't incredulous.