0

I am coding a uart application in Linux written in C, in my case, Linux need to send bytes stream to device which is connnected with UART (UART is in hardware flow control with DTSCTS, baudrate is 115200, no parity, no odd/even bits).

The question is, part of data lost in device side while the bytes stream contain some bytes. Those bytes that may be lost include but not limited to 0x00, 0x02, 0x18 (those are tested with byte stream).

Is there any mechanism in which special bytes will be filtered or dropped? I'm not sure if this is related to the UART driver or hardware stability (if so, it should not loss 0x18 all the time).

0andriy
  • 4,183
  • 1
  • 24
  • 37
Rui
  • 97
  • 1
  • 8
  • 1
    No, there is no such mechanism. – Codo May 12 '23 at 09:48
  • How did you determine how many bytes were lost and their value? Did you completely and correctly handle the results returned from system calls such as send(), recv(), read(), write()? Are you correctly using library calls that take NUL-terminated char arrays as arguments? – Martin James May 12 '23 at 12:53
  • 1
    The most common reason for this is poor clock accuracy. For example using a microcontroller where the available UART baudrate divisors didn't give a good enough accuracy out of the picked system clock. Another common reason is that PC are very often too darn slow to keep up with microcontrollers, particularly if the microcontroller spits out new data at 100% bus load. Yet another common reason is missing signal ground. – Lundin May 12 '23 at 13:28
  • @MartinJames, I use write() to send data to device, and byte value to device is unsigned char. when I debug this issue, device side enable ECHO function, so that PC can receive byte stream just sent to device. I doubt if data size is two large, then, I decrease the byte length of data to be sent, from 128 to 1 byte per time and try, the result is same when issue happens. however, in PC side, I get correct length(return value) every time. and now I even doubt if uart is blocked rather than lossing data. – Rui May 17 '23 at 03:58
  • I can disagree with @Codo. The Linux part (at least) may filter and/or modify a lot of things, because UART is a part of TTY subsystem which includes that kind of magic. The Linux application shall switch UART into `raw` mode, that prevents kernel from modifying the byte stream. – 0andriy May 21 '23 at 14:46

1 Answers1

0

root cause is found!!

Device side enter into a wrong state, in which some pre-defined bytes will be filtered and dropped, during uart communication procedure. Now i will check why device fall into that state. uart seems ok.

Rui
  • 97
  • 1
  • 8