[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] avrftdi TPI support
From: |
Hannes Weisbach |
Subject: |
Re: [avrdude-dev] avrftdi TPI support |
Date: |
Fri, 3 May 2013 12:12:18 +0200 |
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
Re: [avrdude-dev] avrftdi TPI support, Ing. Daniel Rozsnyó, 2013/05/05
Re: [avrdude-dev] avrftdi TPI support, René Liebscher, 2013/05/05