软硬件协同开发的应对方案

从事嵌入式业务已有很多年时间了，但还是不清楚“协同开发”是否是指管理人员梦想实现超高效项目开发进度的一种方式，还是说对于软件开发人员而言是一种折磨。或许它只是意味着软件开发与硬件平台设计齐头并进吧。这除了意味着软件人员的苦难之外，真不清楚还意味着什么。

　　在嵌入式领域，经常要为正在设计中的电路板或芯片同时编写软件。有时是为Mentor Graphics或Cadence Design Systems等EDA厂商仿真环境中复杂的ASIC设计而编写软件。有时则是为Xilinx或Altera等公司功能强大的FPGA设计而编写软件。FPGA器件带有与标准和定制IP模块相连的嵌入式微处理器内核。还有的时候是为了可编程片上系统编写软件，这种可编程片上系统将可编程数字/模拟功能和微控制器完美集成在一起（如赛普拉斯的PSoC器件）。这些功能都非常强大，能实现难以置信的创新，但同时也会带来痛苦，那就是硬件可能随时发生变化，而软件开发人员则难以招架。

　　不是建议放慢创新步伐，而是说应该给软件工程师一个喘气的机会。但事实上刚好相反。硬件工具需要更好地与软件IDE集成在一起才能加速产品上市进程。而设计人员需要更多工具和方法让应用不受硬件变化的影响。不是说向设计中添加或从中移除主要的通信模块。如果您的真需要添加或移除主要通信模块，那么您的软件工程师真该找点别的事干了，因为这意味着硬件设计还根本没就位呢。这里说的变化都是设计周期较晚阶段对于已定义的功能模块进行的微小改变，比方说寄存器地址变动、比特位被重新定义、缓冲区大小改变等。这些“小变化”也会影响到软件，进而可能造成产品缺陷，甚至在忘记硬件变化原因时还要对软件进行长时间返工。

　　软件工程师，现在到了们奋起反击的时候了！以下给出了针对目标不断变化的情况如何灵活进行应用开发的三点建议。在开始新的项目之前，不要忘掉这些建议！

　　1、不要编写HAL,要生成它！

　　我们需要的第一个变化就是让硬件开发工具生成软件接口，也就是通常所说的硬件适配层（HAL）。HAL应包括能可靠地初始化可编程硬件的启动代码，并提供API接口以支持系统的软件控制。HAL不仅简化了固件开发，还能将实施从接口中抽象出来。这就意味着硬件的微小变化不会对固件造成影响。

　　中其实没什么新概念，许多经验丰富的设计人员已经明智指出，常量、函数和变量都应采用一致的、直观的命名规范。不过，对于FPGA、CPLD和PSoC等可编程器件而言，们还要将此规范进一步扩展，也就是HAL要由硬件设计工具生成，否则软件工程师怎么才能确保可靠的接口呢？

　　在固定或变化很少的环境中（比如说固定功能MCU或大规模ASIC项目），们可将HAL视为一套独立的API,可将其作为硬件设计变化的一部分进行修改。不过，对于现代化的可编程器件而言，硬件一天会变化好几次。手动HAL维护与当前情况根本不相匹配，肯定会在实施阶段出现错误，更别说要对软件工程师带来多大痛苦和折磨了！认为，HAL自动生成应为任何可编程平台的必备要求。

　　图1:PSoC Creator工作区域抓屏，其中们看到采用FanController模块和一对比较器（Comp_Hi）和（Comp_Lo）的系统控制器设计所用的API文件（HAL）。

　　2、集成自己最喜欢的

　　可编程器件为创新带来了巨大机遇，但往往设计硬件所需的工具会对正常软件开发实践造成影响。工程师往往不得不使用简单、功能欠佳的工具，而且不能与现有的流程很好地结合。

　　大多数协同设计环境都是从硬件设计工具演变而来，这些工具多年来一直支持ASIC和FPGA或CPLD流程。随着嵌入式CPU越来越普及，为工具产品组合添加软件开发功能的需求变得非常明显，这样，一种工具就能支持软硬件两个领域，但对两个领域各自而言又都不够理想。在此情况下，工程师就会在两个领域都会减少特性选择，甚至丧失特性选择。

　　解决方案不是让工具厂商提供业界领先的调试器，将其捆绑到硬件设计工具中，就宣布成功，然后奇怪软件工程师怎么还在不停地抱怨。为以硬件为中心的工具添加源代码编辑器并调试特性，这并不能真正解决问题，因为工具仍没有集成到用户的流程中。源控制接口、软件测试套件、自动化构建等是目前开发人员每天都要接触的工作，将硬件设计工具集成到他们的日常工作中才是真正的挑战。

　　正确的做法根本不是集成调试器、编辑器或整个IDE,而是要让软件开发人员从项目一开始就能在自己真正喜欢并使用的传统IDE开发环境中开展工作。硬件设计人员或许仍需要工具中的软件特性来创建并运行小型测试程序，但真正的应用开发应当始终在工程师首选的IDE中进行。

如果想要满