[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] Re: simulavr 8515 now nearly complete
Re: [Simulavr-devel] Re: simulavr 8515 now nearly complete
Sun, 27 Apr 2003 19:39:49 +0200
> > 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
way a chance. That is not a designe decission for the official simulavr
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
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
> > 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
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
in a normal way so there is only some avr specific stuff which give some
but can be replaced with the #ifdef. Any other ideas? What kind of
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
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
is prepared but not defined from the "other" side (the external
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
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 :-))))