I'm not sure if this ever got a response, but I think it would be a great
idea to have a wiki page to collect new ideas like
Johannes'.
Adam
On Thu, Jan 1, 2015 at 10:32 AM,
Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
> Hi there,
>
> so I've given sigrok a try with some real-world(tm) measurement tasks.
> So far it is very promising, but there are some issues which bug me.
> Complaining has never gotten anyone anywhere, so I'd like to contribute
> :-) However I'm unsure who to coordinate with and who's the lead on the
> relevant subprojects. I'd like to avoid coding and sending in patches
> that can't/won't be integrated because of a roadmap I'm unaware of. So I
> think the best is that I point out where I see room for improvement and
> maybe you can tell me what the status is and if this is something I
> should/could pursue or if someone else has that already on her radar.
>
> So here I go:
>
> -----------------------------------------------------------
>
> 1. [Pulseview] Show sample points
> It would be great if the user had the ability to display/hide the actual
> sample points. That way one can see how much margin there is between the
> frequency of the measured data and the sampling frequency (and increase
> sampling frequency in case this is too short)
>
> -----------------------------------------------------------
>
> 2. [Pulseview] Specify number of significant digits to display
> Currently, PulseView displays sampling values (e.g. time/frequency) in a
> strange and inconsistent way. For example, the X axis labels are
> sometimes, depending on the zoom level:
> 723500 µs (6 significant digits)
> 723490500 ns (9 SD)
>
> Examples for cursor values are:
> 723490246.03 ns (11 SD!)
> 723485.54 µs (8 SD)
>
> And in the middle region of the cursor
> +1024.98 ns (6 SD)
> + 26.46µs (4 SD)
> + 5.00µs (3 SD)
> +37.7924 kHz (6 SD)
> +199.9135 kHz (7 SD)
>
> This should be normalized to display a consistent (but configurable)
> amount of significant digits. Let's say this were configured as SD = 4
> then the display would be:
>
> 1.234568e-06 -> 1.235 µ
> 1.234568e-05 -> 12.35 µ
> 1.234568e-04 -> 123.5 µ
> 1.234568e-03 -> 1.235 m
> 1.234568e-02 -> 12.35 m
> 1.234568e-01 -> 123.5 m
> 1.234568e+00 -> 1.235
> 1.234568e+01 -> 12.35
> 1.234568e+02 -> 123.5
>
> And so on and so forth.
>
> -----------------------------------------------------------
>
> 3. [Pulseview] Cursors should remember their position
> When deactivating and reactivating cursors, they are reset. When cursors
> have been moved, they should remember their position so one can activate
> and deactivate them (in order to clarify measurements).
>
> -----------------------------------------------------------
>
> 4. [Pulseview] It should be possible to draw "helper lines" on the X axis
> It would be helpful if one could drag a "helping line" from the X axis
> ruler into the measurement. Ideally, this helper line could be named and
> referenced later on. This would be very helpful to debug complex timing
> scenarios. Consider a SRAM chip in which one wants to verify several
> constraints such as t_RLDV, t_RLRH, t_DVWH, t_WLWH (Read Low to Data
> Valid, RD Pulse Width, Data Valid to WR high, WR pulse width, ...)
>
> -----------------------------------------------------------
>
> 5. [Pulseview] Position of traces should be arbitrary
> By default, the position of decoded traces is arbitrary and can be
> used-adjusted. The position of measured channels snaps in to a grid,
> however. While this is a nice default behavior, it would also be good to
> be able to disable this. For example, when doing complex measurements I
> would like to group signals according to their function (RAM input, Data
> bus, Address bus, etc).
>
> -----------------------------------------------------------
>
> 6. [Pulseview/libsigrokdecode?] Decoder that allows locic combination of
> signals
> It would be nice to be able to specify a boolean expression that would
> be evaluated on the channels. For example, I would like to say "!CS1 AND
> CS2 AND !WR" where CS1, CS2, WR are channels that I've previously named
> and captured. Ideally, those could be stacked. This is a useful feature
> because one can then easily debug timing issues. Let's say I have two
> inputs to a NAND gate A, B in hardware and an output Y. I want to
> measure the gate delay time to check if it is within the constraints of
> the system. For this, I measure A, B, Y. Then I calculate "IDEAL_Y = A
> NAND B" and then the discrepancy: "DISC = IDEAL_Y ^ Y"
>
> -----------------------------------------------------------
>
> 7. [Pulseview] Saving capturing setups
> For complex setups it is very cumbersome and error-prone to rename
> channels every time again. Consider a setup with a address bus of 16
> bit, 8 bit data bus and 8 control lines. You need to rename all 32 lines
> every time you do a new capture. What would be nice is to be able to say
> "File -> Save measurement setup" which would save the sames of the
> channels and then be able to load this setup into acquired measurement
> data.
>
> 8. [PulseView] Remember last configuration
> It would be nice if when closing and reopening PulseView it would
> remember what my last Capturing device was (defaults to Demo device),
> what I sample rate and sampling frequency was.
>
> -----------------------------------------------------------
>
> 9. [libsigrokdecode?] Parallel decoder limitations/issues
> When doing parallel decoding, it is only possible to combine 8 bits. For
> a 16 bit address bus, this is insufficient. Selection of the single
> address lines is also rather cumbersome via the comboboxes. It would be
> very nice if one could specify a regular expression or a string. Examples:
>
> D0,D1,D2,D3,D4,D5
> D[0-9],D1[0-9]
>
> Fields that match multiple channels in the regular expression would be
> sorted lexicographically.
>
> Also there is a bug in the parallel decoder: It talks of endianness;
> endianness is *byte* order. However, looking at the implementation it
> actually matches *bit* order. So the field should be named "LSB/MSB
> first", not endianness.
>
> -----------------------------------------------------------
>
> Any feedback to these issues and if they're relevant and if you
> agree/disagree would be helpful for me.
>
> Thanks,
> JOhannes
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> sigrok-devel mailing list
> sigrok-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
