- 博客(20)
- 收藏
- 关注
RSS订阅原创 【第08期】C语言的嵌入式特化 (二) —— Const与Static：符号表与存储区的秘密
在C语言教科书里，const和static往往只有两三页的介绍。但在嵌入式开发中，这两个关键字决定了你的数据（Flash还是RAM），以及（链接属性）。搞不懂它们，你的 RAM 可能莫名其妙就不够用了，或者你的全局变量被隔壁文件莫名其妙地改写了。这一期，我们深入符号表与存储区，重新认识这两个关键字。
2025-12-23 16:46:22
286
原创 【第07期】C语言的嵌入式特化 (一) —— Volatile：最熟悉的陌生人
摘要：在嵌入式开发中，volatile关键字至关重要，它防止编译器优化导致程序异常。典型场景包括：1）硬件寄存器访问（值由硬件改变）；2）中断服务程序修改的全局变量；3）多任务共享标志。常见误区是误认为volatile能保证原子性，实际上它仅确保变量可见性，不解决并发问题。正确使用volatile可避免"玄学Bug"，如优化模式下循环卡死等问题。对于寄存器定义，应采用volatile限定指针或直接映射方式。
2025-12-23 16:41:57
465
原创 【第06期】数据的微观世界 (六) —— 堆（Heap）与栈（Stack）：内存管理的红线
单片机开发中的内存管理挑战：在有限的SRAM（如8KB）中，内存被划分为静态存储区、栈和堆。栈用于函数调用和局部变量，速度快但易溢出；堆虽灵活但存在碎片化、不确定性等问题，通常被禁用。工程实践中推荐静态分配和使用内存池替代malloc，避免动态分配的风险。调试时需警惕栈溢出、递归等问题。总结：栈高效但需谨慎使用，堆在裸机系统中应避免，静态分配是首选方案。思考题探讨了任务栈溢出的隐蔽性及其对系统的影响。
2025-12-23 02:51:57
369
原创 【第05期】数据的微观世界 (五) —— 浮点数 vs 定点数：MCU的数学课
摘要： 在嵌入式MCU开发中，浮点数使用需谨慎。低端MCU无FPU时，软浮点运算效率极低（单次乘法可达100周期），即使带FPU也需注意double陷阱和RTOS上下文开销。IEEE754浮点存储采用符号位、指数（移码）和尾数（隐含1）的三段式编码，内存数据需通过联合体或指针转换传输，但必须处理大小端问题。浮点数存在精度损失，禁止直接==比较，推荐Epsilon容差法。高频控制场景建议使用定点数（Q格式），通过整数缩放和移位实现高效运算。开发中应根据场景选择方案：UI用浮点，高频控制用定点，数据传输用原始字
2025-12-23 02:44:43
490
原创 【第04期】数据的微观世界 (四) —— 位操作（Bit Manipulation）的艺术
《嵌入式工程实战》系列第四期探讨了嵌入式开发中的位操作技巧。文章详细介绍了寄存器操作的"三板斧"：置位(OR)、清零(AND NOT)和翻转(XOR)，并分析了"读-改-写"操作在多任务环境中的风险。特别指出位域(Bit-field)在硬件寄存器映射中的三大隐患：未定义位序、RMW风险及跨字节问题，建议仅在内部状态管理时使用。文章推荐使用STM32的BSRR寄存器实现硬件级原子操作，并分享了提高代码可读性的宏定义技巧。最后强调位操作的安全性原则，并提出了一个关于异或交
2025-12-22 08:00:50
490
原创 【第03期】数据的微观世界 (三) —— 内存对齐（Alignment）与结构体填充
内存对齐是优化CPU访问效率的关键机制，虽然会造成空间浪费但能显著提升性能。结构体成员按大小有序排列（从大到小）可减少填充字节，如将12字节的结构体优化至8字节。__packed关键字虽能消除填充但会导致非对齐访问风险，仅建议用于外部通信协议。特别注意避免将__packed结构体成员的地址直接传递给普通指针，否则可能引发硬件异常。实际应用中应权衡空间与效率，在内存受限的嵌入式系统中尤其重要。
2025-12-22 04:01:00
597
原创 【第02期】数据的微观世界 (二) —— 大小端（Endianness）的陷阱与跨平台通信
文章摘要：本文详细解析了计算机内存中的字节序问题（大小端模式）。大端模式将高位字节存于低地址，符合人类阅读习惯；小端模式则相反，利于CPU处理。ARM和x86多采用小端，而网络协议使用大端。跨设备通信时，字节序不一致会导致数据解析错误（如0x12345678被读作0x78563412）。作者提供了检测大小端的方法，并强调通信时必须手动序列化数据，避免直接发送结构体。调试时需注意内存窗口显示的物理字节序与逻辑值的区别。下期将探讨内存对齐问题。
2025-12-21 17:23:28
414
原创 【第01期】数据的微观世界 (一) —— 原码、反码与补码：CPU为何只需加法器？
摘要：本文深入探讨了计算机底层数据存储机制，重点分析了原码、反码和补码的区别。补码因其解决运算逻辑复杂性和0的二义性问题而成为标准方案，使CPU只需加法器就能完成加减运算。文章揭示了8位系统中-128的特殊性，并通过实际案例（如整型提升、右移操作、死循环计数器）展示了补码理解不足导致的常见bug。最后强调嵌入式工程师必须具备"透视"二进制补码的能力，才能有效排查底层问题。
2025-12-21 17:14:01
620
原创 【第00期】前言：在AI能直接写代码的时代，重铸嵌入式工程师的“内功”
《嵌入式开发的内功修炼：从调库到架构思维的跨越》 文章揭示了当前嵌入式开发领域存在的"快餐文化"现象：过度依赖开源库和AI工具导致开发者忽视底层原理。作者通过三个典型场景，展示了这种"知其然不知其所以然"的严重后果：随机死机、空间不足、通信错误等问题。文章提出，真正的嵌入式开发需要打通理论与实践的任督二脉，深入理解内存管理、中断处理、字节对齐等底层原理。作者计划通过48期系列文章，帮助开发者从"调库侠"成长为"架构师"，强调在快
2025-12-21 16:47:20
241
原创 STM32MP中的安全域（Secure World）到底是什么
ARM架构通过硬件级安全域（TrustZone）将系统划分为安全世界（Secure World）和普通世界（Non-secure World），实现硬件强制隔离。安全世界运行可信固件（如TF-A/OP-TEE/TF-M），负责密钥管理等敏感操作；普通世界运行常规系统（如Linux）。两者通过受控接口（SMC）通信，防止攻击者获取全部权限。不同ARM处理器（Cortex-A/M）采用TrustZone-A/M实现隔离，STM32MP平台根据模式选择安全域位置。这种架构确保安全根始终在硬件保护的可信环境中。
2025-11-26 15:55:43
633
原创 从u-boot说ARM SoC 启动体系最大的架构演变
嵌入式系统启动架构演进：从U-Boot全包到分层安全设计 早期单核SoC（如i.MX6）采用U-Boot全包式启动，负责DDR初始化、时钟配置等所有任务。随着ARMv8多核安全架构（如STM32MP2）的普及，启动流程演变为分层设计：BootROM→TF-A（安全初始化）→U-Boot（引导）→Linux。这种架构将硬件初始化与安全控制（TrustZone/OP-TEE）交由TF-A处理，U-Boot专注系统引导，实现了安全隔离、多核协作和标准化设计。关键转变包括：DDR初始化移至安全域、支持TrustZo
2025-11-26 15:48:01
649
原创 STM32MP2 启动链中的 Device Tree继承关系
本文概述了STM32MP2启动流程中设备树(DT)的继承关系。启动过程分为三个阶段：1) BootROM从存储设备加载TF-A镜像；2) TF-A(EL3)使用fdts/.dts初始化DDR/电源/安全区，并传递DT给U-Boot；3) U-Boot(EL2/1)通过arch/arm/dts/.dts配置启动参数，可能修改Linux DT后传递给内核；4) Linux(EL1)使用arch/arm64/boot/dts/st/*.dts加载驱动和系统配置。三个阶段的DT文件格式相同但功能递进，形成完整的设备
2025-11-21 15:55:21
741
原创 什么是TF-A？
TF-A（TrustedFirmware-A）是ARM平台的安全启动管理固件，负责系统上电后最先运行，初始化CPU、内存和TrustZone安全状态。作为启动链的关键环节，它在BootROM之后执行，建立安全环境并加载U-Boot或OP-TEE。在STM32MP系列中，TF-A作为Linux世界的入口，承担硬件初始化、安全配置和启动协调功能，其触发方式（BootROM或M33）因芯片型号而异。作为ARM平台的"安全引导管理器"，TF-A运行在最高权限级别EL3，为后续操作系统启动奠定基础
2025-11-20 16:07:42
793
原创 stm32MP1跟stm32mp2启动流程异同
摘要：STM32MP2相比MP1在启动架构上有重大升级，主要区别包括：1）MP2支持Cortex-M33实时核主导启动（M33-TD模式），而MP1只能由A7核固定启动；2）MP2具备TrustZone-M安全机制和双启动链可选（A35-TD/M33-TD）；3）MP2的M33可先于Linux系统独立运行，实现快速响应和安全隔离。这些改进使MP2在实时性、安全性和灵活性方面显著优于仅支持单一Linux启动链的MP1，但M33-TD模式目前仅限Yocto-based OpenSTLinux生态支持。
2025-11-19 15:06:40
828
1
原创 stm32mp2开发路线图
摘要：本文介绍了STM32MP257F-DK开发板的渐进式学习路线。首先通过Starter Package让板子启动OpenSTLinux系统，验证基础功能；然后使用Developer Package进行应用开发和内核调试；接着学习M33实时核开发，实现A35与M33的通信；最后进阶到Yocto全系统构建。建议的学习顺序是：先让板子跑起来，再开发应用和驱动，掌握M33协同处理，最后深入Yocto定制系统。这种分阶段的学习方法适合工程师稳扎稳打地掌握嵌入式Linux开发。
2025-11-18 15:04:42
800
原创 Yocto在stm32mp2开发中的作用
Yocto项目是嵌入式Linux发行版的自动化构建框架，其核心任务并非仅构建根文件系统(RootFS)，而是完整定制Linux发行版。它能够从源码生成启动链(Bootloader)、内核镜像、设备树、根文件系统及交叉编译工具链(SDK)。在STM32MP2开发中，Yocto通过定义recipe(.bb文件)来控制软件包的下载、编译和安装，最终根据用户配置生成.wic镜像。该框架包含BitBake引擎、元数据层和BSP层，是一个完整的系统构建流水线。对于ST体系，只有Distribution Package才
2025-11-17 16:36:55
680
原创 stm32mp2开发中Developer Package的主要作用
摘要：Developer Package是一个面向开发的半源码包，提供SDK、内核源码、设备树配置等工具，支持修改BSP、开发驱动和Linux应用，并能与M33核通信。但它无法重建完整系统镜像(如rootfs或.wic镜像)，也不能编译M33固件或添加Yocto层。开发者需结合Distribution Package或STM32CubeMP2来实现更完整的开发需求。简言之，该包适合BSP和应用开发，但不支持系统级构建。
2025-11-17 16:23:37
475
原创 STM32MP2相比STM32MP1在架构层面的重大升级
STM32MP2相比MP1在架构上有显著升级：采用Cortex-A35(64位)+Cortex-M33+NPU的组合，其中M33取代M4并支持TrustZone安全机制。通信依然通过OpenAMP/RPMsg，但安全性更高。启动模式更灵活，M33可由安全固件独立启动。内存隔离更强，M33拥有独立SRAM区，支持安全/非安全分区。开发工具链延续CubeIDE支持，但新增TrustZone调试功能。整体而言，MP2在性能、安全性和灵活性方面均有提升，更适合复杂AIoT应用场景。
2025-11-16 10:45:09
698
原创 STM32MPU Linux 系列（MP1 / MP2）中定义的三层软件生态模型
ST针对STM32MPULinux系列推出三层软件生态模型，满足不同开发需求： Starter Package：提供预编译镜像，即烧即用，适合快速验证和评估； Developer Package：包含SDK和BSP源码，支持应用/驱动开发和M33协同调试； Distribution Package：完整Yocto构建系统，支持定制Linux发行版和量产移植。 选择建议： 快速体验选Starter 应用/驱动开发选Developer 系统级定制选Distribution M33开发需搭配STM32Cube_F
2025-11-16 09:48:07
760
原创 stm32mp1 跟 stm32mp2的主要区别
摘要：STM32MP2是ST最新一代MPU，相比STM32MP1在架构和性能上有显著提升。MP2采用64位Cortex-A35核心(最高1.5GHz)和Cortex-M33协处理器，并新增NPU支持AI加速。在外设接口方面，MP2支持USB3、PCIe等高速接口，安全性和可靠性更强。虽然MP2与MP1在软件生态上不完全兼容，但ST提供了迁移工具支持。MP1仍适合中低性能、成本敏感应用，而MP2更适合需要AI、高性能和长期支持的新设计。
2025-11-16 02:59:17
865
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人