Age | Commit message (Collapse) | Author |
|
annotations now show duration
|
|
|
|
timing values in annotations
|
|
improved timing calculation
|
|
transport layer
|
|
|
|
|
|
layer
|
|
|
|
|
|
|
|
|
|
Change this PD from an I2C->databytes converter/filter to an actual
pure I2C filter in the sense that both input and output is a valid I2C
protocol stream.
Also, change the EDID decoder accordingly, to use the new i2cfilter
output.
|
|
This shall support the original National LM75 I2C-based temperature sensor,
as well as various compatible devices of other vendors, such as the
Fairchild FM75, Dallas DS75, and so on.
Currently only 9bit resolution is supported, and not all commands are
decoded, yet. The register contents and temperatures are decoded
correctly though, and can be output in both Celsius and Kelvin.
|
|
The 'usb_signalling' decoder just decodes symbols from D+/D- levels,
handles bit stuffing and outputs the symbols and (potential) packets.
The 'usb_protocol' decoder takes that output and tried to parse USB
packets from it (SOF, SETUP, IN, OUT, DATA0, and so on).
This is the base decoder on top of which various others will stack
later on.
The two new PDs are work in progress, so we still keep the old 'usb' PD
around for a little while, until the two new ones are fully working and
well-tested.
|
|
Also, add missing ones which are mentioned in the USB spec. However, not
all may be relevant for LS/FS signalling. But they're still useful to
have in the table, so we can output warnings like
"Warning: HS PID encountered, but device is FS???"
|
|
Some of the differences of USB low-speed (compared to full-speed) are:
- 1.5Mb/s datarate, not 12MBit/s.
- The J and K states are swapped/inverted.
Note: This is work in progress, further changes may still be needed.
Add a 'signalling' option, which allows the user to select whether the
PD should decode using the low-speed or full-speed signalling protocol.
If unspecified, the default is full-speed.
|
|
|
|
We need to flush the file output buffer(s), lacking a stop() call in
PDs at the moment, which could do the flush (or file close()) only once
at the end of the PD "session".
|
|
This PD stacks on top of the UART protocol decoder, and ouputs the
decoded UART data in the "canonical" format, one byte after the other
without any metadata (start bits, stop bits, parity bits, errors) and
without any sample-numbers and such. This is basically what you would
see in a terminal program, such as minicom.
Per default it outputs to stdout, but using the 'filename' option
and/or the 'filename_rx'/'filename_tx' options it can also output to
files.
Using the 'tx' and 'rx' options you can also select whether both, or
only one of the data direction's data should be output.
Example:
sigrok-cli -i foo.sr \
-a uart:rx=0:tx=1,uart_dump:rx=no:tx=yes:filename=foo.txt \
-s uart,uart_dump
This PD is just an experiment for now, it's possible that it will be
replaced / reimplemented via a different sigrok facility later on.
|
|
Rename the old 'Text' format to 'Text (verbose)'.
|
|
|
|
|
|
|
|
|
|
The samplenum/scount handling was broken recently (mea culpa), and the
DP/DM probes were swapped.
|
|
|
|
|
|
|
|
|
|
Also handle (not yet implemented) special-case command names such as
'RDP/RES' and 'FAST/READ' correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also, add a self.putx() helper method, as most annotations we have right
now are exactly one I2C packet long (there will also be others later, though).
|
|
The Nintendo Wii Nunchuk protocol decoder, while it was in the repo for
a while, didn't really work yet (among other things, due to lack of
dumps for testing the code).
This is fixed now, the rewritten decoder works fine with most dump
files in the sigrok-dumps repo. A few minor issues remain to be
added/fixed, though.
|
|
|
|
|
|
Should be a list containing:
- Annotation format number (e.g. 0, or ANN_DEC, etc).
- A list of strings (the annotation). If more than one string is
supplied, the other ones should be short versions of the string.
Example: [ANN_DEC, ["Foobarbaz", "Foo", "F"]]
This is optional, and mostly useful for GUIs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|