{"id":6338,"date":"2021-06-07T08:44:03","date_gmt":"2021-06-07T08:44:03","guid":{"rendered":"http:\/\/fastbitlab.com\/?p=6338"},"modified":"2023-09-04T11:19:06","modified_gmt":"2023-09-04T05:49:06","slug":"exercise-testing-our-hello-world-application-over-uart","status":"publish","type":"post","link":"https:\/\/fastbitlab.com\/blog\/exercise-testing-our-hello-world-application-over-uart\/","title":{"rendered":"FreeRTOS Lecture 39 – Exercise: Testing our hello world application over UART"},"content":{"rendered":"
\n
\n
\n
\n

 <\/p>\n<\/div>\n

\n

Exercise: Testing our hello world application over UART<\/span><\/h1>\n
\n
\n
\n

 <\/p>\n

<\/div>\n

 <\/p>\n<\/div>\n<\/div>\n<\/div>\n

Now let\u2019s call the printmsg function from the task handlers, as shown in Figure 1 and Figure 2.<\/span><\/p>\n

printmsg(\"Hello-world: From Task-1\\n\");<\/pre>\n
\"Figure
Figure 1. Call for printmsg function from task handler 1.<\/span><\/figcaption><\/figure>\n
 <\/p>\n
printmsg(\"Hello-world: From Task-2\\n\");<\/pre>\n
\"Figure
Figure 2. Call for printmsg function from task handler 2.<\/span><\/figcaption><\/figure>\n
 <\/p>\n
Now let\u2019s see how these prints are going to display. For that, first, compile the project (Figure 3). It builds successfully without any errors. <\/span><\/p>\n
Remember that now we are printing via UART. Download the code into the board (Figure 4). Tick the reset after the program (Figure 5) and click ok.<\/span><\/p>\n
\"Testing
Figure 3. Building the project.<\/span><\/figcaption><\/figure>\n
 <\/p>\n
\"Testing
Figure 4. Downloading the code.<\/span><\/figcaption><\/figure>\n
 <\/p>\n
\"Testing
Figure 5. Ticking reset after program checkbox.<\/span><\/figcaption><\/figure>\n
 <\/p>\n
In Figure 6, you can see the output of this project. We actually forgot to give \\r and \\n. That\u2019s why the result is printing continuously on the terminal of the serial monitor software.<\/span><\/p>\n
\"Testing
Figure 6. Output on Serial monitor software.<\/span><\/figcaption><\/figure>\n
 <\/p>\n
Let\u2019s give \\r and \\n, as shown in Figure 7.<\/span><\/p>\n
\"Testing
Figure 7. Adding \\r and \\n in printmsg.<\/span><\/figcaption><\/figure>\n
 <\/p>\n
Now in Figure 8, you can observe the output that we cannot be able to visualize.<\/span><\/p>\n
\"Testing
Figure 8. Output on Serial monitor software.<\/span><\/figcaption><\/figure>\n
 <\/p>\n
Now let\u2019s analyze the output. Let\u2019s stop this program execution. <\/span><\/p>\n
Go to the file and click disconnect (Figure 9). Now it is disconnected, and let\u2019s analyze the output. This output (Figure 8) looks like gibberish. The output is completely messed up, and this is happening because of context switching between the tasks.<\/span><\/p>\n
\"Figure
Figure 9. Disconnecting the tera term.<\/span><\/figcaption><\/figure>\n
 <\/p>\n
For example, when task 1 was scheduled to run on the processor. It is supposed to print the complete line \u201cHello-world: From Task-1\u201d. <\/span><\/p>\n
Remember that when it is printing those characters over UART, since task 2 also has got equal priority, task 2 actually preempted task 1 in the middle of the transmission itself. But the task 1 is not yet completed sending all the characters via UART. Now task 2 has already taken over the CPU, and it tries to send its message, i.e., \u201cHello-world: From Task-2\u201d. That\u2019s the reason you don\u2019t see any proper order in this output. Both the tasks are racing around the UART peripheral to dump their characters. <\/span><\/p>\n
This is an example of non-synchronized tasks racing around a shared entity, i.e., the UART peripheral. That means they are continuously corrupting the data register of the UART. Task 1 is preempted by task 2 in the middle, and task 2 is again preempted by task1. They are actually corrupting the data register of the UART, and there is no proper order. That\u2019s why the output is very messed up.<\/span><\/p>\n
Now how to make this non-synchronized task execution synchronized. In RTOS, there are various methods as follows:<\/span><\/p>\n