FatFS + mega328p

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

Hi,

 

I would like to write data to the files on the SD card by mega328p. I read about FatFS and Petit FatFS library, that these libraries are written specially for this purpose. I started with Petit FatFS library, because it has a less memory than FatFS and I thought that it would be enough for mega328p. I found an example dedicated to mega328p, run, and I realized that by Petit FatFS library I cannot create a file. This feature is really important for my project, so I would like to find the example of project implementation with FatFS library for mega328p on Atmel Studio 7.0, beacuse I cannot rewrite basic example for avr from FatFS library website. Has anyone some working examples for mega328p?

Last Edited: Wed. Aug 28, 2019 - 10:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look at the long thread in the tutorial forum as I've shown how to use it for 328 before now.

 

Having said that these days ffexample.zip comes with a USART-SPI driver that should be easily adaptable to 328 anyway.

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

Could you give the link for this thread?

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

The search engine here says https://www.avrfreaks.net/forum/...

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

I downloaded your project solution zip ffsamp-jun22.zip, I changed SPI pins for mega328p and and it doesn't work. The UART doesn't display anything.

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

It takes a bit of work. How far through the f_mount does it get. Specifically how far through the disk_initialize called from that does it get?

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

I haven't got a debugger, so I can't check it.

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

B0nkers wrote:
I haven't got a debugger,

An essential tool for serious programming/debugging.....   What "tools" do you have?   Logic Analyzer? Scope? LED? TTL-serial/USB interface? 

Let us know your tool set and we can make suggestions.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

I work on the Arduino board, so I only have a USB port com cable.

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

Flash an LED or, if you have the technology, output progress messages to LCD or UART. But with something as complex as FatFs don't just treat it as a black box and expect that is bound to work.
.
Of course if you used Petite previously and that could read a file then that has proven SOME of the hardware though bit bang GPIO and real SPI (or rather UART-SPI) are obviously a bit different!

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

Ok, so add some Serial.Println("I'm now here-function name"); function calls in each function so you can follow the trail of bread crumbs to where it gets stuck.

Use the Tools/Serial Monitor to watch this output.

You may have to first add a Serial.begin(115200); in setup() to get this to work.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

B0nkers wrote:

I downloaded your project solution zip ffsamp-jun22.zip, I changed SPI pins for mega328p and and it doesn't work. The UART doesn't display anything.


I'm on a phone so can't easily check that Zip but are you SURE the complete driver in the AVR directory of ffsamp is for SPI and not UART-SPI? I'm 99.9% certain it's for the latter (actually better performance than plain SPI!). I think the plain SPI driver currently shipped is incomplete (the source file has loads of "complete this bit with your solution" sections). The UART-SPI code is (AFAIK) complete.
.
Some of what I've written previously in the long tutorial thread has been how to take the SPI driver out of an older issue of ffsamp and use it in later releases if it is SPI and not UART-SPI you want to use.
.
I'll be back near a PC tomorrow so will check what the latest issue contains.
.
(and, yes, it has always struck me as odd that they used to supply a complete SPI driver then later removed it to give UART-SPI as the only working alternative)

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

clawson wrote:

UART-SPI as the only working alternative

that will make getting it to work on an Arduino a bit difficult, unless they use an Arduino with more then one serial USART.

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

Ah tricky. I missed the post that said Arduino. But if it's an Arduino then the Arduino libs have their own full working FAT SD/MMC implementation. Not a huge amount of point in reinventing wheels.

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

Since you work on an Arduino board (a UNO, Nano, or Pro Mini), use the SD library that is included with Arduino distribution.  Limor Fried wrote it, and she allows the Arduino community to use it.  So it works better and easier than anything else that you are going to find for a raw Mega328P. 

 

Even I can get SD card access when I use this library.   Get your project/product working first with tested/debugged Arduino code,  then study the library code in order to get an overview of what is actually happening under the hood.

 

You don't need a debugger if you're not working with other people's buggy code, like PetitDOS or whatever...

Last Edited: Wed. Aug 28, 2019 - 02:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I went to the FatFs site and the latest ffsample.zpi there is actually dated October 2018 and many of the files in the AVR sub-directory have a 14th Oct 2018 date on them.

 

So there are a number of Makefiles to build project variants in that though just a couple for SD/MMC:

 

Makefile_mmc uses mmc_avr_usart.c as the SPI driver

Makefile_mmccbb uses mmc_bb.c as a bit-bang driver

 

There are three MMC driver files:

 

mmc_avr_usart.c - uses SPI function of USART for those chips where the UART can do SPI - it seems pretty complete.

 

mmc_avr_spi.c - this is the old SPI driver but it's now full of stuff like:

/* Peripheral controls (Platform dependent) */
#define CS_LOW()		To be filled	/* Set MMC_CS = low */
#define	CS_HIGH()		To be filled	/* Set MMC_CS = high */
#define MMC_CD			To be filled	/* Test if card detected.   yes:true, no:false, default:true */
#define MMC_WP			To be filled	/* Test if write protected. yes:true, no:false, default:false */
#define	FCLK_SLOW()		To be filled	/* Set SPI clock for initialization (100-400kHz) */
#define	FCLK_FAST()		To be filled	/* Set SPI clock for read/write (20MHz max) */
static
void power_on (void)
{
	/* Trun socket power on and wait for 10ms+ (nothing to do if no power controls) */
	To be filled


	/* Configure MOSI/MISO/SCLK/CS pins */
	To be filled


	/* Enable SPI module in SPI mode 0 */
	To be filled
}

the old version of this file used to have a specific implementation which was (I think) a much better guide to how to port things - with this you don't really know what you are supposed to put in the "To be filled" sections

 

mmc_avr_bb.c - this is a "bit-bang" driver to use any GPIO. Once again it has some "To be filled" sections:

#define	CS_H()	To be filled	/* Set MMC_CS "high" */
#define CS_L()	To be filled	/* Set MMC_CS "low" */
#define CK_H()	To be filled	/* Set MMC_SCLK "high" */
#define	CK_L()	To be filled	/* Set MMC_SCLK "low" */
#define DI_H()	To be filled	/* Set MMC_DI "high" */
#define DI_L()	To be filled	/* Set MMC_DI "low" */
#define DO	To be filled	/* Test for MMC_DO ('H':true, 'L':false) */

static
void dly_us (UINT n)
{
	/* Delay n microseconds */
	To be filled
}

static
void init_port (void)
{
	/* Initialize the GPIO port MMC attached (CS=High, SCLK=Low, DI=High, DO=In/pullup) */
	To be filled
}

this is possibly a little bit more manageable than the SPI file as it's mainly just those macros and they are just going to be of the form "PORTx |= (1 << bit)" and "PORTx &= ~(1 << bit)"

 

It is a bit of a shame that in the old days the SPI file used to be for a specific AVR (mega128 I think it was) but it showed a complete implementation so for another micro you just needed to know the equivalent (and most AVRs call their SPI registers SPCR, SPDR, SPSR anyway). Equally I think the "bit bang" driver would be better if it were an implementation for specific pins on a specific AVR as it would be clearer how to "port" it.

 

So bottom line - if you pick up a "modern" ffsamp.zip then the only driver that is "complete" is the mmc_avr_sart.c one. For the others you have to complete the implementation.

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

Ok, so first of all I want move my project from Arduino Ide to AVR-C and I don't want to use any Arduino libraries, because these libraries are incompatible with AVR-C language. I wrote code on Arduino earlier and everything works properly.

Moreover I debug the code from ffsamp-jun22.zip: change the device project to mega328p, change Timer references and add own library to usart. The usart start display "res" value continuosly (i don' t why this happend, i didn't insert printf statements in loops) and i tested device initializion and opening a file. It seems like this statements works, because res value was equal to 0.

So maybe the best solution is keep still changing the example code from the FatFs website. Thank you clawson for explanation of parts of the example i will try to fill up this.

Last Edited: Wed. Aug 28, 2019 - 11:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

B0nkers wrote:
because these libraries are incompatible with AVR-C language.
Err no - the only difference is that they are C++ not C. But As7 has exactly the same C++ compiler as Arduino anyway. So nothing stops you using the Arduino library code in AS7.

 

The issue you still have if going the standalone FatFs route is just as I outlined above. ffsamp only has (complete!) code for USART-SPI at present but on an Arduino board the USART is already tied up to a connection to the bootloader. So the Tx/RX pins the USART-SPI would use to connect to the SD/MMC are already connected to the USB-UART chip.

 

So you need to use bit bang or real SPI and for either of those you are gong to have to supply the "To be filled" sections of code.

 

Now in previous threads I have posted the old version of mmc_avr_spi.c - the one with the complete implementation. The "easy" solution may simply to be to track that down.

 

Rather sadly on the fatFs site there is a link to "previous versions" but that only has archived copies of fatafs.zip and petite.zip but it does not have old versions of ffsample.zip. So then I tried the internet archive but it does not appear to have snapshots of older versions of the FatFs website.

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

Ah ha - the internet archive does have SOME snapshots of the ffample.zip (though most just say "forbidden") but I found one in 2014 and the mmc_avr.c (not mmc_avr_spi.c) it contains was the attached. So try this.

 

The code is actually for an atmega64 but I think most should be OK for mega328P too.

 

Attachment(s): 

Last Edited: Wed. Aug 28, 2019 - 11:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found a project which uses mega328p, gps module and FatFS library from this website http://elm-chan.org/works/glg2/report_e.html.

 

And I have a question to this and FatFS library. Does the use of timers mandatory for this library to work efficiently?

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

B0nkers wrote:
Does the use of timers mandatory for this library to work efficiently?
Yes there must be a 100Hz (10ms) timer to call back to disk_timerproc() as this lets the disk reading system operate several timeout counters.

 

In the files you linked to there is a cut-down version of this:

/*---------------------------------------------------------*/
/* 100Hz timer interrupt generated by OC1A                 */
/*---------------------------------------------------------*/


ISR(TIMER1_COMPA_vect)
{
	BYTE n;


	n = Timer;
	if (n) Timer = --n;;
	n = MmcTmr[0];
	if (n) MmcTmr[0] = --n;;
	n = MmcTmr[1];
	if (n) MmcTmr[1] = --n;;

I don't think you need anything else in the timer interrupt beyond that but - those MmcTmr[] are required because the mmc.c stuff uses them such as:

static int rcvr_datablock (
	BYTE *buff,			/* Data buffer to store received data */
	UINT btr			/* Byte count (must be even number) */
)
{
	BYTE token;


	MmcTmr[0] = 10;
	do {							/* Wait for data packet in timeout of 100ms */
		token = rcvr_spi();
	} while ((token == 0xFF) && MmcTmr[0]);

etc.

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

Ok, so everything I should do is set up a Timer and then everything will be work?

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

B0nkers wrote:
then everything will be work?
Not necessarily: FAT + SPI + SD/MMC is a complex system - if you are lucky it may all work straight off - if not you need some kind of debug channel to find out why not. FatFs is very good at returning error codes to aid you in understanding why any part of it may not be operational. So don't just call functions without using the return values and (hopefully) verifying that it's always FR_OK.

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

Ok, so after a short break, I have done rewrite this code. I've used an example from FatFS library of opening a file. I have debugged this by UART, testing mounting and opening a file. The mounting was ok, the function returned 0, but if I wanted open a file, the UART didn't respond. In attachment I send my actual project.

Attachment(s):