avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] Patch for fuse and lock-bits with avr910


From: Jan-Hinnerk Reichert
Subject: Re: [avrdude-dev] Patch for fuse and lock-bits with avr910
Date: Sun, 18 May 2003 19:41:59 +0200
User-agent: KMail/1.5.1

On Sunday 18 May 2003 19:15, Theodore A. Roth wrote:
> On Fri, 16 May 2003, Jan-Hinnerk Reichert wrote:
> :)Hi all,
> :)
> :)I have written a patch that allows to read and write fuse bits with an
> : avr910 )programmer (at least if it supports the "New Universal Command").
> : )
> :)Should work with avr910 version 2.2 and newer (don't have access to older
> :)firmware.
> :)
> :)Patch is against latest CVS version of "avr910.c"
> :)
> :)This is how it works:
> :)1) It implements "avr910_cmd()": sending arbitrary SPI-commands
> :)2) avr910_read_byte() and avr910_write_byte() call
> : avr_read_byte_default(), )resp. avr_write_byte_default(), if memtype is
> : neither flash nor eeprom.
>
> I've been reviewing and testing your patch. One question though.
>
> Can you explain the reasoning behind the "last_spi_byte" variable in the
> avr910_cmd() function?

Right now, I have a little hangover, but I will try ;-)

> It doesn't seem to have any obvious purpose to me.

I was trying to get as close as possible (with reasonable effort) to the 
specification of the function. Since the '.' command only returns the fourth 
byte the other 3 byte need to be "guessed".
The first byte received should be the last byte sent by the previous command.
The second and third byte received are the first and second byte of the 
command.

Of course, the hack with "last_spi_byte" only works, if the previous SPI 
command was also send by means of '.'-command

However, in real life you won't see a difference, because only the fourth byte 
of the result is ever used for avr910 and stk500 programming ;-)
IMHO this is why nobody has noticed that stk500_cmd() is returning wrong 
values in the first three bytes.

> One onther item: firmware versions < 2.0 don't have the '.' command
> (universal command) and will thus fail. I'm thinking that this case should
> be caught and avr910_cmd() should return -1.

ACK.

How should one test for the '.'-command?
- Send '.' and look if a '?' comes back?
- or simply checking the firmware version?

Will you insert the check or should I?

For older prommers fuse bits could also be programmed by the 'f'-command, but 
I'm not sure if it's worth the trouble. IMHO most people must use a 2.x 
version anyway, because of the 'm'-command and the list of supported devices.

 Jan-Hinnerk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]