| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is not entirely correct yet, will be fixed later.
|
|
|
|
|
|
|
|
This fixes bug #845.
|
|
|
|
|
|
|
|
For wordsizes > 8, multiple bytes are used (big-endian).
This fixes bug #686.
|
|
This is in almost all cases what the user will want, only rarely ASCII
(the old default) will be the more natural fit.
|
|
For 5..8 data bits the binary output will be 1 byte, for 9 data bits
it will be 2 bytes (big-endian).
This fixes bug #708.
|
|
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 spurious glitch or that the captured signal does not communicate
at the decoder's configured bitrate.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
|
|
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 while we are here: Nine bits result in a number
range of 0 to 511 (not 512). ASCII codes 30 and 31 are non-printables.
The previous implementation skipped a significant leading digit in the
octal representation.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
|
|
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 <gerhard.sittig@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Handle "Running Status" where status byte can be omitted
- SysEx message can be terminated by status byte, not just EOX
- Handle SysReal messages that interrupt in-progress message transmission
- Identify and print garbage / truncated data
- Add 2 new annotations: text-sysreal-verbose and text-error
|
|
(ex: note 60 is middle C which is C4, not C3)
|
|
The UART bit information was not transmitted correctly to stacked PDs
if there was an overlap between RX and TX bytes in the data.
|
|
|
|
short lengths
|
|
This causes an issue when running the sigrok-test test-cases, so drop
it for now (the same check already exists in decode()).
This fixes bug #758.
|
|
|
|
* Decode note names and percussion names (ex: 'G2', 'Tambourine').
* Decode instrument names and drum_kit names (ex: 'Flute', 'GS Orchestra Kit').
* Handle Polyphonic Pressure / Aftertouch (message 0xAn).
* Handle Program Change (message 0xCn).
* Handle Channel Pressure / Aftertouch (message 0xDn).
* Handle Channel Mode (message 0xBn mm where mm is 120 through 127).
* Handle System Common messages (message 0xF1 through 0xF6), including
full time code decoding.
* SysEx decoding now decodes the 1-3 byte manufacturer field, payload
is now displayed as hex.
* 'undefined' fields now display the value (ex: 'undefined 0xf4').
* Add 'MSB' and 'LSB' to many control_functions entries.
* Fix "trapped in state X" bug with handle_channel_msg_generic(),
though this might be dead code.
* Fix bug in sysex_manufacturer_ids; 1-byte manufacturers were not
tuples due to missing comma.
* Fix bug in SysEx decoding state machine; 0xF7 now sent to handle_sysex_msg().
|
|
|
|
Signed-off-by: Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
|
|
|
|
This patch was contributed by James Sleeman <james@gogo.co.nz>, thanks!
|
|
|
