RLARM Source code

Hello Reinhard,

Something else that annoyed me a great deal lately is FlashFS's RAM "drive". Now, I'm working on a system that exports its FAT12 to the outside world and should not allow direct access to the SD card, so I use RAM as an intermittent file system. it took me a while to figure that the RAM "drive" is not a FAT compatible device; hence, it is formatted to 0 (no boot, root, FAT...) and basically it has its own administration decoupled from an actual file system which of course affects all system calls. it is nothing more than a piece of RAM that can be addressed as a file system. you introduce this "drive" alongside the facilities to control the contents of an SD card, external Flash ext., which is a little misleading. I now need to implement my own FAT12 file system - have I read the little letters in the documentation, it is likely that I would have chosen another solution.

Hello Reinhard,

Something else that annoyed me a great deal lately is FlashFS's RAM "drive". Now, I'm working on a system that exports its FAT12 to the outside world and should not allow direct access to the SD card, so I use RAM as an intermittent file system. it took me a while to figure that the RAM "drive" is not a FAT compatible device; hence, it is formatted to 0 (no boot, root, FAT...) and basically it has its own administration decoupled from an actual file system which of course affects all system calls. it is nothing more than a piece of RAM that can be addressed as a file system. you introduce this "drive" alongside the facilities to control the contents of an SD card, external Flash ext., which is a little misleading. I now need to implement my own FAT12 file system - have I read the little letters in the documentation, it is likely that I would have chosen another solution.

Re. Tamir

The RL-ARM ram drive is a drive, which is able to store/retrieve files. It is designed as simple as possible. The user needs it's functionality, not it's implementation. As far as the functionality is concerned, the user needs to write/read files to/from the ram drive. And the RAM drive does just this. It is really fast, small code-sized and very efficient.

Your concept to use the RAM drive as a shadow image of an SD card is wrong. Insisting in this solution, you will have a lot of troubles. Do you have in mind that the PC has it's own file/FAT caching, and might simply miss the change written to SD from embedded system. If this change is in the FAT, an SD card file system corruption is highly likely to happen. On the other hand, the RL-ARM FlashFS also implements it's own FAT/data caching...

no Franc, no shadowing at all! access to the SD card via the RAM drive will be possible via a folder!
click on it, and the file system of the SD is made available. so no corruption of any kind is possible.

Do you have in mind that the PC has it's own file/FAT caching, and might simply miss the change written to SD from embedded system.

of course. that is why I will be demounting the RAM drive (hence, also the SD card - remember it is a folder in RAM!) using the soft connect pin or some SCSI magic while writing, until I'm done.