When a beginner is on the way from entry to mastery, like this problem discovery → investing in thinking → formulating a learning model is very effective.
One encountered problems
Through the encoding practice of this period of time, some coding experiences have been accumulated, but the defects of the previous code structure have also been realized:
(1) Low development efficiency: Each time a resource (such as a timer) is used on the chip, the author needs to check the technical manual and compare it to an egg.
(2) More code repetition: In each experimental source code, initialization functions such as xtal_init and led_init are written every time
(3) Not easy to modify: The business logic in the code is mixed with the operation of the SFR. The readability is poor, and the modification is also laborious.
It is because of the above problems that the author decided to suspend the continuation of this series of blog posts and took the time to think about solutions.
II. Reflections Caused by Website Layering
Before learning embedded programming, the author had experience of ASP.NET website development and practiced its layering theory. Here's a brief mention:
General websites with certain complexity can be divided into the following three layers:
(1) Data Access Layer (DAL): responsible for interaction with the database for the business logic layer call
(2) Business Logic Layer (BLL): Invoking the data access layer to obtain data and provide support for specific business requirements
(3) User Interface Layer (UIL): responsible for rendering the final user interface
I believe that a large number of friends in the blog garden are very familiar with this and will not repeat them here. In short, after layering, it greatly improves the reusability and scalability of the code.
In embedded development, can we also use layered thinking to improve development efficiency and enhance its maintainability and scalability? The following is a brief summary of some of the author's thoughts.
Three embedded projects also come layered
Of course, you can't copy the concrete layering idea of ​​ASP.NET. The specific problem has to be analyzed concretely.
First of all, the core of embedded development is the chip, which provides a fixed on-chip resource for co-developers to use. And it has a very important feature is that it does not change with the needs of the project. Therefore, it should be used as the bottom layer to provide basic support for the upper level. We named it Hardware Abstract Layer.
Of course, there are not enough chips, usually we will extend some functional modules outside the chip to meet specific project needs, such as: sensors, keyboards, LCD screens. The feature of this layer is that it dynamically increases or decreases by module as the project changes. The operation of this layer requires the internal resources of the chip, so it should be on the hardware abstraction layer and called for the upper layer. We named it the Functional Module Layer.
OK, now the raw materials are all ready: chip + expansion module, then we must start real processing: we need to flexibly call the interface provided by the previous two layers to achieve specific project requirements. We named it Application Layer.
Graphic:
(1) Hardware Abstraction Layer (HAL)
Implements common configuration of on-chip resources (such as timers, ADCs, interrupts, I/Os, etc.), hides the details of specific SFR operations, and provides simple and clear call interfaces for upper layers.
(2) Functional Module Layer (FML)
By calling the HAL, all the off-chip functional modules involved in the project are implemented, the detailed operation details of the module are hidden, and a simple and clear call interface is provided for the upper layer.
(3) Application Layer (APL)
The final application functionality is achieved by calling HAL and FML.
Four small choppers
OK, we give a concrete example to illustrate the use of layered thinking.
Before that, the author needed to complete a slightly comprehensive experimental “temperature monitoring systemâ€. The requirements analysis is as follows:
• CC2430 node achieves the timing of the temperature acquisition, and can indicate its sampling frequency by LED lights
• Nodes send data to the PC
• Node can receive control commands from PC to adjust sample rate and power mode
• With automatic shutdown reset
• Can enter sleep state and wake up by key
From the above requirements, we can see that the core chip of this experiment is CC2430. The off-chip expansion modules needed are LED lights and buttons. The above five points are expected to meet the specific project requirements.
Next, we use the layering theory mentioned above to test the code structure of the “temperature monitoring system†experiment:
(1) Application Layer (APL)
[main.c] References hal.h, ioCC2430.h, and module.h for specific application requirements such as temperature acquisition, PC-to-PC communication, and shutdown reset
(2) Functional Module Layer (FML)
[module.h] defines a series of off-chip functional modules (LEDs, keys), and a series of related function declarations
[module.c] Reference hal.h to implement the function of each off-chip module (LED, key)
(3) Hardware Abstraction Layer (HAL)
[ioCC2430.h] (included in the system): defines all SFRs and interrupt vectors for CC2430
[hal.h] Includes common type definitions, commonly assigned macros, and configuration of CC2430 on-chip resources (I/O, serial communication, ADC, timers, power management, etc.)
(Note: Since the off-chip modules involved in this experiment—LEDs and buttons—are extremely simple to use, I have merged them into a single source file. If you encounter more complex modules, you can create new .h and . c files to achieve, such as LCD.h, LCD.c)
After this design, its advantages gradually emerged:
• Efficient development rate: After finishing the hal.h in the HAL layer, we can easily call, without having to repeatedly query the SFR's specific configuration details
• Rapid expansion: If you need to strengthen system functions, simply add the corresponding function module (ie .c file) at the FML layer and call it in main.c
• Higher code reusability: SFR operations provided by the HAL layer are available for general use, and this layer can be directly used in new CC2430 projects without modification
• Better maintainability: the project code structure is clear, HAL and FML almost do not need to be modified, just modify the APL
V Conclusion
Perhaps for embedded programming masters, the above theory may not be completely worthwhile, and there are even big mistakes. However, when a beginner is on the way from entry to becoming proficient, it is worthwhile and necessary to find a problem like this → to think in terms → to think in terms of the way to propose a program. As many people have said: The process is more important than the conclusion.
Female Header section
Female Header section
ATKCONN ELECTRONICS CO., LTD , https://www.atkconn.com