Age | Commit message (Collapse) | Author |
|
This automatically figures out the files to install for each protocol
decoder, without involving autotools.
All python files (filenames ending in .py) are always installed. If a
protocol decoder requires installation of a non-python file, a small
file called 'config' can be created in that protocol decoder's
directory, with the following content:
# comments are ok
extra-install vendorlist.txt commands.txt
|
|
|
|
|
|
This better reflects what it is: a python object generated and
processed by python code.
|
|
|
|
The usb_signalling PD should not care about packets, only symbols and bits.
The new (fixed) usb_packet PD constructs packets out of individual bits now.
|
|
Also, add missing output for some packet types.
|
|
|
|
|
|
|
|
After a Start of Packet (SOP) has been detected, "sample" the individual
USB symbolѕ/bits in the middle of the respective bittime (depending on
whether full-speed or low-speed signalling is used).
This fixes various incorrectly decoded cases (bug #158).
|
|
|
|
|
|
This makes the decoder suitable for GUI usage.
This fixes bug #155.
|
|
|
|
|
|
The Python module name is determined by the directory name (e.g. dcf77),
the *.py file names in that directory don't matter and can be kept
consistent.
|
|
Ignore/skip identical samples in most (low-level) PDs, as we're usually
(but not necessarily always) only interested in pin changes.
This yields a significant performance improvement for the PDs.
The mechanism was already used in the 'i2s', 'jtag', and 'lpc' PDs, but not
yet in all supported low-level decoders. The following PDs now also use
this mechanism: 'dcf77', 'i2c', 'spi', 'uart', and 'usb_signalling'.
Thanks Lars-Peter Clausen <lars@metafoo.de> for bringing this to our
attention.
|
|
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.
|