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

[Onno Kortmann]

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. 
How do you model external hardware/periphery of the AVRs? I am very interested 
in this,
because I think that there is a lack in simulations for external components
and I like to know how others do it. I connected simulavrxx to icarus verilog
and in my private branch, I have it also working for verilator, which is
a lot faster. It would be best IMO to have a repository of interconnectable
device simulations (LCD, AVR, PIC etc.).
I also have a half-working SD/MMC SPI simulation in verilog which I can
then connect through verilator/icarus to simulavrxx do simulate SD card file 
systems etc.


> 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)
I think this functionality overlaps partly with a patch I have made 
(the one on the savannah tracker is now seriously outdated btw. but did not 
seem to generate
any interest anyway) which basically
implements a new tracing infrastructure in simulavr and allows to write
state change data (currently only value change dump, but my new version is 
extensible).

> So my second question: is there interrest to implement such?
Yes! But maybe we should combine our efforts. If you want, I could send you my
tracing patches, or even better, simply put them onto github.com if 
this would not upset any of the maintainers -(??) (I would only consider this
an unofficial fork with stuff to be integrated into simulavrxx)

> Connected  
> with that: How to send in patches?
I sent them through the savannah tracker which is quite cumbersome. I like
to reiterate my wish for an official git repository here, where external 
contributors like me
could have their own private branches with more experimental stuff.
As the maintainers try to keep the simulavrxx code as stable as possible
(which I think is generally a good idea), there is not so much room for 
experimental
commits with half-working features which may be abandoned at one point.

OTOH, I think that private branches for all the people who tweak simulavr
would make it easier for such changeset to be publically available and also 
easier for other to be tried out. (No more failing patch hunks etc.)

And CVS branches are a PITA or will quickly become one.

> Is there a programming style guide  
> for simulavr, means, how to write, indent and so one code?
From some private eMails with Klaus (please correct me if I'm wrong), there is
no consensus on coding style in simulavrxx and everyone simply reindents 
everything
as wished.

I do not think that this is a good idea, I'd like to have a coding standard.

> What's with  
> code documentation? (I have seen, that sometimes somebody has inserted 
> doxygen comments) 
Yes, that's me, I also have some more docstrings inserted in my private branch 
(as well as
the doxygen config file etc.) but with the slow submit and approval process,
I did not bother to send them upstream yet :-)

> Especially, what's with tab usage? 
See above :-)
> 
> 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.
Great, maybe I can snatch some of your code for my Atmega8 :-) Did you
look at my python device generator code?

> 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!
Hmm, out of curiousity, I tried to built it once and it went successfully for 
me,
including the import in python. Unfortunately, I never went on and did anything
sensible in python, as I try to keep as much as possible in verilog.

> 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.
Well, I think that with only TCL and python, everything should stay in 
simulavrxx
and be selectable with a configure switch (as it is today). I do not see the
reason to split it, especially because I think it will become desynchronized 
from
the rest of the code in one way or the other and there will only be a 
constrained set of 
simulavrxx + simulavrxx-python combinations which will work. For a project of 
this
size and with the given development activity, I do not think it is a good idea.

Best regards,

Onno