On 12/31/06, Daniel Rozsnyó <[EMAIL PROTECTED]> wrote:
tonyb 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?
I would prefer a web interface (ajax like). For a logic analyzer, the
output does not need to be realtime and I think that scripting could be
used to post-process the captured data (on both client/server, js/php).
(why: remote access without software, instantly ported to all OSes which
has a up-to-date browser (or can run firefox))
The output can't be displayed in real-time from when it's captured.
But you need real-time response from the UI for panning around in a
graphical representation of the trace. To implement this, you'd need
a local web server, and that's complexity (and UI latency when
downloading new image slices) we just don't need. What we need is a
simple end-user graphical application. I really don't think the
round-trip through the web server will be fast enough to make panning
pleasant.
Now, if you want to keep it even simpler, note that if it were written
in Perl or Ruby with Tk, the app would be more than fast enough.
>
> 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
>
> Can you provide ssh access to a development system? My preference would
> be that it run Linux and not WinXX.
>
What about:
set master clock (from input XYZ, posedge/negedge/ddr)
This is a good point. For PCI, we'd normally use the PCI clock at 33
or 66MHz. But there are instances where we might want to capture at a
higher rate. I think, using DDR I/O buffers, we could manage 300,
maybe even 400MHz.
start now
stop now
start by triggers
(multiple) trigger setup (input XYZ must be L/H/LH/HL)
get status (state[stop,running,waiting], buffer fill %)
download data
Aside from various commands for starting/stopping capture, triggers,
etc., you'll need a "report" command that sends a slice of the
capture, with some starting time point and some duration. The UI
would typically figure out what is a "screenful" and request that
much.
What I recall from devices I've used like this before, you could
configure where in the trace the trigger occurred. That is, you have
a trigger point, and you can start capturing at the trigger ("start of
trace"). You can stop capturing at the trigger ("end of trace"). You
can capture into a circular buffer and stop capturing 1/2 of a trace
buffer after the trigger ("50% of trace"), letting you look at
activity before and after the trigger. And you can also select 25%
and 70% from beginning of trace.
Other notes:
* If it is possible, the analyzer should use RLE, it can increase the
storage capacity or the data download speed.
And the complexity of the logic. There is a need to be able to
quickly find any point in time and send it over the serial port. If
every point in time requires, say, 8 bytes of memory, then with
256MiB, we can store 33 554 432 time periods. Is that enough?
Devices I've worked with only provided for like 64k time periods.
* HW: there are USB / USB2 chips which implement a simple 8/16b fifo. If
we could attach them to the extension connector it makes a quite usable LA.
Yes. That is definitely an option.
--
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)
