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
