On 12/31/06, tonyb <[EMAIL PROTECTED]> wrote:
I'll offer to help with the software. I've used GTK+ before and that
fits the cross platform requirement. Does anyone else have a preference
for the gui platform?
What is the system configuration? My guess is that there is an OG card,
a trace card, and a video card in the system. The serial port would
send commands and receive status from the trace card. The user
interface would be displayed on the video card. I think that there
would be too much data to try to put the gui on the other end of the
serial port.
You'd need two computers. The likelihood is that if you're using the
tracer, then something's going wrong, and you're not going to be able
to use the text box as the display box.
Here's a simplified explanation. I'm really tired, so I'm just going
to be explicit, even if it's redundant.
You have two computers. One is the "Test" system, and the other is
the "Display" system.
In Test, you have two cards: (a) The Tracer and (b) whatever other
PCI device it is you're trying to debug (like an OGD1 with OGA in it).
You also have whatever OS you're working with, and whatever software
or drivers you need to work with the device you're debugging. For our
purposes, we don't care what OS it's running, because the Tracer is
just a passive observer on the PCI bus. It could be a SPARC running
Solaris 10 or PA-RISC with HPUX.
In Display, you have a regular Linux distro or whatever OS, with a
regular graphics card, etc. And it has a serial port. For this, you
just need some desktop or workstation.
You connect the serial port on the Tracer to the serial port on Display.
The application running on Display exchanges commands with Tracer in
order to get at activity stored in the trace buffer.
Now, the thing is, you never have to download the entire buffer all at
once. The serial port is surely fast enough to download one
screen-full of activity in a way that appears quick to a user. So you
can pan and jump around all you want in the trace, and it'll appear
fast to the user, even though the serial port is "slow."
Mind you, SOME things (like searches) would require examination of the
entire trace buffer. No biggie. We just implement that directly in
the Tracer.
Make sense?
A starting point for the trace api would be:
start trace
stop trace
define trigger
enable trigger
disable trigger
trigger depends on trigger X being true
get status
Those are great. We should allow for fairly complex triggers, even
sequential ones, with lots provided with the tool for very common
situations.
Can you provide ssh access to a development system? My preference would
be that it run Linux and not WinXX.
There's no explicit need for ssh. The tracer is a relatively dumb
device that is controlled through a serial port.
Develop the front-end app to run on multiple platforms. I'll be using
Linux, but we should support Windows. And when we have USB support,
MacOS X also.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
