(software break) Why does changing uart baudrate take so long (250-300ms)?

[zpg6]

I am working with a use case that requires changing the baud rate, sending an 0x00, and changing the baud rate back, in effect creating a software break for LIN Bus.

// initially set to 9600 in uart::Config

lin_uart.write_byte(0).unwrap();
lin_uart_config.baudrate(19200);
lin_uart.apply_config(&lin_uart_config).unwrap();
lin_uart.write_bytes(&[0x55,0x01,0x02,0x03]).unwrap();

But on the oscilloscope there is a 250-300ms gap between the 0x00 and the 0x55.

I even went into esp-hal/src/uart.rs and commented the other operations to exclude them as taking up the time:

fn apply_config(&self, config: &Config) -> Result<(), ConfigError> {
    //self.set_rx_fifo_full_threshold(config.rx_fifo_full_threshold)?;
    //self.set_rx_timeout(config.rx_timeout, config.symbol_length())?;
    self.change_baud(config.baudrate, config.clock_source);
    //self.change_data_bits(config.data_bits);
    //self.change_parity(config.parity);
    //self.change_stop_bits(config.stop_bits);

    // Reset Tx/Rx FIFOs
    //self.rxfifo_reset();
    //self.txfifo_reset();

    Ok(())
}

Any ideas what takes so long? Or a better way to generate software break for LIN

[MabezDev]

A bit more info like which chip, esp-hal version, compiler version etc would be helpful. Are you running in release mode also btw?

[zpg6]

A bit more info like which chip, esp-hal version, compiler version etc would be helpful. Are you running in release mode also btw?

esp-hal = { version = "0.22.0", features = ["esp32"] }

rustc 1.82.0-nightly

---

Run once when I first open the terminal:

. $HOME/export-esp.sh

Then as run command:

cargo +esp run --release

[bjoernQ]

I see some other / general problems with rapidly changing the baud rate (see #2743)

[zpg6]

Testing ongoing, it seems the default value for UART_TX_IDLE_NUM being 0x100 may be the culprit.

I expected the TX FIFO to bounce the bytes right out. I can achieve that now by setting UART_TX_IDLE_NUM to 0 with the PAC at setup.

[zpg6]

Why does LpUart automatically set this to 0 in new() and offer a function to change it change_tx_idle, but Uart does not? This should be supported - its not super obvious/expected behavior for bytes not to bounce right out on the TX line.

LpUart sets it to 0 not once, but twice...

[zpg6]

I created PR #2859 to add tx_idle_num to the uart::Config struct. I left the default as 256 as in the data sheet, but a recommendation to set to 0 if you are expecting bytes to be immediately written to the TX line when written to the FIFO.

[zpg6]

Regarding software break - inverting the level of the TX line does a nice job. Accomplished this by using the PAC to set UART_TXD_INV to 1 for the break duration, then UART_TXD_INV back to 0.