gnupic: Re: [gnupic] Remarks to gpsim of 05/12/2006
Subject:
Re: [gnupic] Remarks to gpsim of 05/12/2006
From:
Robert Pearce ####@####.####
Date:
20 May 2006 23:30:08 +0100
Message-Id: <6PErpIDoO5bEFwl8@jonah.huneausware.local>
On Sat, 20 May 2006, Peter ####@####.#### wrote :
>
>Note that I just made this up. I hope I did not forget anything
>important.
It looked quite extensive, but I think you're re-inventing the wheel
somewhat. GPSim already has an established mechanism for connecting
stimuli via nodes, so it's not appropriate to specify destination pins
in the stimulus file. Indeed that would be a bad idea, because it ties
you to one project. Suppose I have two projects which process the same
or very similar data streams. One of these uses a 12CE519, the other a
16F628. These two processors share no pin names at all so by embedding
the pin names in the stimulus you would force me to create two stimulus
files. GPSim's current asynchronous stimulus system lets me use the same
file for both projects. Oh, and you can stop "supposing", because the
preceding situation is not hypothetical.
I don't think it needs the header with identifier in it. GPSim has no
use for that information that I can see. Providing a comment character
is defined (as is currently the case) then you are free to populate any
information you may want for other tools.
I'm not convinced by the time stamp format. You appear to have defined a
way to specify lots of conflicting combinations of output at the same
time. GPSim will want the file to specify a list of time-stamped events
with only one output pattern being given at any one time. For this, it
seems to me, the sensible approach is to specify that the first column
is always a time stamp. Whether you need three forms of time is also
debatable - the delta from last is possibly a convenient extension, but
the distinction between absolute and start-time relative is redundant.
If you want the times to be absolute, start the stimulus at reset. Mind
you, your description of the examples seems to contradict your
description of the syntax, so I'm not sure whether you meant that.
As for the flexibility to mix analogue and digital, that's probably
useful but not essential. If all the data were defined to be voltages
then digital states can still be represented. Of course, you could
define "H" and "L" as aliases for 5.0 and 0.0 respectively.
I don't think there's really that much need to worry about compressing
the files. From GPSim's viewpoint, compression is an unnecessary
complication, and anyone with enough disk and memory to run GPSim will
be unlikely to run out because of a stimulus file, even with 1000000
samples. But a format that would zip up nicely in case you have to put
it on a floppy or send it by email would be good (and I suspect will
just happen in any case).
For output, GPSim does not need to give names to columns if the format
doesn't need names. The "stimulus file recorder module" would have a
specified number of input pins called "pin1" through "pinx", which you
would connect to the points of interest by the usual mechanism. The file
it creates could then be played back through a "stimulus file input" and
the pins of that module would produce the wave forms recorded by the
corresponding pins on the recorder.
Just my few pence worth.
--
Rob Pearce http://www.bdt-home.demon.co.uk
The contents of this | A new chef from India was fired a week after starting
message are purely | the job. He kept favoring curry.
my opinion. Don't |
believe a word. |
