foreword

Android is not just a mobile phone operating system, it can be seen in many fields.

Whether it is a vehicle system, an industrial control system, a screen control system or an Internet of Things device, there is basically a place for Android.

Under the so-called cold winter, pure Android development seems to be no longer popular, so more and more Android developers have turned to the fields of automotive and industrial control.

In these fields, the knowledge related to serial port communication cannot be bypassed. Whether it is the communication between the vehicle system and various sensors of the vehicle body or ECU or the interaction between the industrial control system and the PLC, the serial port is inseparable.

I am ashamed to say that although I can barely be regarded as an Android industrial controller, the actual job I do is to adjust the wheels and parameters, and I have always had a half-knowledge of the basic principles.

It just so happened that I was free recently, so I decided to learn from serial communication first, and slowly consolidate my basic knowledge.

During the learning process, I will also share what I have learned with the few experiences I have accumulated in my work.

Because I don't know much about this aspect, so it is inevitable that there will be mistakes. If there are mistakes, I hope you can correct me.

Some of the charts in this article come from the references marked at the end of the article

Serial Port Basics

serial vs. parallel

If we want two devices (single chip microcomputer, computer, etc.) to communicate with each other, there are generally two ways: serial and parallel.

For example, we want to send an 8-bit data from device A to device B.

If it is a serial method, it will line up from the first bit to the eighth bit and send it from a line (note that a line here is not a line in the physical sense, it can be understood as a complete data line) past.

If the parallel method is used, there may be 8 lines connected between device A and device B, and the 8 bit data will be sent to device B from 8 lines at the same time when sending.

It may not be easy to understand directly, but you can understand it in seconds by looking at this picture:

serial_parallel

It is not difficult to see from the above figure that parallel transmission is faster than serial transmission, but the corresponding line cost is also higher, and the anti-interference ability is not as strong as serial, so parallel communication distance is not as good as serial Long distance.

At the same time, because the peripherals of the serial protocol are simple, the cost is low and the communication distance is long, so we usually use serial transmission between single-chip microcomputers or industrial control devices.

The serial transmission can be divided into synchronous serial and asynchronous serial.

Synchronous Serial vs. Asynchronous Serial

Synchronous serial means that the clock frequency of the two parties in the communication is consistent, the receiver is always ready to receive data, and only needs to receive the signal to start transmission to continuously transmit data, there is no gap between data, no start bit and End bit, high transmission efficiency, can carry out one-to-many communication. Commonly used synchronous serials are I2C and SPI.

Asynchronous serial means that the clock frequency of the two parties is inconsistent. When transmitting data, the frame format is used for transmission. When the sender sends each frame of data, it needs to add a start bit and an end bit. The receiver realizes it by reading the start bit and end bit. Synchronized with the sender's information, the transmission efficiency is low, and only 1-to-1 communication is possible. Usually a frame of data consists of start bit, data bit, parity bit, and stop bit. The commonly used asynchronous serial has UART, which is what we commonly call serial communication.

Serial communication (UART)

In order to achieve serial communication, we need to connect three wires between the devices: TX (send), RX (receive), GND (ground).

Connect the TX of device A to the RX of device B; connect the RX of device A to the TX of device B; connect the GND of devices A and B.

Since there are both sending and receiving ends between each device, the serial port communication is full-duplex communication, that is, it supports sending and receiving data at the same time.

If we want to send a character "E" from device A to device B, the sending effect is as follows:

That is, a piece of data is sent from the transmitting end (TX) of device A to the receiving end (RX) of device B.

At this time, if you measure the level on this line when sending data, you will get such a waveform diagram:

That is, the binary "01000101" is converted to 69 in decimal, which represents the letter "E" in ASCII:

And how are the 0 and 1 read in the level here defined? Generally speaking, we will define the high level as 1, and the low level as 0. How to define it will be discussed below, but press it for now.

In fact, the waveform diagram here is not complete, remember what we said above when we introduced asynchronous serial? It uses frame transmission to transmit data. That is to say, a complete data frame should at least contain the previous start bit (1 low level) and the last end bit (1-2 high level):

In addition, the data bits in a frame of data can be 5-8 bits, generally speaking, 8 bits are used; there can also be a check bit after the data bit and before the end bit to check whether the data transmission is correct (parity check , CRC check, etc.), when idle, the data line outputs a high level, which is called an idle bit:

So the question is, how does the receiving end know how many data bits are used, whether to use checksums, and how many end bits are there?

The answer is that I don't know, and I can't know.

Therefore, usually before the serial communication starts, both parties need to agree on the data bits, parity bits, and stop bits to be used.

In general use, there are 8 data bits, no parity, and 1 stop bit, which is commonly known as "8N1".

In addition to the three parameters mentioned above, there is also a parameter that needs to be agreed before starting the communication, that is "baud rate".

The baud rate is how many bits of data are transmitted per second, and the unit is bps (bits per second).

Going back to the diagram of transmitting the letter "E" we mentioned above, although the level change can be seen intuitively from the diagram, how should the receiver know that "how long" is a bit? This requires our baud rate.

For example, if the baud rate we set above is 9600 bps, it means that 9600 bits are sent per second, that is, the width of one bit is 104 microseconds.

At this time, after the receiver reads the start bit, it will start to read data every 104 microseconds until the end bit is read.

(In fact, there is usually a delay of 52 microseconds before reading starts after the start bit is read, and then every 104 microseconds to avoid data instability at the beginning of reading)

Since then, the basic principles of serial communication have all been explained.

Do you feel something is missing?

Yes, there is still a question left above, that is, how do we define high level and low level?

This leads to our next protagonist, RS232.

RS232

Generally speaking, serial port communication uses TTL level.

TTL is Transistor-transistor logic, transistor logic, its circuit is composed of bipolar transistors, and the working voltage is 5V. So we generally regard +5V voltage as high level (1), and 0V as low level (0). However, the minimum high level output by the TTL circuit is 2.4V, and the maximum low level is 0.4V, which leads to a minimum difference between the high and low levels of only 2V, so it is extremely susceptible to interference when transmitting data, such as this When it is disturbed by static electricity, it may change the low level to high level. Therefore, the distance of this transmission method is very short, generally within 1 meter, and it is only suitable for data transmission between chips or between devices and computers.

In order to improve these shortcomings, the American Electronics Industry Alliance has developed a standard: RS232.

The way to improve RS232 is very simple, that is to increase the level.

In order to improve the transmission level, we only need to add a level conversion chip between the original serial port transmission devices.

At this time, if the sending device sends a high level of 5V to the conversion chip, it will be raised to -15V and sent to the receiving device; otherwise, if the chip receives a high level of -15V, it will be converted to 5V sent to the device.

This completes the operation of converting TTL level to RS232 level.

In RS232, the high level (1) is -3V to -15V; the low level (0) is +3V to +15V.

RS232 only changes the level, so that the difference between the high and low levels is nearly 20V, so that the anti-interference ability of RS232 is greatly enhanced, and the transmission distance has reached a theoretical 15 meters, while the transmission data format has not changed. But this also leads to the maximum baud rate of RS232 can only use 19200 bps, which makes the transmission rate limited, and the ability to resist common mode interference is still not improved.

Therefore, the RS485 standard was born.

RS485

The same as RS232, RS485 is also realized by adding a level conversion chip on the basis of the original serial communication.

The difference is that RS485 no longer uses a fixed level judgment method, but uses differential signals to represent data.

RS485 wiring only needs two wires A and B. A logic 1 is represented when the voltage difference between A and B is between 2V and 6V; a logic 0 is represented when the difference is between -6V and -2V.

At the same time, RS485 is usually wired in the form of a twisted pair, which greatly enhances its ability to resist common mode interference, because the voltages of A and B will change when they are disturbed, and their voltage difference will basically not be affected. .

Due to the characteristics of RS485 using differential signals, the minimum transmittable signal can reach 200mV, the maximum data transmission rate can reach 10Mbps, and the transmission distance can reach 1200 meters.

However, because RS485 only uses two wires, and both wires are used to transmit the same data, it only supports half-duplex communication, that is, it can only send or receive data at the same time, and cannot send and receive data at the same time; But also because of this feature, RS485 is different from RS232, which can only communicate with two devices point-to-point, but can communicate one-to-many, that is, one master can communicate with multiple slaves at the same time.

Summarize

Since then we have had a basic understanding of serial communication.

From the above, we can find that UART defines the data transmission format standard, and RS232 and RS485 define the data transmission method and wiring method at the physical level:

In other words, whether it is serial communication, RS232 or RS485, their data format and content are actually the same.

For us Android developers, no matter what standard we use, it has almost no effect on us. All we need to do is parse the data transmitted through the serial port.

how to test

After explaining the above serial communication principle, how should we test it?

The best way is of course to have a real machine for testing, but sometimes we don’t have equipment at hand or it’s inconvenient to use real equipment for testing, then we can use virtual serial ports for simulation testing.

overview

The simulation test on Windows is much simpler than that on MAC.

The general process is: use the software to create a virtual serial port - start the Android emulator and connect to the created virtual serial port - complete the communication between Android and the virtual serial port.

Since I am currently using a MAC as my main machine, I try to perform a simulation test on the MAC according to the above steps.

But it is stuck at the first step, which is to create a virtual serial port.

I tried to search and found that there is no virtual serial port software available on MAC. I finally found one, but the maintenance has been stopped, because the new version of MAC has tightened permissions and can no longer create virtual serial ports.

Fortunately, I still have two ESP32 development boards at hand, so I don't need to use the virtual serial port simulation. I can directly use the ESP32 development board for testing.

Well, now the problem comes to the second step.

But after my attempts, MAC still can't start the Android emulator to connect with the serial device.

However, although it cannot be used, some pitfalls were stepped on in the process, and a solution was found, so here is a general introduction.

MAC starts the emulator and connects to the serial port

First of all, we need to create an Android emulator. This step can be created directly in Android Studio in the usual way.

After creating the emulator, we cannot start it directly in Android Studio, but must start it in the terminal, because we need to specify the startup parameters.

The command needs to be executed to start emulator. The executable file of this command is in AndroidSdk/tools, for example, my path is /Users/equationl/Library/Android/sdk/tools. If you don't know where your AndroidSdk directory is, you can directly search for "sdk" in the settings of Android Studio, and see this path in the "Android SDK Location" option:

sdk_location

After finding your path, execute the following command to start the emulator:

cd /Users/equationl/Library/Android/sdk/tools

./emulator -avd Pixel_6_Pro_API_31

"Pixel_6_Pro_API_31" is the name of the emulator you created earlier.

Of course, the emulator is simply started here, and it is not connected to the serial port, so the emulator you start at this time cannot find the serial port you inserted into the device.

If we need to connect to the serial port, we need to execute:

./emulator -avd Pixel_6_Pro_API_31 -qemu -serial /dev/tty.wchusbserial544C0047221

Among them /dev/tty.wchusbserial544C0047221is your serial port path.

The command to view available serial ports on MAC is:

ls /dev/tty.*

However, if your MAC is an ARM CPU, there is a high probability that an error will be reported when starting the emulator:

launcher_emulator_fail

This should be a small BUG of Google. It can also be seen from the error message that the cause of the error is that darwin-x86_64/qemu-system-aarch64this file does not exist.

When we come to the path where the error is reported, we can see that there is no darwin-x86_64folder called at all, but there is a darwin-aarch64folder called , and there is qemu-system-aarch64a file in it.

Hahaha, in fact, it is estimated that some people have already reacted here. We are obviously ARM processors, so how come there is an x86 folder.

So we just darwin-aarch64connect softly to darwin-x86_64.

Excuting an order:

cd /Users/equationl/Library/Android/sdk/emulator/qemu

ln -s darwin-aarch64 darwin-x86_64

Then return to the tools directory and execute the command to start the emulator. You can see that the startup is successful.

However, the connection to the serial port fails and an error is reported:

serial_error

It can be seen that there are two errors, one is that the command cannot be recognized serial; the other is that it cannot connect to the serial port we specified.

Regarding this error, I have also searched for a long time and tried various methods, but none of them can be solved.

However, I found another implementation method, which is to use a separate virtual machine to start an Android emulator, and then create a virtual serial port for the Android emulator by this virtual machine, and connect this virtual serial port to the physical device.

Ah this? What about this doll? Too much trouble! Give up decisively!

If you are interested, you can try it. The tutorial address: [Android] Android serial port and NDK debugging exploration under mac

Summarize

Because of the above reasons, the final test plan I chose is to use the Android real machine + ESP32 development version for testing.

For users who also use MAC, my suggestion is to directly use the real machine + ESP32 development version, or other cheaper development versions for testing and learning. A few dollars and go to toss this bottomless pit of the god pit.

It is much more convenient for Windows users, not only can use the same real machine test scheme as MAC, but also can easily use virtual serial port and Android emulator for testing.

Summarize

Today we mainly explained some basic knowledge of the serial port, and roughly introduced how to test the serial port communication.

All knowledge points are step-by-step. The communication between devices includes serial communication and parallel communication. Generally, we use serial communication more in practice, and serial is divided into synchronous serial and asynchronous serial. The commonly used one is asynchronous Serial and asynchronous serial commonly used protocols are UART, which is often referred to as serial port. In order to solve the problem of serial port communication, protocols such as RS232 and RS485 have been derived.

Android and Serial Port Communication - Basics

foreword

Serial Port Basics

serial vs. parallel

Synchronous Serial vs. Asynchronous Serial

Serial communication (UART)

RS232

RS485

Summarize

how to test

overview

MAC starts the emulator and connects to the serial port

Summarize

Summarize

References

Guess you like