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

时间:2020-12-17 21:09:23

(转自雪松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项目,这实在是一件利国利民利己的好事。有志者都来参加吧,我们需要优秀的你!