On 12/31/06, Jack Carroll <[EMAIL PROTECTED]> wrote:
On Sun, Dec 31, 2006 at 09:17:47PM -0500, Timothy Miller wrote:
> On 12/31/06, Tim Schmidt <[EMAIL PROTECTED]> wrote:
> >On 12/31/06, Tim Schmidt <[EMAIL PROTECTED]> wrote:
> >> Easy to program, easy to use. No GUI needed.
> >
> >Which, of course, doesn't mean someone couldn't write a GUI... just
> >that they'd be writing it to a semi-standardized terminal interface
> >instead of blasting raw serial data over the line.
>
> We could make a human-readable mode, and we could use VT100 codes in
> order to display it nicely. But I don't know how you'd do a good job
> of displaying readable waveforms in a terminal window.
It would have to be in a graphic format. There must be a zillion
formats that can describe a waveform compactly enough to be sent over a slow
serial line. PNG, PDF, EPS, SVG... Most of them are sent as files, so they'd
probably have to be transferred using HTTP, FTP, Kermit, or the like. That
gets us away from the link model of a text terminal, though.
I don't know of any web browser that support HTTP over a serial line.
Sounds like what you're suggesting is a networked device that contains
an embedded web server.
While this is indeed an interesting idea, let's not let feature creep
let us lose sight of producing a working product. The first goal
should be to develop the simplest thing that works well. Being able
to analyze PCI bus activity in the most straightforward way possible
is the important thing. In order to make the design tractible, we
need to keep the Tracer design as simple as possible. Embedding a web
server is not simple. Producing and encoding an image in hardware is
even less simple still. If we don't employ the KISS principle to an
extreme degree, we won't make progress as a project.
In case you're worried about it, we're not at risk of confining
ourselves into a box by not thinking ahead. We have every opportunity
to redesign things completely when we decide to. The most important
thing to do right now is find the shortest path to a working product.
The SHORTEST path. That means we should have the simplest protocol
for controlling the tracer and the quickest solution to an end user
application.
Don't forget that this "excessive" pragmatism is not really natural to
me. I LIKE these ideas. And I look forward to the day when we have
cash flow and money for research and tinkering with wild ideas. But
the fact is, this project is a painfully slow mover right now, and I
absolutely do not want to slow it down any further. If I didn't
expect to run into some sort of show-stopper bug (it always happens!)
that would require watching PCI transactions, then I wouldn't even
bring up the Tracer, because it's a distraction. Distractions are
VERY VERY BAD.
Maybe the simplest way would be to just pack up the stored binary
data so it could be sent as ASCII characters, and let the display PC handle
the conversion to a displayable format. That takes a lot less logic on the
PCI analyzer board, and puts the complicated logic into software where it's
easier to implement.
I completely agree. And we don't really need to "pack up" the data.
Like I say, you can download a screenful plenty fast enough. The end
application just needs to request data on demand from the tracer.
--
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)
