On 2006-11-10, Petar Petkoff <p_petk...@nola7.com> wrote:
> On target MSP430F1611 with Self-made Parallel FET msp430-size gives me:
> text data bss dec hex filename
> 39744 72 1086 40902 9fc6 ./dio.elf
>
> latest msp430-gdbproxy with md5sum b4ced0208b029b4a25dc79930477656e
> loads the elf for 2 min and 52 sec
That's one of the broken versions I tried.
> older msp430-gdbproxy with md5sum 133779c83f80cd180822024264f63195
> loads the same elf for 3 min and 12 sec
That one I don't recognize. The non-broken old version from the mspgcc
tools page that I have has an md5sum of 2ecbb4c03430c87a8a0c0b064e61441e,
but that one doesn't recognize any parts that have come out in
the past couple years.
> maybe compared with an older msp430-gdbproxy is slower, but maybe not.
Definitely. Using default write size, the old gdbproxy is
about 30X faster than recent versions. Increasing the write
size makes the newer versions suck less, but they're still
limited to 1 packet per second.
> for comparison here is statistic from my current msp430-jtag tool
> (not latest in the cvs). is 21 seconds, which includes a few seconds
> for compilations, erase and erase check...
That sounds about right. That's 10X faster than the broken
versions of gdbproxy.
> I have the same problem with not recognized device before a year,
> when I started to work with MSP430F1611 (I have used F169 before using
> F1611). This kind of problems always are very nasty. I want to ask all
> msp430-gdbproxy developers if is possible to provide some extra
> functionality of this closed source tool.
I want to ask that it just be un-broken. :)
There's no reason to busy-wait 1 second before sending the next
download packet after the previous one is done.
> I mean to add external configuration text or xml file,
Plain text please -- unless the configuration data is really so
complex and nested that XML-bloat is really useful.
--
Grant Edwards grante Yow! YOW!! Up ahead! It's
at a DONUT HUT!!
visi.com
