文章归档

嵌入式 Linux 不等于只能写 C。驱动和底层库仍以 C 为主，但业务服务、网络通信、配置管理、升级程序可以根据资源和团队能力选择 C++、Go 或 Rust。语言选型要看约束，不要只看偏好。

嵌入式项目很容易变成一堆 SDK 压缩包、临时补丁、手工改动和不可复现镜像。项目目录和协作方式如果不规范，团队越多人，问题越难追。

嵌入式设备的存储介质差异很大。NOR、NAND、eMMC、SD 卡的特性不同，适合的文件系统和升级方式也不同。选错存储方案，后面会在断电、坏块、寿命和性能上不断补坑。

嵌入式 Linux 上的 C 服务代码，不只是能编译运行就可以。它要长期运行，要处理异常输入，要能记录日志，要能重载配置，要能在资源紧张和网络异常时保持可控。

应用访问外设时，经常会用到 /dev/ttyS1、/dev/i2c-1、/dev/spidev0.0 这类设备节点。设备节点怎么来的、权限怎么设置、热插拔怎么处理，是 rootfs 设计的一部分。

内核配置决定了系统支持哪些驱动、文件系统、网络协议和调试能力。嵌入式 Linux 里，内核不是越全越好，也不是越小越好，而是要和硬件、rootfs、调试需求匹配。

U-Boot 是很多嵌入式 Linux 系统的启动核心。它决定从哪里加载 kernel、dtb、rootfs，也决定 OTA A/B 分区如何切换。理解 U-Boot 环境变量和启动脚本，是排查启动问题和做升级回滚的基础。

嵌入式项目也需要自动化测试。只靠人工烧录、人工点功能，很快会被版本迭代拖垮。自动化不一定一开始就复杂，可以先从构建检查、冒烟测试和硬件在环测试做起。

设备部署到现场后，研发很少能直接接触实物。远程诊断能力决定了问题能不能快速闭环。最基本的远程诊断不是远程 shell，而是能安全地导出状态、日志和配置快照。

固件升级不只是替换二进制。随着版本迭代，配置字段会增加、删除、改名，服务行为也会变化。如果没有版本管理和迁移机制，OTA 后很容易出现旧配置导致新程序启动失败。