Linux上位机开发实践（开源框架和开源算法）

【 声明：版权所有，欢迎转载，请勿用于商业用途。 联系信箱：feixiaoxing @163.com】

        做嵌入式软件开发，如果软件本身比较简单，只是图形界面显示，那么相关的开发工作并不难。最主要的内容也就是数据通讯和协议分析，这类软件一般涉及不到开源方案。此时需要做的，就是做一个软件界面，设计一个交互逻辑，拿到对方的协议数据，做一个展示、分析或者记录即可。这方面，即使没有现成的软件模板，写起来也不会很复杂。

        还有一类软件，开发工作较多，涉及到界面、算法、通信、保存和运动控制。那么这类软件大概率除了业务部分，还要使用到大量的开源框架、开源算法，这个时候应该怎么处理呢。

1、开源框架能用则用

        很多应用都有约定俗成的框架。比如图像使用opencv，界面使用qt，跨平台第三方库使用boost，视频编解码使用ffmpeg，web服务器使用nginx，机器人用ros，这些都是常规的做法。这些框架，你可以用，我也可以用，而且本身可以极大地降低开发难度，提高开发效率，所以大家在进行业务开发的时候，一定要多用、尽快的用，不要总想着从0到1造轮子。

2、开源算法可以用，但是要改进

        除了框架之外，还有很多的算法其实也是可以使用的。以opencv为例，里面除了常规的设备io访问，图片之间的转换，另外还有很多的图像算法可以使用。这类算法可以直接使用，但是有的时候效果未必那么好。因为本身算法是为通用场景准备，不会考虑硬件、业务、加速和性能优化这些差异性，所以很多时候这些算法都需要做二次开发、优化后，才能部署到客户那里。

3、开源框架和芯片sdk进行对接

        前面说到，很多开源框架中的算法，都是针对一般场景进行开发的，往往没有考虑到客户的特殊需求。以编解码为例，很多时候，开源框架提供的算法都是软件编解码方案，这些方案跑在x86电脑上面没有问题，因为本身电脑的性能就足够好，cpu频率足够高。但是在嵌入式平台上面，我们就要想办法用芯片自身的sdk，来代替原来框架中编解码的操作，这样才能够达到事半功倍的效果。否则还是按照原来软件实现的做法去实施，恐怕最终的结果只会差强人意。

4、好的数据比算法还要重要

        很多同学进行嵌入式项目开发的时候，容易陷入一个迷思，就是过度关注算法的某个单一指标。或者是，习惯于用复杂的算法来解决一般的问题。殊不知很多时候，我们可以通过提高传感器的数据精度，或者添加先验知识，就可以大大降低算法处理的难度。激光是这样，图像是这样，声音也是这样。所以，很多时候，我们自己要学会变通，尝试通过各种办法来解决工程问题。

5、用组合去解决问题，而不是盲目提高硬件水平

        好的硬件就意味着高的价格，物料的选择面也会变少。比如说，很多时候mcu就是根据io数量和flash大小来定价的。而soc中，频率高的cpu、性能高的cpu、资源多的芯片就是价格高。比如有一种场景，我们需要频率一般的soc，但是io要非常多。这个时候用高端soc，其实并不合算。一种比较好的这种方法，就是soc+mcu的方案。不仅降低了成本，还增加了soc的选择面。

6、鲁棒、性能和成本

        既然是嵌入式设备，那么除了硬件之外，剩下来就是用软件去满足客户要求。开源框架、开源算法都可以使用，但是通常都要魔改。而且在移植的过程当中注意鲁棒性、性能、以及最终的成本。东西是要卖出去的，所以成本要足够低；功能方面即使是用开源代码做的，也要魔改得非常稳定；性能方面的话，肯定是越高越好，这样才能在市场中有一定的竞争力。

        所以，不管是厂家的sdk，还是开源linux、开源框架或者开源算法，本质都是为业务、为产品服务的。这中间人的价值，就是不断地去降低成本、提高稳定性，同时完成资源整合。谁能够做的最好，谁就可以笑到最后。

7、创造性的方案更有价值

        很多时候，做产品不能人云亦云，那样反而没有自己的特色，也不容易出彩。所以，要跳出原来的思维怪圈，用低成本+高效率，去实现别人高成本方案一样的效果。或者是，A领域成熟的方案，用在B领域，也是可以的。很多时候，作为后来者，在他进入新领域的时候，总是需要想一些自己的怪招、妙招，才能够达到出奇制胜的效果，过分循规蹈矩往往会适得其反。