Re: [avrdude-dev] avrftdi TPI support

2013-05-12 Thread Joerg Wunsch
As Hannes Weisbach wrote: The usbasp.c patch doesn't work: USBasp doesn't have a cmd_tpi, so when avr_tpi_program_enable() calls pgm-cmd_tpi(), it segfaults. I don't understand enough of the USBasp TPI implementation to get an idea how to establish a cmd_tpi method there. I have whipped

Re: [avrdude-dev] avrftdi TPI support

2013-05-06 Thread Hannes Weisbach
Am 05.05.2013 um 12:26 schrieb Ing. Daniel Rozsnyó: Hi, could you please share a usable programmer definition? (I use a FT2232H minimodule by FTDI). Then the 2232HIO programmer should work fine. Connect it like so: FTDI ATtiny4/5/9/10 SCKTPICLK TDI/DO--R--+

Re: [avrdude-dev] avrftdi TPI support

2013-05-06 Thread Hannes Weisbach
Am 03.05.2013 um 12:12 schrieb Hannes Weisbach: 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,

Re: [avrdude-dev] avrftdi TPI support

2013-05-05 Thread Ing. Daniel Rozsnyó
Hi, could you please share a usable programmer definition? (I use a FT2232H minimodule by FTDI). Daniel On 05/02/2013 01:40 PM, Hannes Weisbach wrote: 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

Re: [avrdude-dev] avrftdi TPI support

2013-05-03 Thread Joerg Wunsch
As Joerg Wunsch wrote: Other AVRs require the HV on /RESET to be in the range of 11.5 through 12.5 V. You have to measure the current consumption, but after all, this is a MOS input only, so I wouldn't expect it to draw much beyond of about 1 µA. Actually, it's more. I measured about 550

Re: [avrdude-dev] avrftdi TPI support

2013-05-03 Thread Hannes Weisbach
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,

Re: [avrdude-dev] avrftdi TPI support

2013-05-03 Thread 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 -

Re: [avrdude-dev] avrftdi TPI support

2013-05-03 Thread Hannes Weisbach
Am 02.05.2013 um 17:41 schrieb 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

Re: [avrdude-dev] avrftdi TPI support

2013-05-03 Thread Joerg Wunsch
As Hannes Weisbach wrote: Actually, it's more. I measured about 550 µA @ 12 V, but with a few 100 mV more, it could be about 2 mA already. Hm. Too much current to supply from TPICLK (it's not running continuously). Well, a ring oscillator/voltage tripler, then. Or, just leave it to the

[avrdude-dev] avrftdi TPI support

2013-05-02 Thread 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

Re: [avrdude-dev] avrftdi TPI support

2013-05-02 Thread Joerg Wunsch
As Hannes Weisbach wrote: as of SVN r1156, avrftdi now supports TPI (and I hope I didn't break anything else in the process). Thanks! 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

Re: [avrdude-dev] avrftdi TPI support

2013-05-02 Thread Joerg Wunsch
As Hannes Weisbach wrote: 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