RS-485 for BeagleBone: a quick peek at the OMAP UART

A few weeks ago, I published a blog post demonstrating the need of a real-time solution in order to support the RS-485 standard reliably on BeagleBones. Although I also wrote that the existing OMAP UART (official UART on the BeagleBone SoC) is not a solution to consider here, I decided to take a look at it anyway, out of curiosity.

Actually, I was really interested in discovering how the authors of the driver implemented support for RS-485, which was added in August 2013. Then, when trying it and looking at the source later, I noticed a minor issue affecting performance during ends of transmissions (which is a critical step when implementing RS-485). This led me to submit a patch to the Linux kernel, which was merged last week.

If you are interested in the Linux kernel and industrial protocols, you should appreciate this rather technical post.

Source code analysis

Quickly reading the new version of omap-serial.c (with added RS-485 support), I found that many properties related to RS-485 may now be added to UART OMAP nodes in the DTS. Amongst them, rs485-rts-delay caught my attention: a first look at the code revealed a few calls to mdelay, which uses the values of this property (busy-wait delays before and after UART transmissions).

I first thought those calls were responsible for ensuring a completed transmission: waiting for a fixed time interval after receiving an empty transmit FIFO interrupt. However, when actually reading the code, I found that the mdelay calls are only waiting for an extra time to be added before and after transmissions, while the actual end of transmission is known otherwise. Simply set both values of rs485-rts-delay to 0 in order to get the shortest possible turnaround delay. In fact, the values of this property are directly given to the delay_rts_before_send and delay_rts_before_send members of an instance of struct serial_rs485, a structure defined by the Linux serial subsystem itself.

The data direction signal uses a GPIO pin reserved by the device driver.

In short, here’s how the OMAP UART transmission works within its Linux driver when RS-485 support is enabled:

• When the Linux serial subsystem asks the driver to start a transmission, the latter enables transmit FIFO interrupts (or THR interrupts, for Transmitter Holding Register). The driver also asserts the RS-485 data direction GPIO pin to take the bus.
• The OMAP UART asserts a THR interrupt as long as its transmit FIFO contains 32 characters or less.
• When the driver handles a THR interrupt, it adds up to 16 new characters to this FIFO, potentially increasing its level to 48.
• If the driver, when a THR interrupt is asserted, has nothing else to provide to its UART (no more user-supplied characters), it checks if the transmission is completed (a status bit is dedicated to this condition), and:
  • if the transmission is not finished, it leaves the THR interrupt enabled;
  • if the transmission is finished, it disables the THR interrupt and deasserts the data direction GPIO pin in order to release the RS-485 bus.

Bearing in mind that the UART asserts a THR interrupt as long as its transmit FIFO level is equal or less than 32 characters, we see that the driver is essentially polling the end of transmission status bit during the whole transmission time of 33 characters (since as soon as the transmit FIFO level reaches 32 characters, another one is being transmitted). Indeed, by not disabling the interrupt, the handler is called back immediately since the transmit FIFO is in the process of emptying out. At 9600 bauds (with 1 stop bit and without parity), we’re talking about 34 ms of the ARM doing nothing else but handling UART interrupts. This is true everytime there’s an end of transmission, which obviously happen very often in applications that need RS-485, like industrial control systems.

Let’s confirm those assumptions physically.

Preparing a first test

In my DTS file, I specified no additional delay after/before transmissions. I also set the node to enable RS-485 support as soon as the driver loads. I could also have enabled RS-485 afterwards, in userspace, by calling ioctl with appropriate values. Since the first UART instance, UART0, is used for the console, I’m testing with UART1 (the AM335x has 6 OMAP UARTs):

uart1: serial@48022000 {
    pinctrl-names = "default";
    pinctrl-0 = ;

    /* No extra delay after/before transmissions */
    rs485-rts-delay = ;

    /* GPIO1 pin 17 for data direction */
    rts-gpio = ;

    /* GPIO1 pin 16 for testing */
    test-gpio = ;

    /* Enable RS-485 */
    linux,rs485-enabled-at-boot-time;

    status = "okay";
};

The symbol uart1_pins is a reference to the following configuration node for pin multiplexing:

uart1_pins: pinmux_uart1_pins {
    pinctrl-single,pins = ;
};

Pin 17 of the GPIO1 controller is available on the P9 expansion header, next to the Tx output of UART1, on the white BeagleBone I’m using to test (pins 23 and 24 of this expansion header). In order to verify the frequency of THR interrupts, I also added another GPIO output (pin 16 of GPIO1, which is pin 15 of BeagleBone’s P9 expansion header) that will assert a very short pulse everytime transmit_chars is called (when there’s a THR interrupt).

I’m using the Saleae Logic logic analyzer to verify precisely the UART outputs and the RS-485 turnaround delay. Here’s my setup:

The orange probe is connected to the Tx output of UART1, while the red one is probing the RS-485 data direction output. The blue probe is used for THR interrupts pulses.

Now, on the BeagleBone userspace side:

# stty -F /dev/ttyO1 115200 cs8
# while true; do
    echo -n '0123456789abcdef0123456789abcdefWXYZ0123456789abcdef0123456789abcdef' > /dev/ttyO1
  done

The time required from one iteration to the next to open, configure and close the /dev/ttyO1 port is way enough to properly delimit each little serial transmission. The WXZY part is used here to isolate the 32 last characters of a single transmission.

First test

Using the Saleae analysis software shipped with the Logic, I read 5 million samples at 12 MHz:

This looks like the expected behaviour. First of all, three THR interrupts are handled successively (just before the 4 ms mark):

• The first one adds 16 characters to the empty UART transmit FIFO. The UART continues asserting a THR interrupt since its transmit FIFO has less than 33 characters. Moreover, it immediately starts the transmission of the first character, making the transmit FIFO level 15 characters.
• The second THR interrupt adds 16 more characters, which increases the transmit FIFO level to 31 characters. Again, the transmit FIFO has 32 characters or less, so the UART continues asserting a THR interrupt.
• Finally, the third THR interrupt adds 16 more characters to the transmit FIFO, making the UART not hungry anymore. The transmit FIFO count is now 47.

The transmit FIFO now has to drain 15 characters before the next THR interrupt is asserted, which we observe with the transmission of characters 1 to f. As soon as f is copied from the transmit FIFO to the UART’s transmit shift register, the FIFO level becomes 32, explaining the pulse seen just before f is sent.

This cycle repeats itself until only 4 characters can be added (because of the substring WXYZ) since the driver buffer has nothing else to provide. Those characters are the last cdef to be transmitted at the end. When the next THR interrupt is asserted, just before transmitting Z, the driver buffer is now empty, so it enters in this polling loop we discussed before. This loop goes on during the transmission of 33 characters. The big white rectangles on the above screenshot are in fact an interrupt flood, more easily seen when we zoom in:

Eventually, the last bit is completely transmitted. This condition being satisfied, the driver finally disables THR interrupts and deasserts the RS-485 data direction GPIO pin.

As you can see on the last screenshot, the RS-485 turnaround delay is pretty good (much shorter than the transmission time of a single character). By constantly polling the end of transmission status bit thanks to the interrupt handler being called back all the time, the driver is able to achieve a decent delay between the effective end of a transmission and the update of the RS-485 data direction signal.

Improving omap-serial.c

The behaviour of the UART driver shown above can be improved. The OMAP UART is compatible with 16C750, a well-known UART type, but it also adds a supplementary control register, SCR. The TMEMPTYCTLIT bit of SCR is especially interesting if set: THR interrupts is generated when TX FIFO and TX shift register are empty. This is exactly what is needed.

Obviously, we don’t want to be interrupted at the end of a transmission when the driver buffer is not empty: the transmission has to be continuous, without “holes”. So we only need to set TMEMPTYCTLIT when handling a THR interrupt without it (transmit FIFO reached its threshold) and when the driver has nothing else to provide to the UART, which means an end of transmission is inevitably upcoming. In this case, we must also keep THR interrupts enabled. The next asserted THR interrupt should then tell us that the transmission is finished, in which case we may now disable THR interrupts with peace of mind.

Results? See the difference:

If, during the transmission of the last 32 characters, a new transmission is asked to the driver, then TMEMPTYCTLIT is unset, which causes the assertion of a THR interrupt since the transmit FIFO level is below 33 characters. This is needed to avoid holes between two consecutive independent transmissions.

Although the OMAP UART seems to support the RS-485 standard with a pretty decent turnaround delay, keep in mind that it’s still not a real-time solution. The turnaround delay is always dependent upon the driver availability and therefore not guaranteed. If many other interrupts with higher priorities have to be handled, the OMAP UART driver one will undergo a greater latency, and so will be the turnaround delay.

* The patch was submitted to Linux on October 23th, 2013 and merged on October 29th.