> Petit FatFs is a sub-set of FatFs module for tiny 8-bit microcontrollers. It is written in compliance with ANSI C and completely separated from the disk I/O layer. It can be incorporated into the tiny microcontrollers with limited memory even if the RAM size is less than sector size.
>Petit FatFs is a sub-set of FatFs module for tiny 8-bit microcontrollers. It is written in compliance with ANSI C and completely separated from the disk I/O layer. It can be incorporated into the tiny microcontrollers with limited memory even if the RAM size is less than sector size. Also full featured FAT file system module is available here.
>Features
Very small RAM consumption (44 bytes work area + certain stack).
Very small code size (2K-4K bytes).
FAT12, FAT16 and FAT32.
Single volume and Single file.
Streaming file read.
File write function with some restrictions.
I have noticed there are quite a few FAT-32 implementations out there, but none that do what I want. Ideally what I want is something that would do the following; allow the creation of a new FAT-32 image file of a specified length given a target directory.
The program (or programs/scripts) must be command line driven and run under both Windows and Linux (so they can be integrated into our build system).
The use case is the following; the creation of a single binary image containing some firmware and a (per-unit) custom FAT-32 partition, both of which would effectively concatenated together.
Does anyone have any ideas? Otherwise I might have to make something myself.
I can’t speak for Windows, but on any *nix OS you can do this with a loop back device. You’d have to determining in advance and likely round up a bit. But it’s a literally a couple line shell script.
On Windows you could create and mount a VHD file and format it as FAT32 by using the diskpart utility, with the commands "create vdisk", "attach vdisk", and "format"
> allow the creation of a new FAT-32 image file of a specified length given a target directory [emphasis added]
I think that's your problem: file systems are supposed to go onto a preexisting block device, which you'll need to create seperately. For example, on my system:
You could use the non-petit version of this FAT library to do all the image twiddling from userspace, without having to rely on any kernel support. The only trick then would be compiling the code to run on windows. If you already support that in your build system, then great.
Otherwise, you could try to find a suitable FAT implementation written in a cross platform language like python.
Otherwise you're looking at some fairly nasty scripting to get windows to do the FAT filesystem manipulation for you. As far as I know, windows doesn't support loopback devices out of the box for example.
Do you really need a baked FAT32 filesystem? Could you get away with a simpler payload like a tar?
If it's that onerous to download the zip, maybe we should build a tool to browse .zip/.tgz source links instead of pressuring everyone to centralize all source code on the planet into just two web sites.
Never said it should be a requirement. But downloading a .zip file from a site which does not have a valid SSL certificate nor supports SSL in the first place does not instill confidence. Software security is a thing.
Ah ELM. I always try to urge everyone interested in low-level embedded systems engineering to browse elm-chan.org, it's such a treasure trove.
He describes himself as "Mediocre embedded system engineer" but he is way too humble, the skill he shows is so incredible that I often find myself speechless whenever I look at his projects.
Go there, look around and recommend it to everyone. You will not regret it.
Agreed. Anyone know how to get in touch with him? I used his audio player code, found some bugs, and want to give him the fixes. Tried the email listed on his Profile page, but never heard back.
The original code fails to load WAV's containing metadata – even though an intent to tolerate them appears written into some of the handlers (DISP, LIST FCC, etc). I can provide files from Audacity which reproduce the issue.
Thanks. Tried that as well but didn't get a response (and most of the conversation in other threads seemed to be Chinese which unfortunately I didn't understand)
I've been using this recently and, because it doesn't ever modify the file system structures, you don't have to worry about unmounting the volume cleanly.
It can write to files, but it can't create or resize them.
For that (and more), you want FatFs, the full featured version: http://elm-chan.org/fsw/ff/00index_e.html
elm-chan has also written an AVR bootloader that can update the flash from, for example, an SDCard. It uses this Petit FAT File System Module and requires a 4K bootloader section (so mostly of use on the ATMega1284).
I have used the Petit version a lot and I love it. But it is not always very efficient because it does no caching. I've done a fix so that when I have 512 bytes to spare it will save the last sector read. It speeds things up a lot without the fixed overheads of the full Fatfs. I probably should offer it up if it's possible.
PetitFatFS was handy in a recent build. I was creating a box that could be placed on marine equipment to collect vibrations data, but to capture the modes of interest it had to read accelerometer data and write it to a microSD card at >=660[Hz]. I don't have a programming background and thus had trouble creating code which fit onto the tiny memory of the microcontroller being used. PetitFatFS worked beautifully, and saved a ton of headache on my end. It added the step of creating the storage files on the microSD card prior to inserting it, but that was acceptable for this project.
36 comments
[ 3.8 ms ] story [ 83.2 ms ] thread> Petit FatFs is a sub-set of FatFs module for tiny 8-bit microcontrollers. It is written in compliance with ANSI C and completely separated from the disk I/O layer. It can be incorporated into the tiny microcontrollers with limited memory even if the RAM size is less than sector size.
>Petit FatFs is a sub-set of FatFs module for tiny 8-bit microcontrollers. It is written in compliance with ANSI C and completely separated from the disk I/O layer. It can be incorporated into the tiny microcontrollers with limited memory even if the RAM size is less than sector size. Also full featured FAT file system module is available here.
http://elm-chan.org/fsw/ff/00index_e.html
>Features Very small RAM consumption (44 bytes work area + certain stack). Very small code size (2K-4K bytes). FAT12, FAT16 and FAT32. Single volume and Single file. Streaming file read. File write function with some restrictions.
The program (or programs/scripts) must be command line driven and run under both Windows and Linux (so they can be integrated into our build system).
The use case is the following; the creation of a single binary image containing some firmware and a (per-unit) custom FAT-32 partition, both of which would effectively concatenated together.
Does anyone have any ideas? Otherwise I might have to make something myself.
The mtools/mformat are not AFAIK released pre-built for Windows, in case of need here is a build:
http://reboot.pro/topic/14354-buidlingmodifying-floppy-image...
Syntax/option for mformat are a bit complex, again in case of need here is a small batch that hopefuly makes commands clearer:
http://reboot.pro/topic/21664-makeiso/page-4#entry205455
[1] https://github.com/pengutronix/genimage
I think that's your problem: file systems are supposed to go onto a preexisting block device, which you'll need to create seperately. For example, on my system:
Once you've created the filesystem, fill it with:Otherwise, you could try to find a suitable FAT implementation written in a cross platform language like python.
Otherwise you're looking at some fairly nasty scripting to get windows to do the FAT filesystem manipulation for you. As far as I know, windows doesn't support loopback devices out of the box for example.
Do you really need a baked FAT32 filesystem? Could you get away with a simpler payload like a tar?
He describes himself as "Mediocre embedded system engineer" but he is way too humble, the skill he shows is so incredible that I often find myself speechless whenever I look at his projects.
Go there, look around and recommend it to everyone. You will not regret it.
ChaN, if you're out there:
https://i.imgur.com/E8Z29VE.png
The original code fails to load WAV's containing metadata – even though an intent to tolerate them appears written into some of the handlers (DISP, LIST FCC, etc). I can provide files from Audacity which reproduce the issue.
Moved remaining details here to avoid boring the HN audience: https://pastebin.com/raw/XdneQ8xh
It can write to files, but it can't create or resize them. For that (and more), you want FatFs, the full featured version: http://elm-chan.org/fsw/ff/00index_e.html
elm-chan has also written an AVR bootloader that can update the flash from, for example, an SDCard. It uses this Petit FAT File System Module and requires a 4K bootloader section (so mostly of use on the ATMega1284).
I admire his consistency.