Knut Schwichtenberg wrote:
Joel Sherrill wrote:
Knut Schwichtenberg wrote:
Joel Sherrill wrote:
Knut Schwichtenberg wrote:
Joel,

I tried your example and currently I don't understand your example. And
therefore please explain the details.
Using 0x20 / 0x21 means PINF and PINE as IO - you can't use these
addresses on a
M128 without a look to the HW-manual.

I was trying to copy the stdiodemo to get the UART connected
to the UI port.  But still use a "magic" port to write debug output.
I guess I need to switch the magic port to a reserved address.
The real app (see below) uses two serial ports.

My AVR ignorance is showing. Sorry.
:-)
Okay, here I can only say: You loose a little. :-( The M128 uses all register in
the IO-space from 0x20 to 0x5f. As far as I understand for these magic ports you
need spare addresses (unused to be more precise) or you are "removing an IO
component from the silicon". Currently I decided to remove PORT "E" which are
the addresses 0x21, 0x22 and 0x23 using 0x21 instead of 0x20 prints the
following out on the shell:

OK.  Makes perfect sense.  Eventually I will need to find something
the real application is not using if I want debug IO.  Luckily in this
case, I think they are using one of the UARTs for debug IO but for
testing the feedback, I wanted all of the IO to go to the feedback
program.  I will just have to find addresses left or do away with it. :)
make dogdb
avr-gcc -g -O2 -mmcu=atmega128 -DF_CPU=4000000 -c -o debugio.o debugio.c
avr-gcc -g -O2 -mmcu=atmega128 -DF_CPU=4000000 -o feedback main.o debugio.o 
uart.o
../simulavr.tcl -d atmega128 -f feedback -s ./feedback.tcl -W 0x21,/dev/stderr
-R 0x22,- -F 4000000 -T exit -S ./simfeedback.tcl -g
User Interface Connection opened by host 127.0.0.1 port 7777
Waiting on port 1212 for gdb client to connect...
Initialize debug io
-uart init--h-h-e-e-l-l-l-l-o-o- - -w-w-o-o-r-r-l-l-d-d-J--O--E--L--
-Connection opened by host 0.0.0.0, port -20541.

Great.  Now you are as far as I am.  Did the "simfeedback.tcl" show
up in an xterm and print messages which look like it is getting the
events but no data from the UART?
As a hint I would suggest to use a common define for the -R and the related C
statement, otherwise ... - I think you know too well.

Agreed.
But I'm confused about the debugger behavior. I'll check in the oldish
checkdebug - style especially find a gdb-GUI :-)


The old checkdebug was attaching to the avr program.  Not
the simulator itself.  The new simulavr.tcl should be able to
do that but doesn't start the gdb in another window yet.
It will get there eventually.

FWIW how to debug simulavr DLL in this mode is unclear
to me.

Thanks for looking at this.

--joel



_______________________________________________
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/simulavr-devel

Reply via email to