虚拟平台在嵌入式中的应用（转自雪松http://blog.csdn.net/coolbacon/archive/2011/04/11/6316403.aspx#1638545）

（转自雪松http://blog.csdn.net/coolbacon/archive/2011/04/11/6316403.aspx#1638545 ，鼓励看他的原帖）

 

虚拟平台原先就是一些老学究搞出来的东西，为了在一些大型机上，大家都想使用大 型机而又相互不干扰。于是提出的虚拟机的概念，这使得每个人独立操作而互不干扰。但当时60、70年代，个人电脑还不足以支撑软件虚拟环境，所以一度被搁 置。后来到了90年代后期再度进入人们的实现。

90年代SUN公司弄出的Java虚拟机以及 vmware 虚拟机，都是市场的佼佼者。Java是一次编译到处运行，实在是轻松，怪不得Java的标志是一杯咖啡，大家活都很快干完了，去喝咖啡去 了……vmware虚拟机，据说发明人发现服务器真实的硬件利用率总是很低，那么通过虚拟化技术将一台计算机变成N台计算机，真是太爽了，不需要多投入一 分硬件的钱，却可以得到很多硬件才能实现的功能。通过这种方式提高资源的利用率。同时，这也带来了许多附加的好处，比如说服务器的硬件损坏了，把硬盘抽出 来，虚拟机拷贝出来，又可以在别的机器上运行了。虚拟机可以通过交换机与真实的计算机通信，也可以经过地址转换与真实的机器通信。灵活的方式让企业个人随 心所欲的定制服务器，达到最佳的效果。

以上都是虚拟机在企业级的运用，在嵌入式领域，虚拟机也是大显身手。比如说我喜欢搞RTEMS，但RTEMS的开发环境是GNU的工具链，在 windows下，GNU的工具链运转效率明显没有Linux高。平时我使用的大部分工具和沟通工具都是基于windows的，为了解决这个矛盾，装个虚 拟机，将linux运行在windows之上，啥问题都解决了。

下面我们就来看看嵌入式领域虚拟机的应用。首先在项目的需求收集阶段，客户表述的需求既不专业也不具体，对后续的工作缺乏具体的指导意义。特别是客户可能 和做产品的人横跨两个大的行业，沟通非常成问题。这时，我们可以利用一些系统原型和客户沟通，既减少了沟通成本，也降低了后续项目实施的风险。然而，嵌入 式系统不像PC系统，往往需要特殊的硬件支撑，没有特殊的硬件，原型从何谈起？虚拟的应用一下子让这种看似不可能的事情变得可能。什么样的项目需要这么做 呢？最常见的莫过于操作界面了。然而操作界面大多可以更改API直接在PC系统上跑，可以不用虚拟的。当然，我不反对这样去做，但是，通过虚拟技术，界面 更加接近实际，比PC机接近实际。同时这些所作的成果项目实施的中后期也能用到。就看您如何权衡了。

在项目的设计阶段，可能需要确认技术解决方案的有效性。如系统的内存和ROM的用量，算法的时间是否满足要求等。通常的做法是采用公板跑测试代码，而公板 的价格不菲，且是稀缺资源。把它伺候起来，还需要更加不菲的更加昂贵的调试器帮助。这套弄下来，不说玩起来，资源配置就是个大问题。如果采用虚拟技术，硬 件还是那个硬件，在虚拟系统上跑起来后。像算法的时间能准确的给出是多少个系统时钟脉冲，比实际测得的时间可能更具有意义。可帮助系统工程师确认先期的技 术解决方案,减少前期的资源投入。

在项目的实施阶段，嵌入式最突出的风险就是硬件和软件同时成熟，往往，这两者的平衡我想是许多嵌入式项目经理最头疼的问题。合理的使用虚拟技术，可以大幅 度的削弱这个风险，并且提高项目最终交付的质量。在项目实施的初期，只能开发一些高层的应用程序，这些应用程序调用的系统接口和驱动使用桩函数替代。待到 中后期，硬件出来以后，系统编码人员将驱动和操作系统调试通过后，应用程序开发人员再移植到具体的硬件平台上。紧接着就是疯狂的加班，然后解决Bug。嵌 入式系统的实施人员往往有这种感触，嵌入式项目开发越到后期，加班越是疯狂，丝毫享受不到创造的快乐……如果使用虚拟技术，使得一开始系统编码人员就可以 开发硬件的驱动，有这充分的时间调试，应用程序编码人员也不需要用桩函数替代系统或驱动调用。相当部分的工作，软件和硬件能同时工作，相互不依赖。虚化可 以很好替代真实的硬件工作，且人手一套，实在是方便。硬件开发往往含有较多的不可并行的过程，如绘制PCB，加工PCB、贴板，调试样机等。这些过程往往 都是串行过程，即使添加一倍的人力，也不能将交付期缩短。如果硬件出了问题，对嵌入式整个项目的影响是非常大的。同时也必须看到，虚化技术并不能解决项目 中的全部问题，特别是硬件中含有许多特别的不能虚化的硬件，如AD等。对于这种硬件中的问题，大部分还是采取桩函数的办法，能将真实硬件上的80%的代码 跑起来，可以说虚化的已经很不错了。

在项目实施阶段，对代码的单元测试也是非常重要的，单元测试的测试用例设计有很 多方法，如边界值、临界值等，无论什么办法，有一个硬性的评估指标，那就是代码的覆盖率。只要能到 100%,且测试用例都能通过，那么自然开发人员自然来得有信心。交付的时候也有底气。然而嵌入式系统的单元测试如果在具体的硬件上实现的话，费事费力， 效果不好。因为如果看到覆盖率，必然要跟踪代码的执行，需要非常昂贵的调试跟踪设备。代码在跟踪过程中，也很难实现100%的性能，也会使得代码运行不正 常。在虚拟平台上这似乎太简单了，如qemu只需要带一个参数，就会将覆盖率导出。基本上没有什么性能的损失，非常方便。在后期的集成测试当中，如果没有 足够的样机，可以适当的对虚化做一些扩展，做一些虚拟化的测试。可以大批量的复制，以验证系统的稳定性和可靠性。可与真实的硬件跑出来的效果做对比，更利 于问题的准确定位。特别的，在PC机上做虚拟，对于有界面的嵌入式系统，可以使用一些自动化的测试软件在PC机上反复的操作，节省大量的测试人力物力。如 果拿实际的硬件，你点击文件菜单1000次，测试系统的行为。这个工作量对任何人来说都是难以想象的。

在项目维护和交付阶段，虚化可以用来训练系统维护人员，特别一些贵重的系统，样 机可能公司里也没有，培训售后人员只能是纸上谈兵了；同时系统出了问题，客户反馈来，软件工程师没有样机调试，只能到现场去调试了，那是多么痛苦的事情 啊。虚拟系统是最好的救命稻草了，维护人员可以随便捯饬虚拟系统，寻找感觉。软件开发人员可以先在虚拟系统上解决了，然后再到客户那里一次性解决，既增强 客户和研发人员的信心，也树立了良好的企业形象。

以上我们讨论的是虚化在嵌入式开发的整个过程中的应用。其实虚化在嵌入式市场里也大有作为。现在的智能手机，很多都是两个操作系统够成的。如著名的 Android系统，一个是RTOS，一个是linux。两个操作系统必然要两个CPU。对于开发者来讲，这样无疑大幅度的增加了开发成本，因为技术要求 高了。虚拟技术的应用，大幅度的减小了这个技术难度。将一个CPU虚拟成两个，一个跑RTOS，一个跑linux，哈，完美。移植只需要移植底层的虚拟系 统，rtos和linux都不需要移植了。开发工作者只专注：虚拟系统的移植和UI交互。这个市场是相当广泛的，如OKL4、Hypervisor都是这 样的产品。

本文随便聊聊，旨在推广rickleaf的emboslab项目，这实在是一件利国利民利己的好事。有志者都来参加吧，我们需要优秀的你!