Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:   +32 +0.008% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

An alternative would be to add a compile-time config option

I think that's a slightly better way to do it. Because otherwise we have to agree on the changes to the API which may then be used by other ports. And probably it should default to no pull-ups, because that's what most (all?) other ports have.

And with a compile-time config option, the user doesn't have to worry about which UART needs the pull up enabled/disabled.

I'm assuming that your board itself has the RS485 transceiver installed on a fixed UART instance, and so a static configuration would suffice?

Also note that both RX and CTS are pulled high. CTS is more important to pull high than RX, otherwise transmission can get blocked if the other side doesn't do the right thing with CTS (it's RTS). Did you intend for this option to apply to both RX and CTS, or just RX?

Instead of using MICROPY_HW_UART1_NO_RX_PULLUP as the config option I suggest MICROPY_HW_UART1_RX_PULL (that matches MICROPY_HW_USRSW_PULL). Then if it's not defined it can default to GPIO_PULLUP.

And probably it should default to no pull-ups, because that's what most (all?) other ports have.

mimxrt seems to enable some default pull-ups on all lines (even TX and RTS). I'm not sure if any of them is needed though.

I'm assuming that your board itself has the RS485 transceiver installed on a fixed UART instance, and so a static configuration would suffice?

Yes exactly. This is for the OPTA's board which is currently being added upstream. So I think I should get this done first because it will require changes to the board config file.

Did you intend for this option to apply to both RX and CTS, or just RX?

We didn't test them separately, but without the pull-up on both modbus started working. Would you like to still use MICROPY_HW_UART1_RX_PULL for both ? or something like MICROPY_HW_UART1_NO_PULL ?

Would you like to still use MICROPY_HW_UART1_RX_PULL for both ? or something like MICROPY_HW_UART1_NO_PULL ?

I think they need to be individually configurable... even if that does increase the configuration options by a lot.

I don't like negatives like "NO" in config options because it makes it harder to understand when it's in logic like !MICROPY_HW_UART1_NO_PULL. Much prefer to have positive options than negative options.

So, it would be MICROPY_HW_UARTx_RX_PULL and MICROPY_HW_UARTx_CTS_PULL, defaulting to GPIO_PULLUP. Unless you can think of a cleaner way to do it.

Looking at the original code again, it seems to be configuring a pull-up on all pins not just RX/CTS, am I right ? If so then MICROPY_HW_UARTx_PULL should be used.

    for (uint i = 0; i < 4; i++) {
        if (pins[i] != NULL) {
            // Configure pull-up on RX and CTS (the input pins).
            uint32_t pull = (i & 1) ? MP_HAL_PIN_PULL_UP : MP_HAL_PIN_PULL_NONE;
            bool ret = mp_hal_pin_config_alt(pins[i], mode, pull, uart_fn, uart_unit);
            if (!ret) {
                return false;
            }
        }
    }

EDIT ah I see the (i &1).

So, it would be MICROPY_HW_UARTx_RX_PULL and MICROPY_HW_UARTx_CTS_PULL, defaulting to GPIO_PULLUP. Unless you can think of a cleaner way to do it.

This will just complicate the logic above, not sure if fine-grained control over this is really needed: you either need the pull-ups or not, but I can try.

Unless you can think of a cleaner way to do it.

Okay, how about now with an array solution ?

Okay, how about now with an array solution ?

Yes, that looks good!

Does it work for the OPTA?

Does it work for the OPTA?

I'm confident it will, we just needed to disable the RX pull on UART3. I can't test it right now, but will ask someone else to test it after this and the Opta support are merged.