FILE *ptr

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do I go about linking FILE with a FAT32 driver?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look at FatFs implementation.

 

That has a "file object" (struct) owned by the file system. The file object contains all of the reference and state information needed to access and manage the file. That includes a file name, read-write permissions, and the information needed to link to the FAT. Can't tell you much more.

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Apr 20, 2019 - 04:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look at the FILE structure. It has function pointer members for read/write. The idea is to connect those to the fputc() and fgetc() in your API

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How does fopen and fclose feature in the scheme of things?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My impression is that fopen does the file object creation and that fclose nulls that object. I have not been able to tell if these operations do anything to the FAT.

 

For small micros, that "creation" seems to mean just filling out an existing FILE struct (e.g. no malloc or anything like that).

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well the only FILE structures that usually matter are stdin, stdout and stderr. They are usually attached to a console so are permanently "open" so there is no real concept of fopen() /fclose() except that at the moment of creation for the terminal the output streams are opened and attached to the read/write functions of the terminal. It's because the fputc/fgetc for those streams are attached to stdin/stdout that the user can scanf(), printf() etc.
.
But most file usage is just going to be fopen/fread/fwrite/fscanf/fprintf/fclose/etc so in those cases the FILE is just for "housekeeping"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff -

 

In FatFs, I don't see anything that relates to those things. The file object looks to me as if it has block information, file name, a bunch of status references, and such.

 

It then appears that fread, fwrite, and such use the information from the file object to control access to the physical medium.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Apr 20, 2019 - 07:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

He's talking about an OS abstraction layer higher than a FAT driver. Think POSIX maybe?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may run into a problem with conflicts of the FILE type.

avr-libc's stdio has a FILE structure used for printf() and etc, but it really implements a vastly simplfied "fdev stream" (or something like that), and does not contain the sort of information needed to work with "files" on a an actual filesystem like FAT.   I'd assume (without ever having used it) that FATfs has its own data structure ("FIL", apparently) that has the additional data.  An operating system might have yet another "file" structure :-(

 

If you want avr-libc fprintf() and etc to work with FATfs files, you'll probably have to write an intermediate layer that links them together (carefully, to maintain any performance)   (although it looks like fatfs has its own functions: "f_printf()" and similar.)

 

(that's for AVRs and avr-libc.  If you're using ARM or UC32, stdio probably comes from newlib, and includes more "bloat" that might enable the same write functions to be used for UARTs and actual files...)