Joerg Wunsch wrote:
stk500[v1] 41 s
stk500v2 15 s
jtag2fast 25 s
jtag2/USB 13 s
The first three measurements have been run across the same serial
line, the fourth is only included for comparision.
It's interesting that the JTAG code (that uses larger block reads for
the actual packet payload) is slower than the STK500v2 code (that uses
single-byte reads).
The time took by the application and the system calls is nearly
non-existent (see my previous email
done with time(1): use+sys were very low, that's normal with the high
speed cpu we now have for
years).
Nearly all the time is spent waiting for the serial com so it is
essential to look at all the possible
ways to remove any unneeded serial traffic, especially when there is an
send/expect behavior.
For stk500v2 avrdude now tries to send the lowest number of
'positionning' packets (you have to
position a pointer in the ISP before reading or writing a page of bytes)
instead of setting the
pointer before writing each pages, or never setting it.
When looking at the code for stk500v1, the pointer is positionned each
time before each page write
and if one looks at stk500_loadaddr(), setting the read/write pointer
means sending bytes to the ISP
and then waiting to receive an answer. That could slow the whole process
a lot but I dunno if this
is mandatory for the v1 protocol, or if, like v2, the pointer moves up
automatically after each page
read or page write. If so, we can earn some time here by removing
unneeded positionning traffic.
Maybe some other protocols could also be optimized by looking how they
are implemented and
try to have the lowest possible serial traffic?
Bernard
_______________________________________________
avrdude-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
