> > Once the file format is designed, a "fake" data file could be
> > generated, and the display application could be developed using that.
> > So the display application developer doesn't need access to the
> > hardware.
>
> I hadn't thought of that. There should be a way to dump the entire
> trace to a file and then examine it later. Now, THERE's an instance
> when some simple compression would come in handy.
Compression? Unix lego commands to the rescue:
$ grab_ogd_pci_data --cmdfile grab_setup_345 | gzip --best >
test_run_345.gz
It occurs to me that it would be useful to have some config/setup/rc
type file for the grab_ogd_pci_data program. This file would
specify which signals to save, describe the trigger to use,
specify the window of time to record relative to the trigger,
etc.
Then, when developer A, who has actual hardware, wants to show a problem to
developer B, who doesn't have hardware, they can send the files
test_run_345.gz, grab_setup_345, and display_setup_345. Developer B runs
$ display_ogd_pci_data --cmdfile display_setup_345 test_run_345.gz
and can see the problem, and then scroll/zoom/etc. on the entire dataset.
If more/different data is desired, developer B creates grab_setup_346
and asks dev A to do a new test run.
Once we get to the GUI version of display_ogd_pci_data, a button to create
a display_setup_345 with zoom and scroll data to recreate the current display
would make this easy.
Another useful feature for the GUI display program would be to have a bunch of
markers available. Then dev A can say "look at signal 2 at marker 1".
Otherwise
we get to do something like import a gif into xfig to add a red arrow.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
