On 2006-11-15, Chris Liechti <[email protected]> wrote:
>> Downloading via parallel port and the --debug option both seem
>> to have been broken since April.
>
> maybe some internal debug compiler switch was left on
> accidentally. I've seen this too. Steve?
>
>> Is there any way one can get access to the source code in
>> order to fix these problems?
>
> unfortunately it's not that easy. the MSP430 specific code is
> not freely available (needs a NDA with TI).
I'll sign one if it will allow me to fix gdbproxy.
> the non-MSP430 specific parts of msp430-gdbproxy are in our
> CVS, but that's probably nothing that helps you :-(
Not really. ;)
FWIW, I've got things working acceptibly at the moment by using
large download packet sizes and starting msp430-gdbproxy like
this:
(setsid msp430-gdbproxy msp430 2>&1 | grep -v '^debug:') &
Still, it would be nice to have that 2-3X download speedup that
would result from not busy-waiting for 1-second before sending
each packet. The download packet size appears to max out at a
little over 2KB. It just doesn't take that long to send 2KB out
a parallel port, so limiting it to 1 packet per second is still
slowing things down considerably.
FWIW, even though gdbproxy only sends one frame per second, it
still uses 100% of the CPU (regardless of packet size). Using
100% of a 2GHz cpu to send one 39-byte packet per second just
isn't right. If you want to delay before sending a packet,
just call sleep(). ;)
--
Grant Edwards grante Yow! I'm shaving!! I'M
at SHAVING!!
visi.com
