How Important is Embedded Architecture?
To achieve clear code logic in embedded applications and avoid redundant wheel reinvention,
how can we function without a good application architecture?
If there is no good architecture, porting will be a painful task.
If there is no good architecture, reuse will be the biggest challenge, making it impossible to maximize the reuse of existing code.
If there is no good architecture, once the driver changes, everything needs to be modified, which is time-consuming, labor-intensive, and prone to errors.
If there is no good architecture, the application layer will be interspersed with hardware driver code, creating a chaotic appearance with unclear logic, making code maintenance very difficult.
Next,Embedded ARM will share with you,
Things about Embedded Architecture…
01
Basic Architecture of Embedded Systems
Embedded systems generally consist of two parts: software and hardware, with the embedded processor, memory, and external devices forming the hardware foundation of the entire system. The software part of embedded systems can be divided into three levels: system software, supporting software, and application software, where system software and supporting software form the basis, and application software best reflects the characteristics and functions of the entire embedded system.
Hardware Architecture
The core components of embedded systems are various types of embedded processors:
(1) Embedded Microprocessor: Functionally similar to ordinary microprocessors, but it has the advantages of being small in size, low power consumption, low cost, and high reliability.
(2) Embedded Microcontroller: Also known as a single-chip microcontroller, generally based on a specific microprocessor core, with the entire computer system integrated into a single chip. Compared to embedded microprocessors, its main feature is integration.
(3) Embedded Digital Signal Processor: A processor specifically used for signal processing, DSP (Digital Signal Processor) has a structure that separates programs and data, features dedicated hardware multipliers, and widely uses pipelined operations, providing special DSP instructions.
(4) Embedded System on Chip: A complex system that integrates many functional modules on a single chip, which significantly reduces production costs compared to circuit board systems composed of discrete components when produced in large quantities.
Software Architecture
Most people participate in embedded software design, and are more exposed to the upper-level software system, which can be divided into two main types: embedded software application engineers and embedded driver engineers.
The former is mainly responsible for Linux APP design, responsible for application layer business development, and possesses the following professional skills:
1. Familiar with network programming, TCP/IP protocol, IIC, SPI protocol 2. Familiar with multi-thread management, inter-process communication, file IO operations 3. Understand basic shell programming 4. Familiar with database operations 5. Understand QT or AndroidThe latter is responsible for driver development, which involves more of the underlying layers.
1. Familiar with uboot and Linux kernel, completing Linux kernel customization and system firmware updates 2. Familiar with Linux driver model 3. Familiar with ARM architecture 4. Familiar with basic circuit principles
02Embedded Program Design Thinking
Today’s children love playing with building blocks, assembling one module after another to quickly create various models. Nowadays, product design rarely starts from scratch. Most reuse existing mature modules and focus on specific areas of expertise.
My embedded application architecture thinking comes from this, that is, functional module design and layering.
Dividing APIs into driver layer and application layer APIs, rather than having all programs call the driver layer APIs. (If all applications call the driver layer APIs, it will lead to driver calls being scattered throughout the application, making it impossible to port and maximize reuse)
First, divide an application into functional modules and layer the overall structure, then design independent modules (such as algorithm modules, file library modules, communication library modules), opening public interfaces above the modules.
The driver layer provides public interfaces for the upper layer to call. Each functional module can be compiled independently (such as the algorithm module pure ANSI C, can be reused on any platform), or call driver layer interfaces (file library modules call driver to read and write Flash), in short, to encapsulate various independently reusable functional modules.
Overall divided: hardware driver layer –> functional module layer –> application interface layer –> business logic layer –> application layer
Overall structure schematic diagram:
Application layer, serves as the overall operating framework of the program, organizing the invocation of business logic. It can implement several tasks using a certain embedded operating system. Such as timed tasks, card processing tasks, menu tasks, communication tasks.
Business logic layer, such as CPU card processing, traffic department card processing, UnionPay card processing, M1 card processing, communication record upload, blacklist download, fare parameter download, etc.
Application interface layer, providing public API interfaces for the application interfaces to call from the upper layers. These interfaces can also be opened by the lower functional modules, and the application interface layer is responsible for aggregation.
Functional module layer can encapsulate different functional modules. Such as algorithm library, file library, communication library, UnionPay library, providing interfaces to the application interface layer above, and calling driver interfaces below.
Hardware driver layer, composed of various driver modules, providing unified interfaces upwards.
1. Each module’s provided interfaces must be unified, and only additions are allowed, not modifications to the original interfaces.
2. Modules must be independent of each other, not affecting one another, and can only call the interfaces of the lower layers.
3. Layers composed of modules cannot call across levels. For example, you cannot see direct calls to the driver layer code in the application layer.
4. Modules can also continue to be layered, such as interface layer, driver layer, hardware layer.
If the driver changes, or different platforms are switched, only the driver layer needs to be changed, and the application layer is not affected. If a functional module changes, only the corresponding functional module needs to be upgraded, and other modules are not affected, nor is the application layer affected.
After designing according to this logic, the main work is in the business logic layer. The application layer serves as the overall process and framework of the program, mainly calling the business logic layer to implement different functions.
Our current code structure is basically in line with this thinking.
Hardware driver layer –> functional module layer –> application interface layer –> business logic layer –> application layer.
Which of the following two styles of code do you prefer?
Is it really necessary to split saving parameters into AlgCRC16, WritePraFlash((unsigned char *)&NetPra, NETPRA_ADDR, sizeof(_NetPra)) in two steps?
Also, AH_Para_Verify is redundant in the application layer; it should detect legality upon startup.
Since saving parameters is necessary, a packaging should be done as shown in the above image, planning different parameters used by the system. The application layer calls APP_Open_UseFile or APP_Read_UseFile,
instead of directly reading and writing Flash.
Let’s take a look at the famous Google Android architecture; although complex, it resembles building blocks from the diagram, with each functional module being independent and clearly layered. The lowest layer is based on the Linux Kernel, followed by various component libraries, then the application framework and applications.
For example, if you want to use NC_FileLib, the file library module on other platforms, such as EH0918 handheld devices, only a few hardware layer interfaces need to be ported.Take a break and read an article titled “How to Excel in Embedded/MCU/ARM/DSP?”
03A Cautionary Example
A new colleague joined the company for embedded software development, coming from a listed company in Shanghai. Due to a lack of manpower here, he was assigned to be responsible for the development of a new product, initially handling the functional testing of the accelerometer, NB-IOT, servo, and external Flash. After testing, he was asked to create a general design for the product. After two weeks, he provided us with a general design that honestly looked like it was written by a fresh graduate.
2.1 System Architecture The system is divided into two layers: the hardware driver layer and the application layer. 2.1.1 Hardware Driver Layer The hardware driver layer contains all the drivers needed for the onboard hardware resources to operate normally. 1) MCU initialization 2) I2C data access 3) SPI data reading 4) Accelerometer initialization 5) Bluetooth module startup 6) BC95 module startup 7) 485 communication module startup 2.2.2 Application Layer 1) MCU operating mode switching 2) Vibration and tilt 3) Data parsing 4) Locking/unlocking 5) Data sending 6) Historical data storage
After seeing the first version of the architecture design, I honestly felt that I had never seen such a way to write architecture design; it was actually written in a numbered list, which made it particularly awkward for others to read. Version Two of the Architecture Design
After seeing the second version of the architecture design, I felt somewhat relieved, but realized that reaching our requirements would still require a significant distance. This architecture design has the following issues:1. The understanding of architecture is still not very clear; since it is architecture design, it should be viewed in its entirety, not just limited to one module or function. 2. The understanding of each layer is still not very clear; for example, MCU initialization belongs in the hardware driver layer. MCU initialization, strictly speaking, is part of the process, not a driver. For example, turning on a computer should not be categorized as hardware driver. 3. The startup of each module should not belong to the hardware driver layer; it is also part of the business process, and should not be part of the driver layer. 4. The reading and writing of bus data; although the role of the driver is to read and write, the reading and writing of data buses should not be classified as hardware drivers. 5. The initialization of system parameters in the application layer also belongs to the process. 6. Data parsing and generation are communication functions, and should not be isolated, but belong to a single application.
2. Revised Basic Framework Diagram
(1) Purpose of Architecture Design1. The application’s code logic should be clear and avoid reinventing the wheel. 2. If there is no good architecture, porting will be a painful task; therefore, good architecture design facilitates software porting. 3. Maximize reuse. 4. High cohesion and low coupling. (2) Design Thinking How to encapsulate hardware drivers and functions into individual modules, so that like children with building blocks, they can quickly assemble various models. Our embedded architecture thinking also comes from this, namely, functional modular design and layered design. This design is similar to the MVC pattern in web development, both emphasizing layered design. Modular design: classifying, summarizing, and analyzing collected requirements, summarizing these requirements into individual functions, with each function made into a separate functional module. Layered design is not easily expressed in a single sentence; it is mainly reflected in the following aspects:1. Functional modules expose their calling modules as APIs, encapsulating the underlying drivers as APIs for functional modules to call. (Each functional module can be independently compiled (e.g., communication module pure ANSI C, can be reused on any platform), or call driver layer interfaces (log library module calls driver to read and write Flash), in short, encapsulating various independently reusable functional modules.) 2. APIs are divided into driver layer APIs and application layer APIs, rather than all programs calling driver layer APIs. (If all applications call driver layer APIs, it will lead to driver calls being scattered throughout the application, making it impossible to port and maximize reuse)Overall divided: hardware driver layer –> functional module layer –> business logic layer –> application layer Overall structure schematic diagram:
Notes:1. Layers cannot call across layers. 2. Modules are independent, with no dependencies. 3. Modules provide unified interfaces for upper-level calls, with clear internal and external interfaces. 4. Module functions can only be added, not modified. 5. Each functional module layer can continue to be layered, such as interface layer, driver layer, hardware layer.(3) Module Level Description
Hardware Driver Layer The hardware driver layer includes all the drivers required for the onboard hardware resources to operate normally and provides APIs for functional modules to call.
Functional Module Layer The functional module layer includes functions that implement specific functionalities, calling driver layer APIs to achieve corresponding functionalities, while providing callable APIs to the business logic layer.
Business Logic Layer The business logic layer includes various business processes of the overall product functionality, achieved by calling APIs from the functional module layer.
Application Layer The application layer integrates and calls various business logics to complete the overall functionality of the product. (4) Advantages If the driver changes, or a different platform is switched, only the driver layer needs to be changed, and the application layer is not affected. If a functional module changes, only the corresponding functional module needs to be upgraded, and other modules are not affected, nor is the application layer affected. After designing according to this logic, the main work is in the business logic layer. The application layer serves as the overall process and framework of the program, mainly calling the business logic layer to implement different functions.
04Layering Embedded Code
1. Problems Encountered
The code structure can also have flaws:
(1) Low development efficiency: Every time I use a certain resource (e.g., timer), I have to refer to the CC2430 Chinese manual, which is quite a hassle.
(2) Code duplication: Functions like xtal_init, led_init, etc., need to be written every time in each experimental source code.
(3) Difficult to modify: The business logic in the code is mixed with SFR operations, making it less readable and harder to modify.
Due to these issues, I decided to pause the continuation of this series of blog posts and take some time to think about solutions.
2. Thoughts from Layering Websites
Before learning embedded programming, I had experience in ASP.NET website development and practiced its layering theory; here’s a brief mention:
Generally, a website with a certain complexity can be divided into three layers:
(1) Data Access Layer (DAL): Responsible for interacting with the database, providing support for the business logic layer.
(2) Business Logic Layer (BLL): Calls the data access layer to obtain data and provides support for specific business needs.
(3) User Interface Layer (UIL): Responsible for presenting the final user interface.
In short, layering greatly improves code reusability and scalability.
So, can we also use the idea of layering in embedded development to improve development efficiency and enhance maintainability and scalability? Here are some of my thoughts after contemplation.
3. Layering Embedded Projects
Of course, we cannot directly copy the specific layering ideas of ASP.NET; specific issues must be analyzed specifically~
First, the core of embedded development is the chip, which provides fixed internal resources for developers to use. Moreover, it has a very important characteristic: it does not change with the demands of the project. Therefore, it should be treated as the lowest layer, providing basic support for the upper layers. We will call this the Hardware Abstract Layer (HAL).
Having the chip is not enough; we typically extend some functional modules externally to meet specific project needs, such as sensors, keyboards, LCD screens, etc. This layer is characterized by dynamically increasing or decreasing modules according to project changes. This layer requires support from the chip’s internal resources, so it should be above the hardware abstract layer and callable by the upper layers. We will call this the Functional Module Layer (FML).
Now that we have all the raw materials ready: chip + extended modules, we can begin the actual processing: we need to flexibly call the interfaces provided by the previous two layers to achieve specific project requirements. We will call this the Application Layer (APL).
(1) Hardware Abstract Layer (HAL)
It implements general configurations for internal resources (such as timers, ADCs, interrupts, I/O, etc.), hiding specific SFR operation details and providing simple and clear calling interfaces for upper layers.
The core of embedded development is the chip, which provides fixed internal resources (common ones include I/O, ISR, TIMER, etc.; slightly better ones also include ADC, SPI, etc. hardware resources, without needing external ADC acquisition chips or analog SPI) for developers to use. Moreover, it has a very important characteristic: it does not change with the new demands of the project. Therefore, it should be treated as the lowest layer, providing basic support for the upper layers. (2) Hardware Driver Layer (HDL) Embedded development generally uses external resources, such as AT24C02, W25Q128, etc., common peripheral EEPROM chips, which require SPI communication (hardware SPI or I/O simulated SPI) to send corresponding commands to drive the chip, ensuring the chip operates normally. Therefore, the API function implementation of this driver part is the hardware driver layer. Even if the MCU is changed, only the API functions called through the hardware abstract layer need to be replaced. (3) Functional Module Layer (FML)
By calling HAL, it implements all the external functional modules involved in the project, hiding specific module operation details, and providing simple and clear calling interfaces for the upper layers.
The hardware abstract layer and driver layer mainly provide the functional module layer with the functionalities required for the project, such as KEY, LED, and EEPROM functionalities, where KEY and LED basically call the API functions of the hardware abstract layer (more complex ones may involve obtaining/controlling through external chips, thus also requiring the use of the hardware driver layer), while EEPROM calls the API functions of the hardware driver layer. Even if the EEPROM chip changes (AT24C02 or W25Q128), it does not affect the functionality code previously written (provided that the API functions provided by AT24C02 and W25Q128 are standardized). (4) Application Layer (APL)
It implements the final application functionality by calling HAL and FML. It is responsible for the use of functional modules and the logical relationships between them, such as user interaction interface applications that may require KEY, LED, LCD, etc.Four Main Differences between Hardware Abstract Layer and Hardware Driver LayerThe hardware abstract layer uses the internal resources of the chip itself (which are described in the chip manual), while the hardware driver layer uses resources that do not exist in the chip itself and require corresponding code to be written to implement. For example, the CAN used in the STM32 of the Zhidian Atom requires the TJA1050 chip, CAN belongs to the internal resources of the STM32, while TJA1050 is external. However, since TJA1050 can work normally through the APIs provided by the STM32 without additional code, it is not classified as the hardware driver layer. If TJA1041 is used, additional code must be written to ensure normal operation through the APIs provided by the STM32, so TJA1041 can be classified as the hardware driver layer. If you don’t want to be so detailed, you can unify the hardware abstract layer and hardware driver layer into the hardware abstract layer. Five Main Differences between Functional Module Layer and Hardware Abstract Layer, Hardware Driver LayerThe functional module layer is a function extracted according to project requirements, requiring support from the hardware abstract layer and hardware driver layer to implement, and its changes depend on project functionality. In contrast, the hardware abstract layer and hardware driver layer change according to the hardware-related requirements in the project requirements document, of course, if the addition of sub-functions requires hardware support, then the hardware driver must also be changed. For example, the data storage function in the project can be supported by AT24C02, W25Q128, and the chip’s own FLASH, all of which can support the data storage function. Even if the hardware is changed later due to power consumption or cost-saving issues, the implementation of the data storage function remains unaffected (provided that the API function definitions are well planned) and avoids various issues caused by rewriting the functional code, ensuring the stability of that function.
Layered structure schematic diagram
-END-
