硬件拓扑与映射：处理器选型、内存布局与HAL落地

好，咱们进入第二章。上一章聊了部署视图的整体概念，这一章就得动真格的了——把软件架构真正“焊”在硬件上。说白了，就是回答三个问题：用什么芯片？内存怎么分？外设怎么管？

我这些年做过的项目，从几块钱的MCU到上万元的MPU都碰过。每次架构评审，硬件拓扑这块总是争论最多的地方。为什么？因为一旦芯片选错、内存布局不合理，后面软件写得再漂亮也白搭。

2.1 处理器选型：不只是看主频

很多人选芯片，上来就看主频、看Flash大小。嗯，这没错，但远远不够。我个人习惯把选型拆成四个维度：

维度	关键指标	我的经验
算力	主频、DMIPS、FPU/ DSP	别只看主频，DMIPS/MHz更实在。我踩过坑：某国产Cortex-M4标称200MHz，实际跑浮点还不如ST的168MHz
存储	Flash、SRAM、Cache	SRAM大小往往比Flash更关键。尤其是跑RTOS+网络协议栈时，64KB SRAM和128KB完全是两个世界
外设	UART、SPI、I2C、CAN、Ethernet	注意外设的复用冲突。很多芯片引脚不够，你选了CAN就丢了UART
生态	IDE、SDK、中间件、社区	这个最容易被忽视。我见过团队选了冷门芯片，结果半年没调通USB Host

2.2 核心分配：多核/多任务的“分家”艺术

现在的嵌入式芯片，单核Cortex-M已经不够看了。双核、多核、甚至异构（比如Cortex-M4 + Cortex-A7）越来越常见。核心怎么分？

我一般遵循三个原则：

1. 实时任务独占一个核——比如电机控制、CAN通信，必须跑在独立核上，不能被其他任务打断
2. 非实时任务共享——比如UI刷新、日志记录，可以放在同一个核上，用RTOS调度
3. 安全隔离——功能安全相关的模块（比如刹车控制）必须和普通应用完全隔离

举个例子，我之前做的一个车载网关项目：

• Core 0 (Cortex-M4 @ 200MHz)：跑FreeRTOS，负责CAN/CANFD收发，优先级最高
• Core 1 (Cortex-M4 @ 200MHz)：跑裸机循环，负责以太网TCP/IP协议栈
• 共享内存：通过Mailbox机制交换数据，避免锁竞争

2.3 内存布局规划：一张图说清楚

内存布局是嵌入式软件的“地基”。地基没打好，上层再漂亮也是危楼。我习惯在项目一开始就画一张内存映射图，然后贴在墙上。

下面这张SVG图，展示了一个典型Cortex-M4项目的内存布局：

2.4 外设总线拓扑：谁和谁说话

外设总线拓扑，说白了就是芯片内部和外部的“交通网络”。你想想看，CPU要读写GPIO、UART要发数据、DMA要搬运内存——这些都得走总线。

常见的总线拓扑有三种：

• AHB (Advanced High-performance Bus)：高速总线，连接CPU、内存、DMA。我习惯把实时性要求高的外设挂在这上面
• APB (Advanced Peripheral Bus)：低速总线，连接UART、I2C、GPIO。功耗低，但带宽有限
• AXI (Advanced eXtensible Interface)：更高级的总线，常见于Cortex-A系列，支持多通道并发

举个例子，一个典型的STM32H7总线拓扑：

总线域	挂载外设	时钟频率	带宽
AXI	CPU、Flash、SRAM、LTDC	200MHz	64-bit
AHB1	DMA、Ethernet、USB HS	200MHz	32-bit
AHB2	ADC、DAC、比较器	200MHz	32-bit
APB1	UART4/5、SPI2/3、I2C1/2	100MHz	32-bit
APB2	UART1、SPI1、TIM1/8	100MHz	32-bit

2.5 硬件抽象层(HAL)映射：让软件“忘记”硬件

HAL是嵌入式软件架构中最重要的一层。它的作用是什么？让上层的应用代码不关心底层用的是STM32还是GD32，是UART还是虚拟串口。

我一般把HAL分成三层：

1. MCU层：直接操作寄存器，由芯片厂商提供（比如STM32 HAL库）
2. 板级层(BSP)：封装MCU层，提供板级接口（比如LED_On、UART_Send）
3. 抽象层(API)：完全与硬件无关，只定义接口（比如IO_Write、Comm_Send）

下面是一个简单的HAL映射示例：

// 抽象层接口 (hal_io.h)
#ifndef HAL_IO_H
#define HAL_IO_H

typedef enum {
    IO_LED_RED,
    IO_LED_GREEN,
    IO_BUTTON_USER
} io_pin_t;

void hal_io_init(void);
void hal_io_write(io_pin_t pin, uint8_t state);
uint8_t hal_io_read(io_pin_t pin);

#endif

// 板级层实现 (bsp_stm32f4.c)
#include "hal_io.h"
#include "stm32f4xx_hal.h"

void hal_io_init(void) {
    __HAL_RCC_GPIOA_CLK_ENABLE();
    __HAL_RCC_GPIOC_CLK_ENABLE();
    
    GPIO_InitTypeDef gpio = {0};
    gpio.Mode = GPIO_MODE_OUTPUT_PP;
    gpio.Pull = GPIO_NOPULL;
    gpio.Speed = GPIO_SPEED_FREQ_LOW;
    
    gpio.Pin = GPIO_PIN_0;  // LED Red on PA0
    HAL_GPIO_Init(GPIOA, &gpio);
    
    gpio.Pin = GPIO_PIN_1;  // LED Green on PA1
    HAL_GPIO_Init(GPIOA, &gpio);
}

void hal_io_write(io_pin_t pin, uint8_t state) {
    switch(pin) {
        case IO_LED_RED:
            HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, state);
            break;
        case IO_LED_GREEN:
            HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, state);
            break;
        default:
            break;
    }
}

2.6 映射矩阵：一张表搞定所有

最后，我习惯把所有映射关系整理成一张矩阵表。这张表在项目评审时特别有用，一眼就能看出哪里有问题。

软件模块	处理器核心	内存区域	外设总线	HAL接口
电机控制	Core 0 (M4)	SRAM Bank1 (0x20000000)	AHB1 -> TIM1/8	motor_control.h
CAN通信	Core 0 (M4)	SRAM Bank1	APB1 -> CAN1/2	can_driver.h
以太网	Core 1 (M4)	SRAM Bank2 (0x20010000)	AHB1 -> Ethernet	eth_stack.h
日志系统	Core 1 (M4)	SRAM Bank2	APB2 -> UART1	log_interface.h
用户界面	Core 1 (M4)	外部SDRAM	FMC -> LTDC	ui_driver.h

嗯，这张表就是你的“硬件拓扑地图”。每次架构变更，先改这张表，再改代码。顺序不能乱。