[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] Trigger external component on clock cycle

From: Lars Noschinski
Subject: Re: [Simulavr-devel] Trigger external component on clock cycle
Date: Wed, 23 Nov 2005 22:00:36 +0100
User-agent: mutt-ng devel (Linux)


* Klaus Rudolph <address@hidden> [2005-11-23 21:23]:
sorry for my late answer, I am again totally busy :-(

Me too, so no problem ;)

I want to trigger some input (port change) each thousand clock cycles or
so. I guess this must be possible, but my C++ knowledge tends towards
zero, so ...

I hope that you can derive from some simple classes like the uart which
gives you an idea how to implement a class which simulates a
synchronous triggered device which has external connections. Please
take a look inside this class first. For detailed questions I maybe
could give a more detailed information.

Ok, I'll have a look at serial*.

If I read the examples and the source correct, I'll need to have an
object, which I connect to the systemclock with Add (or
AddAsyncMember?). Do I have to create a C++-Class which derives from
SimulationMember and recompile simulavr or can this task be done also
from a (Tcl or Python) simulation script?

You could recompile the simulator, or the library if you want the hard way :-)
But you also can write your own main routine and bind against the
library which makes much more sense.

Hm, ok :) I totally forgot about the library ...

If you have a clocked device, maybe every 1000 cycles you simple use
the Add member function with the given time. All async members would be
accessed after each!  step of any! core cycle, which consumes a lot of
calculation time and is not what you would do :-)

Then, I'll need an async member, as I want to have some percent
deviance. Performance isn't really a problem, as I need this for
interactive debugging - and I'm slower than simulavr ;)

You have to create a own c++ class derived from SimulationMember.

It is not possible to derive a class on ITCL base, which comes not from
design of simulavr but of the swig wrapper. This is not really nice,
but it is the price of using wrappers :-)

But you also can write a script which steps the engine "manually" and
change the pin state after 1000 steps/cycles. So you need no new class
and no new main nor a recompile.  If this solves your problem and is
fast enough you could do this in this way.

I could have thought of this solution ...

Thank you for your hints. Problem with simulavrxx is, that it is much
more useful then it seems to be at the first glance; only after I
absolutely needed a simulator, I found out, that it is powerful ;)

When I've some more time again, I'll write some little howto, to make it
a bit more visible.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]