PIO Serial.flush - seems to take too much time

[zmechu]

Hello!

Using ArduinoIDE for RP2040 programming. Use serial transmission (PIOSerial, 115k) for sending data, with code:

(...)
int SerialBufferSize=512;
SerialPIO PIOSerial3 (10, 11, SerialBufferSize);
(...)
HardwareSerial* port=nullptr;
port = &PIOSerial3; 
(...)

gpio_put(DIR_PIN, true); //start sending

port->write(txFrameBuffer, totalLen); //sending

gpio_put(DIR_PIN, false); //sending end

Of course it fails, because “sending end” information raise to early - DIR_PIN going low during transmission (upper: data frame, lower DIR_PIN state):

So, lets use Serial.flush() which check when output buffer will be empty (all data sent):

gpio_put(DIR_PIN, true);

port->write(txFrameBuffer, totalLen);

port->flush();  

gpio_put(DIR_PIN, false);

Much better, but.. why Serial.flush() tooks so much time longer? All Serial goes out, but DIR_PIN is HIGH for over 170us after real transmission ends?

Lets do other test - change serial speed to 9600:

The same situation, too long “tail” but seems almost fine

So, speed up to 961k:

Seems Serial.flush() takes about 10x more time than real transmission time! As I see, Serial.flush() executes not less than ~1ms (?)

My questions are:

• Does Serial.flush() should works like that?
• How proper check when serial transmission ends?

Best regards!

[zmechu]

Full testing code:

int SerialBufferSize = 11;
SerialPIO PIOSerial3(10, 11, SerialBufferSize);
byte DIR_PIN = 18;

static uint8_t txFrameBuffer[10];

void setup() {
  PIOSerial3.begin(921600);
  pinMode(DIR_PIN, OUTPUT);
  //lets fill frame with some data..
  for (int x = 0; x < sizeof(txFrameBuffer); x++) txFrameBuffer[x] = random(50, 250);
}

void loop() {
  gpio_put(DIR_PIN, true);
  PIOSerial3.write(txFrameBuffer, sizeof(txFrameBuffer));
  PIOSerial3.flush();
  gpio_put(DIR_PIN, false);

  delay(100);
}

Data frame zoom:

Full transmission width:

[maxgerhardt]

The .flush() method is mostly based on waiting for the TX FIFO to be empty and then waiting for a potential "currently sending byte" to be transmitted fully:

arduino-pico/cores/rp2040/SerialPIO.cpp

Lines 352 to 362 in db59e47

	void SerialPIO::flush() {
	CoreMutex m(&_mutex);
	if (!_running || !m || (_tx == NOPIN)) {
	return;
	}
	while (!pio_sm_is_tx_fifo_empty(_txPIO, _txSM)) {
	delay(1); // Wait for all FIFO to be read
	}
	// Could have 1 byte being transmitted, so wait for bit times
	delay((1000 * (_txBits + 1)) / _baud);
	}

So I would expect that it delays a bit unneccesarily (even if the TX FIFO is empty and no transmission is ongoing). The question is whether the PIO program can sensibly signal its state better (as in TXDONE and TX FIFO EMPTY) to enable a tighter wait loop, without sacrificing transmission speed or waits between transmissions.

Have you checked that using the hardware serial (Serial1, Serial2 with configurable Tx and Rx pins) behaves better?

[zmechu]

Well, it looks kind-of PIO problems:

Code:

int SerialBufferSize = 11;
SerialPIO PIOSerial3(10, 11, SerialBufferSize);
byte DIR_PIN = 18;
byte DIR2_PIN = 19;

static uint8_t txFrameBuffer[10];

void setup() {
  PIOSerial3.begin(921600);
  Serial1.begin(921600);
  pinMode(DIR_PIN, OUTPUT);
  pinMode(DIR2_PIN, OUTPUT);
  //lets fill frame with some data..
  for (int x = 0; x < sizeof(txFrameBuffer); x++) txFrameBuffer[x] = random(50, 250);
}

void loop() {

  txFrameBuffer[0]=0xBB; //hardware START
  gpio_put(DIR2_PIN, true);
  Serial1.write(txFrameBuffer, sizeof(txFrameBuffer));
  Serial1.flush();
  gpio_put(DIR2_PIN, false);

  txFrameBuffer[0]=0xAA;  //PIO start
  gpio_put(DIR_PIN, true);
  PIOSerial3.write(txFrameBuffer, sizeof(txFrameBuffer));
  PIOSerial3.flush();
  gpio_put(DIR_PIN, false);

  delay(100);
}

[maxgerhardt]

Great, as I would expect, the hardware UART peripheral can be flushed way better because it provides a way to check the "transmit done" more efficiently without second-guessing.

arduino-pico/cores/rp2040/SerialUART.cpp

Lines 431 to 440 in db59e47

	void SerialUART::flush() {
	CoreMutex m(&_mutex);
	if (!_running || !m) {
	return;
	}
	if (_polling) {
	_handleIRQ(false);
	}
	uart_tx_wait_blocking(_uart);
	}

https://github.com/raspberrypi/pico-sdk/blob/a1438dff1d38bd9c65dbd693f0e5db4b9ae91779/src/rp2_common/hardware_uart/include/hardware/uart.h#L431-L433

If you don't yet use Serial1 or Serial2 I'd definitely recommend you use those -- until someone finds a way to improve the SerialPIO program to include better feedback for flushing.

arduino-pico/cores/rp2040/pio_uart.pio.h

Lines 19 to 28 in db59e47

	static const uint16_t pio_tx_program_instructions[] = {
	// .wrap_target
	0xe029, // 0: set x, 9
	0x98a0, // 1: pull block side 1
	0x6001, // 2: out pins, 1
	0xa046, // 3: mov y, isr
	0x0084, // 4: jmp y--, 4
	0x0042, // 5: jmp x--, 2
	// .wrap
	};

[zmechu]

Aghhh, mine Serial1 and Serial2 are occupied, used PIO as way to increase number of Serials :-)

[maxgerhardt]

In your current usage for Serial1 and Serial2, do you need the flush? I would just shuffle the used hardware UARTs and PIO serial around so that the hardware one is the one that .flush(); is being used on, and the PIO serial for the one without that requirement.

[zmechu]

yep, will try to exchange hardware ports. But will be nice to use PIO ports the same way as hardware serials :-)

[earlephilhower]

@zmechu I wrote the SerialPIO for correctness, not for performance in this particular case. @maxgerhardt is correct, the only way we can safely know the bits are out of the chip is to check the FIFO is empty and then blindly wait for 1 byte-time.

There were some assumptions I had in the beginning, that the baud would be something low (GPS receivers @ 9600bls was a common request). So assumptions about times at 9.6K are not really valid at 100x that speed.

That said, I think it's a trivial change to increase the resolution. I'll throw a PR up for you to try w/o changing any pinouts.

[maxgerhardt]

Not tested yet, but some tighter wait loops instead of millisecond-delays might already reduce the problem -- we should have at maximum the transmission time of one byte as overhead.

void SerialPIO::flush() {
    CoreMutex m(&_mutex);
    if (!_running || !m || (_tx == NOPIN)) {
        return;
    }

    // Wait until TX FIFO drains completely
    while (!pio_sm_is_tx_fifo_empty(_txPIO, _txSM)) {
        tight_loop_contents();
    }

    // Now we still have *one byte* potentially in shift register.
    // Compute time for that last byte to go out, plus tiny bit of overhead.
    uint32_t bit_time_us = (1000000UL) / _baud;
    uint32_t total_wait_us = bit_time_us * (_txBits + 1) + 10;

    // Busy wait for that duration
    absolute_time_t until = make_timeout_time_us(total_wait_us);
    while (!time_reached(until)) {
        tight_loop_contents();
    }
}

[zmechu]

Thank you! Seems to be fine, at 921600 baud:

and 115200:

and 9600:

Tomorrow will check RP2350.

[earlephilhower]

Thanks for the update! There's nothing in the change which should differ noticeably on the RP2350.

(After thinking about it a bit, it should be possible to know exactly when the last bit has gone out by peeking at the SMx_ADDR and seeing if it's at the PIO pull instruction address. That would be even better than the HW UART which implements the same kind of blind timeout we do here, but is left as an exercise for the reader...)