> > 1) a data gatherer on the OGD1 itself
> >
> > 2) a program to control the data gatherer and upload data
> >
> > 3) a program to display the data
> >
> > In most cases, 2 and 3 will run on the same machine, but if someone
> > needs to work remotely, 2 would run on the support machine with the
> > RS-232/USB/Ethernet/whatever link to the test machine, and 3 would
> > run on the machine with the display. 3 can run standalone using
> > data from a regular disk file. Assuming we need to use demand paging
> > of the data, we need for 3 to be able to talk to 2. And it would
> > be convenient if the user could start a new test run directly from 3.
> > We need a protocol for communication between 1 and 2.
> >
> > specify trigger condition
> > specify capture window start and stop times relative to trigger
> > specify which signals to capture
>
> I think we would usually capture them all. The best you could do is
> shave off a few bits.
I'm not familiar with the signals on the PCI bus. Would it always be
necessary to look at the data bits, or would the control lines be
sufficient in most cases? If you can eliminate 32 or 64 signals
then the data would upload faster. And potentially allow storing more
samples in memory.
> Then to be able to specify which ones you DO
> have could cost you more bits.
2 sends 1 a mask. Not that many bits.
If we think we will need most of the signals most of the time
we could leave this feature out. Simplicity is good. There can
always be a version 2 later.
> > We need a file format for the data files.
> >
> > magic string
> > format version number
> > data, including user specified strings for signal names
> > checksum
> > allow for comments (e.g '#' )
> > allow for demand paging (how?)
>
> We should look at VCD format to see if it serves our purposes well.
> If so, then someone could use GTKwave to view the same data.
What is VCD in this context? Somehow Video Compact Disc doesn't seem right.
> > We need a protocol for communication between 2 and 3.
> >
> > Same needs as protocol between 1&2?
>
> No. I think it should be an API, not a protocol. Just a set of function
> calls.
2 and 3 might be running on different machines.
> > We need setup/rc type file for 2
> >
> > specify trigger condition
> > specify capture window start and stop times relative to trigger
> > specify which signals to capture
> > specify resolution (samples per second)
> > user specified strings for signal names
> > comments
>
> Some stuff needs to go into an rc file. We should also be able to let
> the user load some of these (like trigger conditions) in separate
> files. And most importantly, there should be an intuitive way to
> enter them into the GUI.
Yesterday I suggested that the GUI should have buttons for
switch to a different config file
edit config file (launch $EDITOR)
config file = setup file = rc file
It occurs to me that it would be nice to have a way to select a sample
and export that into a config/setup/rc file and make it the trigger
for the next run.
> > > I take it we want plain C for this?
> >
> > C would be a very good choice. Proven, well known, fast, portable.
>
> Just consider development time versus Perl/Python/Ruby.
Cranking out the actual code is the easy and fast part.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
