Re: [Simulavr-devel] register trace not longer available?

[Lars Immisch]

Hi,

<snip>

>> I have a few patches open on the tracker that make it possible to run
>> multiple simulations within one process, and also one that allows to
>> implement HasPinNotify in Python.
> 
> Why we need a patch for that (sorry, I have not looked in in the moment)?
> 
> As I could remember, swig wraps simply all header files and this makes
> all methods available. I am wrong?

Basically, yes. But that wasn't the problem. I wanted to create multiple 
devices in the same process, one after the other, as I go though my unit tests, 
and that didn't work.

It didn't work because DumpManager.cpp has the static variable 'devidx' that 
can't be resetted, DumpManager::Remove doesn't do what I expect it to do, and 
SystemClock.cpp has an Add, but no Remove.

My patch implements a static method Reset on the DumpManager that nukes the 
DumpManager instance (and tells the devices they are abandoned). It is 
heavyhanded, and I can try to implement something better, but right now, I see 
no way to have a single process load multiple single devices one after the 
other, or even have one device, but load different firmwares.

In essence, to get what I want, a patch is needed, but there might be a better 
way than what I did.

>> A small bit of code that uses this is here: If you are interested,
>> see here:
>> https://github.com/larsimmisch/arduino--/tree/master/test/simulation
>> 
>>> Maybe we could split up to variants of simulator and try to create
>>> equal interfaces.
>>> 
>>> But the actual version of simulavr is useless for me, because it
>>> only could operate with gdb, but multiple core debugging with
>>> tracing is also broken. :-(
>> 
>> I noticed that the multicore regression tests are broken. I'd like
>> that feature.
> 
> I simply put the very old systemclock.h/.cpp in the src path and
> compile. After removing a few interface errors the simulation links and
> works! Also with multi-core simulation, serialrx/tx is working, the gui
> runs as expected.

Ah. I never got the Tcl gui to work, not even on Linux. I'd be interested to 
see that.

Can you push your cahnges onto a branch? Then I could have a look at it and see 
whether I can get the Tcl gui to run under Mac OS X.

> So I have no idea why there are so many changes in
> that file which only brake the functionality. Maybe I killed some new
> features? I don't know. Can someone help to clarify this topic?
> 
> At that point I noticed that tracing for non core devices was also
> removed. I reentered the feature also, cause the old interface of
> systemclock needs that. After that I was also able to trace the
> serialrx/tx pin changes and so on.
> 
> I also would like to reenable the trace and debug features. I need the
> systemclock time (simulation time in ns) in the trace output and also
> the memory changes and register contents. I have no idea why this was
> removed but it seems not so easy to put that back again.
> 
> In addition the aborts from simulavr while using the trace feature must
> be fixed. But I recently did not understand why there is a console
> manager which rises the errors. Maybe this is a new module which is
> needed by windows? I had not understood that. Can anyone help?

It looks a bit Java-ish to me, but the intention to collect tracing in a single 
place seems good.

> Maybe there is only a big misunderstanding in my use of the actual
> sources? But if so many features have been removed, there is a lot of
> work to bring them back.
> 
> If I am the only user of trace output, it makes no sence, but if others
> also want the features back, we should spend some time for it.

I'd like more trace output, but most of all, I want to be able to create trace 
listeners from a scripting language (in my case python)

- Lars