looking for an embedded filesystem, extremely simple - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: July 01, 2014, 01:27:22 pm
content: removed

author: AlfBaz
author_rank: Super Contributor
timestamp: July 01, 2014, 03:09:39 pm
content: Quote from: legacy on July 01, 2014, 01:27:22 pmIf the original code was developed on a PC prior to Win7 and you are having difficulties on Win7 let me know, I'll dig up my fat system and see what changes I had to make to accommodate some new security features introduced in W7QuoteThat's odd, an array (of unit32's no less!) holding true/false values for block usage?? Isn't that what the actual File Allocation Table is for?

author: AlfBaz
author_rank: Super Contributor
timestamp: July 01, 2014, 03:48:47 pm
content: Is it a custom file system, FAT16/32 or some Linux system?

author: AlfBaz
author_rank: Super Contributor
timestamp: July 01, 2014, 03:58:30 pm
content: Quote from: legacy on July 01, 2014, 03:37:52 pmIn your original post you mentioned you could develop it on a PC. That's how I developed mine using a spare drive to mess around on.To insulate fat development from the OS I created a couple of simple hardware access functions who's code would change depending on whether it was running on windows or an embedded target.Simply a read and write block function that would either accept or return 512 byte block from the disk.When I upgraded to W7 I had to add some IO_CTRL chicanery to give those hardware access funcs "permission" to gain raw disk access

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: July 01, 2014, 07:16:09 pm
content: why not use an already existing, tested working FS designed for embedding, yaffs, jffs2, logfs, ubifs, etc?

author: Bored@Work
author_rank: Super Contributor
timestamp: July 01, 2014, 08:41:34 pm
content: Sorry, it is really not clear what you want.You have written your own file system and now want us to clean up the code?You found some file system code somewhere and now want us to clean up the code?You want to write your own file system, and want some clean code for it from us?You want us to write you a file system?And what is the embedded part supposed to be?Will the file system be on an r/w media like an SD card?Will the file system be on a (mostly) read-only media, more like structured, grouped data?And if you look for a simple way to do a simple file system, the last time I needed to do my own I used a B*-tree. I have also used in the past what essentially amounted to a linked list and a simple block manager (cf. FORTH dictionaries, I probably took the idea from there). I have also done a read-only file system which was nothing more than a sorted index of names (to be binary searched), pointing to blocks. The data for such a file system was actually generated with a tool on a PC, converted into an Intel HEX file and burned into Flash.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: July 03, 2014, 12:22:49 am
content: what you really want then is basically, FAT16/FAT32. it doesnt get much more simple, and embeddable.if you want to step up, something a bit more complex like an inode based filesystem like Minix/Ext2...

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: July 03, 2014, 12:45:56 pm
content: Quote from: legacy on July 03, 2014, 02:05:07 amwho cares? does it work yes or no?Quote from: legacy on July 03, 2014, 02:05:07 amexcept it doesnt work and has not been tested.Quote from: legacy on July 03, 2014, 02:05:07 amugh. do you even understand the tradeoff. you want something so simple as to be useless.if you want a read only FS, just concatenate all the files and store the offset/length pairs.if you want something you can write to, well, your going to have to get a little complex and you know, bust out some lines of C.what exactly do you want, are you just pointing us to another crappy project on the internet? do you have an actual need of a embedded filesystem?embedded filesystems are very simple until you start realising that microsd sticks and sd cards are 64gb now and managing that extra space takes extra code. when mem sticks were small and 32bit pointers were nice, things were easy.suddenly you need more/bigger block bitmap, and your inodes end up going quadruple indirect because using 64gb of space requires lots of work.Quote from: legacy on July 03, 2014, 02:05:55 amyeah and its crap. OS_FileEntry_t is full of shit that does not need to be there making it twice as big.its limited all over the place by uint32_t's everywhere.it reads like a basic inode, direct block mapping with no indirect block mapping.if you have lots of edits/deletes this thing is going to get REALLY fragmented to shit to the point you need some kind of defragmenting tool

author: nctnico
author_rank: Super Contributor
timestamp: July 03, 2014, 12:50:32 pm
content: IMHO using fatfs (http://elm-chan.org/fsw/ff/00index_e.html) is the easiest way. It can be cut down to a minimalist implementation for space constrained devices.

author: amyk
author_rank: Super Contributor
timestamp: July 03, 2014, 12:59:49 pm
content: Quote from: BloodyCactus on July 03, 2014, 12:45:56 pm32-bit block addresses with 512-byte blocks already allows 2TB of storage, which is a lot more than most embedded applications will ever need.Just use FAT32.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: July 03, 2014, 02:27:25 pm
content: Quote from: amyk on July 03, 2014, 12:59:49 pmyour facepalm might be warranted but its notall the internal variables are 32bit, so yeah you might think 2TB... but it can only handle nearly 4gb maybe as an absolute disk size.its also some of the worst C I've seen in a long time. putting 'logicalAND' in IF statements instead of &&. redefining C convetion ugh. this is definitely someones university homework.

author: nctnico
author_rank: Super Contributor
timestamp: July 03, 2014, 04:32:40 pm
content: Quote from: legacy on July 03, 2014, 04:11:20 pmIt looks OK to me. Albeit it is a bit cryptic and the configurability doesn't make it easier to follow. What I do know from my own tests is that it works very well.

author: nctnico
author_rank: Super Contributor
timestamp: July 03, 2014, 05:41:43 pm
content: I think we are talking about a different piece of software. The Fatfs I pointed to has a comment for about each line of code telling what it is supposed to do.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: July 03, 2014, 09:09:46 pm
content: Quote from: legacy on July 03, 2014, 04:08:49 pmCode:- compiling app ... In file included from lib_fs_block_l3.h:5:0,from app.h:8,from app.c:1:lib_media_disk.h:13:36: fatal error: lib_media_disk.interface: No such file or directory#include "lib_media_disk.interface"^compilation terminated.make: *** [obj/app.o] Error 1fails on the first file, not even a single file compile! total fail.Quote from: legacy on July 03, 2014, 04:08:49 pmhere is original, 60 bytes long.Code:typedef struct{char_t name;uint32_t iblock; /* first block of file */uint32_t modifiedTime;uint32_t length;uint8_t isDirectory;uint8_t attributes;uint8_t valid;uint8_t mediaType;uint16_t blockSize;uint8_t pad1, pad2;} OS_FileEntry_t;here is what it should be, fits nicely in 32 byte chunk.Code:typedef struct{char_t name;uint32_t iblock;uint32_t modifiedTime;uint32_t length;uint8_t attributes;} OS_FileEntry_t;an entire byte to say its a directy? fuck that. use 1 bit into attributes. for emebdded filesystem you dont even need attributes really. padding? wtf. remove the padding and add them to the filename size. block size stored per file? thats some stupid ass design for an embedded filesystem. media type per file, where its defined as ram/flash/disk/unknown? throw this shit out.Quote from: legacy on July 03, 2014, 04:08:49 pmyou have infinite depth sub directories, file attributes, block size per file that can change, media types?if my 64gb SD card wont work in your device, what good is it to me? do I have to go on ebay and buy some really old 256mb card?Quote from: legacy on July 03, 2014, 04:08:49 pmif its going to be on removable media an user user is going to manage/insert into windows etc, usb key or something, it needs to handle >4gb, be readable on windows machine. proprietary FS wont cut it. 4gb max? not good enough.if its a filesystem for your device that nobody will see, ie only your device sees it, all this complexity of multiple subdirectories, attributes, media types, all this bullshit is not required imo.I knocked out a simple no nothing filesystem test.