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