David Brown wrote:
Hi Arnd-Hendrik,
I did not realise that msp430-gdbproxy accepted a parallel port like this
(although I knew about the choice of tcp/ip port for communicating with
gdb). That would certainly be a help if I can first get access to the
second parallel port.
the argument is passed to the HIL.
Unfortunately, my PC (like most these days) has no ISA slots, so I can't add
a second ISA parallel port. That would probably have worked straight away,
since HIL.c has the second ISA bus parallel port address hard-coded.
you could use a parallel port switch and try switching while the CPU
runs. you can also try to reconnect without downloading. but of course
that not as confortable as having both debuggers open at the same time.
(if you had a second PC, you could also run gdbproxy only on that one
and connect from the other box over TCP/IP. that box does not need to be
fast or have much memory as it does not need to run a full IDE or debugger)
And unfortunately, I'm not running Linux (except as colinux) on this
machine. It looks (from HIL.c) like it would be easier to get things
working with Linux, even with a PCI parallel port, since HIL.c passes
requests down to the /dev/parportX driver rather than trying to guess the
direct hardware address of the parallel port.
windows does not seem to have a API for parallel port bit-banging (just
limited printer access). that's the reason HIL.c does the lowlevel
stuff on itself. there is currently only a (Windows) implementation for
the old ISA style IO mapped devices. to my knowledge, the PCI devices
are not mapped to the IOs, but to the memory (which are different
concepts on the x86 family processors)
if somebody knows of a free higher level API that allows bitbanging
access to the parallel port, it would eb nice to know about it ;-)
chris
