Re: [Simulavr-devel] SimulAVR + simulated hardware

[Klaus Rudolph]

Hi all,


"E. Weddington" wrote:
> 
> On 15 Jan 2004 at 10:04, Bruce R'. Miller wrote:
> 
> > On Thursday 15 January 2004 08:31, E. Weddington wrote:
> > > In Ted's defense:
> >
> > I don't believe that anyone here would dream of attacking Ted.  I see a 
> > number
> > of people offering to help out.
> 
> I do too. I didn't want to come across harsh.

First off all:
 I only want to spend my ideas on working on a simulator for avr. Not
more,
not less. Everybode can participate on my work, this is an offer not an
attack!

For me, and I´m only speaking for me, C is ugly, very ugly for ME! Why I
should write the constructor code
for objects while the c++ compiler knows that all whithout writing any
line of code.
The most important thing for me is, that I want to think in objects not
in procedures. There is a register, a stack or a timer. That can be
represented
in classes directly. So why I should use c. But if many peaple have
never programmed with c++, it is a
hard switch to go to c++. I understand that. But that did not help me. 

I started reprogramming the c++ version while I need more features in
simulavr. The external interupts 
on port pins was the first. The next was the correct timer interrupts
and interrupt flag clearing. This
features were not available at my starttime. As I saw the old code from
Tod, I was really a bit confused.
A lot of "pseudo-oop" in c. I spend a lot of time to understand that
code, but I need more time
to got Tod´s ideas as I was able to fit in my solutions.

My solution for this problem: Do it again. For me, and only for me, it
was absolutly faster to reimplement the
complete code with simple c++. My idea was not to build a simulater. I
only need a tool for development so that
I was able to build my main applications on avr. So I spend not so much
time
in clean code for the simulator. My main target was to have a working
tool for my personal needs.

After working one or two weeks my simulator was able to do the most
things I need. After that more and more
features were added. This was last summer. After a break of 4 or 6 month
now, I started to continue with development,
because I need some additional features like external lcd or pc
keyboard. So I also need a lot of
interworking code for use with different targets.

I know and also other guys which studied my code know that some things
are implemented ugly in my solution.
But as I discussed with Bill for example, there is no problem to
reimplement that parts of code, after!
some more features were added and we all know where the train goes.
Currently there are a lot of open
isues. And I don´t know today how to implement the missing features
today. But I implement them step by step.
And after that work is done, I rework that code again, which normally
known as "refactoring". My way
to generate a product is simple: Do it, do it simple, do it now. And if
you find later that decissions was wrong, 
do it again.

On that point of view, I´m not the guy which want to discuss thousands
of hours for a new feature and how the best 
way to implement it. Simply do it now and maybe do it again later if
this was not the best solution.
The time of discussions is better used in implemtation. If we are not
able to make a complete plan on develop a complete
nice simulator with all needed features in, we should not plan it. Thats
it :-)

 

 
> Well does the C++ version contain all the same features as the C version right
> now?

No, not all. The "disp" is gone away. All other things should run. The
current implementation is a lot
slower while more hardware is build in. It needs a bit time to check all
the inernal timers, uarts, spi....
and step their state machines with all the outgoing portpins. Also this
calculated portpins must propagated to
the connected devices... That needs a bit time. In multi-target
simulation there is currently no way
to connect with gdb. This could only be done with the single target
call. In the future this should be changed.
But I have not deceided how to implement that. Multiple gdb´s or some
kind of multitasking support (pseudo threading???)
for one gdb instance... ??? Don´t really know today.

Before anyone ask here: The actual code I can spend is a working copy of
my harddisk. There is no configure, automake,
there is only a handcrafted Makefile and it works with some hand crafted
changes on most machines I hope. If not, we
will find a solution. If anybody out there is able to add the configure
scripts and the portability stuff he/she
is very wellcome to add that to my sources. :-)

Please remember: I do not want to discuss if C++ is better then C. I
don´t want to discuss 
if Tod´s work is "better" or not. Simply I made my tool for my work and
I want to spend my work for you.
Tod´s work is great and I would not be able to start my work without
Tod. Thats it. But I need 
some features that Tod was not able to spend fast enough :-) so I spend
it in my way. And my way is C++ :-)))

Please select what you need and if you can help one of the
two projects, do it. Thats the way open source lives. Please don´t say:
If we have two projects, both projects goes
slower then one could. Thats is not correct in this case. Look at
simulavr++ and you will find a lot of features that
for simulavr are "only in discussion". And my work on simulavr++ will
continue I hope :-). 

I´m wondering a bit that half a year after my first offer this
discussion starts today.  Was there a dark half year with
to many good filmes in cinema???? :-)))

  

Regards
        Klaus