1. Incorrect Demonstration

Recently, our company hired a new colleague for embedded software development, who came from a listed company in Shanghai. Due to insufficient manpower, he was assigned to be responsible for the R&D of a new product. Initially, he was tasked with testing the functionality of the accelerometer, NB-IOT, servo, and external Flash. After completing the tests, he was asked to create a high-level design for the product. After spending two weeks, he presented us with a high-level design. To be honest, when I saw this design, I felt it was written by a fresh graduate.Version One Architecture Design

The system architecture is divided into two layers: hardware driver layer and application layer. 2.1 Hardware Driver Layer includes all the drivers required for the onboard hardware resources to function properly. 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 Application Layer 1) MCU operating mode switching 2) Vibration and tilt 3) Data parsing 4) Lock/Unlock 5) Data sending 6) Historical data storage.

After seeing Version One’s architecture design, I must admit that it was my first time seeing such a way of writing an architecture design, which was surprisingly written in numbered format, making it particularly awkward for others to read. Version Two Architecture Design

After seeing Version Two’s architecture design, although I felt a bit relieved, I realized there was still a long way to go to meet our requirements. This architecture design mainly has the following issues: 1. The understanding of architecture is still not very clear; since it is architecture design, it should be viewed from a holistic perspective, rather than just being limited to a single module or function. 2. The understanding of each layer is still not very clear; for example, MCU initialization should fall under the hardware driver layer. Strictly speaking, MCU initialization is part of the process rather than a driver. For instance, turning on a computer should not be classified under hardware drivers. 3. The startup of each module should also not belong to the hardware driver layer, as it is part of the business process, and should not be classified as part of the driver layer. 4. Additionally, the reading and writing of bus data, although the role of the driver is to read and write, data bus reading and writing should not be classified as hardware drivers. 5. System parameter initialization in the application layer is also part of the process. 6. Data parsing and data generation are part of communication functionality, and should not be isolated as a standalone application.

2. Modified Basic Framework Diagram

(1) Purpose of Architecture Design 1. The application code logic is clear and avoids reinventing the wheel. 2. Without a good architecture, porting will be a painful process; thus, a good architecture design facilitates software portability. 3. Maximize reusability. 4. High cohesion and low coupling.(2) Design Idea How to encapsulate hardware drivers and functions into modules, allowing them to be quickly assembled like building blocks. Our embedded architecture thinking stems from this, i.e., modular design of functions and layered design. This design is similar to the MVC model in web development, which emphasizes layered design. Modular design: categorize, summarize, and analyze the collected requirements, encapsulating these requirements into individual functions, creating a separate functional module for each. The layered design is difficult to express in one sentence, but it mainly reflects the following aspects: 1. The modules called externally are encapsulated into APIs, allowing the underlying drivers to be accessed via APIs for functional modules. (Each functional module can be compiled independently (e.g., communication modules in pure ANSI C are reusable on any platform), or call driver layer interfaces (e.g., the log library module calls the driver to read and write Flash). In summary, encapsulate independent, reusable functional modules.) 2. APIs are divided into driver layer APIs and application layer APIs, rather than all programs calling driver layer APIs. (If the entire application calls driver layer APIs, it will lead to widespread driver calls within the application, making it unportable and minimizing reusability.) Overall structure schematic diagram:

Note: 1. Layers cannot call across layers. 2. Modules are independent with no dependencies. 3. Modules provide a unified interface for upper layers to call, with clear internal and external interfaces. 4. Module functionality can only be added, not altered. 5. Each functional module layer can also be further divided into sub-layers, such as interface layer, driver layer, hardware layer.(3) Module Level Description

Hardware Driver Layer The hardware driver layer includes all drivers required for the onboard hardware resources to function properly 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 for the business logic layer.

Business Logic Layer The business logic layer includes various business processes for 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 entire product functionality.(4) Advantages If the driver changes or different platforms are used, only the driver layer needs to be modified, and the application layer remains unaffected. If a functional module changes, only the corresponding functional module needs to be upgraded, and other modules remain unaffected, as does the application layer. Once designed logically in this way, the main work is in the business logic layer. The application layer serves as the overall flow and framework of the program, mainly calling the business logic layer to implement different functionalities.

1. The first issue of 2019 “Microcontroller and Embedded System Applications” electronic magazine is freshly released!

2. How to evaluate the performance of various STM32 MCUs?

3. Even Hollywood is discussing the Internet of Things…

4. As an MCU developer, does memory barrier relate to me?

5. The lament of a power engineer after 15 years in the industry…

6. Do you want to get the year-end bonus from Dialog in 2019?

Disclaimer: This article is a network reprint, and the copyright belongs to the original author. If there are any copyright issues, please contact us, and we will confirm the copyright based on the copyright certificate you provide and pay the remuneration or delete the content accordingly.