[Top][All Lists]

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

Re: [avr-gcc-list] Regression tests

From: Uwe Fechner
Subject: Re: [avr-gcc-list] Regression tests
Date: Tue, 15 Nov 2005 18:49:10 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051028)

Mark E. Scott Jr. schrieb:

Can you simulate devices attached other than an AVR in this simulator?  For 
instance, I would like to simulate being attached to a SPI RTC, some flash 
memory, and a number of devices attached via pins.   If I could somehow write 
code to simulate those, I would be the happiest person!
Well, I don't think, that this is possible in the moment.

There is one open source project, that supports mixed mode simulation for pic processors, but not for avr.
Look at: http://ktechlab.org/

I ask them for avr support, and I want to quote from the answer I got:

One possible route would be to use an existing AVR emulator. As far as I'm aware, Simulavr [http://www.nongnu.org/simulavr/] is the only notable one. Then, you'd then need to integrate the emulator with KTechlab's simulation.

Gpsim, for example, has the simulation logic provided in seperate libraries to the user interface, and so KTechlab uses gpsim's shared libraries for PIC simulation - the next two files show most of how gpsim is used:

Interface to gpsim:

Bridge from gpsim to simulation:

If you wanted to do something similar with simulavr (or another AVR emulator), you'd need to ensure that that emulator provided its simulation logic in seperate libraries, so that ktechlab could load them and control the simulation. As far as I can tell, Simulavr comes in one monolothic program - so using Simulavr as a loadable library would involve coding on simulavr first, and sending patches off to its maintainers.

The only other alternative would be to write your own emulator, or use code directly from Simulavr (neither of which I'd reccommend).

Then there is at least one commercial solution:


Not cheap, and the newest AVR they support is the mega128.

I run my unit tests in the following way:

- all the c code is organized in classes (a struct of date and functions working on this data)
- the state of the class can be read from the pc
- all methods can be called from the pc
- I have a kind of RPC framework on the pc in delphi, so I can call all the methods in the embedded device
- I write unit tests in delphi to test the embedded device.

Not an easy solution, but it works.



reply via email to

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