> > 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. > > The display is DEFINITELY on a different machine. Don't even bother > considering the case where you don't have two separate computers. For > one thing, you want to minimize the amount of irrelevant PCI traffic, > so if you want networking, for instance, make sure it's both built > into the chipset and that it's traffic doesn't appear on the PCI bus > (I've seen builtin NICs whose transactions appeared on the PCI bus).
Good point about minimizing other PCI traffic. So it would be preferred to use a disk controller in the chipset (or PCIe?), run the system under test in single user mode, etc. > > Will the hardware be able to detect anything other than a binary > > signal level? Glitches, floating signal levels, etc. > > It would be really nice to be able to do analog, but I don't think we > can do anything other than digital. If the I/O buffers have any > special abilities, we'll certainly use them, but I don't know what the > might be. I haven't debugged a PCI bus, but back in the dark ages when I was doing this sort of thing, I often ran into cases where I ran out of resolution in the logic analyser, and the logic states displayed were logically impossible. I had to switch over to the oscilloscope and find the glitch, or the bogus Voltage level that the logic analyser doesn't show you. So if the hardware can sense any of this non-binary stuff, it would be very useful to provide it to the analyzer. > > 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. > > Remember that 19200 bits/sec isn't very fast. I'd hate to slow it > down by using an ASCII interface. A CLI or text based display does not imply a 19200 bits/sec limit. I can send text to an xterm window way faster than 19200 bits/sec. The data capture running on the OGD can only talk to the analyzer software at RS-232 speeds, (which are officially capped at 20,000 although most systems these days can run much faster) but the analyzer software is likely to have a faster path to the display, most likely either a video card in the same machine or an Ethernet connection to a machine with the display. > > 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. > > I think there are VT102 graphics characters that are top-line and > bottom-line (underscore) symbols, as well as several in between. > Worst case, we could even use _, -, and ^ characters. For multi-bit > signals (like the AD lines), we would insert an X or something like > that at transition points. Yes, various terminals have various graphics characters available. The VTxxx have a bunch, the Wyse have some way to define your own, and the Tek terminals have full blown color graphics. My suggestion is to do the time honored "build one to throw away". A CLI would be quick to get running, and using something like gnuplot for graphical output would be easy as well. > > 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. > > But SLIP and PPP are TCP/IP over serial, aren't they? Yes. > I definitely > don't want to have to put a TCP/IP stack in the tracer. I agree. Note the part saying I don't think this is the way to go. > > 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? > > We're in complete control over this. We don't even need flow control. Flow control is your friend. Flow control avoids many headaches. We need flow control. But that's easy, UARTS have flowcontrol builtin. But if someone is using this across some cu/telnet/ssh/whatever link, are they likely to have an 8-bit clean line? Or do we need a fast 8-bit mode and a safe 7-bit mode? This leads to adding complexity in the OGD, and we want to keep that as simple as possible. We could split the application into a get the data from the OGD part, and a display the data part. The oddball link could go between these two parts, reducing complexity in the OGD. Downside is that you'd need a support computer with the system under test, but we're likely to have that anyway. The get the data from the OGD part could be a simple CLI program. It talks to the OGD over RS-232, and outputs data to stdout. For working remotely, just redirect stdout to a disk file, then transfer the file via ftp, uucp, or whatever. The display the data part could start out as a CLI program and later be rewritten as a GUI. 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. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
