Hello, I have a problem with UART reaction time under Linux.
I need to detect frame break/error situation and send a byte as reaction.
I use following configuration of serial port for Linux:
tty.c_cflag &= ~PARENB;
tty.c_cflag &= ~CSTOPB;
tty.c_cflag &= ~CSIZE;
tty.c_cflag |= CS8;
tty.c_cflag &= ~CRTSCTS;
tty.c_cflag |= CREAD | CLOCAL;
tty.c_lflag &= ~ICANON;
tty.c_lflag &= ~ECHO;
tty.c_lflag &= ~ECHOE;
tty.c_lflag &= ~ECHONL;
tty.c_lflag &= ~ISIG;
tty.c_iflag &= ~(IXON | IXOFF | IXANY);
tty.c_iflag &= ~(IGNBRK|BRKINT|INLCR|IGNCR|ICRNL|IGNPAR|ISTRIP);
tty.c_iflag |= INPCK|PARMRK;
tty.c_oflag &= ~OPOST;
tty.c_oflag &= ~ONLCR;
tty.c_cc[VTIME] = 0;
tty.c_cc[VMIN] = 0;
If I set sender speed to 115200 and send one zero byte, on the receiver side (configured to speed 230400) I get frame error byte sequence(3 bytes): 0xFF, 0, 0.
It is what I need.
The problem is time point of error detection. I toggle in the serial driver GPIO pin over uart_handle_break(stm32_usart_receive_chars_pio()) to see the time point of break detection.
In this function on the Linux driver this situation is handled as "break detection" and not as "frame"-error because of NULL-char as result from stm32_usart_get_char_pio() function - just for Clarity.
For me it is just a situation of error detection and it must happen most early - in this case if stop-bit is not detected on right place, I expect it in the second half part of the gap (resulting from sending zero byte on 115200 instead of 230400).
On the osci-screenshot there are 3 signals:
1(orange) - RX-Line, from here comes broken frame
2(magenta) - GPIO pin over uart_handle_break function, this is the most early place of frame break detection
3(cyan) - TX-Line, on which I try to send some byte on very first place in my application (not in the driver) as reaction.
First of all the break detection signal comes too late - after the gap. I have tried also to set sender speed very very slow - 2400, and the signal is always after the gap.
This means detections happens first if the RX-line signal backs to high level.
The second problem is reaction time for the response - ~620 micro seconds is very very long.
I made the same test but from Linux-PC with FTDI adapter, the application and UART configuration was the same except one important thing - set of ASYNC_LOW_LATENCY over ioctl() (on STM a can not do this - get error on set).
This combination Linux-PC with FTDI works fine, first of all, I break detection comes not after the gap, but already if the time for byte-length (230400) is broken, and second I can send response byte much more earlier then on STM.
The question is: can I some hove speed-up the STM-UART with some register configuration?
It can be, that I just miss some magic bit for that.
