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

[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




reply via email to

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