Hi,
I started a few weeks ago using simulavrxx. My goal is to use simulavr
for unit tests against my avr code. (I use AVR controllers for longer
time, but not with simulavr) I have made such for PIC controllers
together with gpsim and found it really usefull, to develop software for
such controllers with a simulator and with unit tests. The main
advantage is, that you don't need hardware for this and you are able to
do much debugging work, especially, if it is connected with timing.
After this bring your software working on real hardware is easy work.
(if you compare this with development and debugging in real hardware
only, of course)
For writing tests I use Python. On PIC and Gpsim communication to
simulator is made over std in/out and expect. (GUI isn't used in this
case) On simulavr I started this using gdb remote serial protocol. (like
in opcode tests here, I have seen this after I have developed this
interface for myself, so I have developed wheel second time ... ;-) )
To get out timing by gdb remote protocol I have extended for myself
gdbserver.cpp with a special protocol packet for transfering target
frequency and simulation time. I had some mails with Jörg Wunsch (over
mikrocontroller.net a few weeks ago, only for information for Jörg)
about it. He suggested to ask gcc-avr developers, if there is interrest
and how it could used there. So my first question is: does somebody here
know, who could I contact for such things? (I can seek forself, of
course ;-), but why not use experience of others, if available)
Then I would also extend gdbserver.cpp with a working "qSupported"
paket. Especially to transfer "PacketSize" feature to know, what's the
packet limit. If you send packets, which are to big, to simulavr, it
crashes. In gdb docu is explained, that if no "PacketSize" feature is
supported by gdb server, then size of "g" packet (read content of all
registers) must be used for this purpose. But avr-gdb seems not to use
this. (there is no "g" packet before memory write transfers to load
program) Maybe it assumes a fixed limit.
So my second question: is there interrest to implement such? Connected
with that: How to send in patches? Is there a programming style guide
for simulavr, means, how to write, indent and so one code? What's with
code documentation? (I have seen, that sometimes somebody has inserted
doxygen comments) Especially, what's with tab usage?
Next: I started to implement (also for myself at first) ATMega16
controller. timer0 and timer2 now work with most features (timer0 and
timer2 are similar, only prescaler is different). To check, if this
timers work correctly, I use again my unit test equipment. Timing inside
controller should work, but I need some extensions to stimulate external IO.
This brings me to a next hotspot. ;-) I have seen, that there was a
discussion about python extension. In the moment it's commented out in
makefiles and, if python modul will be built, then it's not usable: an
import error raises, because of an missing symbol! (I havn't really
analysed, why, because it looks so, that nobody use this in the moment)
So my first tests on this area was to "replace" main.cpp by an python
module (by using SWIG also, but not simulavr.i) and a little python
script. I think, this could be a base for a "restart" of a python extension.
For such work it's to know, what are the goals for such? Who want's to
use it and for what? I think, it's not a real good idea, only to put
"all" into such extension module like the current module does.
Especially if some features (methods and class members) aren't usable
without special preparations.
For understanding: I know TCL, I have used it a few years till I found
python. :-) And if somebody agreed with the available TCL extension, why
not use. I have no problem with that. (even if I don't use it, of course
;-) ) I would propose, that a python extension isn't deeply integrated
into simulavr. Means, python extension and all files for building it are
separated from normal source. So simulavr could be built as normal
without extension and if somebody needs it, then it's possible to built
on top of normal simulavr (I need only header files and libsim.a, so
it's also possible to hold it completly separated, if header and
libsim.a will be installed to, for example as a simulavr-dev package)
So, enough material for now ... :-) Feel free to ask, if something isn't
clear. (and, I hope, that I've not made to much mistakes)
cu, Thomas
_______________________________________________
Simulavr-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/simulavr-devel
