Hi,
On Sun, Oct 16, 2016 at 06:26:18PM +0200, Gerhard Sittig wrote:
> 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
>
On Sun, Oct 16, 2016 at 06:25:31PM +0200, Gerhard Sittig wrote:
> 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.
Hi,
On Sun, Oct 16, 2016 at 06:25:26PM +0200, Gerhard Sittig wrote:
> 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
Hi,
On Sun, Oct 16, 2016 at 06:25:28PM +0200, Gerhard Sittig wrote:
> 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
First batch of asix-sigma patches is available at
https://gitlab.com/jrysig/libsigrok/commits/asixfix
Following major problems are fixed:
http://sigrok.org/bugzilla/show_bug.cgi?id=841
http://sigrok.org/bugzilla/show_bug.cgi?id=840
http://sigrok.org/bugzilla/show_bug.cgi?id=839
Next on my to-do
On Sun, Oct 23, 2016 at 22:42 +0200, Uwe Hermann wrote:
>
> On Sun, Oct 16, 2016 at 06:25:26PM +0200, Gerhard Sittig wrote:
> > 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)
6 matches
Mail list logo
