Detailed discussion on modular architecture design of MCU firmware

[ Reading guide ] General beginners of SCM students , Just started to do MCU development , Not yet involved in the use of RTOS, And just started directly RTOS It may be difficult . Some use relatively old MCU, and the resources are still limited , It's not suitable for running RTOS. Or use RTOS, I'm confused about the overall idea , I don't know where to start . therefore , Today, let's talk about some ideas and experiences of my overall framework design of single-chip microcomputer program .

Why discuss architecture ？

One of the goals of MCU system developers is to create firmware in the programming environment , To achieve a low-cost system 、 Software reliability and fast development iteration time . The best way to implement this programming environment is to use a unified firmware architecture , The architecture acts as a framework in the product development process and supports “ Firmware modularization ”, Or subsystem .

If a unified design architecture is not adopted , Then the coupling relationship between business requirements is complex , Design first is not used - Post development methodology , Where to think and write , The later maintenance of the program will become extremely difficult , And introduce potential bug/ The risk of defects will also increase greatly , And there is no possibility of multi person collaborative development .

Can be combined with firmware modularization 、 The right combination of testability and compatibility design architecture can be applied to any firmware development project , To maximize code reusability , Speed up firmware debugging and improve firmware portability .

Modular architecture design ？

Modular programming decomposes program functions into firmware modules / Subsystem , Each module performs a function , And contains all the source code and variables required to complete the function .

【 Article Welfare 】 Let's share some related tutorials , You can also add learning groups 780619431 Discuss with you ：
FreeRTOS In depth analysis of kernel source code
Intelligent insertion project ：FreeRTOS+LwIP
A lesson will get you started FreeRTOS
（ STM32+LoRa make LPWA The Internet of things system ）
From single chip microcomputer to embedded system linux What we need to do

modularization / Subsystem helps to coordinate the parallel work of many people in the team , Manage the interdependencies between the various parts of the project , And make designers 、 System integrators can assemble complex systems in a reliable way . say concretely , It can help designers implement and manage complexity . As applications grow in size and functionality , It takes modularity to divide them into separate parts （ No matter what it is “ Components ”,“ modular ” still “ Subsystem ”）. then , Each such separate part becomes an element of the modular architecture . such , Each component can be isolated and accessed using a well-defined interface . Besides , Modular programming can improve the readability of firmware , At the same time, it simplifies the debugging of firmware , Testing and maintenance .

Even if one person develops a project independently , This is still in the debugging of the code 、 Readability 、 Portability is the overall strategy of best practices . If the code is well designed , Can be easily applied to other projects . And the module has been tested and verified by the previous project , Applying it again in new projects will greatly reduce the risk of defects . So every project , With this strategy, we continue to accumulate modules " wheel " Components , As experience grows , Accumulated “ wheel ” More and more , It's getting better and better . So its advantages are obvious , Otherwise, every project , It all starts with the wheel , It takes a long time to develop , The development level has not been improved , Repetitive work is also boring . For example, the nonvolatile storage management subsystem mentioned above , If the design is good , It becomes a reliable and portable wheel . Please understand this passage deeply , And take it away. No thanks ！

Firmware module principle

The basic concept of modular programming in firmware development is to create firmware modules . conceptually , Modules represent separation of concerns . In computer science , Separation of concerns is the process of decomposing a computer program into unique functions that rarely overlap . A concern is any concern or function of the program , And synonymous with function or behavior . The development of separation of concerns has traditionally been achieved through modularity and encapsulation , In fact, it is decoupling thought .

Firmware modules can be divided into several types ：

The code related to many upper user modules is implemented as a separate firmware module . Common, such as the abstract implementation related to the underlying hardware . for example ,hal_adc.c yes ADC The firmware module of the user module , and hal_timer.c yes Timer The firmware module of the user module .
The code for a particular pure software algorithm is implemented as a separate firmware module . for example ,alg_filter.c Is to execute software filters （ For example, median filter , Mean filter or weighted mean filter 、IIR/FIR wave filtering ） Firmware module .
The application specific code is implemented as a separate firmware module . for example ,app_battery.c Is the firmware module for the battery charger application . The code of a specific tool is implemented as a separate firmware module . for example ,debug_print.c It is a firmware module used to realize the log printing function .
…
Some rules for implementing estimation modular design ：

All functions related to the module shall be integrated into a single source file , This is the embodiment of high cohesion .
The module provides a header file , This file declares all the resources of the module （ Hardware dependence / macro / Constant / Variable / function ）. As far as possible with struct The closely related variables are lumped and encapsulated .
Include the self-test code in the source file , To realize all self-test functions of the module .
The interface of firmware module shall be carefully designed and defined .
Because firmware depends on hardware , Therefore, it is necessary to explicitly mention the correlation of hardware in the source file header . For example, use macros to turn hardware dependencies into definitions , Or use functions to encapsulate basic operations . In the new architecture , Just migrate this part of the implementation to use .
Usually , The firmware module can be used by other team members in other projects . It may involve managing changes , Defect repair 、 The owner shall maintain the module . The source file header should contain “ author ” and “ edition ” Information .
The firmware depends to some extent on the compiler . The header of the source file should state which development environment has been verified , To specify the compiler or with IDE Relevant information .
It should be noted that , Modular design introduces some call overhead , It is also possible to increase the firmware size . In practice , Compromise consideration . Don't be overly modular , Therefore, it is recommended to use high cohesion 、 Implementation strategy of low coupling .

The ventilator mentioned in the previous article PB560 The design of the , Read its code , I was going to interpret its code design , But I read it and found , Its design is too modular , There is no idea of achieving high cohesion . Many of its source code source files only implement a function , Instead of concentrating a class of problems on abstract implementation , Then he gave up his code interpretation .

How to split modules ？

Do engineering development , It must be demand driven . The first thing is to have a clear understanding of needs , Then we can design a more reasonable framework . What we need to achieve ？ The general overall design process strategy is shown in the figure below （ I prefer drawing , The picture will make people more intuitive ）.

The first question to ask yourself is ： What are the main functions of this project ？ Where does this come from ？ If it is actual product development , It may come from the demand of the market , If it's your own DIY project , It will YY Come up with a general idea ？ In short, no matter where it comes from , The demand must be sorted out first . So what are the requirements in general ？

What are the hardware IO Interface requirements , For example, switching value input ,ADC sampling ,I2C/SPI Communications, etc
What are the business logic requirements , For example, to collect the data of a sensor , Control a heating device , So this is the demand for high cohesion .
What are the technical requirements related to the algorithm , For example, which signals in the product need filtering processing , What needs frequency domain analysis, etc .
Whether there are external communication protocol requirements .
Is there any business data that needs historical storage , Or the equipment parameters need to be saved after power failure
Whether there is a need for log printing .
…
To name but a few .
Combined with the principle of firmware module and relevant guidelines , Then the demand with high relevance , The abstract is implemented in a series of modules , This series of modules cooperate to realize a highly relevant business requirement , Further, these modules become a subsystem . Multiple subsystems in main.c Under the control of , Coordinate and complete the overall function of the product .

How to integrate scheduling ？

For some, do not use RTOS In terms of application , You can use the following framework to ：

Based on RTOS An example of integration implementation of ：

It's different RTOS, The function names are different , But the general idea is generally the same .

To sum up

This paper starts with why the overall architecture of modular design is needed , To the benefits of doing so , And some specific guidelines , And then how to realize , How to achieve high cohesion and low coupling , It provides some personal experience and ideas . meanwhile , For bare metal program overall framework 、 be based on RTOS The integration framework does two demo, It can basically solve most of the framework thinking problems . Some of the principles advocated by individuals in the previous article , In bold summary ：

All functions related to the module shall be integrated into a single source file , This is the embodiment of high cohesion .

The module provides a header file , This file declares all the resources of the module （ Hardware dependence / macro / Constant / Variable / function ）. As far as possible with struct The closely related variables are lumped and encapsulated .

Include the self-test code in the source file , To realize all self-test functions of the module .

The interface of firmware module shall be carefully designed and defined .

Because firmware depends on hardware , Therefore, it is necessary to explicitly mention the correlation of hardware in the source file header . For example, use macros to turn hardware dependencies into definitions , Or use functions to encapsulate basic operations . In the new architecture , Just migrate this part of the implementation to use .

Usually , The firmware module can be used by other team members in other projects . It may involve managing changes , Defect repair 、 The owner shall maintain the module . The source file header should contain “ author ” and “ edition ” Information .

The firmware depends to some extent on the compiler . The header of the source file should state which development environment has been verified , To specify the compiler or with IDE Relevant information .

It is strongly recommended to use design first - Post development mode , More taboo debug, Where to think and write . Of course, for novice learning , The latter pattern , You can iterate step by step , You can also grow experience faster . Of course, how to choose , It's all personal .

I believe if you read deeply , To realize , We should get some understanding from the design idea , Improved . If it can help you , Then my heart is very relieved , It's worth the hard work of coding so many words . Of course, if you think the article is valuable , Please help me to see , Or forward and share . Let more friends see , Of course, for the great God of MCU development , The views in the article are quite superficial . As for appreciation , Then you can .