I'm going to use FatFS for the first time. Is there anything in particular I should be aware of?

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

I'm going to use FatFS for the very first time. (MCU = Atmega32A) Wish me luck :)

Is there anything in particular that you think I should know?

This topic has a solution.
Last Edited: Sat. Jul 10, 2021 - 02:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

It takes a fair amount of memory, both Flash and Ram.

 

One file open at a time unless you add special settings and that makes the memory foot print even larger.

 

Typically write only unless you add special settings which also increases the memory use.

 

There is a LOT of configuration stuff. It needs to be right. It is pretty well explained but you need to read the explanations over and over. Well, I had to!

 

I use on a Mega328P.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

I'm doing a hobby project to get familiar with AVR's different communication methods.

I haven't used the SPI interface till now (except ISP programming of course).

I'm trying to fill in the blanks in fatfs. Is it OK if I always return 1 for sdcard check If I never hotplug it?

I will keep posting pictures as I fill each blank and ask if guys think it's done right.

When the last blank is filled I will finally flash the .hex file and see if it works.

Attachment(s): 

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

Do not know anything about "hot plug".

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Does everything look OK so far?

Attachment(s): 

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

Uh, I meant not to unplug or plug the SD card whilst MCU is on.

 

Also, how would one check for the presence of sd card if they were to do so?

Last Edited: Fri. Jul 9, 2021 - 07:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mr0099 wrote:
Is there anything in particular that you think I should know?

Have you studied the documentation:

 

http://elm-chan.org/fsw/ff/00index_e.html - in particular, the 'Resources' section at the bottom of the page?

 

Have you looked at the Tutorials here:

 

https://www.avrfreaks.net/search/site/fatfs

 

and the many previous threads ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mr0099 wrote:
how would one check for the presence of sd card

Use a socket with a 'Card Present' feature - aka 'Card Detect' or similar ...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

mr0099 wrote:
Uh, I meant not to unplug or plug the SD card whilst MCU is on.
Eaisest solution to that is mechanical - don't let it happen! If you have a slide switch for on/off have it somehow slide to cover the SD slot opening or similar. Then they have to switch it off to change cards.

 

If you do want to try and support card swapping while on then you need an SD socket with "CP". Trouble is the general move to micoSD from original SD. The old, large sockets often had support for both WP and CP sensor switches but you generally don't get those in uSD sockets. So you will then want to use one of those "plastic carriers" that convert uSd to SD then use an old style socket with card present detector.

 

Of course even with CP all it means is that when your 100ms tick happens you can detect that the event has happened (if it switched from present to not present then the card has just been removed) but suppose that happened while you had a file open and the current sector buffer contents in the cache had not been flushed to the card? Then you may suffer damage to the logical structure of data on the card anyway. What you would really need is some kind of "removal is starting to happen - urgently ensure everything is closed and FAT structures are clean" before the SPI contacts break free.

 

As I say - some way of ensuring it can't be done while "on" is the safe approach. One way (if battery powered) would be to put access to the card slot under the battery !

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

Thanks for the advice :)

(I was actually defining hotplug-ing things as in saying the meaning of "hotplug")

But these are really great pieces of advice! There is going to be one prototype for some time at least and the end-user will be me :( but these would certainly come in handy sometime in the future.

I'm still struggling with the FatFS though and I think I might have to read the "long" post

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

mr0099 wrote:
I'm still struggling with the FatFS though and I think I might have to read the "long" post
The problem with FatFs to a certain extent is that it "moves on". Even during the time that the long post in Tutorial Forum was "active" it changed a few times so that thread tends to document how to adapt each new iteration as it appeared. Then they went and changed the AVR examples in ffexample.zip so that it more focussed on using the UART in SPI mode than the actual SPI itself. That's actually fine if you are using a "modern" AVR where the UARtT can do SPI because the UART actually does it "better" than the SPI itself (you can feed the bytes closer/quicker so card performance is improved a bit). The problem with mega32 is that it is an "old" megaAVR so you have to use the SPI. That means that if you download the "latest" FatFs the mms_avr.c example has a load of "add your code here" in the parts that support SPI whereas older versions of the file had actual example code (admittedly for atmega64 not atmega32 but I think it was largely compatible). So the usual suggestion is to pick up the latest ffexample.zip but then also work back through their archive and get older versions of ffexample.zip too until you find the latest one where mmc_avr.c has a "full examnple".

 

But when you say "I'm struggling" exactly what do you mean anyway?

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

clawson wrote:

But when you say "I'm struggling" exactly what do you mean anyway?

 

I tried editing mmc_avr_spi.c and then compiling the included main.c file. It complained about timer registers which I fixed.

However, it had a lot of extra things included and I couldn't get it to compile because of all the UART, RTC, etc which seemed to need adaptation to Atmega32A as well.

The way I prefer to learn FatFS ( or anything for that matter ) is to have a bare minimum working example and add other things to it as I go along with the project.

For fatfs that would be e.g. getting the list of files/directories and sending them over to UART (I have already worked out UART using Peter Fluery's library) just to see the output on my screen.

 

P.S. I kind of need a nap right now but will try to get a minimum working example built after that.

P.S #2 it seems that the compiler itself is suggesting the correct register names :| Maybe I first try the provided example when I wake (if it should work I will upload the relevant files here as well). I will keep you updated though.

Attachment(s): 

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

mr0099 wrote:
However, it had a lot of extra things included and I couldn't get it to compile because of all the UART, RTC,
Have a look in the ffexample directory:

D:\ffsamp_apr2021\avr>dir
 Volume in drive D is DATA
 Volume Serial Number is 1CF4-86D6

 Directory of D:\ffsamp_apr2021\avr

29/04/2021  13:31    <DIR>          .
29/04/2021  13:31    <DIR>          ..
17/04/2021  12:52               404 avrsp.ini
17/04/2021  12:52            17,688 avr_cfmm2.png
17/04/2021  12:52            14,631 cfc_avr.c
17/04/2021  12:52               761 cfc_avr.h
17/04/2021  12:52             4,368 diskio.c
17/04/2021  12:52             3,690 diskio.h
17/04/2021  12:52           253,954 ff.c
17/04/2021  12:52            16,109 ff.h
17/04/2021  12:52            12,390 ffconf.h
17/04/2021  12:52            94,599 ffunicode_avr.c
17/04/2021  12:52            21,755 main.c
17/04/2021  12:52             3,278 Makefile_cfc
17/04/2021  12:52             3,297 Makefile_cfmm
17/04/2021  12:52             3,267 Makefile_mmc
17/04/2021  12:52             3,250 Makefile_mmcbb
17/04/2021  12:52               767 mmc_avr.h
17/04/2021  12:52            16,005 mmc_avr_bb.c
17/04/2021  12:52            19,974 mmc_avr_spi.c
17/04/2021  12:52            20,492 mmc_avr_usart.c
17/04/2021  12:52               598 rtc.h
17/04/2021  12:52             5,204 rtc_ds1338.c
17/04/2021  12:52             7,500 sound.c
17/04/2021  12:52               562 sound.h
17/04/2021  12:52             1,801 tt.ini
17/04/2021  12:52             1,834 uart.c
17/04/2021  12:52               349 uart.h
17/04/2021  12:52             3,177 xitoa.h
17/04/2021  12:52             9,905 xitoa.S
              28 File(s)        541,609 bytes

Notice the Makefile_* files? They are "recipes" for building various variants of the code. As you are trying to use SD via the SPI interface the one that should interest you there is Makefile_mmc. If you look at that you will find:

D:\ffsamp_apr2021\avr>head Makefile_mmc
### Project name (also used for output file name)
PROJECT = avr_mmc

### Source files and search directory
CSRC    = main.c uart.c diskio.c mmc_avr_usart.c rtc_ds1338.c ff.c ffunicode_avr.c
ASRC    = xitoa.S
VPATH   =

### Target device
DEVICE  = atmega1284p
etc.

That "csrc=" line is kind of key. These are all the files you need to bring together to build a complete example. However you can tell from the inclusion of mmc_avr_usart.c (and the fact it's built for mega1248p) that this is an example that is using he SPI feature of USART (which mega32 does not have).

 

But anyway, apart from an mmc_*.c file (the lowl level, interface driver) the rest show you the files you need to build the example. 

 

Of course, if you study main.c you will find this is an extensive example built to give access to every feature that FF provides and that is driven by a UART interface (which is what uart.c is doing there). So you might want to cut out most of what they have in that 21K main.c file to make a "small working example".

 

Note also the inclusion of ffunicode.c. That is all about mapping "exotic" characters to printable characters when a non US/European language is being used. It is there because ffconf.h has:

D:\ffsamp_apr2021\avr>grep CODE_PAGE ffconf.h
#define FF_CODE_PAGE    932

when you explore that file further you find:

#define FF_CODE_PAGE    932
/* This option specifies the OEM code page to be used on the target system.
/  Incorrect code page setting can cause a file open failure.
/
/   437 - U.S.
/   720 - Arabic
/   737 - Greek
/   771 - KBL
/   775 - Baltic
/   850 - Latin 1
/   852 - Latin 2
/   855 - Cyrillic
/   857 - Turkish
/   860 - Portuguese
/   861 - Icelandic
/   862 - Hebrew
/   863 - Canadian French
/   864 - Arabic
/   865 - Nordic
/   866 - Russian
/   869 - Greek 2
/   932 - Japanese (DBCS)
/   936 - Simplified Chinese (DBCS)
/   949 - Korean (DBCS)
/   950 - Traditional Chinese (DBCS)
/     0 - Include all code pages above and configured by f_setcp()
*/

so 932 is Japanese and the letters DBCS are short for Double Byte Character Set (posh name for "Unicode") so it's because FF has been configured for Japanese (well E L Chan, the author is Japanese after all!) that it then needs ffunicode.c to be in the  build to provide code page mapping tables. So one of the first steps, apart from stripping main.c to "bare minimums" is to make sure that not only FF_CODE_PAGE in ffconf.h but every other setting in that file is set to something sensible for your use. Then you will be able to drop the requirement for ffunicode.c in the build.

 

Of course, another approach, would be not to take ffexample.zip and "strip it back" but to take fatfs.zip (just the core files) and then "build it up".

 

But either way you do have to do a bit of work (which in part relies on understanding some of the configuration) to build a system and file set that has everything you want (and nothing else!)

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

Hey again. Trying to get their example to work, I looked at different Makefile_* and chose one that didn't have mmc_avr_usart.c which was Makefile_cfc, I ported register names and modified ffconfig.h to be the most minimal option.

I ended up commenting nearly every case of the switch in main.c still the generated code size is so high that can't fit into an atmega32a.

ffconfig.h :

#define FF_FS_MINIMIZE	3
/* This option defines minimization level to remove some basic API functions.
/
/   0: Basic functions are fully enabled.
/   1: f_stat(), f_getfree(), f_unlink(), f_mkdir(), f_truncate() and f_rename()
/      are removed.
/   2: f_opendir(), f_readdir() and f_closedir() are removed in addition to 1.
/   3: f_lseek() function is removed in addition to 2. */

immortal@Infinity:~/Documents/AVR_Projects/Libraries/fatfs-ffsample/avr $ ls -ltrh obj_cfc/
total 928K
-rw-r--r-- 1 immortal immortal 8.4K Jul  9 19:03 xitoa.o
-rw-r--r-- 1 immortal immortal  117 Jul  9 19:03 main.d
-rw-r--r-- 1 immortal immortal  32K Jul  9 19:03 main.o
-rw-r--r-- 1 immortal immortal 9.0K Jul  9 19:03 uart.o
-rw-r--r-- 1 immortal immortal   38 Jul  9 19:03 uart.d
-rw-r--r-- 1 immortal immortal 8.7K Jul  9 19:03 diskio.o
-rw-r--r-- 1 immortal immortal   97 Jul  9 19:03 diskio.d
-rw-r--r-- 1 immortal immortal   99 Jul  9 19:03 cfc_avr.d
-rw-r--r-- 1 immortal immortal  29K Jul  9 19:03 cfc_avr.o
-rw-r--r-- 1 immortal immortal   48 Jul  9 19:03 rtc_ds1338.d
-rw-r--r-- 1 immortal immortal  23K Jul  9 19:03 rtc_ds1338.o
-rw-r--r-- 1 immortal immortal   68 Jul  9 19:03 ff.d
-rw-r--r-- 1 immortal immortal 145K Jul  9 19:03 ff.o
-rw-r--r-- 1 immortal immortal   71 Jul  9 19:03 ffunicode_avr.d
-rw-r--r-- 1 immortal immortal 1.8K Jul  9 19:03 ffunicode_avr.o
-rw-r--r-- 1 immortal immortal  37K Jul  9 19:03 avr_cfc.map
-rwxr-xr-x 1 immortal immortal 122K Jul  9 19:03 avr_cfc.elf
-rw-r--r-- 1 immortal immortal  47K Jul  9 19:03 avr_cfc.hex
-rw-r--r-- 1 immortal immortal 404K Jul  9 19:03 avr_cfc.lst
-rw-r--r-- 1 immortal immortal 4.9K Jul  9 19:03 avr_cfc.sym
immortal@Infinity:~/Documents/AVR_Projects/Libraries/fatfs-ffsample

 

so, I think stripping down might be a dead end!

If I want to build up as you call it which files do I need besides the ffconfig.h ff.h ff.c?

Can I find the previous fully implemented versions of mmc_avr* and use that?

P.S. I think of only one use case for writing into the memory card (get schedules from UART and write a schedules.conf to SD containing time and output pins for automated activation or deactivation of those pins). Maybe I need to give up on that and use PetitFS?

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1



If I want to build up as you call it which files do I need besides the ffconfig.h ff.h ff.c?

Well see what you actually get in ff.zip rather than ffsample.zip. It's basically:

 

 

So those files in "source" are basically the "core" (and as mentioned above you can avoid ffunicode.c - also ffsystem.c is only about interface to OS functions which does not apply to micro).

 

So it's basically just diskio.*, ff.*, ffconf.h. Then to that you need to add a "hardware" driver to satisfy the requirements of diskio.c which are basically:

D:\ffsamp_apr2021\avr>grep mmc_ diskio.c
#include "mmc_avr.h"    /* Header file of existing SD control module */
                return mmc_disk_status();
                return mmc_disk_initialize();
                return mmc_disk_read(buff, sector, count);
                return mmc_disk_write(buff, sector, count);
                return mmc_disk_ioctl(cmd, buff);
        mmc_disk_timerproc();

D:\ffsamp_apr2021\avr>

Those are the functions that will be implemented by either mmc_avr.c (SPI), mmc_avr_usart.c (SPI using USART) or mmc_avr_bb.c (bit-bang SPI using general IO pins).

mr0099 wrote:
Can I find the previous fully implemented versions of mmc_avr* and use that?
Exactly what I was suggesting above. The way I have used in the past is the "Internet Archive":

 

https://web.archive.org/web/*/ht...

 

If I just pick a date at random like 2017 then I can access something like:

 

https://web.archive.org/web/2017...

 

However if you download that one and look at mmc_avr_spi.c you will just find a lot of "to be filled"so this post-dates the point where there used to be full working code.

 

So maybe try 2014-2015:

 

https://web.archive.org/web/2014...

 

BINGO - the mmc_avr.c (note it's not mmc_avr_spi.c !) in that does seem to have a complete code implementation.

 

Now there might be a "better" version between 2014 and 2017 on the internet archive - so you might want to spend a bit of time looking at snapshots but otherwise just go with that 2014 copy.

 

So you should be able to put together a system with:

 

diskio.h

diskio.c

ff.h

ff.c

ffconf.h

mmc_avr.c

 

but bear in mind a few things:

 

1) the mmc_avr.c code is for mega64 not mega32 so consider if that matters or are their SPIs identical

 

2) that file is assuming a socket that has CP and WP switches:

#define MMC_CD		(!(PINB & 0x10))	/* Card detected.   yes:true, no:false, default:true */
#define MMC_WP		(PINB & 0x20)		/* Write protected. yes:true, no:false, default:false */

and:

void disk_timerproc (void)
{
	BYTE n, s;


	n = Timer1;				/* 100Hz decrement timer */
	if (n) Timer1 = --n;
	n = Timer2;
	if (n) Timer2 = --n;

	s = Stat;

	if (MMC_WP)				/* Write protected */
		s |= STA_PROTECT;
	else					/* Write enabled */
		s &= ~STA_PROTECT;

	if (MMC_CD)				/* Card inserted */
		s &= ~STA_NODISK;
	else					/* Socket empty */
		s |= (STA_NODISK | STA_NOINIT);

	Stat = s;				/* Update MMC status */
}

if your socket does not have support for those then you need to modify the logic in disk_timerproc so that it behaves as if CardPresent/CardDetect is always true and WriteProtect is always false.

 

3) it is making some assumptions about the wiring. The very fact that MMC_CD is testing bit 4 in PINB and MMC_WP is testing bit 5 may need to be changed if you have those but to other IO pins.

 

4) similarly it's doing stuff like:

static
void power_on (void)
{
	{	/* Remove this block if no socket power control */
		PORTE &= ~_BV(7);	/* Socket power on (PE7=low) */
		DDRE |= _BV(7);
		for (Timer1 = 2; Timer1; );	/* Wait for 20ms */
	}

that's assuming PORTE bit 7 is switching some trasistor that provides power to the SD/MMC. If you don't have that you have to do what it says and remove such blocks

 

5) Code like this:

	PORTB |= 0b00000101;	/* Configure SCK/MOSI/CS as output */
	DDRB  |= 0b00000111;

thinks it knows what pins the SPI MOSI/MISO/SCK/SS are on - if different the bits here have to change

 

6) this code:

	SPCR = 0x52;			/* Enable SPI function in mode 0 */

is actually a bit "naughty". Above this in the file they define:

#define	FCLK_SLOW()	SPCR = 0x52		/* Set slow clock (F_CPU / 64) */
#define	FCLK_FAST()	SPCR = 0x50		/* Set fast clock (F_CPU / 2) */

but then hard code a write of 0x52 without using the macro!

 

7) also the whole point of FCLK_SLOW()/FCLK_FAST() is that when the dialog with an SD/MMC first starts the standard says you can only clock it slowly until it has initialised and you have identified it can operate faster. The clock divisors in the 0x52 and 0x50 values (as the comments say) are /64 and /2. While, when you go "fast" you probably want to go "as fast as possible" it will depend on your F_CPU the value 0x52 may not actually slow it down enough! In their Makefile_mmc 9from the 2014 files) it says:

### Target device
DEVICE  = atmega64

### Optimization level (0, 1, 2, 3, 4 or s)
OPTIMIZE = s

### C Standard level (c89, gnu89, c99 or gnu99)
CSTD = gnu89

### Include dirs, library dirs and definitions
LIBS	=
LIBDIRS	=
INCDIRS	=
DEFS	= F_CPU=11059200 MEDIA=\"MMC\"
ADEFS	=

that reiterates that it is built for mega64 but the DEFS include setting F_CPU to 11.0592MHz - maybe your AVR is clocked faster so the SPI *might* have to be set slower during the slow startup phase.

 

On and for the record the .zip file included:

 

 

that again reiterates things like "atmega64", 11.0592MHz, CD/WP on PB4/PB5, power control on PE7 through that Q1 transistor.

 

You need to consider how anything in your wiring differs from this expected pattern.

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

Update:

It seems I'm very close to getting FatFS to work thanks to clawson.

I'm trying to make a very simple program with it and share it here when it is working.

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

Finally!!! It seems I have done something. (Though I'm not 100% sure it's the final thing to go with )

The program runs fine in simulation.

In real MCU it gets stuck in device initialization.

I'm not sure why that happens I think my SD card might be at fault. At the moment, I don't have MicroSD to USB to reformat the device or fsck it :(

I will upload the project zip file here.

(It would be super nice if someone here could try the project to see if they get the same results in real MCU as well( that is stuck in device initialization). Because if that's the case then I've most likely done something wrong)

Please be kind enough to take a quick look at main.c and if you spot any silly mistakes that might've caused the situation let me know so I can fix it because others will probably use this too... (after all it is my First time trying this :) )

 

Also, It seems that the generated .hex file's size I was referring to in earlier posts is not the amount that gets written to flash :|

What gets written to flash when I flash the .hex file in my case is roughly the same size as the .bin file.

 

Remember to use appropriate CLOCK and fuse bits if you happen to want to try this out :)

P.S. The reason It took me too long after I said I was nearly done is that I mis-saw the datasheet (I was off by a bit -- pun intended :) ) and was setting or clearing the wrong bits :|

 

[Update: fixed a bug where the last buffer-sized chunk of the file would infinitely get sent to uart; removed unnecessary commented debug uart echoes]

Attachment(s): 

Last Edited: Sun. Jul 11, 2021 - 10:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

mr0099 wrote:
At the moment, I don't have MicroSD to USB to reformat the device or fsck it :(
A notebook PC may have a SD socket in a side slot; Chromebooks typically have a microSD socket.

SD Memory Card Formatter | SD Association due to FatFs and disk removal | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

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

Yes, it does. but it is a full-sized SD and requires an adapter I don't have :(

I do have a MicroSD to USB I just don't know where it is and might have to search for a while to find it.

 

P.S. what did you think of the code or picures/* in general?

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

mr0099 wrote:
Yes, it does. but it is a full-sized SD ...
Likewise (HP Elitebook, early '15, AMD); IIRC, went to a Micro Center to purchase a SD (not microSD).

mr0099 wrote:
... and requires an adapter I don't have :(
Camera shops should have SD adapters; drug store/pharmacy?

Well, it's most likely microSD with an adapter.

mr0099 wrote:
... a MicroSD to USB ...
Some desktop PC have that as an option (card reader)

mr0099 wrote:
P.S. what did you think of the code ...
Flies over my head.

Reasons :

  • am more likely to reuse file systems that are in RTOS or a few frameworks
  • bail by a data path to an OS

mr0099 wrote:
... or picures/* in general?
indecision

 


Micro Center - Computers and Electronic Device Retailer

 

ASF-FS | ASF Source Code Documentation

https://github.com/Microchip-MPLAB-Harmony/core_apps_pic32mz_da/tree/master/apps/fs

Summary | GitHub - chilipeppr/serial-port-json-server: ...

Efficient web server technology for resource-constrained microcontrollers - Embedded.com (WebSocket server)

 

"Dare to be naïve." - Buckminster Fuller

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

I have a USB card reader (several, actually) that take maybe 6 or 8 different cards. One even has separate slots for SD and microSD. They cost me under 15USD at a university book store. Other office stores (Staples, OfficeMax, etc) usually have them.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Hello.
I got referred to this thread by awneil
A little detail i want to point out is your fuse settings are set to DEFAULT which results (in my case) of enabling CLK_DIV8 aka divide clock by 8 and the SUT_CKSEL set to unknown value.
Just wanted to point it out, i am facing kind of the same issue as you are. 

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

Decee1 wrote:
i am facing kind of the same issue 

Here: https://www.avrfreaks.net/forum/looking-example-andor-help-fatfs

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...