[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Any SimulAVR or avrtest users out there?
From: |
Georg-Johann Lay |
Subject: |
Re: [avr-gcc-list] Any SimulAVR or avrtest users out there? |
Date: |
Wed, 11 Mar 2009 21:09:41 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.7 (Windows/20050923) |
Weddington, Eric schrieb:
Hi All,
There's a lot of new work being done at the SimulAVR project:
<http://savannah.nongnu.org/projects/simulavr>
Specifically the "old" simulavr project hasn't had much maintenance
done on it in years. There is an "avrtest" project (hosted at WinAVR)
that is used exclusively as a simulator for the GCC Regression Test
Suite. The newer, C++ based simulavrxx is being worked on heavily,
with the intent that it will supersede both the old simulavr and
avrtest and include as much functionality from both as possible.
We would like to turn the simulavrxx branch into a best-of-class AVR
simulator that will work for all of the use cases, on all platforms
that the AVR toolchain is used on, so we don't have various project
forks that don't work effectively for all. At some point we would
like for the old simulavr and avrtest to go away and to be able to
use the C++ based simulavr for everything.
The question has to do with backwards-compatibility. How much
backwards-compatibility should we have to the old simulavr? How many
people out there are using the old simulavr? What features are
absolutely required? How hard would it be to change how you are using
the old simulavr?
IMO it is absolutely required that a simulator can run as gdb server for
avr-gdb.
Stand alone simulators like avrova seem not to have this functionality.
I just skimmed the avrora site and saw no note pointing in that
direction, maybe I middes it.
Some Nice-To-Have features:
-- run in gdb server mode
-- code breakpoints
-- data breakpoints
-- breakpoint on SP to detect stack overrun/underrun (hard because SP is
two SFRs)
-- query ticks since some milestone
-- logging/dumping (what instruction is being executed, what GPRs,
SREG-Bit is changing, etc)
-- can simulate some internal peripheral that triggers IRQ, so that ISRs
can be debugged and tests be written for ISRs
Georg-Johann