Petit FatFs limitation?

Go To Last Post
92 posts / 0 new

Pages

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

Great, I will try the update attachment this evening?

As this is boot loader related ...

I am downloading a hex file via the Ethernet IC, so using TCP/IP I can insure that data received will be correct, this is all done in application area of the flash.

But how can Insure what I am writing is correct?

Only thing I can think of is reading back what has been written to confirm.

Then when I get into boot loader mode, I presume I just read what been written and compare it to the data from the file I have just read?

DJ

Thanks

Regards

DJ

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

Quote:

But how can Insure what I am writing is correct?

Only thing I can think of is reading back what has been written to confirm.


CRC.

You have read the bootloader FAQ in Tutorial Forum haven't you?

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

millwood wrote:
Quote:
Millwood - Any chance you'll post your SPI library?

absolutely.

Uh... when and where?

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

LOL, Smiley--I'll post the complete CodeVision SPI library guts, even though copyrighted. (There is some other stuff foe Xmega and include files and the like, but the entire SPI.LIB boils down to the below.)

/*
  CodeVisionAVR V2.04.5 C Compiler
  (C) 1998-2009 Pavel Haiduc, HP InfoTech S.R.L.

  SPI access function
*/
... Xmega stuff, optimization level check, other baggage...
unsigned char spi(unsigned char data)
{
SPDR=data;
while ((SPSR & (1<<SPIF))==0);
return SPDR;
}

In dozens of production apps, I just use spi(). In a couple of apps with multi-byte transfers, I roll-my-own to fetch/store the next/previous byte before doing the wait, to interleave those cycles and eliminate the function call overhead. But for general work, e.g. a couple byte transfer to a DAC every few milliseconds, spi() works just fine.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
I did say it was completely untested
There, there, Clifford. Don't beat yourself too much, it would have worked if it wasn't for the wrong register and parenthesis :) this makes you almost human. You are no longer just an automated typing machine. #5 is alive!

The init was correct. I only changed it to slow the SPI down during my attempts to get it working, but it's interesting that the SPI can run at full speed even at 16MHz with the SD card.

//#define	INIT_SPI()	{ USICR = 0b00011000; }		// Initialize SPI port 
//#define INIT_SPI()	{ SPCR = 0b01010000; }		// this "borrowed" from mmc.c in FF

//#define INIT_SPI()	{ SPCR = ( 1<<SPE | 1<<MSTR | 1<<SPR1 | 1<<SPR0); } //Slower
//#define INIT_SPI()	{ SPCR = ( 1<<SPE | 1<<MSTR | 1<<SPR1); }	//Medium speed
#define INIT_SPI()	{ SPCR = ( 1<<SPE | 1<<MSTR ); }	//Fastest 

Also the port pin for the SS changed to match the M64

// Port Controls (Platform dependent)
#define SELECT()	PORTB &= ~0x08		// MMC CS = L
#define	DESELECT()	PORTB |=  0x08		// MMC CS = H
#define	MMC_SEL		!(PORTB &  0x08)	// MMC CS status (true:selected)
*/

#define SELECT()	PORTB &= ~0x01		// MMC CS = L
#define	DESELECT()	PORTB |=  0x01		// MMC CS = H
#define	MMC_SEL		!(PORTB &  0x01)	// MMC CS status (true:selected)

I think spi.c did not change but for the small details above

#include 
#include "pff.h"

BYTE xmit_spi(BYTE c) {
	SPDR = c;
	while (!(SPSR & (1<<SPIF)));
	return SPDR;
}

//-----------------------------------------------------------------------
// Receive a byte from MMC via SPI  (Platform dependent)                 
//-----------------------------------------------------------------------

BYTE rcv_spi(void) {
	return xmit_spi(0xFF);
}

and the PORTB init changed to suit the M64

/*
	PORTB = 0b101011;		// u z H L H u
	DDRB =  0b001110;
*/

//Modified to run on Ampertronics CONT-3 With M64 at 16MHz
	PORTB = 0b00000001;		// SS high
	DDRB =  0b00000111;		// !SS,SCK and MOSI outputs

//Modified to use USART0 pins
	PORTE = 0xff;			// all pullup
	DDRE =  0b00000010;		// PE0 outputs

..excuse the magic numbers...

I think smiley is being a bit sarcastic. I know, I know who would believe that someone with such an innocent, almost angelic look in his face could hide a bit of sarcasm... :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:
again, a piece of code that is not portable is a piece of shit.
Tell it to the author Mr Chan. You are really a TWIT talking out of your bum and do not know what you are talking about!!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Lee, no no no! I want to see Millwoods SPI code.

I can wait to see your SPI in the AVR version of Petit FatFS that you and Cliff are working on.

Smiley

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

Quote:
when people are too stupid to attack the ideas,
100% correct deadwood! You attacked ME for someone else' code.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Deadwood,

How is it that this board functions well when you are not here and soon as you come back with your school boy arrogance it deteriorates? I know your only a child but can you TRY to think like an adult in future before you post?

Moderator.

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

millwood wrote:
Quote:
// Port Controls (Platform dependent)
#define SELECT() PORTB &= ~0x08 // MMC CS = L
#define DESELECT() PORTB |= 0x08 // MMC CS = H
#define MMC_SEL !(PORTB & 0x08) // MMC CS status (true:selected)
*/

that's really a poor way of coding it.

what will happen if you move the _cs pin to a different port, or a different pin? think about how many changes you would have done to the code for it to work?

instead, you could have written your code to operate, for example, SPI_CS / SPI_SDO / SPI_SCK / SPI_SDI pins on SPI_PORT. after that, you know with confidence that your code will work on other chips / platforms.

again, a piece of code that is not portable is a piece of shit.

That code is a whole lot more portable than a lot I've seen(and written, for that matter). How many changes would you need to make if the /CS pin moved to a different pin or port? Three lines of code by my reckoning. Code portability is, for the most part, a red herring. It's a fact that 94% of code NEVER gets ported anywhere.

Four legs good, two legs bad, three legs stable.

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

Hi All

I have downloaded the most recent project file.

I am not successfully passing the “disk_initialize()”

I am failing in function “disk_writep()”, when it calls ” xmit_spi(0xFE);”

I am using a 11.0592Mhz

My pin out is as follows
PC7-SCK
PC6-MISO
PC5-MOSI
PC4-SS

Regards

DJ

Thanks

Regards

DJ

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

Do you have a scope. Do you see the right kind of activity on SCK and MOSI (and perhaps even MISO)?

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

No I dont have a scope, but I can confirm that the PCB hardware is working, I have tested this with FATFS.

What else must I change to tailor the project file to my design.

Thanks

Regards

DJ

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

Just out of interest what capacity SD cards are you trying to use?

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

2Gig

Thanks

Regards

DJ

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

I have tested the code both with 2G and 4G cards. Just built another SD interface card so that I can use it with the STK500 and smaller chips.

edit are you still using the M1284? Have you changed the pins for the SPI? They are on different pins than the M64.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

What else must I change to tailor the project file to my design.

What have you written for that function?
How have you configured the SPI?
Is /SS an output?

(or are you still on the Tiny85 version?)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I have set my Chip select but where do I configure the MOSI,MOSO and CLK

This is my main()

int main (void)
{	BYTE res;
	FATFS fs;			/* File system object */
	WORD s1;
	
	pin_set();
//Modified to run on Ampertronics CONT-3 With M64 at 16MHz
	PORTB = 0b00011000;		// SS high
	DDRB =  0b10111010;		// !SS,SCK and MOSI outputs	

	
	des = disk_initialize();
	as=pf_mount(&fs);
	pf_open("GUI.pdb");
	res = pf_read(Line, sizeof(Line), &s1);
	while(1)
	{
	}
}

Thanks

Regards

DJ

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

You also need to change this

// Port Controls (Platform dependent) 
#define SELECT()   PORTB &= ~0x08      // MMC CS = L 
#define   DESELECT()   PORTB |=  0x08      // MMC CS = H 
#define   MMC_SEL      !(PORTB &  0x08)   // MMC CS status (true:selected) 
*/ 

#define SELECT()   PORTB &= ~0x01      // MMC CS = L 
#define   DESELECT()   PORTB |=  0x01      // MMC CS = H 
#define   MMC_SEL      !(PORTB &  0x01)   // MMC CS status (true:selected) 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I have

#define SELECT()	PORTB &= ~(1<<4);		// MMC CS = L
#define	DESELECT()	PORTB |=  (1<<4);		// MMC CS = H
#define	MMC_SEL		!(PORTB & (1<<4))	// MMC CS status (true:selected)

What is MMC_SEL?

By the way I do not have any card insert signal connected to the AVR, is there a card insert being checked anywhere?

DJ

Thanks

Regards

DJ

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

Quote:
I do not have any card insert signal connected to the AVR, is there a card insert being checked anywhere?
Not with the petit fat.

MMC_SEL is being tested down the file in the disk_initialize function and waits for a write to be finalised if in progress.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:
I would say that professionally
Professionally?? Really after 6 months out of school? So you are really LYING about who you say you are?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Got it working, but will test it properly tommrow.

Went into the setting of AVR studio and changed the project device and clock speed.

DJ

Thanks

Regards

DJ

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

By removing the write function I got the code just under 8K and used a M88 with the STK500. It has been fun now I better find a use for this stuff. :)

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I am getting 6394, for just the read function. Would this plus a bootloader be under 8K. I have not written the bootloader yet?

DJ

Thanks

Regards

DJ

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

Quote:

I am getting 6394, for just the read function. Would this plus a bootloader be under 8K

The actual SPM stuff is very small (there are a lot of <512 byte bootloaders out there) so I woudn't worry about it fitting in 8192 bytes. As Johan/David/et al often say - only worry about optimising when you have to.

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

Quote:

how about implementing a file system that writes to the internal flash, rather than an out-board flash memory card?

But what we're talking about here is a bootloader that reads an image from an inserted card then writes it to app flash. If you are talking about code that rewrites the app flash having collected the data from other source (a comms link?) then surely you are just talking about one of the hundreds of existing UART/USB/SPI/whatever bootloaders?

What's proposed here is just a new delivery mechanism - the code is delivered on a FAT formatted SD card that has been written by the PC. So the user is sent a new f/w image, writes it onto an SD in the PC then plugs this into the AVR circuit and that updates the app flash.

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

In regards to the bootloader, what the best code to use. I have read the toutrial and seen the standard libary in help in AVR studio. Matter of fact there is some function written already.
Now that I can read bytes I need to be able to write it to the Flash.

Thanks

Regards

DJ

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

Look at the example code at the top of , it's pretty much a complete program. Here's how I used it:

void 
#ifdef ENABLE_SPM
BOOTLOADER_SECTION
#endif
my_spm_routine(
	void
){
	uint16_t	i;
	uint16_t	page = 0xFE0; // last 32 pages of 528 bytes (16,896) hold f/w image
	uint8_t	buf[SPM_PAGESIZE];
	uint32_t	code_page;
	void (* fn_ptr) (void);
	uint8_t valid = 1;

	cli();
	
	PORTD ^= (1<<LED3);
   	SPI_enable();

	dflash_chip_select();

	write_SPI(0xE8); //continuous array read command
#ifdef FLASH_528
	write_SPI((page >> 6) & 0x3F); //send page number then byte offset = 0
	write_SPI((page &0x3F) << 2);
#else
	write_SPI((page >> 7) & 0x07); //send page number then byte offset = 0
	write_SPI((page &0x7F) << 1);
#endif
	write_SPI(0);

	write_SPI( 0 ); //four don't care bytes to start read process
	write_SPI( 0 );
	write_SPI( 0 );
	write_SPI( 0 );

	write_SPI( 0xFF ); // gonna check 1st three bytes at start of page FE0 for "CJL" to show code is available
	if (SPDR != 'C') {
		valid = 0;
	}
	write_SPI( 0xFF );
	if (SPDR != 'J') {
		valid = 0;
	}
	write_SPI( 0xFF );
	if (SPDR != 'L') {
		valid = 0;
	}

	if (valid) {
		for (code_page=0; code_page<112; code_page++) { // 112 pages of 128 bytes to 1C00
			for (i=0; i < SPM_PAGESIZE; i++) {
				write_SPI(0xFF) ; // dummy write in order to read a byte 
				buf[i] = SPDR;
	//			buf[i] = 0x5F;
			}
			boot_program_page((code_page * SPM_PAGESIZE), buf);
		}
	}

	dflash_chip_unselect();
	SPI_disable();

	if (valid) {
		// force a reboot into the new code
		fn_ptr = (void *) 0;
		fn_ptr();
	}
	sei();
}



void 
#ifdef ENABLE_SPM
BOOTLOADER_SECTION
#endif
boot_program_page (
	uint32_t page,
	uint8_t *buf
){
    uint16_t i;
    uint8_t sreg;

    // Disable interrupts.

    sreg = SREG;
    cli();

    eeprom_busy_wait ();

    boot_page_erase (page);
    boot_spm_busy_wait ();      // Wait until the memory is erased.

    for (i=0; i

In that I'm reading data out of an AT45 not an SD but the technique should be very similar. I also hard coded some numbers (specifically 112 pages of 128 bytes which is right for a mega16)

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

Great its working, I ill just replace the AT45 with the SD card stuff. I am going go through this and will give it a go.

Thanks

DJ

Thanks

Regards

DJ

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

Clawson wrote:
Try diffing my edited files against the stock issue
CAn this be done on a 'DOZE XP system ( if so, how ) or is it Linux only?

JS wrote:
I got the code just under 8K

There are some primo switch settings you can apply to compiler and linker that may drop your #s by KBs, if you haven't already.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Quote:
may drop your #s by KBs, if you haven't already.
Mine was just a learning excercise both with the full fat and petit fat.

As fas a using SD cards in my products it seems unlikely due to "licensing issues" with using SD cards and then M$ if a 32 bit FAT is used.
https://www.avrfreaks.net/index.p...
of course one can never say never...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:
CAn this be done on a 'DOZE XP system ( if so, how ) or is it Linux only?
ExamDiff

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

Other then NOT using long file names , how can you insure you are on FAT16 and not on FAT32. This way as a good practice i am not breaking any MS patients.

DJ

Thanks

Regards

DJ

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

Quote:

Other then NOT using long file names , how can you insure you are on FAT16 and not on FAT32. This way as a good practice i am not breaking any MS patients.

FAT32 is not patented, LFNs are. You can use FAT12/16/32 without licence concerns as long as you only read/write 8.3 filenames.
Quote:
Clawson wrote:
Try diffing my edited files against the stock issue

CAn this be done on a 'DOZE XP system ( if so, how ) or is it Linux only?

If you use WinAVR you already have the "real" diff:

C:\WinAVR-20100110\utils\bin>dir dif*
 Volume in drive C is ACER
 Volume Serial Number is C6B0-75D7

 Directory of C:\WinAVR-20100110\utils\bin

19/01/2010  18:10            68,608 diff.exe
19/01/2010  18:10            17,920 diff3.exe

but, (IMAO), only a masochist uses the command line diff when GUI tools are available. I use Kdiff3 which is really a Linux tool but that's been cross compiled for Linux:

http://kdiff3.sourceforge.net/

In the past, on Windows, I've also used WinMerge, Araxis Merge and Beyond Compare. The latter two are VERY good but they are commercial, not free products so these days I tend to stick to kdiff3 for home use.

Here's some alternatives to kdiff3 on Windows:

http://alternativeto.net/softwar...

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

Quote:
You can use FAT12/16/32 without licence concerns as long as you only read/write 8.3 filenames.
But that's only keeping M$ happy, correct? What about the SD card association? You seem to need a license even to look at a SD card. :(

edit no worries, just saw the other thread.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

What about the SD card association? You seem to need a license even to look at a SD card.

It's the 4 bit interface that is subject to SD license (to access the specs.) Using MMC it was an "open" interface.

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

theusch wrote:
I'm also planning an SD bootloader. ...

... and am getting to it now. I decided that although the main app uses the now deprecated TinyFATfs, I'm going to try to build the bootloader with Petit.

Disallowing directory support is fairly significant in terms of flash footprint, but I don't want to force all firmware images for different target models, versions, etc to be all in the root directory. So we'll see if I end up squeezed on flash footprint.

Anyway, just as this thread got down to the latest posts in early December 2010, a new release was made for Petit with... wait for it ...

Quote:
Petit FatFs Module Sample Projects (C)ChaN, 2010
...

REVISION HISTORY

Jun 15, 2009 First release. (branched from FatFs R0.07b)
Dec 14, 2009 Modified for R0.02
Oct 23, 2010 Added a sample of generic uC
Dec 3, 2010 Added a sample for PIC devices.
Dec 7, 2010 Added a generic MMC boot loader for AVR devices.


I'm just starting to dig into it now. The first job will be the CV port of Petit, and run through the demo program or the equivalent. Then on to the bootloader. I'll try to remember to continue this "blog".

So, js, have you now incorporated Petit into any apps? Work OK? Any follow-up or hints?

BTW, a re-read of this thread uncovered something interesting--all posts by millwood have disappeared? Is the year 1984? We will need a different term to refer to the situation, as HWMNBN already has another meaning here.

Lee
[edit] Nothing to an MMC bootloader--Chan's example:

int main (void)
{
	DWORD fa;	/* Flash address */
	WORD br;	/* Bytes read */


	pf_mount(&Fatfs);	/* Initialize file system */
	if (pf_open("app.bin") == FR_OK) {	/* Open application file */
		for (fa = 0; fa < BOOT_ADR; fa += SPM_PAGESIZE) {	/* Update all application pages */
			flash_erase(fa);					/* Erase a page */
			memset(Buff, 0xFF, SPM_PAGESIZE);	/* Clear buffer */
			pf_read(Buff, SPM_PAGESIZE, &br);	/* Load a page data */
			if (br) flash_write(fa, Buff);		/* Write it if the data is available */
		}
	}

	if (pgm_read_word(0) != 0xFFFF)		/* Start application if exist */
		((void(*)(void))0)();

	for (;;) ;	/* No application, Halt. */
}

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
So, js, have you now incorporated Petit into any apps? Work OK? Any follow-up or hints?
No,Yes,No. :)
It was more of an exercise for me as I had designed a PCB as an add on to one of my boards because of a possible job that ended up using a FTDI Vmusic2 module istead.

Never tested the board so I had a bit of spare time and got it working, one never knows when another job could pop up that may need it.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

And here is the full project running on a M64 at 16MHz.

 

Thank you JS... I have been stymied by my inability to produce a working WinAVR  Makefile for Elm Chan's distribution archive. I took your makefile, shifted it to Elm's distribution, altered your C mods  back to Elm's S versions and wham! everything compiled (using a DOS command line interface). I am using the latest avr-gcc version. Without leaving anything out from capabilities (even leaving FAT32enabled), I get 8000 (exactly!) bytes of text, about 98% full in an ATtiny85.

 

For some reason I couldn't get AVRdude to load the file which came from the WinAVR makefile, but your Makefile made good code.

 

I have to relearn everything I forgot these last 35 years. The last system firmware I designed was for a 68HC05 in 1982. Forgotten a lot since then. Anyway, the library you shared was what I needed. Thanks for all you do!

 

ps: Now comes the hard stuff - moving it to the ATtiny167 so I have enough pins for the project...

 

Last Edited: Thu. Dec 10, 2015 - 05:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The last system firmware I designed was for a 68HC05

Ha the good old days  before I started to hate Motorola!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Pages