Many people, especially students who tend to think in a rigid way, believe that they must thoroughly understand the underlying principles of a technology, such as configuring registers to use a microcontroller, examining task scheduling algorithms, time-slicing, and critical section protection, before they can claim to have learned it.
What happens? After much effort, you manage to get through the tutorial, study the source code, and when you close the book, you still find yourself confused when faced with a real-world requirement.
Then you think that your foundational knowledge is not solid enough, so you search for tutorials everywhere, reviewing the functions and parameters of dozens or even hundreds of API functions, and jotting them down. What’s the use of that? Actually, it’s of no use.
It’s like memorizing an entire dictionary, yet you still can’t write an essay. The essence of technology is in the combination and application to solve problems, not merely in rote memorization.
I would like to share how I digest something I have never encountered before.
My experience is to start from the requirements, and I will use RTOS as an example.
Step 1: Force yourself to do a complex project using bare metal.
Don’t touch RTOS yet; find a project that someone else has done using RTOS and try to do it from scratch using bare metal.
Use the most primitive front-end and back-end system, or a more complex state machine to write it. You will quickly realize that the code becomes extremely bloated, handling multiple events will leave you overwhelmed, and adding a new feature will require you to completely overhaul the entire code logic.
After experiencing this overwhelming feeling, you can then move on to the second step.
Step 2: Only solve the core contradictions.
When you are almost driven mad by the bare metal program, then learn RTOS.
But don’t learn all its features; it’s unnecessary. For 80% of microcontroller products, you only need to master three core components: tasks, message queues, and semaphores.
A task is about breaking down a large chunk of logic that was previously mixed together into several independently running tasks.
A queue is a conveyor belt for passing information between tasks.
A semaphore is a token that coordinates tasks competing for the same resource.
Using these three tools, refactor your previously unfinished bare metal project, and you will understand the significance of RTOS.
For example, in the gateway project we guide students through, we first implement it using our own front-end and back-end system, and then we implement it again using FreeRTOS. This way, your understanding of the architecture becomes deeper, and the learning process will be much smoother, as many of the thought processes are similar.
Step 3: Analyze expert code to understand architectural thinking.
Once you can run the project using RTOS, you are on the right track.
At this point, don’t go back to studying theory; instead, find a piece of excellent source code from a mass-produced product to study, such as flight control systems or some open-source projects.
If you want to improve quickly, you can also participate in our projects, which incorporate many years of our development experience and architectural design methods.
Consider how experts organize tasks when facing complex projects. How is data safely transmitted between multiple tasks? Why is a queue used here, and a semaphore there? What we are looking at is not just the code, but the architectural thinking behind how others solve complex problems, which is much more useful than blindly reading kernel source code.
end
