[mimxrt (teensy) Allow Any GPIO pin for RS485 pin

[KurtE]

Fixes #6310
Fixes #6332

The existing code was setup that allowed you to specify an RTS
pin to be used as an RS485 direction pin, however there are no
RTS pins that are exposed on any of the Teensy 4.x boards.

Instead Arduino code base allowed you to specify any GPIO pin to
work instead. So I added the code in to facilitate this.

In addition the alternative code to wrap your own GPIO pin set high and low
around call(s) to uart.write() will not currently work, unless maybe you
fudge it and add your own delays as the write will return after the last
byte was pushed onto the UART’s hardware FIFO queue and as such if you
then immediately set the IO pin low, it will corrupt your output stream.

The code I added detects that you are setup to use the RS485 pin and
before it returns will wait for the UART’s Transfer complete status flag
to be set.

We (@mjs513 and myself) have done a little playing with Dynamixel Servos connected up to a Teensy 4.1

I have hacked up the Python version of the DynamixelSDK to run on CPY.

Will continue to play some more, with it...

[KurtE]

Note: This is to fix the issues in #6310

[KurtE]

As a slightly off topic - in that other ports have similar limitations, like RP2040, I am playing with a first cut of making the same logical code work more or less the same on it...

That is the construct code has added (also remove the error message)

    if (rs485_dir != NULL) {
        uint8_t pin = rs485_dir->number;
        self->rs485_dir_pin = pin;
        self->rs485_invert = rs485_invert;

        gpio_init(pin);

        claim_pin(rs485_dir);

        gpio_disable_pulls(pin);

        // Turn on "strong" pin driving (more current available).
        hw_write_masked(&padsbank0_hw->io[pin],
            PADS_BANK0_GPIO0_DRIVE_VALUE_12MA << PADS_BANK0_GPIO0_DRIVE_LSB,
            PADS_BANK0_GPIO0_DRIVE_BITS);

        gpio_put(self->rs485_dir_pin, rs485_invert);
        gpio_set_dir(self->rs485_dir_pin, GPIO_OUT);
    } else {
        self->rs485_dir_pin = NO_PIN;
    }

And the write code:

size_t common_hal_busio_uart_write(busio_uart_obj_t *self, const uint8_t *data, size_t len, int *errcode) {
    if (self->tx_pin == NO_PIN) {
        mp_raise_ValueError(translate("No TX pin"));
    }

    if (self->rs485_dir_pin != NO_PIN) {
        uart_tx_wait_blocking(self->uart);
        gpio_put(self->rs485_dir_pin, !self->rs485_invert);
    }

    size_t left_to_write = len;
    while (left_to_write > 0) {
        while (uart_is_writable(self->uart) && left_to_write > 0) {
            // Write and advance.
            uart_get_hw(self->uart)->dr = *data++;
            // Decrease how many chars left to write.
            left_to_write--;
        }
        RUN_BACKGROUND_TASKS;
    }
    if (self->rs485_dir_pin != NO_PIN) {
        uart_tx_wait_blocking(self->uart);
        gpio_put(self->rs485_dir_pin, self->rs485_invert);
    }
    return len;
}

And I am getting it to drive that pin 

Adafruit CircuitPython 7.3.0-beta.1-31-g73f6b4867-dirty on 2022-04-30; Adafruit Feather RP2040 with rp2040

import board, busio
board.UART().deinit()
uart = busio.UART(board.TX, board.RX, rs485_dir=board.D5, baudrate=1000000)
uart.write(b'abcdeef')
7

![image](https://user-images.githubusercontent.com/1558080/166118548-d1749b01-68f3-4a87-bb0c-5a3bae519c98.png)

But as you can see, it holds the DIR pin high for longer than I would like... Not sure if
` uart_tx_wait_blocking(self->uart);
`
Is the best way to detect when the write completes?  Sorry I am not much of expert on these chips... But the spec sort of sounded like the busy flag would be held asserted until the TX completes...

Suggestions?  Or maybe just punt? 

[jepler]

I didn't spot any problems, but no testing performed.

Note: This is to fix the issues in #6310

Please use the special syntax (by editing the initial comment on the PR) to 'link' issues that will be fixed by a pull request. It's super helpful. You can do this anytime before the PR is merged. (edited to add the link to the docs)

[dhalbert]

Hi - my understanding is that you are simulating RS485 serial hardware, which guarantees certain timing on the direction pin, as described, for instance, in https://www.st.com/resource/en/application_note/cd00249778-managing-the-driver-enable-signal-for-rs485-and-iolink-communications-with-the-stm32s-usart-stmicroelectronics.pdf (linke courtesy @jepler).

if, say, an interrupt occurred before the pin was toggled, the signal might get delayed, or it might get lengthened if the interrupt occurred during the toggle. Then the timing might break RS485 rules.

Up to now, we have only implemented RS485 when the hardware provided it, e.g. SAMD51 vs SAMD21. Did the i.MX port use hw RS485 before, and now it optionally doesn't? I'm not sure even after reading the code.

I'm concerned that this RS485 might work "most" of the time, but would randomly fail occasionally due to timing issues. For casual servo work that might be fine, but not in other cases.

[KurtE]

I'm concerned that this RS485 might work "most" of the time, but would randomly fail occasionally due to timing issues. For casual servo work that might be fine, but not in other cases.

Understood!

However today on all of the Teensy 4.x board you two choices. Either it works most of the time, or works none of the time. None of the Uarts have any CTS pins exposed, as such you do not have a way to synchronize a pin with when transmission completes.

Your Uart Write code here is neither synchronous nor asynchronous as it returns as soon as it places the last byte in the output queue of the IMXRT processor. As I showed in the issue mentioned in first post, if your code then tries to emulate it, it may easily drop the IO level before the transfer completes.

And your interface does not provide anything like Arduino: Serial1.flush()
or Linux(FTDI) termios tcDrain() which I found you really want to avoid except for FTDI...

So If you are uncomfortable with this approach, you should probably close out this PR as well as #6330

Alternatively you could choose to do something different like:

a) Add a flush() method which waits until transfer is complete. Note PySerial has this. At which case the user code code do the same stuff as I did in this PR.

b) Do a major rework of your BUSIO code base, and for example have software output queue, where the UART code will fill up the hardware queue from software queue, and when it completes, and you get the interrupt for Transfer complete, the interrupt code is the one that then transfer has completed, at which point it handles setting the state of the RS485 direction pin... It also handles changing the appropriate registers to allow the Serial port to work in half duplex mode.

Until then I will stop experimenting of trying to use CircuitPython on Robot controller that outputs to servos.

[dhalbert]

Your Uart Write code here is neither synchronous nor asynchronous as it returns as soon as it places the last byte in the output queue of the IMXRT processor.

Both the atmel-samd and the nrf ports wait until the UART peripheral is no longer busy to return. I think, but am not sure, that mean that the last byte has been transmitted out of the FIFO. If the i.MX port is not doing that, then it should, and we would welcome that fix.

(As I think may be clear already, the current i.MX code is in no way sacred, and issues you find are not necessarily based on deliberate choices when the code was written.)

Re RS485. We could place a warning in the documentation that the RS485 support is "best effort, use with caution", and that seems fine to me.

[dhalbert]

Re RS485. We could place a warning in the documentation that the RS485 support is "best effort, use with caution", and that seems fine to me.

Added a doc note. I'll approve this and the RP2040 one after that.

[KurtE]

Sounds good

[dhalbert]

Thanks for your work on this!

[dhalbert]

Both the atmel-samd and the nrf ports wait until the UART peripheral is no longer busy to return. I think, but am not sure, that mean that the last byte has been transmitted out of the FIFO. If the i.MX port is not doing that, then it should, and we would welcome that fix.

There is an issue I found about this for atmel-samd: #1770