[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:
https://svn.fadedminds.com/ktechlab/src/electronics/gpsimprocessor.cpp
Bridge from gpsim to simulation:
https://svn.fadedminds.com/ktechlab/src/electronics/components/piccomponentpin.cpp
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:
http://www.labcenter.co.uk/
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.
Regards:
Uwe