gnupic: gpsim: TMR0 has 3 nibbles?
Subject:
Re: gpsim: TMR0 has 3 nibbles?
From:
John Sutton ####@####.####
Date:
6 Sep 2001 17:41:42 -0000
Message-Id: <01090618343200.25323@diva.localdomain>
Scott
>>While I have your attention, can I ask what facilites are currently available
>>for logging outputs. I've seen the trace facility but I can't see how to dump
>>it to a file? And in any case, it's a bit too verbose to be easily processed.
>>What we really need is a dump of instruction cycle count against output latch
>>state for a given output. We can then use this to draw a graph. Maybe the
>>gtk+extra stuff is about drawing graphs of outputs? I'd appreciate any
>>pointers to relevant documents.
>
> There's an unannounced feature in the trace logger that will dump to a log
> file. It's currently lying domant. The problem with it is that it
> generates way too much data. In a matter of seconds you can easily
> generate a 100Meg log file!
>
> As you note, the log files are very verbose. gpsim logs nearly everything
> it does. So for file logging to be useful, I see two features that need to
> be added:
>
> 1 - Logging Filter
> This will allow you to choose what things get stored in the logfile
>
> 2 - Structured reporting
> This will an external parser to easily interpret the info present in
> the log file.
>
> Any others?
Those 2 cover my requirement, certainly. I'm writing a UART (don't ask why
we're not using a PIC with a built-in UART ;-(.
If I could get a log of the state of an output pin in the format of the stimulus
file, I could feed both to a graphing package and get "real" timing
diagrams out. Looking at those is sure going to beat "raw thinking" when
dubugging the little beast!
In your description above you mention an unannounced feature? Hey, it is still
unannounced by me 'cos I can't switch it on! I'll dig about in the source...
if can hook into that, I can organise a pipe to a concurrent task doing the
graphing "real-time"? But just to hook it into a file would be great. If I
could put the Window/Trace format (in the trace viewer window) into a file, a
little sed'ing will give me the stimulus file format.
> Several times I've looked at adding plotting support to gpsim. It
> certainly has its appeal, but I've always backed away. I like the
> flexibility that an integrated wave viewer provides. It's interactive (or
> can be made so), it can be customized (e.g. you may want to have the wave
> viewer decode a pulse train the way a UART would), etc.. Third party tools
> such as gtkwave or gwave are promising alternatives. gwave in particular
> is nice in that it's possible to customize it with guile scripts.
I'll have a look at these and see if I can understand them.
Initially, I thought that another approach (for what I want) might be to
get/write a gpsim "module" such as the LCD decoder, but you haven't mentioned
this so far. Presumably this is how you would implement an
(integrated) interactive wave viewer? My "pipe log data to a
concurrent graphing task" would never be able to support interaction, but
still, it would be better than nothing and (I figure) a lot quicker to
implement (if the graphing tools - gwave, etc - are suitable for the purpose).
John
PS When I do a reset, my stimulus is not reset. How do I reset the stimulus
ready for another run, other than by starting over?
PPS I'll write you a "RedHat-compliant" gpsim.spec! Your current version is a
"riot of omission" if it was intended for use on RH? I don't know how other
vendors (Suse, etc) do their thing.
***************************************************
John Sutton
SCL Computer Services
URL http://www.scl.co.uk/
Tel. +44 (0) 1239 711 888
***************************************************
