你了解嵌入式软件的发展历程吗？如何分析嵌入式软件的问题？

嵌入式软件与嵌入式系统是密不可分的，嵌入式系统一般由嵌入式微处理器、外围硬件设备、嵌入式操作系统等部分组成。为增进大家对嵌入式软件的认识，本文将对嵌入式软件的发展以及分析嵌入式软件问题的方法予以介绍。如果你对嵌入式软件具有兴趣，不妨继续往下阅读哦。

一、嵌入式软件的发展

第一阶段：早期的嵌入式系统设计方法，通常是采用“硬件优先”原则。即在只粗略估计软件任务需求的情况下，首先进行硬件设计与实现。然后，在此硬件平台之上，再进行软件设计。因而很难达到充分利用硬件软件资源，取得最佳性能的效果。同时，一旦在测试时发现问题，需要对设计进行修改时，整个设计流程将重新进行，对成本和设计周期的影响很大。这种传统的设计方法只能改善硬件/软件各自的性能，在有限的设计空间不可能对系统做出较好的性能综合优化，在很大程度上依赖于设计者的经验和反复实验。

第二阶段：90年代以来随着电子系统功能的日益强大和微型化，系统设计所涉及的问题越来越多，难度也越来越大。同时硬件和软件也不再是截然分开的两个概念，而是紧密结合、相互影响的。因而出现了软硬件协同（codesign）设计方法，即使用统一的方法和工具对软硬件，协同设计软硬件体系结构，以最大限度地挖掘系统软硬件能力，避免由于独立设计软硬件体系结构而带来的种种弊病，得到高性能低代价的优化设计方案。

二、如何分析嵌入式软件的问题

1、分析日志文件

从log中寻找异常提示，是应对不可重复性、偶发性故障最基本的手段。在系统某处发生异常时，一定会在log中留下蛛丝马迹，可以请客户协助提供串口日志，在log文件中查找问题。或者设备自己内部记录log，但嵌入式设备由于存储空间的限制，可能先前过于久远的信息，就会被新的信息被覆盖，针对这种情况，就需要定期清除无效日志。有些异常会导致系统重启，而重启之后，就会导致异常信息被正常重启的信息覆盖，这就需要系统能够支持log的备份。不管怎么样，log为定位现场问题提供了最基本的、最主要的信息来源。一个完善的log机制，对于定位现场问题非常有帮助。如果不满足，可能首要任务是先完善日志功能。

2、回退软件版本，紧急消除现场问题

有些现场问题，虽然偶发事件，但发生后影响严重，客户无法接受。针对这种情况，在解决问题之前，可以先把软件降级，降级到相对稳定，没有严重故障的版本。

3、比较相邻版本之间的代码改动

如果不容易复现的故障，确认在升级了某个软件版本之后才出现的，而其他现场条件都没有变化，且分析log也无法发现异常点。此时，一种高效的解决此问题的方法，就是比较两个版本之间的代码的改动。

代码改动比较少，分析代码比较容易；如果代码改动比较多，就需要根据用户描述的现象，结合前后代码的改动模块，初步分析最可能是哪个模块引起的，这种往往需要对系统架构较深刻的理解。在众多修改模块中，分析最有可能关联的代码模块的改动，然后逐一排查 。分析代码的改动与出现的现象之间可能的关联关系，对开发人员个人的技术素养和方法论有较高的要求 。比较相邻版本之间的代码改动，针对某些棘手的现场问题，有时候确实是一个非常有效的手段。

4、问题复现

虽然常规来说现场很难复现，但可以人为的修改软件、构建或增加模拟数据，人为创造或触发条件，增加故障复现的几率。在设计触发条件时，需要围绕用户描述的现场故障现象来设计触发条件，观察是否能否复现，且表现一致。

5、分析代码

根据用户描述的现象，硬分析代码，是一种通用的方法，放之四海皆准的方法，熟悉自身代码的逻辑关系是基本功，但解决问题的效率就比较难把握了。

6、增加 log 更新版本继续测

如果常规的log无法展现故障的异常，就需要在猜测有可能的部分增加日志，在现场复测。但这种日志添加的位置是否合理，决定了问题再次出现时是否能定位问题的准确性。这种方法在工程实践中，实施难度大，需要客户多次配合。

以上便是此次带来的嵌入式软件相关内容，通过本文，希望大家对嵌入式软件已经具备一定的了解。如果你喜欢本文，不妨持续关注我们网站哦，将于后期带来更多精彩内容。最后，十分感谢大家的阅读，have a nice day!