When I using uart port to send data, how can I know that the data is really send finished ？？
may I know which pin you’re used for testing, you should also check TX2 J21 Header Pinout for correct connections.
you could enable loopback test to verify the communication, please note that default baudrate settings is 115200/8n1.
What is being sent to? Can you program the end to echo back what you send?
Hello，thanks for your reply。
Let me describe it in detail，We convert uart232 on the board to RS485
to communication，We need a GPIO pin to control the direction of RS485, so we need to know exactly time when the date was send finished。In this way, we can accurately switch the direction of RS485。
I do not work with RS-485, but if I were using RS-232, then I’d use CTS/RTS hardware flow control. It sort of sounds like you want to use GPIO for something similar. My answer on this is probably very naive, but I’d think you need to detect a “space” (versus “mark”) which exists for some predetermined time, where the predetermined time differs on each node, and then use this to trigger GPIO.
Hello，Thanks you for your reply。
232 driver, where can we know that the data is actually sent from the buffer to the other hardware。Does 232 driver have registers or functions to know？
I have not looked at the 232 driver itself, but if you check the hardware flow control code (CTS/RTS wire handling), then this is exactly what it does. This does not mean the data was sent without error, but what it does is guarantee one end thinks the send is over and the other end acknowledges. Asserting CTS implies one side can send, asserting RTS implies that end is ready to receive. This is tied in to a small buffer, but you’d need to check the TRM for those details since it is possible for the UART to emulate several modes, including older 16450, or a newer 16550A. The same section of the TRM would in fact talk about registers, but you would have to consider that in combination with the driver in the kernel.
If you go here, log in, and then go to the link a second time (redirect does not work), then you can find the Technical Reference Manual (TRM):
To save you some confusion, in the device tree each UART has an entry called “
compatible”. That entry states which drivers the UART is compatible with, and usually (due to the adaptability of the hardware) more than one driver is possible. If you talk to a driver using the syntax “
/dev/ttyS<number>”, then you are using the regular driver (e.g., 16550A); if you are talking to the “
/dev/ttyTHS<number>” device, then it is the same hardware, but it is using the “Tegra High Speed” driver (which can use DMA). Both device special files will exist for most of the UARTs, but you’ll want to use only one device naming convention without switching back and forth.
The serial console uses “
/dev/ttyS0” instead of the THS version because the bootloader and early boot stages only have driver code for the 16550A version…switching to a THS driver during kernel load would possibly cause some serial console log lines to fail during the mode switch. The THS driver tends to be used when you don’t need the code in earlier boot stages. If you need one of the drivers to go away and consistently force just one mode, then you would do this with the “
compatible” parameter in the device tree.
How much this applies in RS-485 I do not know, but the driver code should still point out registers used for the UART hardware, and in combination with the TRM, it will help figure it out.