Re: [avrdude-dev] avrftdi TPI support

[Darell Tan]

Hi Hannes,

I think implementing a global chip_erase and program_enable for TPI is a
good idea. In fact, we were talking about it some time last year. The
usbasp programmer has the most duplication of TPI code.

As for the SKEY constant, I wrote it in the way it appeared in the ATtiny
datasheet - I probably should have wrote it in such a way where it can be
passed directly to the cmd_tpi function instead.

--
Regards,
Darell Tan


On Fri, May 3, 2013 at 6:12 PM, Hannes Weisbach <address@hidden>wrote:

>
> 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
> _______________________________________________
> avrdude-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>