What is serial communication?

Serial port, generally refers to asynchronous serial interface (Serial port), mainly used for serial bit-by-bit data transmission. The serial port is an indispensable part for us in the embedded industry. When we first started learning microcontrollers, the first communication interface we learned was USART (Universal Synchronous/Asynchronous Receiver/Transmitter) - Universal Synchronous/Asynchronous Serial row receiver/transmitter.

In addition, serial communication is mainly divided into three communication methods: RS232, RS422, and RS485. It has been explained systematically before (Introduction to RS485/RS232/RS422 serial communication interface), and Xiaoyi will not introduce it in detail here.

   As mentioned above, the serial port plays a very important role in our daily development, and we often encounter many problems and suffer from various tortures. Next, let’s talk about the common problems and solutions in the usual serial communication.
   Usually when we encounter problems in debugging serial communication, we need to use a tool such as USB to TTL, DuPont line (wire), etc. First of all, we should ensure that our tools are normal, and we can self-test and troubleshoot serial communication problems through the following methods:

1. Short-circuit the TX and RX of the USB to TTL with a Dupont wire or a jumper cap, open the serial port debugging tools, such as XCOM, SSCOM, etc., and adjust the baud rate, stop bit, check bit and other parameters to the required The parameters of the communication module, and then send some data at will. Usually, the author prefers to use hexadecimal to send and receive, so as to ensure that there are some data in the middle or at the end of the data that cannot be visually seen using ASCII values, such as data. There are 0x00, 0x0a, etc. at the end. After making sure that there are no problems with your tools and wires, you can continue to troubleshoot communication problems

2. It is found that TX and RX have been reversely connected between the USB to TTL and the wireless module, but there is no response after sending commands to the module.

Solution: When encountering the above problems, you should first self-check the tool, and then check whether the two sides share the same ground. GND provides a reference 0 level. If there is no common ground, it is very likely that there will be problems. Next, check both sides Whether the serial port parameters are consistent, serial port communication is a communication protocol that is easy to develop and adjustable in speed, most of which we will use UART - Universal Asynchronous Transmission Receiver/Transmitter, serial port asynchronous communication can also be called start-stop asynchronous communication , is directly transmitted in units of characters, there is no fixed time requirement between characters, and each bit in each character is transmitted at a fixed time. This means that if you use a relatively high baud rate to communicate with a relatively low baud rate, it is very likely that the low baud rate device will not be able to read the communication data. Transition information of the idle signal. Here I use a more extreme example to illustrate:

Related products :

        serial-to-BLE module -- E104-BT5032A

       wireless serial port module--E280-2G4T12S

When the data bits of the parameters of both serial ports are 8bit, the stop bit is 1bit, and the parity bit is 0bit, but the baud rate of the A device is 9600, and the B device is 921600, the following situation will occur:

When B-device sends a byte of data to A-device, the time required for B-device from sending to the end is 1/921600*(8+1+1)=10.8us, and the same A-device sends/receives a The time of a byte is (8+1+1)/9600=1.04ms. Let me ask, if the time difference is several times like this, when a high baud rate is sent to a low baud rate device, it is very likely that the low baud rate The device will never think that the data stream sent is a string of data, because it cannot be parsed at all.

Therefore, the serial port communication must ensure that the baud rate, stop bit and other parameters of both parties are consistent. Conversely, sending data at a low baud rate to a high baud rate will be considered wrong data, which is the so-called garbled code.

3. It is found that the two parties have used the same parameters for communication, but there are still communication problems, such as receiving garbled characters.

Solution: First of all, you should lower the baud first to ensure that there is no problem with the module and the USB to TLL, and also make sure that the module is not in special cases such as transparent transmission. You can also use logic analyzers and other tools to check. Many logic analyzers are now With its own data analysis, it can be used to ensure that the module is normal. In fact, most of the time when you encounter this kind of problem, it is more recommended to first check whether the USB to TLL supports the current working mode.