Click the blue text above “Luomu Qingyun” to follow me!
What mindset is required for microcontroller programming?
It has been a long time since I updated my articles. This article was actually written a long time ago, but I only completed it today. I apologize for keeping those who are waiting for updates waiting! Looking at the backend data, I noticed that many friends have unfollowed during this time, but it is comforting that the total number of followers has not decreased, so I sincerely thank all the friends who continue to follow. Of course, I can understand those who unfollow, as I haven’t updated for a long time, and the learning progress has certainly lagged behind; some content is even slower than self-study. I initially thought about sharing some videos when I didn’t have new content, but I still received inquiries from friends who were unaware about the video content, and answering questions about content that I didn’t create myself feels a bit “deceptive,” so I decided not to share them. In the future, if I come across some videos that are truly worth watching, I will share them with everyone. Of course, I will emphasize that the videos are shared (when I uploaded some videos from other platforms, I chose to label them as original because those platforms are not very friendly to external links. The original videos I posted on my WeChat public account were not labeled as original at that time because I hadn’t obtained the original rights yet. After the original function was enabled, all my videos published were labeled as original. Fortunately, the public account does not require review of shared videos as long as they are not labeled as original, so in the future, if you see videos that are not labeled as original, you should understand that they are shared from elsewhere, and just enjoy them 
). In summary, I will continue to share some practical knowledge or skills here, hoping that friends who read the articles will gain something. Of course, writing articles and making videos will not bring me income; the main hope is that this can become a platform for communication, helping those in need. Life is not just about distant dreams; it also involves daily necessities. So when I am unable to update, you can leave a message or privately message me with your questions in the backend, and I will definitely respond to your inquiries when I see the messages. I wish everyone a happy weekend and a pleasant holiday for those on summer break! Haha, I still have to continue working tomorrow. Recently, I am preparing for a web 3D project, and since it is my first time encountering it, I need to spend enough effort. Friends with experience or interest are welcome to communicate together. I will also write a few articles to share with everyone when I have free time. Now, let’s get into today’s main topic.
In the previous articles “Basic Knowledge of 51 Microcontroller” and “Programming Development of 51 Microcontroller,” we briefly introduced the basic knowledge of the 51 microcontroller. Friends who have read them should now have no problem writing some simple programs using the 51 microcontroller, right? Of course, the previous content is just the tip of the iceberg in the world of microcontrollers, and there is still a considerable distance from being able to do project development. Simply put, after learning the previous content, what you can do is just some small gadgets, and this code will not bring you any economic income. Perhaps some friends can create some interesting “gadgets” based on this foundation. If so, congratulations, keep up the good work, and you can create more interesting things in the future.
In the following articles, I will gradually share with everyone how to become a microcontroller engineer with project development capabilities. I will explain some professional skills that engineers need to master based on my personal experience, and of course, I welcome you to share your experiences as well. The previous content was meant to let everyone play with the microcontroller like a toy, but project development is not about making toys, so I will also introduce some knowledge that you may use in future job positions. Of course, if you have a development board on hand, compare the materials provided by the store with the knowledge points I wrote in the basic part of the 51 microcontroller; there are still some topics I haven’t mentioned, such as ADC/DAC (analog-to-digital conversion), infrared sensors, temperature sensors, humidity sensors, clock chips, motor drivers, external RAM, external ROM, IIC, SPI communication protocols, etc. These topics were not introduced separately because the circuits you use may differ, or because some content may not be used in the future, or because there may be simpler solutions available. In fact, these are just applications derived from the knowledge points we discussed earlier, so I will supplement the knowledge that will be used more frequently in future articles. Although I will not introduce them in separate articles, I will list a section of content for explanation when using them, making it easier for beginners to grasp everything at once.
Having said so much, how can we develop project capabilities? We must master the programming mindset of microcontrollers. Programming mindset is like the framework of a house or the skeleton of a person; the framework determines the appearance of the house, and the skeleton determines the shape and size of a person. The microcontroller programming mindset also determines the efficiency, readability, and portability of the program. So what content do we need to master in microcontroller programming mindset? We have touched on it before but did not elaborate, and different people have different opinions on this, as it is more influenced by an individual’s programming habits. In my view, the mindset required for microcontroller development is primarily modularization, followed by multitasking, and then object-oriented programming. Of course, these programming mindsets do not exist independently, nor do they necessarily have a time sequence. In my career, they often coexist in my code, and these programming mindsets are more like a collaborative programming habit. Once you form your own programming mindset, you will certainly have your own understanding of it.
Here, I would like to recommend a book to everyone – “Time-Triggered Embedded System Design Patterns.” It may take some time for beginners to understand, but I strongly recommend this book, hoping that everyone can develop a good programming style in the initial stages. Other reference materials on programming habits include “Huawei C Programming Specifications and Examples,” and other related materials from Huawei are also worth reading, such as PCB design specifications, EMC guidelines, etc. Standing on the shoulders of giants, you will see further, so take the time to read them. Of course, improving programming skills is more important than just reading; you must be willing to experiment and make mistakes. If time allows, looking at open-source projects online is also a good choice, as excellent open-source projects are watched by developers worldwide, and they are well-structured, which is better than writing code in isolation.
Modular Programming
Modular programming is the first programming mindset that developers will master. As we have mentioned several times before, it involves packaging specific functional code into a function, allowing for easy copying and pasting in other projects. This is the simplest modularization concept. Of course, to be more standardized, we need to add some necessary comments before the function to facilitate quick understanding of the code’s functionality when we reuse it later. For example, the following code:
/*
***********************************************
* Function Name: led_display
* Description: ****
* Input: ****
* Output: ****
* Return: ****
* Call: ****
* Remarks: ****
************************************************
*/
void led_display(uint16_t duty ,uint8_t up_rate,uint8_t down_rate)
{
****
}
Of course, you don’t have to write so many comments; as long as the comments can ensure that the function’s meaning is understandable, the content can be determined according to your preferences. For example, you can write:
/**
* @brief ：****
* @param ： ****
* @retval ： ****
**/
Or you can simply use a single comment to explain, such as:
/* **** */
Or directly
// ****
As long as it ensures that your explanation is easily understood at a glance, it is fine. However, it is best to form a unified comment format to make the program look more aesthetically pleasing, as this will make it easier for others to read your program, especially since project development is not always done alone, particularly in internet projects. For example, a large project involves front-end developers, back-end developers, mobile (or desktop) developers, and even testers. Although not everyone needs to read your code, at least someone will collaborate with you to complete application functionality. Therefore, many companies have established comment and programming standards.
In addition to being good at packaging functions to modularize programs, in projects, our programs often consist of more than just a few functions. Our projects may use a large number of peripherals, requiring many functions to complete the functionality. If we only package functions, our code can become very large. If a file contains thousands or even tens of thousands of lines of code, maintaining it later can be overwhelming, and it may take a long time to find a bug. So what should we do? In fact, the C language library files have already told us the answer, and the same applies to other languages. We can perform file-based packaging, which means placing code that has the same functionality or controls the same peripheral in the same file for modularization. This approach is more advantageous than simply using functions, as we can directly copy the entire file for reuse without searching for these functions in the code. Now let’s see how this is implemented.
The image above demonstrates this modular approach, where different codes with different functions are placed in different folders, and the code for different modules is placed in different ***.c files. This greatly improves the efficiency of modifying, debugging, and porting code in the future. How is this achieved? Previously, when we introduced C language files, we mentioned that there are two main types of C language files: .c and .h files. The .c files are called source files, while the .h files are called header files. In source files, we store various variable or function definitions, while in header files, we declare corresponding variables, functions, or macro definitions, etc. Therefore, in general, source files and header files appear in pairs. If a file needs to use a function defined in another file, it adds the corresponding header file at the top of that file, allowing for mutual calls between module programs. By separating source files and header files, when you encounter some code files that you do not want others to see but still need to share, there are corresponding handling methods, which we will introduce later.
In general, we also describe the file in different source files with some comments, such as:
/**** (C) COPYRIGHT *********
* File Name ：****
* Description ：****
* Operating System ：****
* Software Platform ：****
* Hardware Basis ：****
* Library Version ：****
* Author ：****
* Version Number ：****
* Modification Time ：****
* Modification Description ：****
**********************************/
Of course, you can also choose not to write so much content; just ensure that you can understand it.
Next,
Multitasking Programming
Generally, when we program 51, AVR, STM32, and other microcontrollers, we use a while(1) loop in the main function to complete all processing, meaning the application program is an infinite loop, calling the corresponding functions to complete the required processing. Sometimes we also need to use interrupts to complete some functional operations. Compared to multitasking systems, this is a single-task system, also known as a front-and-back system, where the interrupt service function acts as the foreground program, and the while(1) loop acts as the background program.
Similar to the following approach:
void IRQHandler_fun()
{
flag1 = 1;
}
int main (void)
{
while(1)
{
if (1 == flag1)
{
func1();
flag1 = 0;
}
}
}
This approach is completely fine in general projects, but one drawback of this program structure is that the real-time performance of the front-and-back system is not strong. Each task (application) in the front-and-back system waits in line to be executed in turn, regardless of how urgent your program is; if it is not your turn, you can only wait! This means that all tasks (applications) have the same priority. In small projects, the front-and-back system is simple, consumes fewer resources, and is manageable for microcontrollers. However, in slightly larger embedded applications where real-time performance is required, the front-and-back system becomes inadequate. At this point, multitasking processing is needed, as shown in the following approach:
void first_task()
{
while (1)
{
if(has_data())
put_data();
}
}
void second_task()
{
while (1)
{
if(get_data())
do_something();
}
}
int main(void)
{
create_task(first_task);
create_task(second_task);
start_task();
}
Careful friends will notice that this approach is clearly different because each task function has a while(1) loop. Does this mean that we just need to use more while(1) loops in the program? In simple terms, you can think so, but the actual situation is definitely not that simple.
So how does multitasking programming achieve program functionality? The multitasking system divides a large problem into smaller problems, gradually solving the small tasks, and thus the large task is also solved. These tasks are processed concurrently. Note that this does not mean that many tasks are executed simultaneously; after all, our microcontroller projects use single-core chips, and at any given moment, only one task can occupy its core. It appears as if many tasks are executed simultaneously because each task’s execution time is very short.
After reading the above content, do you feel that multitasking programming is very difficult? It is indeed challenging, but it is not that difficult because there are many open-source multitasking systems available for us to choose from, such as FreeRTOS, RT-Thread, UC/OS, etc. Therefore, we do not need to write a multitasking system from scratch; we can choose a suitable system for porting to reduce a lot of workload.
In the above project, FreeRTOS is used to implement program functionality. Of course, this programming mindset cannot be mastered in a day or two; it requires some project experience. Therefore, it is normal for beginners to find it difficult to understand. What is important is that you need to master the basics of C language; once your foundation is solid, programming will become intuitive.
Object-Oriented Programming
Earlier, when we introduced the basics of C language, we mentioned that programming languages are mainly divided into procedural and object-oriented types. C language is a typical procedural programming language. You might wonder why we need an object-oriented programming mindset when developing microcontroller programs with C language. Are we supposed to use an object-oriented programming language for development? Of course not; we still use C language for programming. However, we handle related functionalities in an object-oriented manner, simply put, we encapsulate C language through certain techniques to execute program functionalities as if it were an object-oriented programming language.
For simple programs with clear processes, there is generally only one main process line, which can easily be divided into several steps executed sequentially. In this case, there is not much difference between object-oriented programming and procedural programming, and procedural programming is generally more intuitive and efficient than object-oriented programming.
When we face a large and complex program, due to its intricate processes and interactions, it is difficult to simply break it down into a single main line of simple steps, and it usually presents a network-like relationship structure. At this point, the procedural programming approach, which is linear and process-oriented, becomes cumbersome, while the advantages of object-oriented programming become more apparent.
This is one of the reasons why object-oriented programming languages are considered more advanced; the code style of object-oriented programming is easier to reuse, extend, and maintain, making it more advanced, more user-friendly, and more suitable for developing large-scale complex programs. Object-oriented programming methods are used in some operating systems developed with C language (including Unix, Linux, and Windows, etc.), which involve many structures, pointers, linked lists, and other content. If you have not yet encountered object-oriented programming, it only indicates that what you are working on is not complex enough. However, mastering this skill is not a prerequisite for project development; it simply allows you to develop more complex projects, and your salary will certainly be higher than others.
Let’s take a look at some simple object-oriented programming code:
The above are snippets of code from the official standard library functions of a certain series of STM32 chips.
This is a function for creating tasks in FreeRTOS. For beginners, these may seem very profound, so there is no need for you to master them right now; just knowing that they exist is sufficient. It is unlikely that you will be asked in an interview whether you have tried object-oriented development of microcontroller programs without being able to say anything.
This is a segment of source code from a certain version of a Microsoft file, which looks quite complex. To be honest, I haven’t looked at it in detail, and it is impossible to understand it at a glance. I just happened to see it and wanted to share it with everyone.
Conclusion:
Today’s content is a necessary path toward project development, and I have written quite a bit. There is no need to worry or fear if you cannot understand some of the content now; many things become familiar through practice. Therefore, when you encounter knowledge points that you do not understand, do not be afraid; just search for answers. As you encounter more problems and solve them one by one, you will not be stumped in the future. The benefits of hands-on practice during the initial learning stage lie in exposing your shortcomings early, helping you become more adept at project development in the future.
Scan the code to follow and see more content.
