gnupic: Re: Trace logging in gpsim


Previous by date: 6 Sep 2000 18:15:33 -0000 Re: Trace logging in gpsim, Scott Dattalo
Next by date: 6 Sep 2000 18:15:33 -0000 Quick port of Janusz J. Mlodzianowski's MediumC to linux, D. Jeff Dionne
Previous in thread: 6 Sep 2000 18:15:33 -0000 Re: Trace logging in gpsim, Scott Dattalo
Next in thread: 6 Sep 2000 18:15:33 -0000 Re: Trace logging in gpsim, Scott Dattalo

Subject: Re: RFC: Trace logging in gpsim
From: "Daniel Christian" ####@####.####
Date: 6 Sep 2000 18:15:33 -0000
Message-Id: <5f9dcd122753ea0b.2753ea0b5f9dcd12@smacker.x.cx>

I think this is a great idea in one form or another.

Personally, I want some kind of scope/logic analyzer functionality.  I
want this to work either in real time or from a saved file.  Being able
to verify serial IO, or I2C, or interrupt response time would be great. 
Dumping things in hex format would be easy to work with without wasting
too much time on formatting.

The other trace feature that I want is to be able to back step through
the instruction sequence.  I want to be able to set a breakpoint at an
"abandonAllHope" point, and then back trace to figure out how it got
there (and why).

I don't care so much about logging everything as being able to dump the
log to a file.  Of course, this works fine as long as the fixed trace
buffer is "big enough".

I modified the trace output to put out one line for every cycle.  This
is far from perfect, but I find it much more readable than the current
style.  I can easily see all the things that happened during that
cycle.  It can get really wide.  I better form would break the line and
indent properly.  Let me know if you want the patch.

Would there be a way to extend the trace mechanism?  As you add modules,
you may want a way to catch new internal state.

One other question.  Can gpsim actually handle a multi-processor
system?  The JRKerr servo controllers use two PICs (one for control and
one just to count the encoders).  There are situation where this is just
what you want to do to get guaranteed response times.  Debugging the
interaction could be tricky unless you could simulate both at the same
time.

-Dan Christian




Previous by date: 6 Sep 2000 18:15:33 -0000 Re: Trace logging in gpsim, Scott Dattalo
Next by date: 6 Sep 2000 18:15:33 -0000 Quick port of Janusz J. Mlodzianowski's MediumC to linux, D. Jeff Dionne
Previous in thread: 6 Sep 2000 18:15:33 -0000 Re: Trace logging in gpsim, Scott Dattalo
Next in thread: 6 Sep 2000 18:15:33 -0000 Re: Trace logging in gpsim, Scott Dattalo


Powered by ezmlm-browse 0.20.