[Top][All Lists]
[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