avrftdi TPI support

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

avrftdi TPI support

Hannes Weisbach-2
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.

The way that TPI works limits it's speed especially for non-H devices. avrdude reported about 16s for 1024 byte write and 18s for the read (4232H: 7s and 9s, respectively). 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.

Cabling looks like so (monospace font!):
SCK------------TPICLK
MISO---R---+
           +---TPIDATA
MOSI---R---+

In AVR918 Atmel suggests 220Ω for R. However FTDI devices can usually sink and source about 8mA (don't quote me on that) so I used 1k. If 16mA I/O current is enabled in the FTDI you can go down to 312Ω, but I don't recommend that. Everything up to about 10k or so should work (at least with reduced clock rate).

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.

Best regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

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 too much.

I don't see any real option for paged writes in the memory programming
description of these devices.

> 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.

A cabling like that is also used for other selfmade bitbang TPI
programmers.

> 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.

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.  I think a chargepump voltage tripler with a 12 V Z
diode to limit the resulting voltage ought to be enough.

If you look into the STK500 schematics, they use a chargepump doubler
starting at VIN (which must be at least 7.5 V on the STK500), followed
by a TL431 stabilizer.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Hannes Weisbach-2
>> 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
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

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 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).

OK, reason enough for the second resistor.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Joerg Wunsch
In reply to this post by 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 µA @ 12 V, but with a
few 100 mV more, it could be about 2 mA already.

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Hannes Weisbach-2
In reply to this post by Hannes Weisbach-2

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

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 - 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 <[hidden email]>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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Hannes Weisbach-2
In reply to this post by Hannes Weisbach-2

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
>> 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):
> [...]
So, I have written such a paged_load-function for avrftdi and it performs rather well. I'm now down to 0.88s (FT2232D) and 0.66s (FT4232H) (from 8s/6s, resp.) to read out 1024 bytes of flash memory.
I have hooked the pgm->paged_load() callback into avr_read() like so:

/* supports "paged load" thru post-increment */
if ((p->flags & AVRPART_HAS_TPI) && mem->page_size != 0 &&
    pgm->cmd_tpi != NULL) {
        if(!strcasecmp(memtype, "flash") && pgm->paged_load) {
                return pgm->paged_load(pgm, p, mem, mem->page_size, 0, mem->size);
        }
[ normal TPI stuff continues ]

which means that the function will only be called for flash readouts and a "page" is defined as the entire memory. Everything else has to be handled by the programmer.
I don't know how compatible this change is. All programmers who are based on bitbang.c to implement pgm->cmd_tpi() do not NULL out their paged_load() member when in TPI mode, so I think this will break. usbasp.c actually has a usbasp_tpi_paged_load(), but I don't see how that could have ever been called, since avr_read() does always byte-wise I/O for TPI parts.

Anyway, I'd like to hear your comments on this change. I think it's rather hack-ish, because it changes somehow the meaning of the paged_load() parameters. The only pro-argument I have is that it is so f****** fast.

Best regards,
Hannes


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Hannes Weisbach-2
In reply to this post by Joerg Wunsch

Am 03.05.2013 um 09:26 schrieb 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 µ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.

Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

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 user to supply the 12 V externally when
they need to handle a disabled /RESET pin.  After all, other
TPI-capable programmers (like the AVRISPmkII) don't handle this
either.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

"Ing. Daniel Rozsnyó"
In reply to this post by Hannes Weisbach-2
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 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.
>
> The way that TPI works limits it's speed especially for non-H devices. avrdude reported about 16s for 1024 byte write and 18s for the read (4232H: 7s and 9s, respectively). 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.
>
> Cabling looks like so (monospace font!):
> SCK------------TPICLK
> MISO---R---+
>             +---TPIDATA
> MOSI---R---+
>
> In AVR918 Atmel suggests 220Ω for R. However FTDI devices can usually sink and source about 8mA (don't quote me on that) so I used 1k. If 16mA I/O current is enabled in the FTDI you can go down to 312Ω, but I don't recommend that. Everything up to about 10k or so should work (at least with reduced clock rate).
>
> 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.
>
> Best regards,
> Hannes
> _______________________________________________
> avrdude-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

René Liebscher
In reply to this post by Hannes Weisbach-2
Hi,

at my Ubuntu 12.10 avrftdi is no longer available. The reason is that it
checks for some ftdi1, which is not found here. (I have installed
libftdi1!) If I define HAVE_LIBFTDI1 for myself and change the includes
from libftdi1/ftdi1.h to ftdi.h it works as before.

René


On 02.05.2013 13:40, 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 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.
> ....
>
> Best regards,
> Hannes
> _______________________________________________
> avrdude-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Hannes Weisbach-2

Am 05.05.2013 um 15:49 schrieb René Liebscher:

> Hi,
>
> at my Ubuntu 12.10 avrftdi is no longer available. The reason is that it checks for some ftdi1, which is not found here. (I have installed libftdi1!) If I define HAVE_LIBFTDI1 for myself and change the includes from libftdi1/ftdi1.h to ftdi.h it works as before.
>
> René
>
Then Ubuntu puts the header in the wrong directory. I use the git HEAD for testing. You get ftdi.h also when you have libftdi-0.x installed (How does Ubuntu handle a libftdi-0.x/libftdi1 co-installation?). ftdi.h unfortunately has no version information itself, however a function call ftdi_get_library_version() is available, returning a struct ftdi_version_info. I don't know if it is possible to have autoconf/autotools compile a test program an parse its output for version information.
This leaves the issue, that putting headers in different directories makes the code rather ugly, because it has to handle all eventualities.

Best regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Hannes Weisbach-2
In reply to this post by "Ing. Daniel Rozsnyó"

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
SCK------------TPICLK
TDI/DO--R--+
           +---TPIDATA
TDO/DI--R--+
TMS------------RESET
(Have a look at AVR918, p. 8 for a better diagram, but use R = 1kΩ or something like that.)
Remember to use 5V, otherwise writing to flash fails. (For me, reading the signature bytes worked with 3.3V).
If you have the RSTDISBL fuse programmed, then you have to apply 12V to the RESET pin of the ATtiny (haven't tried that yet).

Best regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Hannes Weisbach-2
In reply to this post by Hannes Weisbach-2

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, 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, SVN r1166 provides avr_tpi_chip_erase(), r1167 avr_tpi_program_enable() and in r1168 avrftdi makes use of these functions.
> So my idea is to add to the PROGRAMMER structure:
> - tpi_guard_time field
> - tpi_break() function
This was not necessary. The guard time is supplied as parameter to the function. Therefore, the programmer cannot just set pgm->chip_erase to avr_tpi_chip_erase(), but call it from a dedicated function.
tpi_break() is not needed, because if something went wrong it is retried and eventually the code just fails. As I see it, for dumb programmers like avrftdi it is not possible to discern if the part is in error mode, anyway.
Thus, the PROGRAMMER structure is unchanged.
> 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.
I have updated usbasp.c and bitbang.c. Because I don't have either one of those programmers I provide the changes as patch files, so they can be tested and applied if everything works.

Best regards,
Hannes


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

bitbang_tpi.patch (2K) Download Attachment
usbasp_tpi.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Joerg Wunsch
As Hannes Weisbach wrote:

> I have updated usbasp.c and bitbang.c. Because I don't have either
> one of those programmers I provide the changes as patch files, so
> they can be tested and applied if everything works.

Hehe, just look at the attached photos, it's really simple to build
these. :-)

However, I cannot get the "ponyser" to produce any usable TPI right
now.  I think it used to work back when I committed patch #7244 in
2011, but even if I revert SVN to that date, it just doesn't work for
me now (TPICLK is low all the time).  Thus, it doesn't make sense for
me to test the bitbang.c patch.

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.

(Besides, the TPI-capable firmware appears to have a bug, too.  It
works well in terminal mode, but when I try reading back the entire
flash using -U flash:r:foo.hex:i, I get an empty file.)

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

ponyser.jpg (81K) Download Attachment
usbasp.jpg (83K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Hannes Weisbach-2
>
> Hehe, just look at the attached photos, it's really simple to build
> these. :-)
I don't have all the parts I need for the USBasp. But ftdi_syncbb also uses bitbang as backend, right? So I can test that with an FT232R.
>
> 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.
Urgs. I read usbasp_tpi_cmd() and though I was ready to go. On a second look, this is just an empty (except error message) function.
I have whipped up a cmd_tpi() function and attached a patch against SVN trunk - maybe it works ;)

Best regards,
Hannes


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev

usbasp_tpi2.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Hannes Weisbach-2
In reply to this post by Joerg Wunsch

Am 08.05.2013 um 16:58 schrieb Joerg Wunsch:

> As Hannes Weisbach wrote:
>
>> I have updated usbasp.c and bitbang.c. Because I don't have either
>> one of those programmers I provide the changes as patch files, so
>> they can be tested and applied if everything works.
>
> Hehe, just look at the attached photos, it's really simple to build
> these. :-)
>
> However, I cannot get the "ponyser" to produce any usable TPI right
> now.  I think it used to work back when I committed patch #7244 in
> 2011, but even if I revert SVN to that date, it just doesn't work for
> me now (TPICLK is low all the time).  Thus, it doesn't make sense for
> me to test the bitbang.c patch.
Ok, I hooked up an FT232R as ponyser (with inverted signals) and that works for OS X and Linux (Windows not tested). Interestingly it was way faster on OS X (100/60 W/R) than Linux (420/270 W/R).
I've also built an RS232-adapter but I don't have a computer with RS232, so I'll have to check on Monday in the lab.

Anyway, it would be nice if someone else could confirm this or report back if the patch works with the Buspirate, Parallel port, and Linux GPIO programmers.

Best regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrftdi TPI support

Joerg Wunsch
In reply to this post by Hannes Weisbach-2
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 up a cmd_tpi() function and attached a patch against
> SVN trunk - maybe it works ;)

Yes, that seems to work.  I can use the USBasp with that.

I've also been able to test your original bitbang patch with my "bsd"
programmer (Brian S. Dean's original parallel-port bitbang dongle).
Works fine as well.

No idea why my "ponyser" dongle currently doesn't want to handle TPI
at all (even though ISP works), but I wouldn't care too much for that.

I'd say, go ahead and commit them.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev