On 1/5/07, Dieter <[EMAIL PROTECTED]> wrote:
> > 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.
Not convenient. Absolutely necessary. From a usability standpoint,
there's no good reason to have them separate. Now, 2 may be a library
that's used by 3, and that's good engineering, but it does us no harm
for 3 to contain the "baggage" from 2, even when you're not using it.
In general, 3 and parts of 2 would be in one thread, and then the rest
of 2 would be in another. But from the user's point of view, they're
not separate components. To the developers (us), the threading is
there to maximize UI responsiveness and to make sure we don't lose any
I/O while the UI is busy. Even better, there's 2, and there's 3, and
then there's some glue code and thread code that goes between them.
And they compile (or interpret) as one program.
This is one of those situations where a user-centric top-down
methodology is going to yield the best result, because many things
we'd think to engineer for efficiency just don't need to be efficient.
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. Then to be able to specify which ones you DO
have could cost you more bits.
specify resolution (samples per second)
Yeah, we could provide a number of options for this.
enable/disable capture
upload data range a,b (should this be in bytes, samples, ... ?)
Samples. A sample is a fixed amount of data that is then compressed,
making the return data packet variable sized.
error detection and handling
inform that capture is started
inform that capture is completed
All good!
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.
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.
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.
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
Basically, stuff that most users won't touch. :) But if we can, we
should integrate into the GNOME/KDE/whatever environment by inheriting
these properties, as well as allowing the user to override them for
the application. This is something that should NOT be changable from
within the app, because it's not a usability concern. It's aesthetic
and rather advanced.
We could probably have a single setup/rc file for both 2&3.
Yeah. Since they'd usually be one app, that makes sense. But we can
distinguish between the properties for one and the properties for the
other by how we name them.
What have I left out?
Are there existing protocols or file formats that we could use
and gain compatibility?
VCD is the only one I know about. But it may not be appropriate. One
option is to use VCD, and for any metadata that we want but can't
store conveniently in the file, we can add as signals that people
wouldn't typically view.
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.
Just consider development time versus Perl/Python/Ruby.
--
Timothy Miller
http://www.cse.ohio-state.edu/~millerti
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
