Re: [Simulavr-devel] Is this project still alive?

[Klaus Rudolph]

Michael N. Moran schrieb:
> Klaus Rudolph wrote:
> > All the open patches are not really out of problems, so I
> > could not patch them in with no side effects.
>
> Klaus,
>
> If you would like to enumerate and discuss the issues
> that you see perhaps I could help you work through them.
> I do not know about any objections that you might have.

As I have in mind, all the patches have some side effects as also noted 
in the database. For a first overview simply look in the patch database.
I actually could spend to much time to go through the list myself, so it 
is only a backup of my mind which is not realy good enough for a 
deatiled technical discussion.

If I restart to work through the things, I have done the work myself :-)
So I am a bit in a gap of time to do the things myself or help you...
terrible, I know.

As allready discussed later, my strategie to become a more powerfull 
simulavrxx I (and this is realy only my wish) want to have all the 
hardware features from the avr family implemented in classes and set up 
all the known devises. But for this, we have no information whcih 
hardware components are really campatible (the same!) and which have 
small or big differences. All what I/we can do isdigging through all the 
datasheets. And yes, I have no fun for that. There are people from atmel 
on the list but we never get any information on this topic. I asked 1000 
times for that task, but heared nothing. I can´t tell you why Atmel is 
not interested in a open source simulator. Maybe you can ask again!

All other thnigs, also having allready some patches is to enable special 
features in the "outside" world, like have python scripting or add ons 
for electrical simulations in "outside" programms. All these are nice 
things, but I (and this is also only my personal opinion) would only put 
these things to the mainline, if they will not have any side effects. 
One of the open patches will disturb my Pin/Port class in a way that my 
"normal" simulations will not run anymore, because the reflaction of the 
pin status comes from the "outside world" which is not what the actual 
design is made for. Maybe I have not understood the problem but it was 
not as important for me :-)

All the build problems are on the side of Bill. If he have time and fun, 
he will make a new release to fix the latest problems which comes to 
simulavrxx while the environment on typical distros change. simulavrxx 
depends on some tools like tcl/tk. So we have to keep track of the tools 
which costs a lot of time. Other tools make it much easier, they simply 
include all the needed stuff in the own project and have a constant 
build and a own "world view" in an absolutly insulated own world. But 
this is also not a thing I want.

Any ideas for that?




> > It makes no sense I personaly think to have a new AD
> > component which will not work as in the original
> > hardware.
>
> I agree with you in principle, and it has been a while
> since I have looked at that code, but as I recall it
> *does* behave like the original hardware. Again, please
> elaborate on specifics.
>
> I just assumed that the project was dead or at least
> in suspended animation. I know what it is like to run
> out of time to work on these projects, especially if
> they are not scratching a particular itch :-)


A very simple question :-)

which features are missing??
If we need the AD part of mega devices, we have to implement all the 
stuff: IO/selection, differential/single input selection, /gain control, 
... not only one channel without any other functionality. That makes no 
sence for me. Noby could use it, because the target avr code has to set 
up the registers and having dummy registers is not a thing I want to 
have in the simulator.

we can start a list of whishes here. My one is to make mega128 complete, 
after that implement the usb stuff for 1286/7 parts. After that pwm devices.

Having that, we can elaborate the differences between the parts and 
start refactoring for the unique/different hardware ip´s . But without 
the atmel list this is a job for paper recyclers :-)

Whats your opinion?

bye
  Klaus