You don't have to know how FAT works to create your own filing system. I have created embedded systems with 256GB microSD cards for mass data storage. I threat the microSD card as one huge memory and I use it any way I wish.

 

Hmmmmm I thought that FAT is managing the Files so something like FILE isn't needed hmmmm.
...

You're trying to getting too far ahead of where you are and will just get lost with more info. Work and slowly build on what you know until you have a good understanding.

 

Okay. Lets open two files using an API that does not use a file handle.

f_open(“foo.txt”);
f_open(“bar.txt”);
f_read(buffer, 10);

What file did you just read from?

 

You're trying to getting too far ahead of where you are and will just get lost with more info. Work and slowly build on what you know until you have a good understanding.

Yes but I need a starting point or a source ;D
Working on something while not having a starting point or reading codes that doesn't tell me a lot won't get me far. So I wanted to know how I could start in this thing though with some basic programming knowledge (let's say I somehow understand how some commands in HAL works inside but only partly).
Also wanted to just know something of what I asked there.

Okay. Lets open two files using an API that does not use a file handle.

f_open(“foo.txt”);
f_open(“bar.txt”);
f_read(buffer, 10);

What file did you just read from?

So the handle is about which disk if there are multiple ?
I thought of it as a single disk, that f_open just works on. If it's for FAT12 then he know where exactly is Root Directory Which first address of that location would be Root_start_address = Boot_Offset (size of Boot)+ FAT_Offset (size of FAT), from this point I can find the file like foo.txt, bar.txt, buffer.txt if it's in this single disk.

 

You don't have to know how FAT works to create your own filing system. I have created embedded systems with 256GB microSD cards for mass data storage. I threat the microSD card as one huge memory and I use it any way I wish.

You are right, I just thought of if what I was answering to your questions fits this FAT system or the FAT12 system.

But yea when I checked the example codes I couldn't find similarities to FAT12 because they were already premade functions and uses some FIL objects or FRESULT or FAFTS that didn't match the description of a FAT12 or FAT itself. I imagined it that it would just try to find the Root Direct to find the file the user want's to find (so this is what must be put into function), and that should be enough to start the algorythm of finding all data, but in examples they uses some other side that manages also files although FAT itself manages the files also.

So I ended up wanting the answers to 3 questions. Because I feel a bit lost and don't know where to start with to be honest and reading codes that have some structures I don't know what they have and why they must be there doesn't tell me a lot. Same as the starting point in which I also don't know where to start with. So I've accepted some facts that these codes were premade and it's good to use them. So now I try to find answers to 3 questions and maybe find a source to start understanding complex codes. Simple ones I somehow handle same goes with some HAL functions (when it comes to analyzing some of them is some how doable), but when the concept doesn't match with the code this is where I get confused or the amount of layers (that sometimes is also in HAL so I try to accept most of them).

 

In my application, all the data files are of the sames size, for example, 16KB each. Hence each file occupies the same number of sectors. I don't have a FAT, map, linked list, or directory. When I need to read/write FILEn, I know exactly which sectors to access.

 

In my application, all the data files are of the sames size, for example, 16KB each. Hence each file occupies the same number of sectors. I don't have a FAT, map, linked list, or directory. When I need to read/write FILEn, I know exactly which sectors to access.

Cool stuff though.
So how do I understand a code that works as FAT12, but uses some objects that doesn't takes care of files although FAT is taking care also of files