How to configure ESP32 HW UART to input an inverted signal with no pullup on its rxpin?

[GEAG]

Tasmota uses the Arduino HarwareSerial Abstraction for its TasmotaSerial Class which is also uses by the Tasmota SerialBridge.

Until Tasmota 13.4.y, based on core 2.x, it has been possible to patch the source code to disable the pullup on the rxPin of the UART by using the function pinmode(rxPin, INPUT) from the Arduino collection.

Due to a semantic change from core 2.x to 3.x, that is no longer possible. With core 3.x, the UART becomes disconnected by the pinmode function and the pin becomes reconfigured as a digital input pin. Fortunately, it is possible to use an alternative lower driver level function gpio_pullup_dis(pin) for ESP32 instead to avoid to disconnect the UART, This function is declared within "driver/uart.h".

It seems to me to be desirable, that the TasmotaSerial class and SerialBridge would be enhanced with some config options, such that:

1. inverted serial signals can be read if needed
2. The internal pullup, which is activated by default uppon UART allocation through HardwareSerial, can somehow be deactivated if needed.

Or is this desired functionality already possible by other configurable means (without patching the code)?

[sfromis]

At least when using Berry, you have the option of "inverted" when constructing a serial object.
https://tasmota.github.io/docs/Berry/#serial-class
(And I'd already recommend Berry instead of the older serial bridge feature)

This is using the corresponding option on TasmotaSerial
https://github.com/arendst/Tasmota/blob/development/lib/default/TasmotaSerial-3.6.0/src/TasmotaSerial.h#L46

It should be simple to set that option from the serial bridge, if you go that way, but does not appear to already be externalized.
https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_08_serial_bridge.ino#L244

[sfromis]

You're quick to getting up to speed with Berry :-)

One minor detail I noticed is that it would not allow doing a start again after the stop call, as self.ser is still has the closed version of the object. And the nil test in init() should be redundant, as this constructor is only called when the object was freshly created.

[GEAG]

Thanks for your comments. I made some progress to better understand Berry. I have improved my Berry code for a Serial Monitor (v3) for our case of an inverted signal that does not tolerate an internal pullup.

• It successfully reads serial data with Tasmota 13.4.0. (Exception of missing serial.close() method is irrelevant for this purpose)
• Unfortunately, it does not work with Tasmota >14.0.0, because to the semantic change from core 2.x to 3.x

class SerMon
  var ser

  def init(rxPin)
    var invertLevel = true
    var noTxPin = -1
    var baudrate = 2400

    self.ser = serial(rxPin, noTxPin, baudrate, serial.SERIAL_8E1, invertLevel)
    print(tasmota.millis(), "serial channel opened for rxPin", rxPin)
    gpio.pin_mode(rxPin, gpio.INPUT)   # disable pullup
  end

  def poll()
    # assert SerMon object must have been initialized

    var nbB = self.ser.available()
    print(tasmota.millis(), "nb of bytes available =", nbB)

    var bb = bytes() # empty byteBuf
    if (nbB > 0)
      bb = self.ser.read() 
      print(tasmota.millis(), bb.size(), "bytes read from serial =/", bb.tohex(), "/")
    end
    # may do something with bb here
  end

  def start()
    tasmota.add_cron("*/2 * * * * *", /-> self.poll(), "poller")
    print(tasmota.millis(), "cron serial poller activated every 2nd sec")
  end

  def stop()
    tasmota.remove_cron("poller")
    print(tasmota.millis(), "cron poller terminated" )
    self.ser.close()
    print(tasmota.millis(), "serial channel closed", self.ser)
    self.ser = nil # allow gc to collect Serial object
  end

  def runFor(runSec)
    self.start()
    print(tasmota.millis(), "will stop after runSec=", runSec, "seconds")
    tasmota.set_timer(runSec*1000, / -> self.stop())  # closure for method with no args
  end
end

This is the code for a test run:

# testing
  # next 2 lines only needed to avoid bugs in T 13.4.0
  var smo = nil
  tasmota.gc()

  smo = SerMon(10)
  smo.runFor(6)

And this is the output in the console for T 13.4.0 (hex byte buffers ... cut off by hand):

20:38:10.635 BRY: Serial UART1
20:38:10.637 1268712 serial channel opened for rxPin 10
20:38:10.641 1268717 cron serial poller activated every 2nd sec
20:38:10.643 1268718 will stop after runSec= 6 seconds
20:38:12.237 1270312 nb of bytes available = 56
20:38:12.239 1270314 56 bytes read from serial =/ 8000FF0F02... /
20:38:14.242 1272317 nb of bytes available = 179
20:38:14.245 1272320 179 bytes read from serial =/ 7EA084CEFF0313... /
20:38:16.247 1274322 nb of bytes available = 20
20:38:16.250 1274325 20 bytes read from serial =/ 7EA084CEFF0313... /
20:38:16.694 1274769 cron poller terminated
20:38:16.695 BRY: Exception> 'attribute_error' - the 'serial' object has no attribute 'close'
20:38:16.696 stack traceback:
20:38:16.697 	<unknown source>: in function `stop`
20:38:16.699 	<unknown source>: in function `<lambda>`
20:38:16.700 	<unknown source>: in function `run_deferred`
20:38:16.701 	<unknown source>: in function `event`

The same code run on T 14.0.0 oder 14.1.0 does never show any bytes available.
The problem is probably this function, that disconnects the UART from the HW pin in core 3.x:

gpio.pin_mode(rxPin, gpio.INPUT)

Would be nice, if this could be fixed in an upcoming release.

[sfromis]

The detail about close() (which is indeed not important to this testing) was due to this being added for consistency. Internally, it does the same as the destructor deinit(), but it is not good programming practice to treat the destructor as an API method; hence close() was added - also making it more similar to other classes where you can choose when resources can be released, using an explicit close() method.

[GEAG]

The same code run on T 14.0.0 oder 14.1.0 does never show any bytes available. The problem is probably this function, that disconnects the UART from the HW pin in core 3.x:

gpio.pin_mode(rxPin, gpio.INPUT)

Would be nice, if this could be fixed in an upcoming release.

To verify my assumption, I have compiled a fresh Tasmota 14.2.0 with the following uggly patch (just for demo), applied to file xdrv_52_3_berry_native.ino:

 int gp_pin_mode(bvm *vm) {
    int32_t argc = be_top(vm); // Get the number of arguments
    if (argc == 2 && be_isint(vm, 1) && be_isint(vm, 2)) {
      int32_t pin = be_toint(vm, 1);
      int32_t mode = be_toint(vm, 2);
      if (pin >= 0) {
        if (mode > 0) {
          // standard ESP mode
          // GEAG replaced Arduino function by ESP32 lower level function
          //pinMode(pin, mode);
          gpio_pullup_dis((gpio_num_t)pin);
        } else {

As expected, the serial Berry code also performs fine with the same result as the unpatched Tasmota 13.4.0 for a serial pin connected to the UART that needs to have the pullup disabled.

The pinMode function from the arduino core 3.x should be replaced to fix this problem. I am not sure, how this is done best. I hope that someone from the more experienced Tasmota developers is able to take over to integrate such a fix in Tasmota 14.2.x. The solution should hopefully also work for the SerialBridge without Berry (and probably other drivers that use an UART to input data, where no pullup can be tolerated.

[GEAG]

The problem might be fixed in the following place within Tasmota in file support_esp32.ino?

/******************************************************************************************/
// Since ESP-IDF 4.4, GPIO matrix or I/O is not reset during a restart
// and GPIO configuration can get stuck because of leftovers
//
// This patched version of pinMode forces a full GPIO reset before setting new mode
//
#include "driver/gpio.h"

extern "C" void ARDUINO_ISR_ATTR __pinMode(uint8_t pin, uint8_t mode);

extern "C" void ARDUINO_ISR_ATTR pinMode(uint8_t pin, uint8_t mode) {
gpio_reset_pin((gpio_num_t)pin);
__pinMode(pin, mode);**

The brute force added gpio_reset_pin function is probably not 100% appropriate, if the user just wants to set some new mode for a pin, because it also disconnects the UART from the pin.

[esp_err_t](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/esp_err.html#_CPPv49esp_err_t) gpio_reset_pin(gpio_num_t gpio_num)[](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/gpio.html#_CPPv414gpio_reset_pin10gpio_num_t)

    Reset an gpio to default state (select gpio function, **enable pullup** and disable input and output).

    Note

    This function also configures the IOMUX for this pin to the GPIO function, and disconnects any other peripheral output configured via GPIO Matrix.

But unfortunately, this does not have an effect on Berry.

[arendst]

Try latest dev branch. It adds command SetOption69 1 to invert Rx on SerialBridge.

[GEAG]

Thanks for the enhancement.
It would probably not work in my case, because the pullup is not disabled. I will therefore not be able to test it.