Stick mark/space parity for RS485 support

[u77345]

Suggesting the addition of mark/space stick parity to support RS485 on the PL011 UART. Stick parity seems to be a standard feature of the PL011 UART, as reported to work on the BCM8235:
https://marc.info/?l=linux-serial&m=145706834101241&w=2

Using stick parity also assumes the UART will be used in blocking mode to transmit, given that stick parity needs to be set/reset by reinitializing before each write(). Therefore, it is necessary to detect when the TX buffer is empty.

This technique worked well on the RP2040 UART, also a PL011 device.

[rsta2]

In my opinion RS485 support should be implemented in a separate class. The class CSerialDevice is already rather complex. According to the "BCM2835 ARM Periperals" document it's forbidden to change the parity settings in the UART LCRH register, while the UART is enabled, but CSerialDevice is designed for the UART being enabled all the time, when it is used. That's why implementing the Mark/Space parity setting would make it even more complex.

[rsta2]

RS-485 support would be great to have in Circle. What I read, it is used for data acquisition systems, which I see as one interesting application for Circle. Unfortunately I'm not familiar with RS-485 and I do not have RS-485 equipment for testing. So I would need help to realize this. From Wikipedia I did read, that:

RS-485 does not define a communication protocol; merely an electrical interface. Although many applications use RS-485 signal levels, the speed, format, and protocol of the data transmission are not specified by RS-485.

Therefore I'm a little bit unsure, what it needs to support real RS-485 applications. I can only see, that the PL011 UART description for the BCM2835 says:

The UART_LCRH, UART_IBRD, and UART_FBRD registers must not be changed:

• when the UART is enabled
• when completing a transmission or a reception when it has been programmed to become disabled.

This makes it complicated to add a method to the Circle serial driver, which simply changes the (stick) parity settings, while the UART is running. These setting are made in the UART_LCRH register. Thus I would prefer to add a specific class, which implements the mentioned TX block mode and switches the UART on and off, when it is necessary. To implement this more info on the protocol is required.

[u77345]

This article well describes the RS-485 multidrop networks: https://www.electronicdesign.com/technologies/embedded/article/21763399/use-the-pcs-uart-with-9-bit-protocols

I agree, the UART as a standard component is not a good fit. Thinking of a new specific PL011UART class might be better to expose the low level functions, like the RP2040 SDK does. This is my code on Pico SDK to send a packet on a mutidrop bus with RP2040 (also PL011):

    uart_tx_wait_blocking(UART_ID);
    hw_clear_bits(&uart_get_hw(UART_ID)->lcr_h, UART_UARTLCR_H_EPS_BITS);
    uart_putc_raw(UART_ID, PACKET_START);
    sleep_us(PACKET_SPACING);
    
    uart_tx_wait_blocking(UART_ID);
    hw_set_bits(&uart_get_hw(UART_ID)->lcr_h, UART_UARTLCR_H_EPS_BITS);
    for (int i = 0; i < length; i++) {
        uart_putc_raw(UART_ID, msg[i]);
        sleep_us(PACKET_SPACING);
    }
    
    uart_tx_wait_blocking(UART_ID);
    uart_putc_raw(UART_ID, calculate_checksum(msg, length));
    sleep_us(PACKET_SPACING);

    hw_clear_bits(&uart_get_hw(UART_ID)->lcr_h, UART_UARTLCR_H_EPS_BITS);
    uart_putc_raw(UART_ID, PACKET_END);

It does not and can not use interrupts, neither is expected.
The receive interrupt handler needs access to the 12 bit UARTDR register to get the received parity bit:

void on_uart_rx() {
    while (uart_is_readable(UART_ID)) {
        uint8_t ch = uart_getc(UART_ID);

        // check parity
        io_rw_32 dr = uart_get_hw(UART_ID)->dr;

        // check bit 9, invert
        int parity_rx = (dr & (1 << 9)) == 0;

My objective is to migrate the working RP2040 code to Pi and Circle.

[rsta2]

I think, I understand it better now. Thanks.

One question: Which Raspberry Pi model do you want to use, and is this the only serial interface, you are using? It would be more simple to use only one UART0 at GPIO14/15 for the RS-485 multidrop network. If other UARTs should be used at the same time, which are supported on the RPi 4 or 5, it could be more complicated to synchronize the interrupt usage between the normal CSerialDevice driver and the RS-485 multidrop network driver, because some UARTs share the same IRQ.

[u77345]

I'm about to use Pi1. Given that only UART0 is PL011, and the mini UART does not support parity, I think the RS-485 device should be UART0. I do not need to use another UART, however, it would be nice to allow the mini to be reallocated as the Circle UART.

[rsta2]

Thanks for info. I will try to provide classes for the master and slave (needed for testing) for a serial block mode (how I understand it from the given info) for the RPi 1. This will take some time. I think, for a simple test configuration with one master and one slave I can connect the two UARTs directly with a crossed wire, without the need for RS-485 equipment.

A driver for the Mini-UART is a different thing, which can come in a second step.

[rsta2]

A correction: Unfortunately it's not possible to use the PL011 UART and the Mini-UART at the same time on a RPi 1, because both can only use GPIO14/15 from the GPIOs connected to the GPIO header.

[rsta2]

After diving more into this, I want to provide the attached patch (in the .zip file), which adds the following methods to the serial driver CSerialDevice:

• SetParity()
• IsTransmitting()
• RegisterCharReceivedHandler()

Please see the header file serial.h for details about these methods. I think, they should help to implement the RS-485 blocking mode, like you did for the RP2040. This patch is not tested, because I currently do not have a slave device for this purpose.

This is not, what I planned before (new class(es) for RS-485 support). I realized, that there are a number of different protocols, which are used with a RS-485 physical layer, and that a lot of them are user defined protocols (not standards). I guess, your protocol is some kind of that. Because of this it seems to be impossible to me, to provide classes for the most common protocols (and for your protocol) in an amount of time, which makes sense. Furthermore I found out, that there is RS-485 support in the Linux PL011 driver too. That's why I tried, to add the necessary function to the Circle serial driver, even knowing, that I did not find this useful before.

serial-rs485.zip

[u77345]

Thanks. Moved on to start testing the receive callback. Seems Serial does not find the InterruptSystem:

serial.cpp(740): assertion failed: m_pInterruptSystem != 0

This is how the init code looks like:

boolean CKernel::Initialize (void)
{
	boolean bOK = TRUE;

	if (bOK)
	{
		bOK = m_Screen.Initialize ();
	}

	if (bOK)
	{
		bOK = m_Serial.Initialize (156000);
		m_Serial.SetParity (CSerialDevice::ParityMark); 
	}

	if (bOK)
	{
		CDevice *pTarget = m_DeviceNameService.GetDevice (m_Options.GetLogDevice (), FALSE);
		if (pTarget == 0)
		{
			pTarget = &m_Screen;
		} else {
			pTarget = &m_Serial;
		}

		bOK = m_Logger.Initialize (pTarget);
	}

	if (bOK)
	{
		bOK = m_Interrupt.Initialize ();
	}

	if (bOK)
	{
		bOK = m_Timer.Initialize ();
	}

	if (bOK)
	{
		bOK = m_USBHCI.Initialize ();
	}

	if (bOK)
	{
		bOK = m_Net.Initialize ();
	}

	if (bOK)
	{
		m_Serial.RegisterCharReceivedHandler(CKernel::SerialRxHandler, this);
	}
	return bOK;
}

[rsta2]

You are welcome. You have to add a member initializer for m_Serial:

CKernel::CKernel (void)
:       m_Screen (m_Options.GetWidth (), m_Options.GetHeight ()),
        m_Serial (&m_Interrupt, TRUE),
...

TRUE enables the FIQ, which is recommended. Otherwise the IRQ is used.

[rsta2]

Did you made progress here? I'm asking, because I would add the patch for CSerialDevice generally to Circle, if it helps.

[u77345]

Yes, both rx and tx are working fine with the parity bit sending and receiving as expected. Have not integrated into the full application code yet. Thanks for the support!

[rsta2]

You are welcome and thanks for info! The modifications for mark/space parity, TX busy check and per character receive are on the develop branch now.