Thoughts on Serial Communication Design with 51 Microcontroller

Recently, I needed to use the 51 microcontroller for some control tasks in a project. The main function is to receive commands from the host computer through the serial port, analyze and decode them, and wait for an external trigger signal to execute the previously received command actions.

Fortunately, I had an STC89C52 on hand, so I quickly set up a minimal system. The STC89C52 microcontroller can download programs via the serial port, but after several attempts, I was unable to download successfully. Upon careful inspection, I found that I had forgotten to connect the GND (ground wire) of the 9-pin serial cable. Here’s a summary of the main reasons for unsuccessful downloads on the STC microcontroller:

1. Issues with the minimal system (correct crystal oscillator, reset circuit, and pin connections);

2. Level matching issues (generally requires adding a MAX232 level conversion chip);

3. Serial cable (the quality of the serial cable is also very important) connections (at least connect 3 wires: TXD, RXD, GND), including the correct direction for sending and receiving;

4. Correct download operation steps (power off the microcontroller —> click download —> power on the microcontroller).

Thoughts on Serial Communication Design with 51 Microcontroller

Thoughts on Serial Communication Design with 51 Microcontroller

After ruling out the failures of the download, I could write the code and download the program. First, I wrote code for serial debugging, using the serial receive interrupt method, to echo the received bytes back to the host computer in the main program.

Serial Communication Design (Blocking Design)

Code can be found in the original text.

Testing the above code revealed:

1. The host computer sends 1 byte every 0.5 seconds, and the code works well without data loss;

2. The host computer sends a file of 987 bytes, receiving 986 bytes back from the microcontroller, losing 1 byte;

3. The host computer sends a file of 12307 bytes, receiving 12286 bytes back from the microcontroller, losing 21 bytes;

4. The host computer sends a file of 61541 bytes, receiving 61453 bytes back from the microcontroller, losing 88 bytes.

In general, to make serial communication more robust, a buffering mechanism is employed, which means designing a receive FIFO to temporarily store the received data. This prevents overwriting issues during large data transfers. The FIFO is generally designed as circular, with a read pointer and a write pointer. When operating on the FIFO, these two pointers are checked to determine the FIFO’s status. To distinguish between the full and empty states of the FIFO, one storage unit is often sacrificed, creating the following conditions:

1. Before writing, if wr_ptr + 1 = rd_ptr, it indicates that the FIFO is full (there’s actually 1 empty spot left, but we sacrificed it);

2. Before reading, if rd_ptr = wr_ptr, it indicates that the FIFO is empty (at this point, the FIFO is truly empty).

Serial Communication Design (Non-blocking Design)

Code can be found in the original text.

Testing the code in the same way:

1. The host computer sends 1 byte every 0.5 seconds, and the code works well without data loss;

2. The host computer sends a file of 987 bytes, receiving 986 bytes back from the microcontroller, losing 1 byte;

3. The host computer sends a file of 12307 bytes, receiving 12286 bytes back from the microcontroller, losing 21 bytes;

4. The host computer sends a file of 61541 bytes, receiving 61429 bytes back from the microcontroller, losing 112 bytes.

From the above test data, it appears that the blocking serial communication is slightly better than the non-blocking one. However, according to many books and theoretical deductions, the non-blocking design should be far superior to the blocking one. Today’s test results have left me somewhat incredulous. Taking a moment to reflect, I seem to have reached some conclusions:

1. In this test, the microcontroller is only performing 2 tasks: receiving and sending. The tasks are too simple, and the blocking method can work well, while the non-blocking method does not demonstrate its advantages;

2. In this single task, the non-blocking method has to read and write to the FIFO, which consumes time, leading to the above test data favoring the blocking method;

3. If additional tasks are introduced, the non-blocking method should theoretically perform better than the blocking method, though this remains to be verified;

4. It is indeed important to conduct more experiments; one cannot rely solely on what is written in books but must test in practice to see which methods are applicable under what circumstances.

Thoughts on Serial Communication Design with 51 Microcontroller

Leave a Comment