Re: [avrdude-dev] avrftdi TPI support
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 avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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--+ +---TPIDATA TDO/DI--R--+ TMSRESET (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 avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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
bitbang_tpi.patch
Description: Binary data
usbasp_tpi.patch
Description: Binary data
___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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!):
SCKTPICLK
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
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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 avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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 hannes_weisb...@gmx.netwrote:
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
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
___
avrdude-dev mailing list
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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
avrdude-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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 avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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!): SCKTPICLK 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 avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Re: [avrdude-dev] avrftdi TPI support
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 avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
