uart: Drop extensive protocol info (moved to wiki).

Move the full details of the protocol to the wiki, the docs in the PD
itself should only be a short description and/or a collection of notes
that could be useful for a user in a GUI (or CLI) to decide which
PD to select, which options to set how, what PDs to stack where, and so on.

The full protocol description (including photos, examples, ...) is here:

  http://sigrok.org/wiki/Protocol_decoder:Uart

1 files changed, 14 insertions, 66 deletions

diff --git a/decoders/uart/__init__.py b/decoders/uart/__init__.py
index dcee3bf..a8b7303 100644
--- a/decoders/uart/__init__.py
+++ b/decoders/uart/__init__.py
@@ -24,72 +24,20 @@ UART 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
+This decoder should work on all "UART-like" async protocols with one
+start bit (0), 7-9 databits, an (optional) parity bit, and one or more
+stop bits (1), in this order.
+
+It can be run on one signal line (RX or TX) only, or on two lines (RX + TX).
+
+There are various standards for the physical layer specification of the
+signals, including RS232, (TTL) UART, RS485, and others. However, the logic
+level of the respective pins is only relevant when acquiring the data via
+a logic analyzer (you have to select the correct logic analyzer and/or
+the correct place where to probe). Once the data is in digital form and
+matches the "UART" description above, this protocol decoder can work with
+it though, no matter whether the source was on TTL UART levels, or RS232,
+or others.
 
 Protocol output format: