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 _______________________________________________ Simulavr-devel mailing list Simulavr-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/simulavr-devel