嵌入式系统那些事-先导篇

0、 背景

        笔者从毕业至今已经8年有余，前面一直忙于紧张的开发工作，现在相对来说开发任务没那么重，所以想将先前的工作和实践经验总结一下，帮助自己系统化地梳理知识结构，找出知识的盲点。为何选择《嵌入式系统那些事》这个主题，首先笔者8年多一直在嵌入式领域耕耘，从mcu到arm芯片开发，从裸机开发到操作系统上的开发，从底层的驱动开发到应用层的开发，从toc的消费类产品到tob的通信产品，笔者都有所涉猎，但是发现这些知识都是零散地存在，没有形成一张网，于是笔者想通过这种形式织一张网出来。其次笔者目前感兴趣的领域是万物互联、边缘计算和自然人机交互，而这其中嵌入式的设备占据了很大一部分，笔者正在尝试梳理这个庞大的知识体系，也在为后续的开源项目实战做技术上的储备。

        最后在笔者看来要想做好一个嵌入式项目，需要站在5个视角去思考，分别是：解决方案的视角、产品的视角、系统的视角、架构的视角和技术的视角。前两个视角，笔者将在另外一个专栏《万物互联之垂直行业篇》中探讨，后面的三个将在本专栏中探讨，分别是在架构上笔者会探讨《嵌入式架构设计那些事》、在技术上则主要探讨《嵌入式中间件那些事》。本篇《嵌入式系统那些事》主要专注在从底层硬件到底软最终到应用层的知识点系统化，探讨在实际项目过程中总结的一些基础技术方案、复盘问题（涉及内存、性能、通信等）的定位思路，会比较多地偏重于嵌入式整个系统层面技术广度的探讨。通过温故而知新的方式去搭建一份嵌入式系统设计、开发和维护的端到端的知识地图。

1、基本的嵌入式系统架构

        嵌入式系统跟通用的服务器系统不同，在系统资源、性能等方面有很多限制，很难去给出一份通用的系统架构，笔者根据过往经验，尽可能地将其梳理出来。做服务器的应用层可能就很少去关注底层系统和驱动层，但是作为嵌入式的应用开发工程师，除了业务开发外，还需要了解硬件，系统和驱动方面的知识，只有这样在出现问题时，才可以更快速地定界，与其他领域的人员讨论问题时不至于对齐不了语言（俗称行业黑话），毕竟现在的嵌入式系统，除了像mcu这样的小系统1~2个人就可以搞定开发任务，在大型的嵌入式设备开发，如通信设备，通常是团队协作开发的。有了这样的一张知识层次地图心里就会有底，就能找到正确的团队（很多的团队也通常是按照模块的方式组织的，甚至划分的模块更细）或者个人。

        笔者过往的经验深刻感受到必须要在心里有这样的一张图，即使你是一个小螺丝钉也要有这样的全局观念，前面很多人都说全栈是一个说烂的词，是的，单从一个人的能力来说，确实不可能在每个点上都做到很精通，但是事物往往是触类旁通的，只要有所了解，在用到的时候，就可以很快速的上手，知识的深度要有，广度也是不可或缺的，如果你想往更高的层次发展，如系统架构师，就更不能少了这一步。

         笔者在本文中将嵌入式的系统总结为7层，如图所示，分别是硬件电路层，芯片层，体系结构层，芯片驱动sdk和系统驱动bsp（可以统称为系统驱动层），操作系统，中间件，app。为何是这7层呢？这7层是几乎所有带系统的嵌入式设备所必须的，一个设备从设计开始就要考虑每一层的技术选型，选型的依据需要结合具体的业务类型和功能，上下层之间也是有一定的关联的。分层是程序员最为常见的一种模型，通过分层可以将原本复杂的问题分解为一个个可以解决的小问题，各层之间相互独立，只需要完成自己份内的事情，就可以组合出一个完整的产品。上面的分层如果从单一产品的生命周期看越往下越稳定，越往上变化越多，这是很明显的；如果从软件的视角看，应用程序是跟业务关联性最强的，更新迭代最快，越往下的中间件、操作系统脱离了具体的业务，会相对稳定；在商业化场景，硬件的变化也是比较快的，会有降成本，硬件升级，芯片国产化等各种新板子的开发需求，所以对应的硬件变更又会变得更快，驱动程序也会跟着变化，这就像一个漏斗状，两头宽，中间细，如下图所示，理想情况下应该做厚中间层，将平台搭好，越来越稳定，将产品化的做薄，适应性更强。

        

2、分层简述

        图中的app笔者是以通信设备为例做的总结，其中涉及到网络协议栈、配置管理等模块。在实际的嵌入式开发中会有各种业务开发需求，这一块儿也是跟行业和具体业务结合最紧密的地方，在笔者看来在这个层面上的开发工作，技术可能只占很少的一部分，更多的需要对业务知识的深刻理解，因为笔者只在智能家居（智能音箱）和通信设备两个行业做过，所以其业务知识也仅限于这两个行业，同样的笔者会去复盘通信行业和智能家居行业的业务知识，同时会去开拓一个新的行业，比如自动驾驶，智慧城市等等，这个笔者还在思考中，先期先完成复盘。

        中间件是介于操作系统和应用程序之间的一层，向下屏蔽操作系统的差异，提供操作系统抽象层，适配第三方的开源代码，当它们发生变化的时候，只需要对中间件进行修改即可，应用程序完全不可见；中间件向上为应用程序提供平台化的服务，如日志管理、监控手段、安全模块、升级服务等基础服务，同时会根据业务的不同提供业务框架，便于快速开发应用程序。中间件的终极目标是将应用程序像积木一样快速组装，具备良好地扩展性、移植性，节省开发的成本和时间，经过长时间不同产品对其稳定性的打磨，整体软件的质量也会进一步提升，笔者后续将有一个专题探讨中间件的相关话题。

        操作系统的重要性不言而喻，如果你是一名专注于中间件开发的工程师，那对操作系统的了解程度需要更加深入一些，不仅仅只在用上，如果你是一名应用程序开发工程师，那只要会用操作系统的各种系统调用即可，甚至于这些系统调用已经被中间件屏蔽了，你就只需要熟悉中间件的一些系统抽象接口，出现系统相关的问题，也会有中间件工程师跟你一起分析。笔者后续会站在一个中间件开发工程师的视角去解读操作系统的相关知识，比如详细解读操作系统中的进程、内存、文件系统、驱动和网络五个重要课题，以及在中间件视角下的封装和监控；常见的踩内存（飞踩、概率性踩内存）的问题如何复现、布控和定位，进程（任务）切换引发的性能问题如何增加定位手段，如何定位，内核有关的问题如何定位等等；最后笔者也会扩展一些常用地操作系统，对比分析差异和选型。笔者也深刻地感觉到尽管在应用开发中时时刻刻都在和系统打交道，却没有真正从实战的视角去反思过，希望借此机会梳理一下，也为自己后续的物联网场景和边缘计算场景的操作系统选型做好准备。

        接下来就来到芯片驱动层（sdk）和系统驱动层（bsp），这两个驱动一个是对芯片层面的驱动，如驱动cpu(ROM/RAM)/fpga/内存/flash、串口和网口的工作；一个是驱动和引导操作系统工作，两者都跟底层的体系结构和芯片强相关，也称之为固件，在开发者视角上属于底软层面，向下屏蔽硬件驱动的差异，向上提供对操作各种硬件的驱动接口（部分操作系统未提供的），如读写flash等，在岗位角色上，sdk会提供芯片的各种驱动接口，bsp的工程师还会负责系统各类资源的分配，对设备进行管理（当前一般都是设备管理树），各类总线的驱动和管理。笔者在这一部分的接触比较少，更多的仅限于应用，后面笔者会加强这一部分的查漏补缺，重点补齐这部分。

        体系结构这部分笔者所开发的系统都是基于arm的，对其知识也仅限于知道这样的一个体系结构，至于说其工作原理、发展历史、核心技术等了解的很少，尽管前面有项目专门搞过在不同的arm版本上进行切换，切换的时候如何去重构代码，先行解决一些可能会导致问题的地方，但是迫于项目比较紧急也没有详细去总结过，笔者会将原来项目中的一些技术抽象出来，通过另外的自研项目实例来说明。其他的体系结构，如x86，通常在服务器上应用比较广泛，在后续笔者的边缘计算相关的自研项目中也会作为一种备选方案，会在这里做一些技术储备。

        芯片和硬件这一块儿也是在嵌入式开发中需要重点关注的，特别是芯片作为卡脖子的存在，对芯片的掌握也是一个嵌入式系统工程师所必须的，在笔者看来只需深入1~2款芯片即可，笔者将综合前面的一些芯片问题定位过程中的案例，系统地将芯片这块儿硬骨头啃下来。硬件方面，笔者有mcu开发时的项目经验，那时基本上就是跟硬件原理图，软硬件接口手册和各类硬件测试设备打交道，希望在还没有完全丢掉前捡起来，系统一下。

3、小结

        本文并没有涉及太多的技术问题，就给出了一个简单的嵌入式系统的框架，然后针对这个框架谈了一些嵌入式系统设计的问题，后续笔者会以该框架为蓝图，系统梳理每一层的知识要点，也会结合过往的项目经验给出一些定位问题的思路，一些具体的案例，通过这样的复盘和分享一起来搭建嵌入式系统知识地图。这个大主题将会分几个迭代循环去搞，每一层会通过以点带面的方式展开，会先去复盘，然后查漏补缺，最后会在开源实践中实战。敬请期待！