Hi, and welcome :)
On Thu, Jan 01, 2015 at 05:32:35PM +0100, Johannes Bauer wrote: > 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) Yup, that would be great, we have a tracker bug for this already: http://sigrok.org/bugzilla/show_bug.cgi?id=485 > 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. No issue for this yet, but please feel free to create one: http://sigrok.org/bugzilla I'm not aware of anyone working on this currently. > 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). Seems nice, though the current behavior of cursors always appearing somewhere in the space you're currently looking at also has some benefits and is quite handy. Maybe there's a way to get both behaviors supported somehow. Either way, feel free to file an issue for this as well. > 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, ...) This has been implemented recently by Joel, you can now click into the x-axis (at the top) to get an arbitrary number of markers, which can also have names and can be moved around etc. > 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). That can be done, I think. You can group/ungroup any traces you like with CTRL+g and CTRL-u (IIRC). Subgroups / nested groups are also possible. > 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" Something like that could probably be done, yeah. Also have a look at the "jitter" decoder (might be renamed to "latency") which does somewhat similar timing measurements. Feel free to file an issue for this. > 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. Yup, I think that's on the long-term TODO list. Not sure if there's an issue for it yet. > 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. Yep. The infrastructure is there, PV remembers window position and size for example, so it's just a matter of saving more state. > 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 That's a one-liner fix in pd.py, feel free to change an 8 to 32 there for more probes. There's currently a PV limitation in that it doesn't have scrollbars for Decoder settings etc. so that many channels would cause usability issues. But the PD itself should be able to handle pretty much an arbitrary amount of channels. > 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. Hm, that sounds neat though it's a veery specific use-case. I'll see if I can come up with a somewhat-usable method to do this. > 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. That's possible, I can have a look later. Feel free to file a bugreport. Thanks for your suggestions! Uwe. -- http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org ------------------------------------------------------------------------------ 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
