avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] SimulAVR - Interrupts and display copro


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] SimulAVR - Interrupts and display copro
Date: Thu, 17 Jun 2004 10:31:55 +0200 (MET DST)

Pat Deegan <address@hidden> wrote:

> This may be a faq but I couldn't locate an answer: is there a way to
> simulate an interrupt (timer overflow or uart receive, etc.) while
> debugging with gdb+simulavr?

ISTR at least some timer interrupts are implemented in the simulator.
IIRC, UART send/receive isn't though.  (After all, you'd need to
``connect'' the UART somewhere to an outside data stream for it to
make sense.)

> Are there currently any programs available to use as a display
> coprocess with simulavr?

Last time I've been looking, there were at least two of them.  One is
the simulavr-disp, an xterm/ncurses based register/memory viewer.
This has been the first one at all, and supposedly been used by Ted a
lot during development.

Now, there's also disp-vcd, the comment says it's a VCD file writer.
Offhand, I don't have an idea what a VCD file might be, but somehow
it's some sort of processor status history file or such.

The major drawback of the display coprocess is that it slows down
simulation quite a bit, and you cannot selectively enable/disable it.
You either have to run it through your entire simulation session, or
not at all.  So far, I've been using it do debug assembler code where
it helps to watch each register's contents from instruction to
instruction, while I don't run a display coprocess when debugging
(supposedly more complex) C code.  ``show info'' could still be used
to get the information about registers by the time it's needed.

> Would it be possible to augment such a co-process in order to
> simulate external hardware or events (i.e. get simulavr to *read*
> data from the co-process, for instance to simulate an external
> device or flash)?

I think that's not the purpose of it, and the coprocess doesn't stand
a chance to feed anything back into the main simulator.  However, some
basic infrastructure for simulating IO events is already there, it
only needs developers to write the respective device simulation.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]