'''
1-Wire protocol decoder.
-Universal Asynchronous Receiver Transmitter (UART) is a simple serial
-communication protocol which allows two devices to talk to each other.
-
-It uses just two data signals and a ground (GND) signal:
- - RX/RXD: Receive signal
- - TX/TXD: Transmit signal
-
-The protocol is asynchronous, i.e., there is no dedicated clock signal.
-Rather, both devices have to agree on a baudrate (number of bits to be
-transmitted per second) beforehand. Baudrates can be arbitrary in theory,
-but usually the choice is limited by the hardware UARTs that are used.
-Common values are 9600 or 115200.
-
-The protocol allows full-duplex transmission, i.e. both devices can send
-data at the same time. However, unlike SPI (which is always full-duplex,
-i.e., each send operation is automatically also a receive operation), UART
-allows one-way communication, too. In such a case only one signal (and GND)
-is required.
-
-The data is sent over the TX line in so-called 'frames', which consist of:
- - Exactly one start bit (always 0/low).
- - Between 5 and 9 data bits.
- - An (optional) parity bit.
- - One or more stop bit(s).
-
-The idle state of the RX/TX line is 1/high. As the start bit is 0/low, the
-receiver can continually monitor its RX line for a falling edge, in order
-to detect the start bit.
-
-Once detected, it can (due to the agreed-upon baudrate and thus the known
-width/duration of one UART bit) sample the state of the RX line "in the
-middle" of each (start/data/parity/stop) bit it wants to analyze.
-
-It is configurable whether there is a parity bit in a frame, and if yes,
-which type of parity is used:
- - None: No parity bit is included.
- - Odd: The number of 1 bits in the data (and parity bit itself) is odd.
- - Even: The number of 1 bits in the data (and parity bit itself) is even.
- - Mark/one: The parity bit is always 1/high (also called 'mark state').
- - Space/zero: The parity bit is always 0/low (also called 'space state').
-
-It is also configurable how many stop bits are to be used:
- - 1 stop bit (most common case)
- - 2 stop bits
- - 1.5 stop bits (i.e., one stop bit, but 1.5 times the UART bit width)
- - 0.5 stop bits (i.e., one stop bit, but 0.5 times the UART bit width)
-
-The bit order of the 5-9 data bits is LSB-first.
-
-Possible special cases:
- - One or both data lines could be inverted, which also means that the idle
- state of the signal line(s) is low instead of high.
- - Only the data bits on one or both data lines (and the parity bit) could
- be inverted (but the start/stop bits remain non-inverted).
- - The bit order could be MSB-first instead of LSB-first.
- - The baudrate could change in the middle of the communication. This only
- happens in very special cases, and can only work if both devices know
- to which baudrate they are to switch, and when.
- - Theoretically, the baudrate on RX and the one on TX could also be
- different, but that's a very obscure case and probably doesn't happen
- very often in practice.
-
-Error conditions:
- - If there is a parity bit, but it doesn't match the expected parity,
- this is called a 'parity error'.
- - If there are no stop bit(s), that's called a 'frame error'.
-
-More information:
-TODO: URLs
-
-Protocol output format:
-
-UART packet:
-[<packet-type>, <rxtx>, <packet-data>]
-
-This is the list of <packet-types>s and their respective <packet-data>:
- - 'STARTBIT': The data is the (integer) value of the start bit (0/1).
- - 'DATA': The data is the (integer) value of the UART data. Valid values
- range from 0 to 512 (as the data can be up to 9 bits in size).
- - 'PARITYBIT': The data is the (integer) value of the parity bit (0/1).
- - 'STOPBIT': The data is the (integer) value of the stop bit (0 or 1).
- - 'INVALID STARTBIT': The data is the (integer) value of the start bit (0/1).
- - 'INVALID STOPBIT': The data is the (integer) value of the stop bit (0/1).
- - 'PARITY ERROR': The data is a tuple with two entries. The first one is
- the expected parity value, the second is the actual parity value.
- - TODO: Frame error?
-
-The <rxtx> field is 0 for RX packets, 1 for TX packets.
+The 1-Wire protocol enables bidirectional communication over a single wire (and
+ground) between a single master and one or multiple slaves. The protocol is
+layered, the provided parser decodes the next layers:
+- Link layer (reset, presence detection, reading/writing bits)
+- Network layer (skip, search, match device ROM addresses)
+The higher layers (transport, presentation) are not decoded, since they are
+mostly device specific and it would take a lot of code to interpret them.
+
+Sample rate:
+A high enough sample rate is required to properly detect all the elements of
+the protocol. A lower sample rate can be used if the master does not use
+overdrive communication speed. The next minimal values should be used:
+- overdrive available: 2MHz minimum, 5MHz suggested
+- overdrive not available: 400kHz minimum, 1MHz suggested
+
+Probes:
+1-Wire requires a single signal, but some master implementations might have a
+separate signal use to deliver power to the bus during temperature conversion
+as an example. This power signal is currently not parsed.
+- owr (1-Wire bus)
+- pwr (1-Wire power)
+
+Options:
+1-Wire is an asynchronous protocol, so the decoder must know the sample rate.
+The timing for sampling bits, presence and reset is calculated by the decoder,
+but in case the user wishes to use different values, it is possible to
+configure the next timing values (number of sample rate periods):
+- overdrive (if active the decoder will be prepared for overdrive)
+- cnt_normal_bit (time for normal mode sample bit)
+- cnt_normal_presence (time for normal mode sample presence)
+- cnt_normal_reset (time for normal mode reset)
+- cnt_overdrive_bit (time for overdrive mode sample bit)
+- cnt_overdrive_presence (time for overdrive mode sample presence)
+- cnt_overdrive_reset (time for overdrive mode reset)
+This options should be configured only on very rare cases and the user should
+read the decoder source code to understand them correctly.
+
+Annotations:
+Annotations can be shown for each layer of the protocol separately:
+- link (the value of each transmitted bit is shown separately)
+- network (the ROM command, and address are shown)
+- transport (only transport layer byte transfers are shown)
+If link layer annotations are shown, possible issues with sample rate and sample
+timing are also shown.
+
+TODO:
+- add CRC checks for network layer
+- add transport layer code
+- review link layer code, to check for protocol correctness
+- define output protocol
'''
from .onewire import *
projects / libsigrokdecode.git / blobdiff