Timothy> solution will be to use some device to watch the PCI bus activity and
Timothy> let us observe them.
Such an analyzer could also be useful to people reverse engineering
undocumented hardware.
Timothy> Later, we should consider figuring out how to do USB 1.1.
I'm not sure what you have in mind for this (USB analyzer?),
but if you are going to bother doing USB, doing both USB1 and USB2
would be the way to go.
tonyb> Does anyone else have a preference for the gui platform?
X11 would seem to be the obvious choice. I don't know much about
GTK+ or its competators, but pick something that is as bug free as
possible, and portable to at least the BSDs, Plan9, OS-X, Linux,
Solaris, and to ILP32, LP64, big and little endian. Does Plan9 do X11?
tonyb> My guess is that there is an OG card,
tonyb> a trace card, and a video card in the system.
Don't assume a video card. Assuming X11 should be fairly safe.
The display may well be on a different machine. If the board
being analyzed is sufficiently buggy, the analyzer software
will need to be on a different machine.
tonyb> The serial port would
tonyb> send commands and receive status from the trace card.
And I assume, the data would also go across RS-232?
tonyb> I think that there
tonyb> would be too much data to try to put the gui on the other end of the
tonyb> serial port.
You want the analyzer software, including the GUI, running on the
analyzer/support computer, not on the OGD card.
tonyb> A starting point for the trace api would be:
tonyb> start trace
tonyb> stop trace
tonyb> define trigger
tonyb> enable trigger
tonyb> disable trigger
tonyb> trigger depends on trigger X being true
tonyb> get status
The ability to start/stop the trace with a time offset relative to the
trigger may be useful. The trigger time does not necessarily have to be
within the capture. (might not have enough memory)
Timothy> If
Timothy> every point in time requires, say, 8 bytes of memory, then with
Timothy> 256MiB, we can store 33 554 432 time periods. Is that enough?
You can have too little, but you can never have too much. It would be good
to have the ability to save only the signals of interest, to allow storing
more time samples.
The ability to start/stop the default display with an time offset relative
to the trigger is likely to be useful. (save a lot of scrolling)
The ability to zoom in/out.
The ability to select which signals to display, and in what order.
The ability to search for a particular bit pattern. (perhaps
sequences of bit patterns?)
Tha ability to have setup/config/rc files, and be able to switch
from one to another easily.
Will the hardware be able to detect anything other than a binary
signal level? Glitches, floating signal levels, etc.
tim> The easiest interface (and arguably the most cross-platform) would be
tim> a simple terminal interface on the serial line. Fire up minicom or
tim> hyperterminal or whatever... to 8N1 @ 152000 and go.
tim>
tim> Easy to program, easy to use. No GUI needed.
The command interface could probably be CLI. While the data display
could also be text based, you can display a lot more data using
graphics, so the data display should probably be graphical.
The fastest way to get something useful might be a CLI with
graphical data output via something like gnuplot. Get a bit
of experiance and figure out what features are needed,
then do the GUI version. For extra credit, have a button that
dumps the screen as PostScript. And a button to dump all the
raw data to a file on disk.
daniel> instantly ported to all OSes which
daniel> has a up-to-date browser (or can run firefox))
Firefox is NOT portable and is insanely buggy. :-(
Timothy> But you need real-time response from the UI for panning around in a
Timothy> graphical representation of the trace.
The OGD must capture the PCI data in real-time. The UI doesn't need to be
real-time. It would be good if the UI were fast enough to not be annoying,
but you don't lose data if it lags behind. ("real time" != "fast")
Timothy> I don't know how you'd do a good job
Timothy> of displaying readable waveforms in a terminal window.
It can be done in ASCII, but graphics would be better.
-------\_______/-------\_/---
----------\__/-------\_______
_/-\_/-\_/-\_/-\_/-\_/-\_/-\_
Timothy> I don't know of any web browser that support HTTP over a serial line.
That's what slip and ppp are for. But I don't think the web browser
interface is the way to go for this.
I suggest making the part that lives in the OGD fairly simple and small.
Conserve memory for data storage since we will not be able to transfer
data over RS-232 in real time. Also, simple tends to be less buggy.
Question is what format to use for data transfer. Can we assume an
8 bit data path with hardware (e.g. RTS/CTS) flow control? If so,
then data transfers will be faster. Or do we need to allow for a
7 bit data path, and reserve control-s and control-q for flow control?
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
