Re: [avrdude-dev] attiny10 with ftdi and bitbang

[Darell Tan]

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 <address@hidden> 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