https://pycv.github.io/blog/tags/%E5%B5%8C%E5%85%A5%E5%BC%8F/Recent content in 嵌入式 on To the MoonHugo -- gohugo.iozh-cnMon, 27 Jul 2026 11:41:16 +0800https://pycv.github.io/blog/excerpts/2026-06-01-embedded-c-ai-future/Mon, 01 Jun 2026 21:37:00 +0800https://pycv.github.io/blog/excerpts/2026-06-01-embedded-c-ai-future/ <blockquote> <p>本文由 AI 自动摘录整理，原始链接：<a class="link" href="https://mp.weixin.qq.com/s/AWuxQ_dPruM2BBp2fsdI6Q" target="_blank" rel="noopener" >嵌入式C语言会不会像当年的汇编语言一样，慢慢被边缘化？</a></p> <p><strong>推荐指数</strong>：6/10（读重点章节）</p> </blockquote> <h2 id="背景">背景 </h2><p>微信公众号「最后一个bug」的文章，探讨在 AI 写代码能力越来越强的背景下，嵌入式 C 语言是否会像当年的汇编语言一样被边缘化，以及嵌入式 C 程序员如何应对。</p> <h2 id="核心观点">核心观点 </h2><ul> <li><strong>汇编的致命伤是架构绑定</strong>：汇编完全绑定特定 CPU 架构，换芯片就得重写；C 语言通过编译器抽象实现了跨平台可移植性，这是汇编永远无法跨越的鸿沟</li> <li><strong>C 语言是软件世界的地基</strong>：CPython 解释器、Java 的 HotSpot 虚拟机、V8 引擎、Linux 内核、FreeRTOS、TCP/IP 协议栈全是 C/C++ 写的——&ldquo;塔尖可以换，但塔底一动整个塔就塌了&rdquo;</li> <li><strong>AI 能生成代码，但解决不了硬件问题</strong>：AI 可以写出一份八九不离十的 SPI 初始化代码，但高温下时钟毛刺导致的 SPI 丢数据，AI 看不到示波器波形也闻不到板子烧焦的味道</li> <li><strong>破局三方向</strong>：往&quot;硬&quot;了走（硬件调试）、往&quot;深&quot;了走（系统级设计决策）、往&quot;广&quot;了走（技能栈拓宽，如 Rust/Python/Go）</li> </ul> <h2 id="补充要点">补充要点 </h2><ul> <li>MCU 的物理限制是 C 语言最坚固的护城河——一颗只有 64KB RAM 的 STM32F103 跑不了 AI 模型</li> <li>AI 辅助生成的外设驱动代码已经可用，但嵌入式工程师的不可替代性从&quot;写代码&quot;转移到了&quot;解决系统问题&quot;</li> <li>汇编没落不是因为汇编程序员技术不好，而是需求收缩了——纯粹汇编的用武之地仅剩启动代码、RTOS 上下文切换、逆向工程等狭窄场景</li> <li>系统级决策（裸机 vs RTOS、任务栈大小、优先级排布、磨损均衡策略）是 AI 目前最薄弱的环节</li> <li>建议用 Rust 的内存安全理念反向改进 C 语言编程习惯——&ldquo;最好的护城河不是你会什么语言，而是你能解决什么问题&rdquo;</li> <li>文章以 SPI 通信高温丢数据的真实案例说明硬件调试的不可替代性：用逻辑分析仪抓了一下午才定位到时钟毛刺</li> </ul> https://pycv.github.io/blog/excerpts/2026-03-14-embedded-segmentation-fault-debugging/Sat, 14 Mar 2026 16:19:35 +0800https://pycv.github.io/blog/excerpts/2026-03-14-embedded-segmentation-fault-debugging/ <blockquote> <p>本文由 AI 自动摘录整理，原始链接：<a class="link" href="https://mp.weixin.qq.com/s/7cFIPWiEzTIJQEHmR7gOjQ" target="_blank" rel="noopener" >一个数组越界，竟让我排查了几天</a></p> <p><strong>推荐指数</strong>：8/10（推荐读原文）</p> </blockquote> <h2 id="背景">背景 </h2><p>程序跑了几天好好的，换个位置就段错误死机。屏蔽两行三角函数代码就正常，打开就必崩——但问题根源和那两行代码毫无关系。最终真凶是一个&quot;隔山打牛&quot;式的数组越界。</p> <h2 id="核心观点">核心观点 </h2><ul> <li> <p><strong>打印法可能把你带偏</strong>：屏蔽代码后&quot;不崩了&quot;，只是切断了越界的触发路径，并没有解决根本问题。表象往往和根因相隔甚远。</p> </li> <li> <p><strong>远程 GDB 精确定位崩溃点</strong>：gdbserver + VSCode 远程调试，段错误发生时能精确知道崩溃的代码行号，比打印法更可靠。</p> </li> <li> <p><strong>数组越界&quot;隔山打牛&quot;</strong>：一个 5 元素的 float 数组 <code>arr</code>，实际写到了 <code>arr[5]</code>、<code>arr[6]</code>、<code>arr[7]</code>、<code>arr[8]</code>。而 <code>arr[8]</code> 的地址正好是静态全局变量 <code>fd</code> 的地址，写入操作直接篡改了 <code>fd</code> 的值，导致段错误。</p> </li> </ul> <h2 id="关键技巧">关键技巧 </h2><ul> <li> <p><strong>-fdata-sections 编译参数</strong>：让每个变量放到独立的 section 中，链接器生成 map 文件时就会包含 static 变量的地址信息，方便分析内存布局。</p> </li> <li> <p><strong>AddressSanitizer（-fsanitize=address）</strong>：对付内存类 bug 的&quot;大杀器&quot;，会直接报出数组越界的精确位置和调用栈，可能 10 分钟就能定位根因。</p> </li> </ul> <h2 id="调试工具速查表">调试工具速查表 </h2><table> <thead> <tr> <th>工具/方法</th> <th>适用场景</th> <th>优势</th> </tr> </thead> <tbody> <tr> <td>log 打印法</td> <td>快速初筛</td> <td>简单直接，零成本</td> </tr> <tr> <td>远程 GDB</td> <td>精确定位崩溃行</td> <td>可看调用栈和变量值</td> </tr> <tr> <td>core dump + gdb</td> <td>事后分析</td> <td>不需要复现，离线分析</td> </tr> <tr> <td>strace</td> <td>系统调用级跟踪</td> <td>排查文件/网络/权限问题</td> </tr> <tr> <td>AddressSanitizer</td> <td>内存越界/溢出/UAF</td> <td>编译期插桩，精确到行</td> </tr> <tr> <td>map 文件 + -fdata-sections</td> <td>分析变量内存布局</td> <td>查看 static 变量地址</td> </tr> </tbody> </table> <h2 id="经验总结">经验总结 </h2><ol> <li> <p><strong>表象 ≠ 根因</strong>：通过屏蔽/打开某些代码来定位问题时，看到的可能只是 bug 的表象。要多思考&quot;为什么&quot;，从根本上解决。</p> </li> <li> <p><strong>选对工具事半功倍</strong>：打印法虽然常用，但遇到内存踩踏类 bug 时容易把人带偏。远程 GDB 和 map 文件是更高效的手段。</p> </li> <li> <p><strong>AI 辅助排查</strong>：有明显代码缺陷的代码，AI review 分分钟就能检测出来。结对分析可以让 AI 检查可疑代码是否存在缺陷。</p> </li> </ol> <hr> <p><em>摘录时间：2026-03-14</em></p>