五、嵌入式微处理器分类与选型
5.1、基础分类
5.1.1、微处理器
MPU - Micro Processor Unit
将微处理器装配在专门设计的电路板上，只保留与嵌入式应用有关的母板功能。
一般以某种微处理内核为核心，内核一致，区别在于存储器和外设的配置和封装。
5.1.2、微控制器
MCU - Micro Control Unit
又称单片机。
最大优点 ：单片化。体积大大减小，从而使功耗和成本下降，可靠性提高。
5.1.3、信号处理器
DSP - Digital Signal Processor
对系统结构和指令进行了特殊设计（通常采用哈佛结构）。
特点：适合执行DSP算法，编译效率高，指令执行速度也高。
5.1.4、图形处理器
GPU - Graphics Processing Unit
定义：可执行渲染3D图形等图像的半导体芯片。
作用：减少对CPU的依赖，进行部分原本CPU的工作（如硬件T&L、纹理压缩）。
性能：集成成千上万个Core，峰值性能高达100 TFlops以上。
5.1.5、片上系统
SoC - System on Chip
定义 ：追求产品系统最大包容的集成器件。既是一个有专用目标的产品，也是一种设计技术（从确定功能到软/硬件划分）。
核心特征 ：成功实现了软硬件的无缝结合 ，直接在片内嵌入操作系统的代码模块。
广义比喻：如果CPU是大脑，SoC就是包括大脑、心脏、眼睛和手的系统。
组成：MPU + 模拟IP核 + 数字IP核 + 存储器。
5.2、MPU vs MCU
1）MCU (单片机)：
特点 ：片内自带Flash和RAM。上电即跑，无需复杂外部总线。
场景：电饭煲、汽车电子（车窗控制）、工业仪表。
OS ：通常运行RTOS (uC/OS, FreeRTOS) 或裸机跑。
2）MPU (微处理器)：
特点 ：片内无Flash/RAM（或很小），必须外挂DDR和NAND Flash。性能强，主频高。
场景：智能手机、路由器、智能网关。
OS ：通常运行复杂OS (Linux, Android, Windows)。
5.3、DSP 的"哈佛结构"
冯·诺依曼结构 (Von Neumann) ：程序指令和数据存储在同一个存储器中，共用一条总线。瓶颈在于取指和取数不能同时进行。
哈佛结构 (Harvard) ：程序指令和数据存储在两个独立的存储器 中，有两条独立总线。允许同时取指和取数，极大提高了数字滤波、FFT等算法的效率。
5.4、SoC 的核心理念
软硬协同与IP核
5.4.1、IP核
SoC 设计就像搭积木，这些积木就是 IP 核。
软核 (Soft Core)：代码形式（HDL），灵活性高，性能不可预测。
硬核 (Hard Core)：版图形式，性能最好，无法修改。
固核 (Firm Core)：门级网表，介于两者之间。
5.4.2、软硬件划分
设计 SoC 的第一步是决定哪些功能用硬件（速度快、功耗低、不可改）实现，哪些用软件（灵活、易升级、速度慢）实现。
5.5、五大处理器选型指南
嵌入式处理器选型
MPU 微处理器
MCU 微控制器
DSP 信号处理器
GPU 图形处理器
SoC 片上系统
特征: 性能强, 需外挂存储
场景: 手机, 复杂网关, 跑Linux
特征: 单片化, 低成本, 功耗低
场景: 家电, 传感器, 工业控制
特征: 哈佛结构, 算法快
场景: 音视频编解码, 雷达信号
特征: 并行计算, 3D渲染
场景: 游戏, 自动驾驶AI, 图像识别
特征: 软硬协同, IP核复用
场景: 定制化高端设备, 极致集成
5.6、SoC的广义定义
包含
<<System on Chip 片上系统>>
SoC_System
心脏 : 电源管理 / 时钟
眼睛 : 摄像头 / 传感器接口
手脚 : 执行器 / IO接口
大脑 : CPU(控制核心)
<<底层物理组成>>
Components
核心 : MPU Core
硬件 : Analog IP(模拟核)
硬件 : Digital IP(数字核)
软件 : Embedded SW(嵌入式软件)
🔴 核心考点:
(1) 软硬件无缝结合
(2) 直接嵌入OS代码模块
六、嵌入式操作系统 (EOS)
6.1、定义与职责
定义：用于嵌入式系统的操作系统。它是用途广泛的系统软件。
职责：负责嵌入式系统的全部软、硬件资源分配、任务调度、控制、协调并发活动等。
组成：通常包括与硬件相关的底层驱动软件、系统内核、设备驱动接口、通信协议、图形界面、标准化浏览器等。
6.2、分类
6.2.1、按时间敏感程度划分
嵌入式非实时系统：如早期的PDA、消费电子。
嵌入式实时系统 (RTOS) ：能够在指定或者确定的时间内完成系统功能和外部或内部、同步或异步时间做出响应的系统。
6.2.2、按安全性要求划分
安全攸关系统 (Safety-Critical) ：也称安全生命关键系统。其不正确的功能或者失效会导致人员伤亡、财产损失等严重后果（如航空航天、医疗设备、核工业）。
非安全攸关系统。
6.3、核心特点
微型化：占用资源少。
代码质量高：系统稳定可靠。
专业化：针对特定领域优化。
实时性强 ：最核心特点。
可裁剪、可配置、可定制 ，与 BSP, HAL 相关，意味着 可移植。
6.4、"实时性"的深度辨析
快速 (Speed/Throughput)：指处理得快（如高性能服务器）。
实时 (Real-Time) ：指确定性 (Determinism) 。即系统必须在规定的时间窗口内做出反应，"准时"比"快"更重要。
硬实时 (Hard Real-Time)：超时即失败（如安全气囊、飞行控制）。
软实时 (Soft Real-Time)：超时会降低体验，但不会导致灾难（如视频播放掉帧）。
6.5、"可裁剪性"与架构设计
嵌入式硬件千差万别。
可裁剪：为了省钱、省电、省空间，不需要的模块（如网络协议栈、GUI）必须能去掉。
可配置/可移植 ：通过 BSP (板级支持包) 和 HAL (硬件抽象层) 隔离硬件差异，使得同一个 OS 内核可以跑在不同的芯片上。这是层次化架构的最佳实践。
6.6、安全攸关系统的设计策略
冗余设计：双机热备、三模冗余 (TMR)。
异构性：主控制器用 ARM，备份控制器用 FPGA，防止同一个软件Bug导致两者同时挂掉。
看门狗 (Watchdog)：必须配备，防止死锁。
6.7、嵌入式操作系统的分类体系图
嵌入式操作系统
EOS
按时间特性
RTOS
Hard RT
Soft RT
note: 核心是"确定性"
非实时系统
消费电子
早期PDA
按安全特性
安全攸关系统
航空航天
医疗/核能
note: 故障=灾难
非安全攸关
智能家居
娱乐设备
6.8、五大特征与架构支撑
技术/架构支撑
EOS 五大核心特点
(1) 微型化
(2) 代码质量高
(3) 专业化
(4) 实时性强
(5) 可裁剪/可配置
资源受限/成本控制
固化代码/难升级
特定领域算法
抢占式调度/中断低延迟
BSP & HAL 层
最核心特点
手写重点: 易移植
七、操作系统内核架构
7.1、架构定义
7.1.1、宏内核
实质 ：将图形、设备驱动及文件系统等功能全部在内核中实现，运行在内核状态和同一地址空间。
7.1.2、微内核
实质 ：只实现基本功能（如IPC、调度），将图形系统、文件系统、设备驱动及通信功能放在内核之外（即用户态）。
典型代表 ：鸿蒙操作系统 (HarmonyOS)。
7.2、优缺点深度对比
| 维度 | 宏内核 (单体内核) | 微内核 (鸿蒙/Minix) |
|---|---|---|
| 执行效率 | 高。减少了进程间通信 (IPC) 和状态切换的系统开销。 | 偏低 。用户态和内核态需要频繁切换，且服务间通信需通过 IPC，导致系统效率不如单体内核。 |
| 稳定性/安全性 | 不好。内核庞大，任何驱动故障可能导致整个系统崩溃。 | 较高。服务运行在用户地址空间，故障隔离，单个服务崩溃不影响系统核心。 |
| 可裁剪/可移植 | 不易剪裁。内核庞大，占用资源多。 | 便于剪裁和移植 。内核精练，具有很好的灵活性和可扩展性。 |
| 开发维护 | 耦合度高。 | 结构清晰，有利于协作开发。 |
| 适用场景 | 传统高性能通用计算 (服务器/PC)。 | 分布式系统、高可靠嵌入式系统。 |
7.3、鸿蒙为什么选择微内核？
分布式软总线：微内核的"服务化"架构天然适应分布式。在微内核眼里，调用本地的"相机服务"和调用隔壁手机的"相机服务"，机制是一样的（都是发个 IPC 消息）。这就实现了鸿蒙的**"超级终端"**理念。
高可靠性：物联网设备（如智能门锁、车机）对死机是零容忍的。微内核的驱动挂了重启即可，不会导致整个系统"变砖"。
7.4、性能瓶颈的本质：上下文切换
宏内核 ：应用程序调用驱动 →\rightarrow→ 系统调用 (1次切换) →\rightarrow→ 内核干活 →\rightarrow→ 返回 (1次切换)。共2次切换。
微内核 ：应用程序请求服务 →\rightarrow→ IPC发送 (切换进内核) →\rightarrow→ 内核转发给驱动服务 (切换回用户态) →\rightarrow→ 驱动干活 →\rightarrow→ IPC回复 (切换进内核) →\rightarrow→ 内核转发给应用 (切换回用户态)。共4次切换。
如果题目问"微内核最大的劣势是什么？"，答案就是**"频繁的用户态/内核态切换导致的性能损耗"**。
7.5、协作开发
因为文件系统、网络协议栈都是独立的用户态进程，互不干扰。
A团队 可以专心开发文件服务，B团队专心开发网络服务，只要定义好 IPC 接口，大家可以并行工作，不用担心改了一行代码导致全内核编译报错。
7.6、两种架构的内部构造与通信路径
微内核架构 (Microkernel)
宏内核架构 (Monolithic)
硬件平台
内核空间 (精简)
用户空间
(1) 请求
(2) 转发
(3) 操作硬件
(4) 执行
系统调用 (快)
内核空间 (All-in-One)
文件系统
设备驱动
IPC/调度
网络协议
CPU / 内存 / 外设
应用程序
应用程序
文件服务进程
设备驱动进程
IPC消息转发
地址映射/调度
考点: 路径长, 切换多
7.7、决策矩阵
内核架构选型决策矩阵
Y轴: 低灵活性 Low Flexibility
Y轴: 高灵活性 High Flexibility
象限2: 混合内核 (Hybrid)
代表: Win / Mac
特点: 兼容性强
象限1: 微内核 (Micro)
代表: 鸿蒙 / QNX
(1) 分布式支持: 极高
(2) 易于裁剪: 极高
象限3: 宏内核 (Mono)
代表: Linux / Android
(1) 高性能计算: 强
(2) 代码规模: 庞大
象限4: 裸机 / 库OS
代表: RTOS / Library
特点: 极致简单
X轴: 低可靠性
X轴: 高可靠性
八、鸿蒙操作系统
8.1、四大技术特性
分布式架构 ：首次用于终端 OS，实现跨终端无缝协同体验（如：手机和电视无缝流转）。
天生流畅 ：通过确定时延引擎 和高性能 IPC 技术实现。
可信安全 ：基于微内核架构重塑终端设备可信安全（TEE）。
生态共享 ：通过统一 IDE 支撑一次开发，多端部署，实现跨终端生态共享。
8.2、整体架构设计 (分层模型)
8.2.1、内核层 (Kernel Layer)
内核子系统：支持 Linux Kernel 和 LiteOS（多内核设计）。
KAL (内核抽象层)：屏蔽不同内核差异。
驱动子系统：HDF (HarmonyOS Driver Framework) 驱动框架。
8.2.2、系统服务层 (System Service Layer)
核心能力 ：分布式任务调度 、分布式数据管理 、分布式软总线。
其他：基础软件服务、增强软件服务、硬件服务子系统等。
8.2.3、框架层 (Framework Layer)
用户程序框架、Ability 框架、UI 框架。
8.2.4、应用层 (Application Layer)
系统应用、扩展应用/三方应用。
8.2、核心设计理念
系统功能按照**"系统" - "子系统" - "功能/模块"** 逐级展开。支持根据实际需求裁剪某些非必要的子系统或功能模块（对应嵌入式系统的可裁剪性）。
8.3、为什么要搞 "KAL (内核抽象层)"？
问题：手机需要强大的 Linux，但智能台灯只需要极简的 LiteOS。如果开发两套系统，生态就分裂了。
解决 ：KAL (Kernel Abstraction Layer) 的作用就是把底层内核（无论是 Linux 还是 LiteOS）封装成统一的接口。
这体现了**"屏蔽异构性"的架构思想。上层服务层不需要知道底下跑的是什么内核，从而实现了"一次开发，多端部署"**。
8.4、核心黑科技：分布式软总线
这是鸿蒙最核心的考点，位于系统服务层。
传统方式：手机连打印机，要搜蓝牙、配对、输密码，很麻烦。
软总线 ：在软件层面虚拟出一条总线，让不同设备（手机、电视、手表）只要在同一个网络下，发现、连接、组网就像连在同一根物理总线上一样简单。
架构价值：它是实现"超级终端"的基石，让多设备融合为一个逻辑设备。
8.5、确定时延引擎
对应考点 ：RTOS 的实时性。
原理 ：通过对任务优先级的精准调度，确保高优先级任务（如界面滑动、点击响应）在确定的时间内得到执行，解决安卓系统"越用越卡"的问题。
8.6、鸿蒙四层架构全景图
鸿蒙操作系统架构
内核层 Kernel
系统服务层 System Service
分布式核心能力
多内核设计
Linux Kernel
LiteOS
框架层 Framework
Ability 框架
UI 框架
应用层 Application
系统应用 / 第三方应用
分布式软总线
分布式数据管理
分布式任务调度
基础软件服务 / 硬件服务
KAL 内核抽象层
HDF 驱动框架
考点: 设备发现与互联
考点: 屏蔽内核差异
8.7、四大特性思维导图
鸿蒙OS
四大特性
分布式架构
跨终端无缝协同
虚拟超级终端
天生流畅
确定时延引擎
高性能IPC
可信安全
微内核架构
可信执行环境
生态共享
统一IDE
一次开发, 多端部署
九、嵌入式数据库系统
9.1、主要特点
嵌入式：集成在应用程序中。
实时性：需满足受限的时间约束。
移动性：支持移动计算环境。
伸缩性：可根据资源裁剪。
9.2、三大分类
9.2.1、基于内存方式
定义：数据库的"工作版本"常驻内存，活动事务只与内存拷贝打交道。
特点 ：支持实时事务的最佳技术。
9.2.2、基于文件方式
定义：数据按一定格式存储在磁盘（或Flash）的文件中。
特点：访问是被动式的（通过驱动读写），安全性低，但能满足特定的空间要求。
9.2.3、基于网络方式
定义 ：基于 4G/5G 移动通信，逻辑上把嵌入式设备看作远程服务器的一个客户端。
特点 ：无需解析 SQL 语句，客户端小，有利于代码重用。
9.3、嵌入式网络数据库详解
实质 ：把功能强大的远程数据库映射到本地数据库，让访问远程就像访问本地一样方便。
组成：
1）客户端：提供接口给嵌入式程序。
2）通信协议：规范通信，解决多客户端并发。
3）远程服务器：维护实际数据。
综合系统 ：通常由 网络数据库 + 本地数据库 + Web服务器 构成综合信息系统。
9.4、选型策略
| 场景需求 | 推荐类型 | 原因分析 | 典型代表 |
|---|---|---|---|
| 高频交易、飞行控制 | MMDB (内存) | 实时性第一。磁盘I/O太慢，必须在内存操作。 | FastDB, eXtremeDB |
| 手机通讯录、日志记录 | FDB (文件) | 数据量不大，需要持久化，断电不丢，资源占用极小。 | SQLite (最著名) |
| 物流追踪、外卖骑手 | NDB (网络) | 数据需要实时同步到云端，本地只做简单展示。 | 各种 RESTful API 客户端 |
9.5、为什么 NDB "无需解析 SQL"？
传统 DB ：客户端发 SQL →\rightarrow→ 数据库引擎词法分析 →\rightarrow→ 语法分析 →\rightarrow→ 查询优化 →\rightarrow→ 执行。这套流程对嵌入式 CPU 压力很大。
嵌入式 NDB ：嵌入式客户端只负责打包请求（比如封装成二进制流或 JSON），繁重的 SQL 解析和执行全部扔给性能强大的远程服务器去做。这体现了**"胖服务器，瘦客户端"**的架构思想。
9.6、移动数据库的关键挑战
断网处理 (Disconnection)：移动信号不稳定，必须支持"离线操作，联网同步"。
数据一致性：多终端同时修改数据，如何解决冲突？（通常采用时间戳或版本号机制）。
9.7、嵌入式数据库分类决策树
嵌入式数据库选型
(1) 基于内存 (MMDB)
特征: 常驻内存, 无I/O瓶颈
优点: 实时性极强
(2) 基于文件 (FDB)
特征: 磁盘文件存储, 被动访问
优点: 持久化, 资源占用低
缺点: 安全性低
(3) 基于网络 (NDB)
特征: 客户端-服务器模式, 4G/5G
优点: 本地无需解析SQL, 代码复用
典型: SQLite
考点: 实时性最佳
9.8、嵌入式网络数据库架构 (NDB)
远程数据库服务器 NDB 客户端 (本地) 嵌入式应用程序 远程数据库服务器 NDB 客户端 (本地) 嵌入式应用程序 特点: 瘦客户端 不解析SQL 解析SQL ->> 执行 ->> 获取结果 看起来像在访问本地数据库 (映射机制) 调用接口 (如: query_data) 封装请求 (Protocol) 发送请求 (通过 4G/5G) 返回结果数据 数据解包并呈现
十、嵌入式开发环境与低功耗设计
10.1、嵌入式软件开发特点
宿主机-目标机模式 ：开发在宿主机 (Host) （PC/工作站）上进行，生成二进制代码后，下载到目标机 (Target) 运行。
固化：代码通常需要固化在目标机的存储器（ROM/Flash）中。
专用性：需要专用的开发工具、目标系统和测试设备。
软硬件协同：强调软/硬协同工作的效率和稳定性。
严格约束 ：对实时性、安全性、可靠性 要求更高，且需充分考虑代码规模（资源受限）。
10.2、交叉开发环境与调试
10.2.1、交叉开发工具链
交叉编译器 (Cross Compiler)：在宿主机上生成目标机可执行代码。
交叉链接器：链接目标代码。
调试器/代理：用于远程调试。
10.2.2、调试接口 (JTAG)
全称：Joint Test Action Group (联合测试工作组)。
标准：IEEE 1149.1 标准测试协议。
作用 ：主要用于芯片内部测试 和调试（设置断点、查看寄存器）。
10.2.3、目标代码格式
COFF, ELF。
10.3、低功耗设计
软硬件协同设计：软件设计要匹配硬件特性（如：关闭闲置外设的电源）。
编译优化：采用低功耗优化的编译技术（如：指令重排减少总线翻转）。
算法优化：减少系统持续运行时间（让系统尽快处理完，尽快休眠）。
用"中断"代替"查询"：查询（Polling）会让CPU一直空转耗电；中断（Interrupt）允许CPU在无事时休眠。
电源有效管理：动态电源管理 (DPM)。
10.4、为什么要"交叉开发"？
因为目标机资源不够。嵌入式设备（如智能手环）的 CPU 和内存无法运行庞大的编译器（GCC/Visual Studio）。
异构性 ：宿主机通常是 x86 架构（Intel/AMD），而目标机通常是 ARM/MIPS/RISC-V 架构。所以在 PC 上编译出来的 .exe 是不能在单片机上跑的，必须用交叉编译器 （如 arm-none-eabi-gcc）翻译成目标机能懂的机器码。
10.5、JTAG 的双重身份
调试 (Debug)：开发阶段，用来单步执行、看变量。
边界扫描 (Boundary Scan)：生产阶段，在不焊下芯片的情况下，通过扫描链测试芯片引脚有没有虚焊。
安全警示 ：在最终量产的高安防产品中，必须禁用 JTAG 接口，防止黑客通过它读取固件或篡改内存。
10.6、"中断 vs 查询"的功耗本质
1）查询 (Polling)：
代码逻辑 ：while(1) { if(event) handle(); }
功耗 ：CPU 占用率 100%，一直全速跑，功耗极大。
2）中断 (Interrupt)：
代码逻辑 ：CPU 进入 Sleep/Idle 模式 →\rightarrow→ 硬件产生信号 →\rightarrow→ 唤醒 CPU 处理 →\rightarrow→ 处理完继续睡。
功耗 ：CPU 大部分时间在睡觉，功耗极低。
10.7、交叉开发工作流
目标机 (Target: Embedded Device)
连接通道
宿主机 (Host: PC/Workstation)
加载符号表
下载/固化
调试指令
IEEE 1149.1
源代码 C/C++
交叉编译/链接器
目标二进制代码
ELF/COFF
调试器 Host端
以太网/串口/USB
(下载代码)
JTAG 仿真器
(控制/调试)
存储器 ROM/Flash
目标操作系统
调试代理 Agent
10.8、低功耗软件设计策略金字塔
软件优化策略
低功耗设计目标: 延长电池寿命
(1) 算法级: 减少运行时间
(2) 机制级: 中断代替查询
(3) 编译级: 低功耗指令优化
(4) 架构级: 软硬协同 (关外设)
核心技巧: 让CPU多睡觉