Petit FatFs limitation?

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

Hi All

I would like to use Petit Fat to read a text file and program my AVR from the bootloader.

I am using the ATMEGA1284P, which has 8K for its bootloader.

I need to use my ethernet connection to transfers the updated AVR hex,which meansmy ethernet IC code and FATFS, would not fit for the 8K boot space.

So what I was thinking was in my application,I could download the file and then in my bootloader just read the file and update the AVR.

Is there any limiation with 2GB SD card or any other issue when using Petit I should be aware of.

regards

DJ

Thanks

Regards

DJ

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

Hi I have download the AVR example..

I am getting some assemebler message error related to usi.S.

../usi.S: Assembler messages:
../usi.S:31: Error: constant value required
../usi.S:31: Error: number must be positive and less than 64
../usi.S:51: Error: constant value required
../usi.S:51: Error: number must be positive and less than 64

Any advice?

By the way, how small can petitfatfs be, can it be less then 6K, So I can added bootloader code as well?

DJ

Thanks

Regards

DJ

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

You have to show those lines of code, we don't know what / where they are ! Info. about memory sizes for different config. settings are on Chan's site, but i don't remember where.

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:

So what I was thinking was in my application,I could download the file and then in my bootloader just read the file and update the AVR.

I'm also planning an SD bootloader. I plan to do something similar to what you describe: My application already has functionality to browse directories and pick a file. So I planned to have the app pick the file, place the necessary information (complete file name with directories, other info such as EEPROM clear/overwrite or not, control words, perhaps checksum) into a defined EEPROM area and then invoke the bootloader. The bootloader would then "go" if all the information is in order. TBD how to tell the bootloader to "go" if all the EEPROM info isn't set up--for example, after a failed bootload.

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

A strategy
Bootloader should be told the length and CRC16 of the code to be loaded. On AVR CPU reset, the BL should verify the CRC/length of the in-flash code and if correct, it's OK to jump to the app. Else try go re-flash using a new or prior flash file whose names are a given to the BL.

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

indianajones11 wrote:
You have to show those lines of code, we don't know what / where they are ! Info. about memory sizes for different config. settings are on Chan's site, but i don't remember where.

Here is what I was refering to

; Receive a byte (28 clks)
; BYTE rcv_spi (void);
.global rcv_spi
.func rcv_spi
rcv_spi:
ldi	r24, 0xFF
; Link next function
.endfunc


; Transmit a byte (27 clks)

; void xmit_spi (BYTE);
.global xmit_spi
.func xmit_spi
xmit_spi:
	out	_SFR_IO_ADDR(USIDR), r24

	ldi	r24, 0b000100		; PB2(SCK)
	out	_SFR_IO_ADDR(PINB), r24	; Toggle SCK 16 times
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	out	_SFR_IO_ADDR(PINB), r24
	nop
	in	r24, _SFR_IO_ADDR(USIDR)
	reti
.endfunc

whats this code doing?

By the way how small have you guys got PetitFats compiled

Regards

DJ

Thanks

Regards

DJ

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

Quote:

By the way how small have you guys got PetitFats compiled

If you just download pfsample.zip and build it for tiny85 you get:

AVR Memory Usage
----------------
Device: attiny85

Program:    8142 bytes (99.4% Full)
(.text + .data + .bootloader)

Data:        139 bytes (27.1% Full)
(.data + .bss + .noinit)

If you now edit pff.h to change the build options to:

#define	_USE_READ	1	/* pf_read(): 0:Remove ,1:Enable */

#define	_USE_DIR	0	/* pf_opendir() and pf_readdir(): 0:Remove ,1:Enable */

#define	_USE_LSEEK	0	/* pf_lseek(): 0:Remove ,1:Enable */

#define	_USE_WRITE	0	/* pf_write(): 0:Remove ,1:Enable */

#define _FS_FAT32	1	/* 0:Supports FAT12/16 only, 1:Enable FAT32 supprt */

(that is switch off DIR/LSEEK/WRITE) you get:

AVR Memory Usage
----------------
Device: attiny85

Program:    5380 bytes (65.7% Full)
(.text + .data + .bootloader)

Data:        135 bytes (26.4% Full)
(.data + .bss + .noinit)

In an 8192 BLS that leaves 8192-5380=2,812 which should be more than enough to hold the rest of the SPM code needed to implement a bootloader.

What's more the pfsample contains a complete UART driven "monitor". Obviously a bootloader doesn't need this so the majority of main(), suart.* and xitoa.* will not be needed.

By the way, the problem you raised in your second post is because tiny85 does not have SPI. Instead it's USI can do a kind of half-baked SPI. This is kind of half-built-in-function, half-bit-bang-yourself. The code to do this is in usi.S. As the 1284 doesn't have USI and it does have proper SPI then replace the xmit_spi() and rcv_spi() functions in usi.S with new code that does it properly using the 1284's SPI module.

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

Great, I also need to transfer some data to a GUI IC . The GUI IC, has it a bootloader option as well. I can update that bootloader in my AVR application mode, so I guess 2K for my bootloader code should be enough.

Its now trying to overcome all the errors

Thanks

DJ

Thanks

Regards

DJ

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

Not sure if it helps but I've edited the pfsample\avr files to replace the USI stuff with SPI stuff and to remove the majority of main() and all the UART reliance. This builds to:

D:\pfboot\avr>make
avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -mmcu=atmega16    -c -o main.o main
.c
avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -mmcu=atmega16    -c -o pff.o pff.c

avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -mmcu=atmega16    -c -o mmc.o mmc.c

avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -mmcu=atmega16    -c -o spi.o spi.c

avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -mmcu=atmega16  -Wl,-Map,pfftest.map -Wl,--relax -o pfftest.elf main.o pff.o mmc.o spi.o
avr-objdump -h -S pfftest.elf > pfftest.lst
avr-objcopy -j .text -j .data -O ihex pfftest.elf pfftest.hex
avr-size -C --mcu=atmega16 pfftest.elf
AVR Memory Usage
----------------
Device: atmega16

Program:    3982 bytes (24.3% Full)
(.text + .data + .bootloader)

Data:        145 bytes (14.2% Full)
(.data + .bss + .noinit)

This is COMPLETELY UNTESTED but may serve as starting point.

Attachment(s): 

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

Quote:

Not sure if it helps but I've edited the pfsample\avr files to replace the USI stuff with SPI stuff and to remove the majority of main() and all the UART reliance. This builds to

Sorry, what is USI stuff?

I thought the SPI was all ready included? OR am i missing somthing

I will give this code a try in evening, we can progress from your code onwards.

Thanks

Regards

DJ

Thanks

Regards

DJ

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

Quote:

Sorry, what is USI stuff?

I explained that above - did you miss my post?

Bottom line: big AVRs have true SPI and UART. Small Tiny's (such as the tiny85 that the PetitFs port was engineered for) have neither but have kind of "half" of each in a rather half-baked peripheral called USI. As the 1284 you plan to use has SPI and not USI then the PetitFs needs to be edited to ditch the usi.S support and provide xmit_spi and rcv_spi routines that work via SPI. That's what I've done (very simplistically using C routines) in the .zip file above. I was also interested to know how small the code could be built without all the extra "monitor" stuff included and, as you seem that comes out as 3982 bytes. While it may be possible to shave this further and write an SD bootloader to fit into a 4096 byte BLS I have a feeling that it's really going to need an 8K BLS.

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

So when you say its not tested, I would guess that the SPI interface is working, in terms of being called by the required functions.

In your main function, there is a case statement, how important is that. I guess you could just initialise the SD card, and open a file and start reading?

Regards

DJ

Thanks

Regards

DJ

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

When I say it's not tested I mean I edited the files until the compiler stopped outputting any warnings or errors. Just because something compiles does not mean it runs and works as intended.

In my main() function there is NOT a switch/case() statement - that's all part of the existing PetitFs test code that's now under "#if 0". main() actually looks like:

int main (void)
{
	BYTE res;
	FATFS fs;			/* File system object */
	WORD s1;

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

	res = disk_initialize();
	pf_mount(&fs);
	pf_open("myfile.txt");
	res = pf_read(Line, sizeof(Line), &s1);
	while(1);
	
}

once you remove the "#if 0" stuff. Again I just wrote this based on the facilities that were being used in the existing code and my prior knowledge that FatFs needs the sequence: initialize, mount, open, read. This is completely untested. I was just making sure that, after stripping, there was enough to support the calling of these functions. The pf_read() doesn't actually do anything useful - nothing then uses what (hopefully!) has been read into "Line".

I'm tempted to dig out an STK500, a mega16 and an SD socket and wire something up. I think a template "SD bootloader" might be useful to a number of folks as the trend is to put SD/MMC into designs when large amounts of data storage are required anyway.

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

Hi Clawson

Had a go at your code, I got few questions.

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

What is this setting up, I am using the ATMega 1284P, therefore my pin for SPI is
PB7-SCK
PB6-MISO
PB5-MOSI
PB4-SS

It not clear, what SPI pins are what in the port.

When I am using the Fatfs, I perform the following before I start disk_initialize.

int result=0;
_delay_ms(10);
PORTB|= (1 <<4);//SD CS high
PORTB|= (1 <<6);//MOSO HIGH
for(result=0;result<90;result++)
{
PORTB|= (1 <<7);//CLK high
_delay_ms(1);
PORTB &=~  (1 <<7);//CLK low
_delay_ms(1);
}
PORTB|= (1 <<7);

In the following int of SPI

#define 	SELECT()	PORTB &= ~(1<<4)		/* MMC CS = L */
#define	DESELECT()	PORTB |=  (1<<4)		/* MMC CS = H */
#define	MMC_SEL		!(PORTB &  0x08)	/* MMC CS status (true:selected) */
#if 0
#define	INIT_SPI()	{SPCR = (1<<SPE)|(1<<MSTR); }		/* Initialize SPI port */
#else
#define INIT_SPI()	{SPCR = (1<<SPE)|(1<<MSTR); }			/* this "borrowed" from mmc.c in FF */
#endif

What is MMC_SEL?

I also changed the receive function just like the FF

BYTE rcv_spi(void) {
SPDR = 0xFF;
loop_until_bit_is_set(SPSR, SPIF);
return SPDR;	}

Am I missing anything out?

Regards

Thanks

Regards

DJ

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

theusch wrote:
I'm also planning an SD bootloader. I plan to do something similar to what you describe: My application already has functionality to browse directories and pick a file. So I planned to have the app pick the file, place the necessary information (complete file name with directories, other info such as EEPROM clear/overwrite or not, control words, perhaps checksum) into a defined EEPROM area and then invoke the bootloader. The bootloader would then "go" if all the information is in order. TBD how to tell the bootloader to "go" if all the EEPROM info isn't set up--for example, after a failed bootload.

Lee

clawson wrote:
I'm tempted to dig out an STK500, a mega16 and an SD socket and wire something up. I think a template "SD bootloader" might be useful to a number of folks as the trend is to put SD/MMC into designs when large amounts of data storage are required anyway.

I would like to see the results of either or both of these efforts. Didn't Collin do something like this a few years ago and publish it in Circuit Cellar? Anyway it would provide an alternative to bootloading through a serial port and on systems that will already have an SD card that could be a real savings.

Smiley

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

Yes, I am trying to get the petit working.

Regards

DJ

Thanks

Regards

DJ

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

Hi Clawson

By chaning the the code so that SPI is hardware based compared to the software previouly, do we need to modify anything else like timers.

As i am failing intialsing the SD card.

DJ

Thanks

Regards

DJ

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

Did anyone manage to get this compiled for the Tiny85 as shown in the pfsample? It shows 290 bytes overflow when I try to compile it. :roll:

edit just modified the code using Cliff's hardare SPI code and SPI init instead of the USI and it compiles at 8818 byte using a M164.

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:
Did anyone manage to get this compiled for the Tiny85 as shown in the pfsample? It shows 290 bytes overflow when I try to compile it. :roll:
edit just modified the code using Cliff's hardare SPI code and SPI init instead of the USI and it compiles at 8818 byte using a M164.

I have manged to get 4500 bytes, you need to edit the file pff.h

#define	_USE_READ	1	/* pf_read(): 0:Remove ,1:Enable */
#define	_USE_DIR	0	/* pf_opendir() and pf_readdir(): 0:Remove ,1:Enable */
#define	_USE_LSEEK	0	/* pf_lseek(): 0:Remove ,1:Enable */
#define	_USE_WRITE	0	/* pf_write(): 0:Remove ,1:Enable */
#define _FS_FAT32	1	/* 0:Supports FAT12/16 only, 1:Enable FAT32 supprt */

As this is for a bootloader, all we need is the read.

DJ

Thanks

Regards

DJ

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

Quote:

theusch wrote:
I'm also planning an SD bootloader. I plan to do something similar to what you describe: My application already has functionality to browse directories and pick a file. So I planned to have the app pick the file, place the necessary information (complete file name with directories, other info such as EEPROM clear/overwrite or not, control words, perhaps checksum) into a defined EEPROM area and then invoke the bootloader. The bootloader would then "go" if all the information is in order. TBD how to tell the bootloader to "go" if all the EEPROM info isn't set up--for example, after a failed bootload.

Oh, yeah--I also have the luxury of a vast expanse of 8KB of SRAM, that common people wouldn't have. At the expense of performance, it may make for a simpler bootloader to read one flash page (128 words, 256 bytes on the Mega640/1280) at a time versus reading a sector and then getting chunks. You'd have to get down to about the Mega48 before that is a bottleneck one way or the other. But on that size AVR you'd have to skip the FAT as mentioned above anyway.

Lee

clawson wrote:
I'm tempted to dig out an STK500, a mega16 and an SD socket and wire something up. I think a template "SD bootloader" might be useful to a number of folks as the trend is to put SD/MMC into designs when large amounts of data storage are required anyway.

I would like to see the results of either or both of these efforts.


I just had a thought--

If I do indeed have the app select the file, then the bootloader doesn't need FAT info--just the starting sector address and the like. That should cut down on code size quite a bit.

On the flip side, though, it would then be harder to do the "emergency boot" for e.g. a corrupted system--the app wouldn't be there to set the boot file parameters.

My target is Mega640/1280. So I have the luxury of a big bootloader partition-- 4K words; 8K bytes.

Quote:

js wrote:
Did anyone manage to get this compiled for the Tiny85 as shown in the pfsample? It shows 290 bytes overflow when I try to compile it.

My baseline for comparison would be my working TinyFATfs implementation. Single file, but read, write, directories, and SDHD/FAT32 support.

FAT part: 5450 bytes
MMC/SD/SDHC part: 1128 bytes
so a total of 6578 bytes in my app for SD card support.

For bootloader, one can subtract
write, sync: 663 bytes
lseek?: 481 bytes
mkdir: 363 bytes
or 1507 bytes less, bringing the footprint down to about 5000 bytes.

You can see from those numbers that if you can get the hard sector address from some means, or take shortcuts, the footprint can be greatly reduced.

NOTE: To the footprint above must be added what looks like a virtually complete set of 32-bit arithmetic primitives. In my big full app those are used elsewhere anyway so aren't important. But in the bootloader... lessee if they are in a convenient section of my .LST file... maybe 512 to 1024 bytes.

There might be a couple other functions that can be dropped. I'd estimate my starting footprint at about 5000 bytes. Then put together a newfangled Petit configuration and see how that stacks up.

If I can't conveniently squish down to the 4k byte partition, then why take all the shortcuts? It would surely make sense, though, in a smaller chip--skip the FAT and somehow get the sector address for the bootloader. Heck. it could even be a brute-force read of the SD card till you find the right stuff...

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:

Heck. it could even be a brute-force read of the SD card till you find the right stuff...

Lee,

Believe it or not but that's almost certainly the easiest way to do this. Just start the data with something like "@(#)Bootloader image" or something equally recognisable then read LBAs and skip until '@' found then check for the rest of the string.

In a thread the other day I explained to JS how to find the root directory the "official" way. It's actually not too onerous. Just read the MBR then a few fields from the BPB. If the image could fit in a single cluster then finding/reading the data could also be pretty trivial. If it spans clusters you either go the whole hog and process the FAT or make the assumption that the clusters are simply contiguous.

Cliff

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

Lee.. do you have working petit Fatfs, that has SPI hardware?

DJ

Thanks

Regards

DJ

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

Quote:

Lee.. do you have working petit Fatfs, that has SPI hardware?


No, but js does...
https://www.avrfreaks.net/index.p...

I'll do some evaluation, but if the sizes are about the same I may use the same TinyFatFs base that I use in the main app for the bootloader, rather than one based on Petit. TBD.

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

If I wasn't scurrying around trying to get everything sorted for a two week vacation I'd rig something up on an STK500 and make the code I started above work. Maybe when I come back but, in reality, because of Christmas, this might not be possible until the new year.

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

[quote="theusch
No, but js does...
https://www.avrfreaks.net/index.p...

I'll do some evaluation, but if the sizes are about the same I may use the same TinyFatFs base that I use in the main app for the bootloader, rather than one based on Petit. TBD.

Lee

Whats the differnece between the tinyFatDS and petitFatFs?

The link you sent me, should it have download for the project js has done? If so it no longer there.

DJ

Thanks

Regards

DJ

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

First there was FatFs. Then there was TinyFatFs. Then there was PetitFs. Then FatFs and TinyFs were combined into a single FatFs with a build-time option to select the behaviour of one or the other.

I think Lee's files date from when TinyFatFs was separate from the main thing. As such, in that sense, the files are no longer available.

(I wonder how long before PetitFs is merged into FatFs in fact - I'm sure Chan would prefer to be working on one code base, not two or three!)

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

Quote:

The link you sent me, should it have download for the project js has done? If so it no longer there.

Did you read the thread? Did you go to Elm Chan and get the sample app and build it or adapt it? Isn't that what the thread was about?

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 tired the sample from chans site, but from what I understood, that does not use SPI.

DJ

Thanks

Regards

DJ

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

Quote:
that does not use SPI.
It is intented for tiny chips that DO NOT have SPI so the USI is used instead. Cliff posted the simple change to use the SPI instead of the USI.

I'll try running the full, SPI modified, PetitFs on the same M64 board where I have the full ffsample running now. Then I may build another SD interface pcb with pins so that it can be used with any other suitable chip with the STK500.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I did my first build of Petit. It is a "nonsense" build as I had to whack at the monitor part to get rid of the GCC tendrils. In addition, as djoshi finds, building for an Tiny85 is not everyone's cup of tea. (DJ--"porting" usually does NOT mean "take that code and drop it into my app". It means examining the code, and adapting as needed for one's environment. Do you want to see my very sophisticated re-writes of the primitives in order to use TinyFatFs?]

/*-----------------------------------------------------------------------*/
/* Transmit a byte to MMC via SPI  (Platform dependent)                  */
/*-----------------------------------------------------------------------*/

#define xmit_spi(dat) 	SPDR=(dat); loop_until_bit_is_set(SPSR,SPIF)



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

static
BYTE rcvr_spi (void)
{
	SPDR = 0xFF;
	loop_until_bit_is_set(SPSR, SPIF);
	return SPDR;
}

/* Alternative macro to receive data fast */
#define rcvr_spi_m(dst)	SPDR=0xFF; loop_until_bit_is_set(SPSR,SPIF); *(dst)=SPDR

Anyway, total app was about 6600 bytes without any printf(). RE-configuring for read-only makes it about 4500 bytes.

First disturbing thing is that CV estimates data stack usage at 216 bytes, for an essentially flat app. Perhaps there are deep call chains I don't see. I can't find any functions with more than ~50 bytes of local data.

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

js wrote:
Quote:
that does not use SPI.
It is intented for tiny chips that DO NOT have SPI so the USI is used instead. Cliff posted the simple change to use the SPI instead of the USI.

I'll try running the full, SPI modified, PetitFs on the same M64 board where I have the full ffsample running now. Then I may build another SD interface pcb with pins so that it can be used with any other suitable chip with the STK500.

Ahh, that makes sense and the reason for the modify.

If you can test it out that would be good, I have tried but had no luck. I am not sure if it just the code or the acutal changes I made e.g. port changes.

Does petit have to have a timer like the full one?

DJ

Thanks

Regards

DJ

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

Lee does your code work

currently my spi is as

#include 
#include "pff.h"

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

BYTE rcv_spi(void) {
	SPDR = 0xFF;
	loop_until_bit_is_set(SPSR, SPIF);
	return SPDR;
}

When I try a disk_initialize(), I keep getting a 0x01,

DJ

Thanks

Regards

DJ

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

Not as easy as I thought. :( the SPI pins and the USI pins are not the same on portB. Also the soft USART uses just 1 pin in half duplex mode.

I'l adjourn my tests to later when I have a bit more time.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

So what would be a good start? The SPI addition, seems simple, but I dont know where its going wrong.

Could there be a possbilty of using the USI version on a MegaAVR?

Thanks

Thanks

Regards

DJ

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

The USI is only availabe in VERY SMALL chips. You will need to rearrange the pins to match the SPI pinout rather than the USI pinout as shown on the supplied diagram for the T85.

Also ther will be some port init change and the init for the SPI itself. I don't have any Tiny chips large enough to test the USI types so I'll stick with a M164 or M168 once I get the hardware ready.

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:
The USI is only availabe in VERY SMALL chips. You will need to rearrange the pins to match the SPI pinout rather than the USI pinout as shown on the supplied diagram for the T85.

At the moment the SD card is connected to SPI ports of my Mega1284P, is this what you mean.

Quote:

Also ther will be some port init change and the init for the SPI itself.

This init of the SPI, would that mean it has to be fully hardware. At moment I am getting error due to USIDR.

Quote:
I don't have any Tiny chips large enough to test the USI types so I'll stick with a M164 or M168 once I get the hardware ready.
I am using M1284P, is there more work to do on the SPI file the clawson uploaded? At the moment, I am not sure where and what is failing.

DJ

Thanks

Regards

DJ

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

js wrote:
The USI is only availabe in VERY SMALL chips. You will need to rearrange the pins to match the SPI pinout rather than the USI pinout as shown on the supplied diagram for the T85.

At the moment the SD card is connected to SPI ports of my Mega1284P, is this what you mean.

Quote:

Also ther will be some port init change and the init for the SPI itself.

This init of the SPI, would that mean it has to be fully hardware. At moment I am getting error due to USIDR.

Quote:
I don't have any Tiny chips large enough to test the USI types so I'll stick with a M164 or M168 once I get the hardware ready.
I am using M1284P, is there more work to do on the SPI file the clawson uploaded? At the moment, I am not sure where and what is failing.

DJ

Thanks

Regards

DJ

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

Quote:
At moment I am getting error due to USIDR.
Because
Quote:
The USI is only availabe in VERY SMALL chips.
So you DON'T have an USI. Anything to do with the USI is NOT there and the code needs to be modified accordingly.

May want to delete 2/3 of the posts above.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Sorry about that, how do I delete.
I guess,I will stick to clawson. Out of curosity, how would I check the SPI is working? Is there a small test I could do. My SPI does work with the full FATFS. I am using the JTAGICE, I just need some advice on where to start to get this petit working for a bootloader.

DJ

Thanks

Regards

DJ

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

If you attach MOSI to MISO and send 0x55 to SPDR then read it back, do you get what you sent? Does this test fail with MOSI-MISO connection disconnected?

Imagecraft compiler user

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

Petit fs my foot!! It should be rename pesky fs!! I have managed to get the soft usart running in full duplex mode (no echo so local echo is turned on) using the same pins as USART0 for the M64 and reorganised the SPI code and pinouts to match the working ffsample.

No cigar yet. :( it keeps on coming back with rc=1 with the di command which mean it cannot initialise the disk.
I have tried slowing down the clock to 2MHz and 8MHz (from 16MHz) to no avail. My eyes are blurry now....until we meet again.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Judging from the petitFatfs sample file on Chan’s website, I would have thought that the only functions that would need a change would be in usi.S file, rcv_spi and Xmit_spi.

I would have thought to the rest of the code would function as it was intend without releasing that the data comes from a hardware spi rather then usi.

Am I missing something important here or does there need to be further modification done.

Thanks

Regards

DJ

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

Quote:

Am I missing something important here or does there need to be further modification done.

Try diffing my edited files against the stock issue and you'll see what I changed. Not only does he have the USI functions in Usi.S but he also had some USI configuration in one of the other files (mmc.c perhaps?). All I did there was to replace it with the exact same SPI configuration as found in FatFs.

But like I said I only did what was necessary to make it compile error free with USI change to SPI. There are no guarantees it will actually work. It's just a starting point for the rest of any porting work that is necessary.

As you don't seem confident in doing this yourself it currently seems like js is your best hope to come up with a working template.

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

Quote:

it keeps on coming back with rc=1 with the di command which mean it cannot initialise the disk.

That is essentially the same result as djoshi, right?

Quote:

But like I said I only did what was necessary to make it compile error free with USI change to SPI.

Now y'all have me intrigued. When I port, it will be to real SPI for my target. I may or may not do the monitor port--certainly I'm not going to do soft USART.

My aim is a reasonably-small footprint to use as a bootloader. To avoid translating/sorting Intel .HEX, I thought I'd use a .BIN. TBD how to determine .EEP or no .EEP (which would also be .BIN I think).

I may have a BOOT.TXT file with file names (or sector numbers) and checksums and "prarameters".

As mentioned earlier, I have the luxury of a large boot partition. Skip the FAT and 4k should certainly be feasible--about 2k for "mmc.c" read functions. As complete USART bootloaders fit into 1k or half that, the actual bootloading should fit nicely into about 1k, and the total with that approach should fit into a 4k partition I would think.

So is the footprint of Petit going to be much less than with my TinyFatFs? Don't know. I may just use the same TinyFatFs base from the real app...

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 8K for a bootloader, so petit should be Ok for me

Thanks

Regards

DJ

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

Quote:
assuming that you are able to.
Speaking of pesky.. :) look what has returned from the black lagoon. And everybody thought you had been abducted by aliens and used for experiments.

According to the docs pf should only be 2-4k on it's own depending on what's being used. So a 3-5K bootloader should be possible.

The reason I got the soft usart running is that I wanted to keep the sample code as original as possible. It has provisions for full duplex so I changed the flag for that and reworked things so it appears on PE0 and PE1 and can use a standard RS232 adaptor.

I have a SD card adaptor provision on my CONT-3 module where the standard 49K fatfs sample runs well.

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!! It was Cliff's fault. :lol:

BYTE xmit_spi(BYTE c) {
	SPDR = c;
	while (!SPCR & (1<<SPIF));  You naughty, naughty boy!! SPSR maybe?
	return SPDR;
}

edit also wrong parenthesis. And here is the full project running on a M64 at 16MHz.

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

millwood wrote:
I for example have all of my spi functions in one library that I use from device to device, to maintain reliability and consistency so I don't need to worry if my spi routines work or not.
Could you post those libraries on a new thread. Folks would sure find them useful.

Smiley

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

I think deadwood is not who he (or she) says is. I think it's another obnoxious person pretending. Surely there could not be in the same galaxy 2 people that speak out of their, let's say hats, without knowing the full story.

Anyway if you are so clever you should have sorted this issue out a long time ago instead of waiting for me to do it.

A library of SPI functions?? :roll: That's like saying that one needs a user's manual for a light switch.

Still hasn't understood that one can reply to more than 1 topic in the same post, just a waste of space.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Millwood - Any chance you'll post your SPI library?

Smiley

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

I did say it was completely untested :oops: :oops:

  • 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