Re: [avrdude-dev] avrftdi TPI support

[Hannes Weisbach]

Am 02.05.2013 um 13:40 schrieb Hannes Weisbach:

> Hello,
> 
> as of SVN r1156, avrftdi now supports TPI (and I hope I didn't break anything 
> else in the process). I tested TPI support with all configurations in the 
> cartesian product {Win7 x64, Ubuntu Linux 12.04.2, OS X 10.6.8} x {FT2232D, 
> FT4232H} x {ATtiny10} (Thanks go to Joerg for providing the ATtiny). Bug 
> reports as well as success reports are welcome.
I just had a look around and I noticed that all 'dumb' programmers 
(avrfdi_tpi.c, bitbang.c, usbasp.c)supporting TPI implement stuff like
*_tpi_chip_erase() and
*_tpi_program_enable() (setting guard time, sending skey, reading 
identification and status register)
all for themselves. This is not necessary, since the two functions can be 
programmed by using only pgm->cmd_tpi() callbacks.
So my idea is to add to the PROGRAMMER structure:
- tpi_guard_time field
- tpi_break() function
and implement avr_tpi_chip_erase() and avr_tpi_program_enable() globally in 
avr.c.

avr_tpi_program_enable() can be called from every programmer after providing 16 
init clock cycles.
A programmer can set pgm->chip_erase() to avr_tpi_chip_erase(), if it wishes to 
do so.
I think this way we can stay compatible to 'smart' and future programmers and 
reduce code duplication at the same time.

(And improve code quality, mind you:
- usbasp.c and avrftdi_tpi.c have the address hard-coded in *_tpi_chip_erase().
- only bitbang.c checks if the memory region to be erase is actually "flash".
- tpi_skey in tpi.h is in the "wrong" byte order, prohibiting calling 
pgm->cmd_tpi() directly on the array.)

I do have one question, though: usbasp_tpi_chip_erase() calls pgm->initialize() 
after the erase. I didn't read this was necessary and bitbang.c and 
avrftdi_tpi.c don't do it. Is this a possible left over from copying 
usbasp_spi_chip_erase() or does usbasp actually need this second 
pgm->initialize() call itself?

Comments, hints, problems I don't see and/or "go ahead" are welcome.

Best regards,
Hannes