| Age | Commit message (Collapse) | Author |
|---|
|
The temperature unit is nowadays called just "Kelvin", not
"degrees Kelvin" (even though this was not always the case).
|
|
|
|
|
|
|
|
While states in the PD should be ALLCAPS per guidelines (for
consistency), the annotations that a PD outputs (and are shown in a
console via sigrok-cli or in a GUI) should be "normal" human-readable
text/formatting usually, i.e. not ALLCAPS.
|
|
|
|
|
|
|
|
It doesn't make sense to have one "generic" onewire_transport PD, as
this layer is very much device-specific and such a generic PD would
have to contain an accumulation of all possible features and commands
and handling code of all existing (now and in the future) 1-Wire
devices, which is neither possible nor useful nor elegant.
There are (for example) 1-Wire thermometers, RTCs, EEPROMs,
special-purpose security chips with passwords/keys, battery monitoring
chips, and many many others. They all have a different set of features,
commands and command codes, RAM areas/sizes/partitioning/contents,
protocols, and so on.
Thus, the layering for 1-Wire PD stacks should look like this:
onewire_link -> onewire_network -> <specificdevice>
Examples:
onewire_link -> onewire_network -> maxim_ds28ea00 (special thermometer)
onewire_link -> onewire_network -> maxim_ds2431 (1kbit EEPROM)
onewire_link -> onewire_network -> maxim_ds2417 (RTC)
onewire_link -> onewire_network -> maxim_ds2762 (battery monitor)
onewire_link -> onewire_network -> maxim_ds1961s (SHA-1 eCash iButton)
and so on...
So, renaming onewire_transport to maxim_ds28ea00. The non-DS28EA00
specific code will be dropped and/or moved to other PDs on top of
onewire_network later.
|
|
The 'Overdrive match ROM' command is 0x69, not 0x6d. Verified in various
datasheets and the original 1-Wire/iButton spec.
|
|
The annotation types are 'Text' and 'Warnings', not 'Link' etc. as the
annotations of the onewire_link PD (for example) are already clearly
from the link layer. The annotation types should be different things/formats
of a specific PD's annotation output instead (like "Celsius" / "Kelvin"
for some temperature sensor, for example).
|
|
Also, some additional cleanups.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
exit message
|
|
|
|
|
|
|
|
The new 'usb_signalling' and the 'usb_protocol' PD which stacks on top
of it, replace the old 'usb' decoder.
|
|
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.
|
|
This is just a preparation for later, the report() is not hooked up
anywhere, yet.
|
|
|
|
|
|
|
|
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)'.
|
