Hi Hannes, That's good news! Actually I am not sure if it would cause a lot of duplication - it may be just a bit, which is fine.
The TPI code is currently implemented in 2 main files: bitbang.c and avr.c. It is probably already split into the access layer and physical layer. In avr.c, TPI code is in these functions: - avr_read_byte_default - avr_read - avr_write_byte_default - avr_write In bitbang.c, the TPI "physical layer" is in these functions: - bitbang_tpi_clk - bitbang_tpi_tx - bitbang_tpi_rx - bitbang_cmd_tpi (exposed in pgm struct) The only place where code is duplicated is in these functions: - bitbang_chip_erase - bitbang_program_enable - bitbang_initialize The cmd_tpi is the main function which should be implemented in avrftdi for the physical layer. As for the chip_erase and program_enable, there is no avr_xxx common function available for these, so the code has to be duplicated here. The bitbang_initialize also needs to be implemented to enable the TPI interface. All the code in avr.c is already calling cmd_tpi, so there's not much problems there. There's no real paged reads/writes, since if avr_read and avr_write is called with a block of contiguous data, the reads and writes can be performed faster using post-increment. Am I missing anything here? -- Regards, Darell Tan On Sun, Jul 8, 2012 at 8:10 PM, Hannes Weisbach <[email protected]> wrote: > > Am 03.07.2012 um 16:10 schrieb Darell Tan: > > Hello, > >> If I had the time, I would implement TPI over avrftdi too, but it >> seems like I need to copy/paste (or re-implement) the TPI logic into >> avrftdi, which is not an elegant solution. If the code in avr.c could >> be re-used, then it would have been really simple to get TPI working >> for avrftdi. > > Yesterday I implemented prototypical TPI support in avrftdi (Again, thanks to > Joerg for the Attiny10 breakout board). For now, I can only read the device > ID (although fuses should be possible, too). > I agree, that TPI causes a lot of code duplication. I propose to split code > into two layers "TPI access layer" and "TPI physical layer" - like Atmel did > in the chip. See AVR918 (chapters 3.2 and 3.3) or Attiny10 datasheet (chapter > 14.2). I imagine the access layer to be a generic implementation with > callbacks into the physical layer. The physical layer has to implemented by > every programmer. In the simplest case this would be a byte transmit and byte > receive function. However, I suppose some programmer would benefit from "bulk > transfers" (multiple bytes read or written). > I do not know if this is a viable approach with respect to "smart" > programmers which have their own firmware. Maybe someone can comment on that. > > Regards, > Hannes _______________________________________________ avrdude-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avrdude-dev
