Re: [Simulavr-devel] Re: simulavr 8515 now nearly complete

[Klaus Rudolph]

> > Nice. My problem is, that i started at version 0.1.1. and reworked
> > the complete sources. So I think there is no way for a merge in source,but
> > a merge with ideas .
> This is a little bit bad. What is it good for if we have 2 incompatible
> simulavr versions?

To have two versions with same functionality is bad.
My start point was that I need a simulavr with all working hardware
components with a timing correct trace functionality. So I
started to look inside the simulavr sources and found a lot object
oriented C code. I think, but that is only my personal opinion,
that object oriented C code could be better and easier written in c++.
So I started to reimplement most things in c++. The next thing a made
was the assembler parameter calculation in decoding stage. That
is actual also done in the cvs simulavr from Tod, so we made the
same work both :-(. 
For me it is much easier to read/write c++, so I decided to give that
new
way a chance. That is not a designe decission for the official simulavr
at all.
If my work will be lost, ok, thats only my problem....

> 
> > > What I've done is:
> > > - Changed the handling of the register layout(device dependent instead of
> > >  the
> > > constants defined in the source code)
> > My idea is to bring them up in the device constructor. There is a mapper
> > class which handle the device depend register layout to the
> > implemented hardware class. This is allready done and works.
> My way is to keep a table for each device that contains the position for each
> bit in the registers. This table is also a feature definition as you can do
> checks if a bit is existent and if this check fails you know this feature is
> not present.

Yes, I not finished that point at all. One point is that calculating
"hidden" bits which will masked out later is a bit expensive here. So I
will
maybe split the timer 1 in acra, ocrb and so on and build a new
class BitAtRegister maybe. But that is also a bit expensive for runtime.
I will try both I think :-)


> 
> > > - Added Timer/Counter1,2,3 and OCR0,1ABC,2,3ABC support
> > Timer 1 (avr8515) is complete with all OCRx and pwm mode
> How did you implement pwm? The user must see the state.
The pins are handled. So you can see them outside and a few 
days later, maybe end of next week I have a way to set stimulus from
outside here.

> 
> > Also now working eeprom with all waitsates.
> Even with an clock and voltage dependend timing?
Yes and no. Currently I have a constant cpu-clock to internal timing
faktor (also for wado). That can be removed to a external setup
variable at all, so we are able to set the
correct voltage dependend timing here. (Should only a few lines of code
:-)
It is prepared for.

> 
> > EEPROM space reachable from gdb read/write.
> Nice feature. Can you please publish the sources so I can give it a look?
> Maybe Ted Roth can upload it to the simulavr homepage.
Yes, that is what I also prefere to make the discussion on facts :-)
If Tod can give a bit disk space :-). I have no possibility to put
my sources somewhere now. :-( But I try to ask a bit around my friends.



> 
> > > - Changed the interrupt mechanism to match the real device behavior
> >
> > Complete reworked. Now the flags are resettet if neccecarry, everytime
> > one instruction is handled before next irq is handled and so on. The timing
> > (4 waitstates for stack operation) is also in.

> Where do you clear the flags (When raising the interrupt or in the Interrupt
> routine)?

If the hardware clears the interrupt while executing the vector I will
do excact this.
 

> BTW: Did you correct the behaviour of clearing flags? (Clearing in simulavr:
> writing a 0 instead of a 1)
I clear with writing a logical 1. 


> > > - Added some new devices
> > Yes. I have currently only the 8515 inside.
> I'm working on a converter to generate to positions of bits and the interrupt
> table from the avr-libc header files.

Very good. But what is the problem to bring there some #ifdef simulavr
in the libc-files? I think there must not a converter. The bits are
defined
in a normal way so there is only some avr specific stuff which give some
trouble
but can be replaced with the #ifdef. Any other ideas? What kind of
converter 
do you mean. awk/sed?

> > The next step is to watch out for really!!! equal hardware blocks.
> > lot of minor changes from device to device. So that is really a lot work I
> > think. I watched out for 2313 with timer 0/1. That are not the same :-(
> > (OCRB missing)
> Not needed. Just check if a feature is present or not. See above.
> There are not a lot off. There are a
??? rest of sentence dropped by email delivery????
Yes, as deiscussed a few lines above I will look for creating some more
devices. If I work on it I get an idea of differences are really
important.
So that descission will need a bit time.

> 
> > I also added a way to bring the pins outside the simulation and from
> > outside to the core. There could be a TCL/TK application that shows the
> > pins and let input values there. This is one of the next steps.
> Super! This was one of my most important problems.
No problem. It is only a question of how to do that. The interface for
it
is prepared but not defined from the "other" side (the external
application).
I will have a way to use external simulations with leds/lcd´s and so on
:-)

> > And importent, there should be multiple cores run with interconnected pins.
> I don't think this would be widely used.

That is my main feature. I work on a model railway system. There are
many avr controllers
talking over a new serial bus system. For real checking all my features
I need a multiple
core simulavr. It is also possible to run multiple simulavr, that is not
the 
decission yet. But I need a inter-device pin-to-pin connection to make
multiple avr cores interconnectable to simulate the complete model
railway bus system now.
Different clocks needed!
 


> > Seems to be a litle step now. What I prefer is an interworking with some
> > well known electronic simulator.
> Ok, that's better.
Yes, any idea´s? What is a free tool with sourcecode available?

Give my a url to download. If the tool works I will bring simulavr in
:-)
In hope that I will not also rework the electronic simulator then :-))))

Bye
        Klaus