mirror of
https://github.com/esphome/esphome-docs.git
synced 2024-09-07 01:08:15 +02:00
185 lines
8.3 KiB
ReStructuredText
185 lines
8.3 KiB
ReStructuredText
.. _uart:
|
|
|
|
UART Bus
|
|
========
|
|
|
|
.. seo::
|
|
:description: Instructions for setting up a UART serial bus on ESPs
|
|
:image: uart.svg
|
|
:keywords: UART, serial bus
|
|
|
|
UART is a common serial protocol for a lot of devices. For example, when uploading a binary to your ESP
|
|
you have probably used UART to access the chip. UART (or for Arduino often also called Serial) usually
|
|
consists of 2 pins:
|
|
|
|
- **TX**: This line is used to send data to the device at the other end.
|
|
- **RX**: This line is used to receive data from the device at the other end.
|
|
|
|
Please note that the naming of these two pins depends on the chosen perspective and can be ambiguous. For example,
|
|
while the ESP might send (``TX``) on pin A and receive (``RX``) data on pin B, from the other device's
|
|
perspective these two pins are switched (i.e. *it* sends on pin B and receives on pin A). So you might
|
|
need to try with the two pins switched if it doesn't work immediately.
|
|
|
|
Additionally, each UART bus can operate at different speeds (baud rates), so ESPHome needs to know what speed to
|
|
receive/send data at using the ``baud_rate`` option. The most common baud rates are 9600 and 115200.
|
|
|
|
In some cases only **TX** or **RX** exists as the device at the other end only accepts data or sends data.
|
|
|
|
.. note::
|
|
|
|
On the ESP32, this component uses the hardware UART units and is thus very accurate. On the ESP8266 however,
|
|
ESPHome has to use a software implementation as there are no other hardware UART units available other than the
|
|
ones used for logging. Therefore the UART data on the ESP8266 can have occasional data glitches especially with
|
|
higher baud rates..
|
|
|
|
.. note::
|
|
|
|
From ESPHome 2021.8 the ``ESP8266SoftwareSerial`` UART ``write_byte`` function had the parity bit fixed to be correct
|
|
for the data being sent. This could cause unexpected issues if you are using the Software Serial and have devices that
|
|
explicity check the parity. Most likely you will need to flip the ``parity`` flag in YAML.
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
# Example configuration entry
|
|
uart:
|
|
tx_pin: 1
|
|
rx_pin: 3
|
|
baud_rate: 9600
|
|
|
|
Configuration variables:
|
|
------------------------
|
|
|
|
- **baud_rate** (**Required**, int): The baud rate of the UART bus.
|
|
- **tx_pin** (*Optional*, :ref:`config-pin`): The pin to send data to from the ESP's perspective. Use the full pin schema and set ``inverted: true`` to invert logic levels.
|
|
- **rx_pin** (*Optional*, :ref:`config-pin`): The pin to receive data on from the ESP's perspective. Use the full pin schema and set ``inverted: true`` to invert logic levels.
|
|
- **rx_buffer_size** (*Optional*, int): The size of the buffer used for receiving UART messages. Increase if you use an integration that needs to read big payloads from UART. Defaults to ``256``.
|
|
- **data_bits** (*Optional*, int): The number of data bits used on the UART bus. Options: 5 to 8. Defaults to 8.
|
|
- **parity** (*Optional*): The parity used on the UART bus. Options: ``NONE``, ``EVEN``, ``ODD``. Defaults to ``NONE``.
|
|
- **stop_bits** (*Optional*, int): The number of stop bits to send. Options: 1, 2. Defaults to 1.
|
|
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this UART hub if you need multiple UART hubs.
|
|
- **debug** (*Optional*, mapping): Options for debugging communication on the UART hub, see :ref:`uart-debugging`.
|
|
|
|
.. _uart-hardware_uarts:
|
|
|
|
Hardware UARTs
|
|
--------------
|
|
|
|
Whenever possible, ESPHome will use the hardware UART unit on the processor for fast and accurate communication.
|
|
When the hardware UARTs are all occupied, ESPHome will fall back to a software implementation that may not
|
|
be accurate at higher baud rates.
|
|
|
|
``UART0`` is (by default) used by the :doc:`logger component </components/logger>`, using ``tx_pin: GPIO1`` and
|
|
``rx_pin: GPIO3``. If you configure a UART that overlaps with these pins, you can share the hardware with the
|
|
logger and leave others available. If you have configured the logger to use a different hardware UART, the pins
|
|
used for hardware sharing change accordingly.
|
|
|
|
The ESP32 has three UARTs. Any pair of GPIO pins can be used, as long as they support the proper output/input modes.
|
|
|
|
The ESP8266 has two UARTs; the second of which is TX-only. Only a limited set of pins can be used. ``UART0`` may
|
|
use either ``tx_pin: GPIO1`` and ``rx_pin: GPIO3``, or ``tx_pin: GPIO15`` and ``rx_pin: GPIO13``. ``UART1`` must
|
|
use ``tx_pin: GPIO2``. Any other combination of pins will result in use of a software UART.
|
|
|
|
.. _uart-write_action:
|
|
|
|
``uart.write`` Action
|
|
---------------------
|
|
|
|
This :ref:`Action <config-action>` sends a defined UART signal to the given UART bus.
|
|
|
|
.. code-block:: yaml
|
|
|
|
on_...:
|
|
- uart.write: 'Hello World'
|
|
|
|
# For escape characters, you must use double quotes!
|
|
- uart.write: "Hello World\r\n"
|
|
|
|
# Raw data
|
|
- uart.write: [0x00, 0x20, 0x42]
|
|
|
|
# Templated, return type is std::vector<uint8_t>
|
|
- uart.write: !lambda
|
|
return {0x00, 0x20, 0x42};
|
|
|
|
# in case you need to specify the uart id
|
|
- uart.write:
|
|
id: my_second_uart
|
|
data: 'other data'
|
|
|
|
.. _uart-debugging:
|
|
|
|
Debugging
|
|
---------
|
|
|
|
If you need insight in the communication that is being sent and/or received over a UART bus, then you can make use
|
|
of the debugging feature.
|
|
|
|
.. code-block:: yaml
|
|
|
|
# Example configuration entry
|
|
uart:
|
|
baud_rate: 115200
|
|
debug:
|
|
direction: BOTH
|
|
dummy_receiver: false
|
|
after:
|
|
delimiter: "\n"
|
|
sequence:
|
|
- lambda: UARTDebug::log_string(direction, bytes);
|
|
|
|
# Minimal configuration example, logs hex strings by default
|
|
uart:
|
|
baud_rate: 9600
|
|
debug:
|
|
|
|
- **direction** (*Optional*, enum): The direction of communication to debug, one of: "RX" (receive, incoming),
|
|
"TX" (send, outgoing) or "BOTH". Defaults to "BOTH".
|
|
- **dummy_receiver** (*Optional*, boolean): Whether or not to enable the dummy receiver feature. The debugger
|
|
will only accumulate bytes that are actually read or sent by a UART device component. This feature is
|
|
useful when you want to debug all incoming communication, while no UART device component is configured
|
|
for the UART bus (yet). This is especially useful for developers. Normally you'd want to leave this
|
|
option disabled. Defaults to false.
|
|
- **after** (*Optional*, mapping): The debugger accumulates bytes of communication. This option defines when
|
|
to trigger publishing the accumulated bytes. The possible options are:
|
|
|
|
- **bytes** (*Optional*, int): Trigger after accumulating the specified number of bytes. Defaults to 150.
|
|
- **timeout** (*Optional*, :ref:`config-time`): Trigger after no communication has been seen during the
|
|
specified timeout, while one or more bytes have been accumulated. Defaults to 100ms.
|
|
- **delimiter** (*Optional*, string or list of bytes): Trigger after the specified sequence of bytes is
|
|
detected in the communication.
|
|
|
|
- **sequence** (*Optional*, :ref:`Action <config-action>`): Action(s) to perform for publishing debugging data.
|
|
Defaults to an action that logs the bytes in hex format. The actions can make use of the following variables:
|
|
|
|
- **direction**: ``uart::UART_DIRECTION_RX`` or ``uart::UART_DIRECTION_TX``
|
|
- **bytes**: ``std::vector<uint8_t>`` containing the accumulated bytes
|
|
|
|
**Helper functions for logging**
|
|
|
|
Helper functions are provided to make logging of debug data in various formats easy:
|
|
|
|
- **UARTDebug::log_hex(direction, bytes, char separator)** Log the bytes as hex values, separated by the provided
|
|
separator character.
|
|
- **UARTDebug::log_string(direction, bytes)** Log the bytes as string values, escaping unprintable characters.
|
|
- **UARTDebug::log_int(direction, bytes, char separator)** Log the bytes as integer values, separated by the provided
|
|
separator character.
|
|
- **UARTDebug::log_binary(direction, bytes, char separator)** Log the bytes as ``<binary> (<hex>)`` values,
|
|
separated by the provided separator character.
|
|
|
|
**Logger buffer size**
|
|
|
|
Beware that the ``logger`` component uses a limited buffer size of 512 bytes by default. If the UART
|
|
debugger log lines become too long, then you will notice that they end up truncated in the log output.
|
|
|
|
In that case, either make sure that the debugger outputs less data per log line (e.g. by setting the
|
|
``after.bytes`` option to a lower value) or increase the logger buffer size using the logger
|
|
``tx_buffer_size`` option.
|
|
|
|
See Also
|
|
--------
|
|
|
|
- :doc:`/components/logger`
|
|
- :apiref:`uart/uart.h`
|
|
- :ghedit:`Edit`
|