OK, fair enough :-)
Dave
On 03/07/2020 14:38, Gerhard Sittig wrote:
On Fri, 2020-07-03 at 02:23 +0100, David Slipper wrote:
When I look at the screenshot for (say) the GPIB decoder it shows
the channels labelled as per the pin assignments in the decoder.
You haven't seen many screenshots yet. Look further. :)
And see below.
But when I load a decoder and assign pins the pin legends (logic
analyser channels) remain the same unless I manually alter them to
match.
Is there a mechanism to do this automatically ? or a command to make
it happen ??
I am writing a decoder and feel this would be a useful facility.
I'm afraid this would not be as useful as you may assume. Perhaps
it looks like a good idea in the simple cases, with just one
decoder in a setup, and the capture's purpose being exactly
custom made for this decoder. There's more to it.
How is a decoder supposed to know which of your traces carry
which information, and what _you_ would like the signal to be
named? Naive automatic assumption will not work out well. Add the
fact that you can use several decoders in one setup, and are free
to assign any of your input traces to any of the decoders' input
signals. Which name to pick for the signal in that case? Letting
a decoder decide which name a digital input of a capture device
has sounds like a bad idea to me.
It's rather the other way around. Connect your traces. In the way
that _you_ want them to be. Then either add decoders and wire
their inputs by hand (that's what most people do before they
notice there's an easier way). Or name the traces accordingly,
add the decoder, and the application may(!) automatically connect
the traces to decoder inputs if their names match. Then adjust
what doesn't fit. Notice that having to undo too much of naive
automatic assignments is as undesirable, as incomplete or total
lack of automatic assignment may be perceived as.
There is a limit to this. Not all apps do it. Pulseview the GUI
does, yet won't match any combination that you could think of.
The command line tool doesn't, instead it assumes that you
provide the signals in the order that is expected by the decoder,
or that you explicitly specify the pin mappings. See the docs.
There may be more applications which use the sigrok libraries,
check their individual capabilities. And each may implement its
personal taste of what's considered a match.
Why I say the auto connect may fail? Think of ambiguous setups.
Got several UART channels that you capture in parallel? Well,
which one to connect to? Needs human interaction. Then there's
the multitude of expressing negation in signals (think hashes and
slashes and tildes and prefix and suffix and I probablly forgot a
thousand others that people came up with). There's the not
uncommon case where people try to sniff wide busses with devices
that have few channels. Let _them_ chose which signals they want
to inspect at a given time. There is the many names for identical
things like clocks, data lines, etc etc.
If you get tired renaming the traces before starting a capture,
do read the manual and check for saved sessions. Reading the
manual is also a good idea in many other situations. :-P
The GPIB setup may be a special case, but this discussion isn't
new either. Acquisition devices encode their traces' names in the
driver for the acquisition hardware. When you use something
generic (guess an FX2 eval board) then you get a generic set of
names. When you'd use some custom GPIB sniffer hardware, you
could get proper signal names, out of the box and without manual
intervention. Just requires that the sniffer device identifies as
one, and won't pretend it'd be something generic. Ask artag, he's
been there. ISTR the experiment got stuck when an individual USB
ID was required to get there. Maybe you can help?
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
