> > Create library with functions to handle "demand paging",
> > checksum verification, etc. to be reused by GUI version.
>
> Perhaps we can start by designing the interface for this library? Then=20
> we can create a stub that returns dummy data, which the UI people can=20
> work with while the hardware and low-level software is built.
If we look at this top-down, we have:
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
specify resolution (samples per second)
enable/disable capture
upload data range a,b (should this be in bytes, samples, ... ?)
error detection and handling
inform that capture is started
inform that capture is completed
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 need a protocol for communication between 2 and 3.
Same needs as protocol between 1&2?
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
We need setup/rc type file for 3
specify fonts, colors, styles, ...
specify display window relative to trigger (horz scroll)
specify vert scroll
specify zoom factor
specify markers
specify text string for window title bar
specify text strings to be displayed (somewhere)
comments
We could probably have a single setup/rc file for both 2&3.
What have I left out?
Are there existing protocols or file formats that we could use
and gain compatibility?
Once we have this, we can work on the library functions.
> I take it we want plain C for this?
C would be a very good choice. Proven, well known, fast, portable.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
