Difference between "SerBr" Tx/Rx and "Serial" Tx/Rx

[dx136]

I'll be interfacing to a variety of serial devices in coming weeks and months and I have a few questions. I've done a fair bit of web searching and forum reading (but have not dug into C code) and the answers are not clear to me. I'd like to stick with the Tasmota web/console environment, so I ask my questions in the context of "no-programming-in-C-code".

Question 1 - I really want to understand the difference between GPIOs defined as "Serial" and "SerBr". For Received data, what is the difference in: (A) "availability" of data? (what is it available to - console? rules? other?) (B) built-in processing by Tasmota? (published via MQTT unless setoption147; other?); and (C) functions for handling the data? (no equivalent functions to SerialSend).
Question 2 - I use a good variety of devices: esp8266, esp32-DOWD-V3, esp32-s2-mini, and esp32-S3-zero, so I'd also like to understand when there's a difference between 8266 and esp32 versions.

For Q2, I'll start off the list of differences below and invite any confirmations, corrections and additions.
Thanks very much! - Michael

ESP32:

• all serial ports are hardware UARTs
• can have multiple serial ports using Berry
• can use most any GPIO for a serial port in Berry
• Berry explicitly allows uni-directional serial (Tx only, or Rx only)
• for Berry serial ports GPIOs need NOT be predefined/configured in the template
• when using Tasmcompiler (I love it!), without adding the correct options, SerBr Tx/Rx are NOT available in the template!
  ??? Not clear which, if any GPIOs are predefined as serial ports (in contrast to esp8266)

ESP8266

• Only one usable hardware serial port, others are software
  Ref: https://tasmota.github.io/docs/Peripherals/#serial
• limited number of ports: limited number of drivers, and drivers can only attach to a single serial port
  So that means at most 3: 1 x hardware, 1 x software, 1 x TCP serial (bridge) (??? please confirm)
  Ref: Accessing the 3rd serial port #18542 "most of Tasmota driver can only be instanciated once"
  ... but not sure if SerBr and Serial are different drivers (??? please confirm)
• GPIO 1 & 3 (alternatively 15 & 13) are pre-defined as hardware serial
  Ref: https://tasmota.github.io/docs/Peripherals/#serial
  Not sure how to set 15 & 13 as alternate hardware Tx/Rx? (??? please confirm/answer)
  https://tasmota.github.io/docs/Commands/#serial-bridge
• Berry is not available, so none of those Berry enhancements (above) are available

[sfromis]

While ESP32 is flexible about which pins you connect to the built-in UART controllers, you still only have three (for ESP32 and ESP32-S3), or two for the other ESP32 variants supported by Tasmota, but with USB CDC, this does not mean that all 3 or 2 are freely available. No pins are predefined as serial, unless you count USB CDC usage. You do not get more UART controllers with Berry, even if you can choose to only use half. Basically, you are still pretty low on available serial devices.

With USE_SERIAL_BRIDGE being default for standard Tasmota builds (with the exception of some specialized builds), and the tool TasmoCompiler not being part of the Tasmota project, any issues with standard selections deviating from the general ones would have to be taken up with the creator of that tool.

With ESP8266, the serial driver will also use hardware serial for gpio 15/13, not only gpio 1/3. TCP serial bridge is not another UART, and software serial usually not recommended for bridging. If you have different sensor drivers having their own usage of serial, I think that you can have extra pins for additional software serial, but not recommended due to timing constraints with software serial being resource-heavy.

In general, if you want to do "your own" serial processing with rules or MQTT bridging, I'd recommend to stick with SerBr. Don't think of this as "software serial", it is just that it can be software serial on ESP8266. Not all serial features are available without using SerBr, and you have the risk of Tasmota standard serial processing (as a console) will get in the way if not using SerBr pins. With ESP32 and Berry, you do of course have a much fuller way of programming with serial.

[ProfAnderson-1]

@sfromis Thanks for the reply.
It's helpful to know the limit on the number of hardware UARTs for the different variants of the ESP32.

Your comment also helped me to know that adding "#define USE_SERIAL_BRIDGE" added in "user_config_override.h" is what makes SerBr available when using TasmoCompiler to build customized firmware.

Regarding TCP serial bridge: your comment makes me think you are saying that feature is a pure software serial (regardless of whether it's on ESP8266 or ESP32). I would have expected it to still be a hardware UART on ESP32. Is there any easy way to verify that for ESP32 (e.g. in the C code)?

Regarding the difference between "SerBr" and "Serial" configuration in the Template or Module: Is it as simple as "Serial" is what's used to designate an RS232 Console port (i.e. for issuing commands and seeing the resulting output), whereas "SerBr" is for Tx/Rx of general data to/from some other device??

Thanks again.

[sfromis]

No, TCP Serial bridge is still as much hardware serial, it's just that expecting to use it on ESP8266 pins not supporting hardware serial is not something to aim for. While it may be "somewhat workable" with lower speeds, software serial is still putting extra load on the CPU, and then you have networking added to also cause extra load per byte.

I've not done a detailed comparison about even considering to use anything but SerBr xx (or specialized pin configs using the serial driver) when adding stuff, as I consider everything but console usage to be within the concept of bridging serial to "something else". And AFAIK, console usage can only work for pins configured for Serial xx, including the implied default when not making an explicit config.

[dx136]

sfromis, Thanks VERY much for you time and help! Much appreciated. :-)