 |
| Author |
Message |
|
|
Posted: Apr 26, 2010 - 09:25 AM |
|


Joined: Jul 18, 2005
Posts: 62230
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
You need to completely replace diskio.c as those registers named in your errors are the AVR8's names for the SPI control and data registers and control bits.
BTW this is an AVR8 forum so your post is slightly off-topic here. I cannot help thinking that other AVR32 users must already have used FatFs so you might want to search the AVR32 fora for mentions of FatFs
EDIT: there are 5 such threads - a couple of them look very interesting. |
_________________
|
| |
|
|
|
|
|
Posted: Apr 26, 2010 - 02:26 PM |
|

Joined: Apr 07, 2010
Posts: 6
|
|
| Ah thanks for the heads up... I didn't see a tutorial sub-forum in the AVR32 forums so I just assumed that this one was a conglomeration. Thanks! |
|
|
| |
|
|
|
|
|
Posted: May 29, 2010 - 05:49 PM |
|

Joined: Jun 02, 2009
Posts: 15
|
|
Thanks for a great tutorial. Between this one and kubark42's most of the heavy lifting is done for us. I'm implementing the FAT file system on the ATMEGA644P and things are going fairly well so far. I do have a couple of questions, though. In the function descriptions (online, sfileinfo.html), the disk_initialize() function has the statement "Application program should not call this function, or FAT structure on the volume can be collapsed. To re-initialize the file system, use f_mount function." This implies that you should just do an f_mount() to initialize. However looking through the f_mount() code it appears that disk_initialize is never referenced, and casual experimentation indicates that calling disk_initialize() after f_mount() has no obvious ill effect. Anybody have any experience pro or con?
Also, I plan to open and append to existing files, and I assume the best way to find the end of the file is to do an f_stat() call and use FILINFO.fsize value in an f_lseek() command. Anybody used this, or found a better way? If memory serves, DOS had an f_seek(END) type call to go right to the end.
Finally, I'd like to mention some problems with power control- I'm using a FET switch under program control since my application is battery powered. The switch works fine but the 'switched' side (power pin of the card) stays high when the switch is off, I believe because of backfeed through the SPI pins. I can't really pull these pins low when the card is off because I need to talk to the RTC and other SPI devices while running. Has this issue been encountered and addressed by anyone? I guess I could put switches on the SPI lines to the card but that seems a bit excessive in terms of cost & real estate. It may be a non-issue since I don't think the card is really consuming any significant power while the switch is off, but on the other hand the power pin IS at 3.3V.
I apologize for the long post, and thanks again for a super tutorial.
Thanks,
Harry |
|
|
| |
|
|
|
|
|
Posted: May 29, 2010 - 09:44 PM |
|

Joined: May 27, 2008
Posts: 41
|
|
disk_initialize() will get called as apropriate when you do somthing that realy needs to access the card you do not need to do it yourself. FILINFO.fsize will get filled in when you do f_open so no need for the f_stat just f_open then f_lseek.
Not sure about the power side of things but it may well be card dependent. With my system mostly used for loging so mainly writing so long as I finish up by closeing my files the card looks to go low power. Straight after a read the card I am using can be using an anoying amount of power. |
|
|
| |
|
|
|
|
|
|
|