嵌入式系统

前言：实时系统为什么越来越离不开网络 过去谈嵌入式实时系统，很多工程师第一反应是中断延迟、任务优先级、定时器精度和 RTOS 调度器。只要 CPU 够快、ISR 写得短、关键任务优先级足够高，系统就能在板子内部把时序控制住。但这几年现场设备的形态已经变了：电机驱动、视觉传感器、PLC、边缘 AI 控制器、远程 IO、机械臂关节模块不再挤在同一块 PCB 上，它们通过以太网组成一个分布式控制系统。此时，实时性的瓶颈不只在内核，也在网络。 传统以太网追求“尽力而为”：帧能发就发，交换机按队列转发，拥塞时排队，严重时丢包。它很适合办公网络和普通数据采集，却不适合“每 1 ms 必须收到一帧传感器数据，控制器计算 200 μs，执行器再在指定窗口更新 PWM”这种硬约束场景。工业现场常见做法是上专用实时以太网，例如 EtherCAT、PROFINET IRT、SERCOS III 等。它们很好用，但生态相对封闭，协议栈、硬件、工具链往往绑定供应商。 TSN（Time-Sensitive Networking，时间敏感网络）试图解决的正是这个问题：在标准以太网上增加时间同步、流量整形、门控队列、帧抢占、流过滤和集中配置等能力，让普通以太网具备可分析、可规划、可隔离的实时传输能力。它不是一个单独协议，而是一组 IEEE 802.1 标准的组合。对于做嵌入式、RTOS、工业控制和边缘计算的团队来说，TSN 的价值不在于“把网络变快”，而在于把网络行为从概率问题变成工程问题：什么时候发、能不能进队列、最多排多久、丢包后如何隔离，都可以在设计阶段说清楚。 本文以实战视角梳理 TSN 在嵌入式实时系统中的落地方式。我们会从基础概念讲起，重点放在 802.1AS 时间同步、802.1Qbv 门控调度、802.1Qci 流过滤、Linux tc 配置和端到端时延预算。文章不会把标准条文逐条翻译，而是站在系统工程师角度回答几个更实际的问题：什么时候需要 TSN？它和 RTOS / PREEMPT_RT 如何配合？一个 1 ms 控制周期应该怎样拆成网络窗口？调试时应该看哪些指标？ 一、TSN 解决的不是带宽，而是确定性 很多项目第一次遇到网络实时性问题时，会本能地升级链路：百兆换千兆，千兆换 2.5G，交换机换更大缓存。短期看，平均延迟确实下降了，但最坏情况不一定变好。原因很简单：实时系统关心的是 deadline miss，而不是平均吞吐。一个 1 ms 周期任务，前 999 次都在 80 μs 内收到帧，只有第 1000 次因为低优先级大包阻塞了 700 μs，控制回路仍然可能抖一下。 确定性网络最核心的指标通常有四个： 有界时延：从发送端应用层写入数据，到接收端应用层读到数据，最大时间可以估算。 低抖动：相邻周期到达时间的偏差可控，不能依赖“运气好”。 流隔离：关键控制流不被日志、视频、OTA、Web 配置页面等普通流量拖累。 可诊断性：当时序变差时，能定位是时钟漂移、门控窗口配置错误、驱动队列阻塞，还是应用线程没有及时取包。 TSN 的设计思路是把网络传输拆成两个层面：首先让所有节点拥有同一套时间基准，然后让交换机和网卡在同一时间基准下按照计划打开或关闭队列。这样一来，控制帧不是“抢着发”，而是在预留窗口里发；普通流量不是“完全禁止”，而是被安排在不影响关键流的时间片内发送。 ...

前言 在嵌入式系统飞速发展的今天，GPU 早已不再仅仅是"游戏显卡"的代名词。从智能手机的流畅 UI 渲染，到车载娱乐系统的 3D 导航，从边缘设备的 AI 推理加速，到 AR/VR 设备的实时渲染，GPU 已经成为现代嵌入式 SoC 中不可或缺的核心组件。而在这个领域，ARM Mali GPU 无疑是占据统治地位的存在——全球超过 70% 的 Android 设备都搭载了 Mali GPU，从入门级的 Mali-G52 到旗舰级的 Mali-G720，Mali 架构覆盖了从低端到高端的完整产品线。 然而，尽管 Mali GPU 如此普及，真正深入理解其架构原理的开发者却并不多。大多数嵌入式工程师习惯于 CPU 的线性编程模型，面对 GPU 的并行计算架构和独特的渲染流水线时，往往感到无从下手。更重要的是，Mali GPU 采用的基于分片（Tile-Based）的渲染架构，与桌面端 NVIDIA/AMD 的立即模式渲染有着本质区别，如果不理解这种差异，写出的着色器代码往往会出现严重的性能问题。 我曾见过太多这样的案例：一个在 PC 上运行流畅的 OpenGL ES 应用，移植到嵌入式平台后帧率暴跌；一份看似合理的着色器代码，却在 Mali GPU 上出现了难以解释的带宽瓶颈；一个经过精心优化的渲染流程，实际性能却只有理论值的三分之一。这些问题的根源，往往都在于对 Mali GPU 架构的理解不够深入。 本文将从硬件架构出发，系统地讲解 Mali GPU 的工作原理。我们会从最基础的 Tiler 分片渲染机制讲起，深入到着色器核心的执行模型，分析内存层次结构的设计考量，最后给出一套完整的性能优化方法论。无论你是正在开发嵌入式图形应用的工程师，还是对 GPU 架构感兴趣的技术爱好者，这篇文章都能为你揭开 Mali GPU 的神秘面纱。 一、为什么嵌入式 GPU 需要不同的架构设计？ 在深入 Mali GPU 的具体架构之前，我们首先要回答一个根本性的问题：为什么嵌入式 GPU 不能直接沿用桌面 GPU 的设计？答案可以用三个关键词来概括：功耗、带宽、面积。 ...

前言 在嵌入式系统开发领域，从简单的 8 位单片机跑超级循环，到复杂的 32 位 MCU 运行多任务操作系统，这是每个嵌入式开发者必然经历的成长路径。而 FreeRTOS 作为市场占有率最高的轻量级实时操作系统，几乎是嵌入式工程师必须掌握的核心技能之一。 然而，很多开发者对 FreeRTOS 的理解还停留在「能跑几个任务」的层面。真正要构建一个健壮、高效、可维护的实时系统，远不止调用 xTaskCreate 那么简单。任务优先级如何合理分配？死锁和优先级翻转如何避免？中断与任务之间如何安全通信？内存泄漏如何检测和预防？这些问题在实际项目中往往比实现功能本身更具挑战性。 本文将从实战角度出发，系统讲解 FreeRTOS 的核心设计理念，结合大量代码示例，带你深入理解实时系统的设计原则。从任务管理、同步机制、通信方式到调试技巧，每一个知识点都配有可运行的代码和详细的原理解析。无论你是刚开始接触 RTOS 的新手，还是想要深入理解内核实现的进阶开发者，都能从本文中获得有价值的参考。 一、为什么选择 FreeRTOS？ 在众多 RTOS 选型时，我们有很多选择：从商用的 VxWorks、QNX，到开源的 FreeRTOS、Zephyr、RT-Thread，再到芯片厂商自家的 RT-Thread、AliOS Things 等等。那么 FreeRTOS 为什么能脱颖而出，成为绝大多数嵌入式领域的事实标准？ 1.1 极致的轻量级设计 FreeRTOS 的核心内核代码只有几十个 C 文件，最小内存占用极低。一个最小配置下，ROM 占用通常在 6-10KB 左右，RAM 占用甚至可以低至几百字节。这使得它能够运行在资源极其有限的 MCU 上，从 8 位的 8051 到 32 位的 Cortex-M7 都能完美适配。 这种轻量级不是通过阉割功能换来的，而是精心设计的结果。内核采用「按需配置」的设计哲学，所有功能都是可裁剪的。你用不到的功能，就不会被编译进最终固件。 1.2 商业友好的许可证 FreeRTOS 使用 MIT 许可证，这意味着你可以完全免费地将其用于商业产品中，不需要公开你的源代码，也不需要支付任何专利费用。这对于商业公司来说是一个巨大的优势。对比之下，Linux 的 GPL 许可证在很多商业场景下会受到限制，而商用 RTOS 的授权费用往往高达数万甚至数十万美元。 1.3 广泛的芯片支持与社区生态 FreeRTOS 几乎支持所有主流的处理器架构：ARM Cortex-M/R/A、RISC-V、Xtensa、AVR、PIC、MSP430 等等。几乎你能想到的 MCU，官方都提供了移植好的端口代码。同时，由于市场占有率高，遇到问题很容易在社区找到解决方案，各种第三方组件、驱动、中间件也极其丰富。 ...

详细介绍嵌入式系统内存管理的 5 种方法：静态分配、栈分配、堆分配、内存池和自定义分配器，包含性能对比和实战代码。