直接写物理地址在嵌入式C++中大概率失败，因现代ARM/RISC-V系统启用MMU/MPU，用户态仅见虚拟地址，对0x40020000等物理地址解引用会触发Data Abort或BusFault；裸机下需通过链接脚本定位、extern声明和缓存维护确保合法访问。
为什么直接写物理地址在嵌入式 C++ 中大概率失败
现代嵌入式系统（ARM Cortex-M/A、RISC-V）几乎都启用 MMU 或 MPU，用户态代码看到的永远是虚拟地址。直接对 0x40020000 这类物理地址取址、解引用，会触发 Data Abort 或 BusFault——不是“没效果”，而是 CPU 硬件直接报错停机。
常见错误现象包括：
- 程序启动后立即进入 HardFault_Handler
-
<em>(volatile uint32_t</em>)0x40020000 = 1;编译通过但运行崩溃 - 在裸机环境能跑，换到 FreeRTOS/RT-Thread 后失效（因内核启用了 MPU）
根本原因：C++ 标准不定义物理地址操作；能否访问取决于启动代码是否已将该物理页映射为可写、可缓存属性，并且当前特权级允许。
裸机环境下用 volatile + 链接脚本定位最可靠
裸机（无 OS）时，你控制整个内存布局。关键不是“怎么写地址”，而是“让编译器相信这个地址合法且不优化”。
立即学习“C++免费学习笔记（深入）”；
必须做三件事：
- 在链接脚本（
linker.ld）中声明一个段，起始地址设为你要操作的物理地址，例如PERIPH_BASE = 0x40020000; - 定义一个 extern 符号指向该段，如
extern "C" volatile uint32_t RCC_CR; - 在启动文件（
startup_*.s）或 C 初始化代码中确保该地址所在页未被缓存污染（尤其 ARM Cortex-M7/M8，需 clean+invalidate）
示例（STM32F4，操作 RCC_CR 寄存器）：
// 在头文件中 #define RCC_BASE 0x40023800UL #define RCC_CR (*(volatile uint32_t*)(RCC_BASE + 0x00)) // 使用时 RCC_CR |= (1U << 0); // 开启 HSI注意：
RCC_CR 是宏，不是变量；每次读写都强制访存，不会被编译器优化掉。
带 MPU/MMU 的 RTOS 中必须走驱动接口
FreeRTOS、Zephyr、RT-Thread 等启用 MPU 后，用户任务默认只能访问自己分配的堆栈和共享内存区。直接硬编码物理地址会被 MPU 拦截。
正确路径只有一条：通过 BSP 层提供的外设驱动 API。
- 不要自己算
0x50000000去访问 GPIOE_BSRR - 改用
gpio_pin_set_dt(&led, 1)（Zephyr）或rt_pin_write(LED_PIN, PIN_HIGH)（RT-Thread）
如果你必须绕过驱动（比如调试寄存器），需：
- 在 MPU 配置阶段显式添加一条 region，基址=
0x40020000，大小=64KB，属性=可读写、非缓冲、非执行 - 切换到 Handler mode（如 SVC 调用）再访问，避开任务级 MPU 检查
这极容易出错：MPU region 数量有限（通常 8 条），配错一条就导致整片外设失联。
mmap() 在 Linux 嵌入式中不等于“映射物理地址”
很多开发者看到 Linux 下用 mmap() 访问 GPIO，误以为这是通用方案。实际上：
-
mmap()映射的是/dev/mem，而该设备节点默认被禁用（CONFIG_STRICT_DEVMEM=y） - 即使开启，也需要 root 权限，且现代 SoC（如 i.MX8、RK3588）会通过 TZPC 或 SMC 调用拦截非安全世界对某些物理地址的访问
-
mmap()返回的是用户虚拟地址，背后由 kernel page fault handler 触发页表更新——这不是你在 C++ 里“操作物理地址”，而是 Linux 内核替你做了映射和权限检查
真正可控的方式是写一个字符设备驱动，在 .mmap file operation 中调用 remap_pfn_range()，把目标物理页帧号（pfn）映射进用户空间。
裸机和 RTOS 场景下根本不存在 mmap()，别被 Linux 经验误导。
物理地址操作从来不是“语法问题”，而是启动配置、内存控制器初始化、特权级切换、缓存一致性这四层叠加的结果。少一层，代码就停在 Fault Handler 里。
