simulavr-devel
[Top][All Lists]
Advanced

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

Re: [Simulavr-devel] AVR testing [was Re: Revised release criteria for G


From: Klaus Rudolph
Subject: Re: [Simulavr-devel] AVR testing [was Re: Revised release criteria for GCC 4.0]
Date: Thu, 16 Dec 2004 08:46:52 +0100 (MET)

> Bernardo Innocenti wrote:
> 
> > Hans-Peter Nilsson wrote:
> >
> >> The presence of a turn-key simulator as per simtest-howto.html
> >> makes it *immensely* more simple for others than hardware
> >> holders to regression-test their GCC changes, verify bugs and
> >> fix them.  So all the shouting from AVR enthusiasts is suggested
> >> be better spent getting an AVR simulator and a newlib port in
> >> the tree.
> >
> >
> > I forgot to say that the AVR simulator is a GPL'd project
> > on Savannah:
> >
> >  http://savannah.nongnu.org/projects/simulavr
> >
> > There's also a gdb-remote debugger for JTAG ICEs:
> >
> >  http://sourceforge.net/projects/avarice/
> >
> >
> > AFAIK, these projects have never tried merging into
> > gdb... and perhaps they should consider it.

Speaking for simulavr it makes no sense to try a merge into gdb.
The simulavrxx actually provide a lot more functionality which is 
not directly related to a source level debugging tool. Gdb only add
the features for debugging, all the rest fom simulavr could never be catched
by any kind of general debugger. A simulator is not a debugger and it make
no sense to integrate both I think. And gdb is a general target independent 
tool which all the existing simulations never could be. If you want to
make them more general you allways will loose flexibility and also speed.
And speed is absolutly important for a simulator. 


> Bernardo,
> 
> Both of these projects are going through upheavals at the moment for 
> different reasons. SimulAVR is going through changes to its internal 
> architecture, and new management has taken over.

After a break of two month now I think the internal structure descussion 
has ended because there is no energy for doing it. And it is not important
to do
the change because all is working as I know. I will provide the
missung uSart and the twi and then the platform seems to be complete.
The rest is only picking the hardware parts into the controler environment
for
all the different devices. But this is nothing to think about. The mega
devices
are nearly all the same and adding another constant for flash or ram size is
nothing which must be spoken over.


> Both Avarice and 
> SimulAVR (and many other AVR projects) have just lost a long time 
> volunteer developer due to health issues,
for simulavr yes, for simulavrxx no. The project is maintained and
development continues. :-)


> and this developer just 
> happens to be the AVR port maintainer for GDB. Avarice could be in need 
> of new maintainer. So a lot of things are in flux right now and there 
> seems to be some interest into finally getting a system together that 
> can do more simulation as well as be used for running the testsuite.

Absolutly ACK. The actual simualtion can do lots more then testsuites. :-)))
Look for the details like 
- interrupt statistics
- runtime analyzsis
- full trace
- multiple device simulation including netlists for connected pins 
- simulated external hardware like ttys, LCD and some others...
....

> But 
> this is getting OT for the gcc list, better to take this to the 
> avr-gcc-list <http://www.avr1.org/mailman/listinfo/avr-gcc-list>.

Abolutly no theme for gcc. It is avr-gcc and simulavr.

Regards 
    Klaus

-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++




reply via email to

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