On Thu, 2021-01-21 at 17:36 -0700, Uffe Jakobsen wrote:
>
> I tend to get annoyed with the stock timing protocol decoder (PD).
> It sounds trivial - but its major problem is that it constructs annotations
> that are too wide - and the PD lacks (configuration) flexibility.
> From within PulseView - with multiple values (timing and frequency plus
> their SI-units) concatenated into a single annotation row - user will have
> to zoom quite "deep" into the samples before the annotations gets so wide
> that all text/values of an annotation are visible.
> Sure - the "Times" row can be changed into one of its "terse" output modes -
> but that does not help the the width of the other concatenated rows
> (Averages and Deltas)
I can feel that pain. :) The "terse" format was an attempt of
mine to improve usability of the PD in least intrusive ways and
fully backwards compatible to not break others' setups.
I also keep finding myself disabling the average feature (set
period to zero) as one of the first steps after adding this
decoder. Am using the cursor when I'm interested in a single
period, or between conditions that a human can identify but a PD
cannot. Am using the 'timing' PD when I need "all" (actually:
many or most) distances of edges or periods of waveform cycles,
like during creation of another decoder, or when comparing
hardware implementations of clocked protocols to software
bitbang. Have never used the frequency nor the averaging parts,
but there will be users who do, and do a lot of that, for sure.
> [ ... split, specialize, or make configurable? ... ]
Let's hear what the original authors say, or those users who keep
using that PD more frequently. In the past I hesitated to do more
than I did to that PD because of my infrequent use, and not being
able to tell what others prefer or desire.
Random feedback below, haven't digested all of your message yet.
And it's well understood that as simple as the timing PD might
look at first glance, it's so essential and expectations may
differ so much that coming up with _the_ answer need not be. :)
> Some of them are multipurpose timing PDs - displaying samples, time, freq,
> delta_time, delta_freq, avg_time, avg_freq in separate annotation rows (to
> keep the annotaions narrow)
> The multi-purpose timing PDs has config properties to hide/unhide and change
> units of every annotation row - highly flexible.
Proper use of annotation classes and rows is highly desirable,
the mix of different values in a single text field is undesirable
(yet would be an incompatible change which needs consideration).
Are you aware that all mainline applications (CLI as well as GUI)
can filter annotation classes and rows in generic ways and
without cluttering individual decoders with visibility options?
For "new" or "recently adjusted" decoders it's also highly
desirable to not create "nice looking text" for human
consumption, but instead to prefer "raw information" such that
applications can pick a preferred presentation (think of the
popular dec/hex/etc requests), or process the information, or
search in the output or filter the data.
> 2) splits the existing timing PD into smaller single-purpose PDs (for
> example separate PD for samples, timing, frequency - and their delta and
> average combinations (permutations))
Could be highly depending on personal taste. Last similar thing I
remember was a PR (something about "vectors") that led to what's
"numbers and state" now. Compare the original submission to what
ended up in mainline. Really a tough call to make. In that
specific case, I thought that one PD would be more usable than a
set of stacked micro PDs would be. But that's only because this
specific set of decoders had sooo much overlap. Also depends on
your preferred UI and how you specify decoder selections or their
properties.
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
