There is a wiki section with the roadmap:
http://sigrok.org/wiki/Roadmap
As far as I am aware it is not fully updated. I would suggest that all new
entries to this wiki article are time-stamped.
From: Adam Fraser-Kruck
Sent: Sunday, January 4, 2015 1:01 PM
To: Johannes Bauer
Cc: sigrok-devel@lists.sourceforge.net
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
