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

[Michael N. Moran]

Klaus Rudolph wrote:
> 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.

Could you please be more specific about *wher*& to look
in the patch database for this information. For example
patch #4593 only has my original submission comments.

<https://savannah.nongnu.org/patch/?4594>

> 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.

That sounds like a good goal.

> 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.

That's a lot of work to expect up front. Wouldn't it
be better to allow development to continue on an "as needed"
basis and refactor as required? Otherwise, the project
will not move forward because no one has the time to
"do it right".

> 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.

My parser failed on that last paragraph. :-(

> 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 :-)

Can you please give me a patch number. Perhaps that would
help me to understand what you are talking about here.

> 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.

Are you saying that not having an ADC implementation is
better than having a partial implementation? Isn't an
incremental approach more pragmatic than a "big bang"
approach?

> That makes no sence for me. Noby could use it,

Umm. I used it, and I'm somebody ;-)
I used the ATmega48 simulation to test and verify
all of the code for 2 projects. The code was
finished weeks before my target hardware arrived
and months before the target hardware worked.

> 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.

I don't want it either. However isn't it better to
have a partial implementation than NO implementation?

> 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.

My wish is to be able to simulate any of my AVR based
products before I have actual hardware available.

This means that I am looking for a breadth of AVR device
support. I am willing to implement features and peripherals
as I need them (e.g. ADC, SPI) and contribute those
features back to the simulavrxx project.

> 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 :-)

I can not, however, spend the time required to analyze
and implement an entire product line of peripherals and
their variants, since I will have real hardware before
that happens ;-)

Clearly, you do not have the time to do this work either,
so perhaps it is time to try a new approach.

mike

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1