Hey Paul,
I've updated my patch with your suggestion.
Thanks for the heads up. I used the parallel decoder as a basis for the
PS/2 one and just copied the header information from that file.
Regards
Daniel
On 15.10.2016 19:29, Paul Fertser wrote:
> Hey Daniel,
>
> On Sat, Oct 15, 2016 at 07:10:
Given the generic nature of UART communication and the supported range
for the data width, "byte" may be a misleading name for the numeric
value that gets communicated in five to nine data bits. Rename the
"databyte" variable to "datavalue".
Signed-off-by: Gerhard Sittig
---
decoders/uart/pd.py
The output of `sigrok -P --show` omitted the binary classes,
users could not learn which specs are available for the -B option. Add
a "Binary classes:" section after the list of annotations.
Signed-off-by: Gerhard Sittig
---
show.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion
Several checks get applied when loading externally provided protocol
decoders. Print error messages when checks fail, so that developers can
better resolve issues.
The sequence of tests terminates upon the first failed check, while
decoders may suffer from several issues at the same time. This i
The current implementation of the ASIX Sigma firmware download contains
comments which express uncertainty. Rephrase them, no magic is involved.
Discuss the polarity of the CCLK hardware signal. Which shall eliminate
potential concerns in future reviews or maintenance.
Put an explicit "EMPTY" m
Create a "counter" directory, and add captures from UART communication
with the number of data bits in the range from 5 to 9. Parity/stopbit
is identical across all captures, as other dumps already provide those
variants. This set is useful to test how decoders cope with various
numbers of databi
In the absence of respective instructions, git will use a rather generic
approach to generate diffs and patches. Introduce a git attributes file
which results in improved output for Python sources (i.e. all protocol
decoders).
Signed-off-by: Gerhard Sittig
---
.gitattributes | 1 +
1 file chang
The version text length check fails for git setups that use more digits
in abbreviated hashes, as is recommended by e.g. the Linux kernel project.
Raise the upper limit for acceptable version strings, and add comments
on how the limits were determined. The test still might fail in setups
of sligh
Fix the array size check in the sigma_write_register() routine. The
'len' parameter specifies the number of bytes to write, while the 'buf'
array holds one nibble per array item.
The previous implementation (commit e8686e3ae36c1) switched to a
constant size and made the buffer large enough so tha
Factor out the code which generates a textual representation for the
numeric values that were communicated via UART bit patterns. Make the
width of the output text depend on the number of bits in the UART frame
(five to nine) instead of assuming bytes of exactly eight bits.
Fix other minor issues
The driver internally implements the "limit samples" feature by means of
the "limit sample period" approach. Determination of the corresponding
period of time for captures depends on the sample rate as well as the
maximum sample count, and thus needs to be re-done when either setting
changes.
Int
Commit 2c9c0df86eaf removed the sentinel from the samplerates[] array,
but did not adjust the test which checked whether a rate is listed in
the set of supported rates. This could result in an out-of-range access
beyond the array's last item.
Fix the "listed?" check after iterating the table of s
This is a set of patches that I'm confident about. They fix minor
issues, address minor nits, or add slight improvements. I provide a
little more context where appropriate (git diff -U), to simplify the
review -- it should become more apparent what the issue may be.
There will be a separate set
It's assumed that this is the libsigrok codebase reflecting on its local
configuration during the process of building the library itself, and not
an application which reflects on an installed library's configuration
(the name is just too ambiguous for the latter purpose).
Adjust the #include dire
Upon reception of the SR_DF_END packet, communicate this end of the
datafeed event to libsigrokdecode. Which in turn can invoke the
protocol decoders' optional decode_end() method before closing the
output stream.
This allows to flush previously accumulated and not yet committed output
data, emit
Protocol decoders scan incoming samples in their decode() method, to
derive higher level "frames" or "transactions" or similar, and send them
to the output stream. Typically sample data from multiple decode()
calls needs to get processed before sending a higher level annotation to
the output. But
Since tastes and requirements might differ, introduce support for a
user specified character set in the construction of ASCII art graphs
of signal levels. The syntax is "charset=[]",
the default remains backwards compatible with existing consumers.
In comparison to assuming a fixed character set,
This is a set of patches that I'd like to suggest, yet wouldn't like to
cram down other peoples' throats. :) I'd expect those to be potentially
controversal, or in need of more consideration since they change an API.
Others might be considered incomplete, given that they could be somehow
represent
Stick with the "one data byte per UART frame" approach for frames which
carry 5 to 8 data bits. But send two bytes per UART frames (big endian
representation) for configurations with 9 data bits.
This addresses Bug 708, passing values greater than 255 to the bytes()
Python routine broke execution
When the start bit is not low at its sample point, then stop trying
to interpret the remaining frame -- it's already known to be invalid,
anyway.
Wait for the next start bit instead, assuming that either the falling
edge which started the inspection of the UART frame and its start bit
was a spurio
The srzip output module's get_options() routine used to pre-set the
default for an option which no longer existed, the "filename" setting
was removed in a previous commit. The cleanup() routine undid the
previous allocation.
Resource allocation was balanced, the data wasn't used, so the issue did
I appreciate this being worked on.
There is one scenario I am wondering whether it is handled. I am not familiar
enough with libsigrokdecode's code to know. The question is when a lower-level
PD has its decode_end() called and that PD flushes data with calls to put(),
will the next higher-le
Hi,
On Sun, Oct 16, 2016 at 06:25:30PM +0200, Gerhard Sittig wrote:
> The output of `sigrok -P --show` omitted the binary classes,
> users could not learn which specs are available for the -B option. Add
> a "Binary classes:" section after the list of annotations.
Merged, thanks a lot! That was
Hi,
On Thu, Oct 13, 2016 at 04:36:16PM +0200, Gerhard Sittig wrote:
> A doc update patch for INSTALL is attached.
Thanks! Can you please update the check in CMakeLists.txt as well in
this patch?
Also, please don't use double-spaces between sentences for sigrok
commits (neither commit messages n
Hi,
On Sun, Oct 16, 2016 at 06:25:18PM +0200, Gerhard Sittig wrote:
> Signed-off-by: Gerhard Sittig
Merged, thanks!
> while (sigma_read(&pins, 1, devc) == 1)
> - ;
> + /* EMPTY */;
Dropped this hunk though, that's pretty idiomatic IMHO, a comment is not
really ne
On Sun, Oct 16, 2016 at 06:25:19PM +0200, Gerhard Sittig wrote:
> Commit 2c9c0df86eaf removed the sentinel from the samplerates[] array,
> but did not adjust the test which checked whether a rate is listed in
> the set of supported rates. This could result in an out-of-range access
> beyond the ar
On Sun, Oct 16, 2016 at 06:25:20PM +0200, Gerhard Sittig wrote:
> The driver internally implements the "limit samples" feature by means of
> the "limit sample period" approach. Determination of the corresponding
> period of time for captures depends on the sample rate as well as the
> maximum samp
On Sun, Oct 16, 2016 at 06:25:21PM +0200, Gerhard Sittig wrote:
> Fix the array size check in the sigma_write_register() routine. The
> 'len' parameter specifies the number of bytes to write, while the 'buf'
> array holds one nibble per array item.
>
> The previous implementation (commit e8686e3a
On Sun, Oct 16, 2016 at 06:25:22PM +0200, Gerhard Sittig wrote:
> The version text length check fails for git setups that use more digits
> in abbreviated hashes, as is recommended by e.g. the Linux kernel project.
>
> Raise the upper limit for acceptable version strings, and add comments
> on how
On Sun, Oct 16, 2016 at 19:14 +, Chris Dreher wrote:
>
> I appreciate this being worked on.
Notice that we are talking about "flush" here, not "late
manipulation". For file header updates as samples get appended,
there already is an undisputed approach (output modules).
> There is one scen
Unfortunately, it isn't quite clear to me whether the question been addressed.
I'm not too concerned whether the decode_end() methods are called in PD stack
order. The check-in appears to handle that nicely.
The issue is whether a put() called by a lower-level PD during its decode_end()
will
On Mon, Oct 17, 2016 at 07:53 +0200, Gerhard Sittig wrote:
>
> On Sun, Oct 16, 2016 at 19:14 +, Chris Dreher wrote:
> >
> > There is one scenario I am wondering whether it is handled. I
> > am not familiar enough with libsigrokdecode's code to know.
> > The question is when a lower-level PD
32 matches
Mail list logo
