Re: [avrdude-dev] avrftdi TPI support

[Hannes Weisbach]

>> Page read and write operations should speed up these operations
>> somewhat, but TPI requires to poll a bit (NVMBSY) after each written
>> word, so don't expect too much.
> 
> I don't see any real option for paged writes in the memory programming
> description of these devices.
Ah, yes. You are right. What I meant, though, was the reduction of USB 
transactions by coalescing reads and writes. For example, avr_read() does 
essentially (for TPI):
- write NVMCMD register (2)
- write PR low (2)
- write PR high (2)
- send command (1)
- read data byte (1)
The numbers in parenthesis designate the number of bytes transferred. Each step 
calls pgm->tpi_cmd(), which results in a single USB IN or OUT request for every 
byte(!). This is due to the current implementation of avrftdi_tpi_cmd(). 
Although it would be possible to reduce that to one USB OUT and one USB IN 
request (the latter does not happen, if no data is read) per cmd_tpi()-call, 
this still results in 5 OUT requests and one IN request per from the part in 
total (to read one data byte, and we need to read 1024 of those ...). A 
paged_read()-function could coalesce the data to 2 requests total (one OUT with 
7 bytes and one IN with 1 byte). Reading data currently causes an additional 
OUT request for transferring the MPSSE instruction to actually read the data 
in, which could be appended to the previous OUT request.

Switching the transfer direction (using avrftdi's set_pin()) causes additional 
overhead, which could be reduced in a paged_write/load().
[I just realised that calling set_pin() is no longer necessary. This reduces 
write/read to 8s/6s (previously 16s/18s) for my FT2232D.]

For paged_read(), it would also be possible to whip up a buffer, which causes 
multiple bytes to be read in one go. For paged_write() this is not possible, 
because we have to poll NVMBSY in between flash words.

Side note: all bytes mentioned so far are payload bytes. One payload byte is 
translated to a TPI-frame which is encoded in 2 bytes + 3 bytes MPSSE 
instructions. The paged_read() function could therefore transfer the data in 
one OUT request with 14 bytes (TPI frames) + 3 bytes (MPSSE). As I see it, up 
to 384 bytes (for 2232C/D devices) could be read in one go, thus reducing 4224* 
IN and OUT requests to 2. (I hope i got that right ;))

*: 7 OUT requests for 7 bytes written + 1 OUT requests and 1 IN request for 1 
byte read + 2 OUT requests and 1 IN request for set_pin() = 11 requests for 1 
byte * 384 bytes 
> 
>> Cabling looks like so (monospace font!):
>> SCK------------TPICLK
>> MISO---R---+
>>           +---TPIDATA
>> MOSI---R---+
> 
> I think a resistor between MOSI and TPIDATA is enough; MISO is an input
> only anyway, so it cannot drive any output against the TPIDATA output.
Theoretically yes. But this is freely configurable over MPSSE. So the question 
is, in which state the FTDI is, before avrftdi can configure it. The FT4232H 
data sheet states, that upon reset the device is in UART mode, which makes the 
MISO pin RTS and thus an output (I don't know on which level it would be 
driving). Or a previous application didn't reset the chip properly ... I 
recommend angst resistors :) (I think neither device would be destroyed if an 
Atmel and an FTDI drove against each other.)
> 
> 
>> Flashing with RSTDISBL fuse programmed is not (yet)
>> supported. Unfortunately Atmel does not give a voltage range for
>> HV-programming for ATtiny4/5/9/10 or a current on the HV-rail (Maybe
>> Joerg can comment on that?). My current idea is to use a voltage
>> doubler (Dickson charge pump) driven from TPICLK to generate 9-ish
>> volts and switch those to the /RESET pin, somehow. This works,
>> because the ATtiny always have to be flashed from 5V.
>  I think a chargepump voltage tripler with a 12 V Z
> diode to limit the resulting voltage ought to be enough.
I'll try that.

Hannes