[Simulavr-devel] Python again ;-) and some other things

[ThomasK]

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