一个软件工程师的软硬件协同开发应对经验浅谈

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

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

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

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

1 不要编写HAL，要生成它！

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

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

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

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

2 集成自己最喜欢的IDE

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

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

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

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

如果想要满足这一要求，一个办法就是要能够将项目从一个工具导出到另一个工具。举例来说，赛普拉斯的PSoC Creator能够将PSoC设计直接导入到Keil μVision工具中。在许多可编程系统中，“硬件”事实上是作为数据块提供，能在启动时被编程到器件中，以创建配置好的器件。对于软件而言，它仅仅是数据，因此导出设计只需硬件工具为目标产品生成项目文件，再用HAL源文件和初始化代码植入即可。应用随后就能在硬件顶层上进行构建，而且不会干扰现代化环境中使用的自动化测试和源控制系统。

图2：PSoC Creator的“IDE 导出”GUI。本对话框用来创建和更新用于应用开发的Keil μVision项目。

当然，对于动态的硬件平台而言，一次性导出不是完整的解决方案，还必须提供无缝更新设计的特性，而且不会破坏应用。对于支持库的IDE来说，更新过程很简单，因为设计可被拆分为应用项目和配置库，这就能将应用完全隔离开来，而且能让包含配置数据和HAL的硬件库在设计变化时自动更新。

图3：以上导出的系统控制器项目在Keil μVision中打开，可用于应用开发。

3 超越软件范畴的调试

设计人员所需的第三个特性就是改进调试。在现代化器件中，“处理器”的定义不仅限于CPU的寄存器和指令集。处理器芯片集成了各种额外的片上功能，比如说常见的通信模块和标准接口，此外还包括无所不在的定时器和计数器，以及为软件提供数字接口的模拟功能，有时也包括定制逻辑和可切换的路由功能等。这种可定制性说到底正是我们最初选择协同设计的原因所在。调试器如果只支持CPU，就会让软件开发人员非常失望。我们需要围绕硬件认真解决以下问题：硬件启动了吗？时钟启动并稳定了吗？外设在正常工作吗？通信模块是否生成中断？能否发送和接收数据？能否在内部总线上正常工作？

如果这听起来就够吓人的话，我还没说到从调试器改变硬件呢，这其实是让人的角色在迫害者和受害者之间转变。我需要符号化外设硬件的存取方式，这样我就能监控和控制影响应用的状态变化。

当然，符号信息必须从硬件工具中生成，就好像上述HAL一样。通过简单添加这一点，调试过程就变得更加简单，功能也更加强大了。之所以说更简单，是因为我们不再需要一直查询文档去寻找并确认调试器中要注意哪些关键寄存器的地址了。而之所以说更强大，是因为现在它能支持更为复杂的调试。除了快速获得外设模块状态快照之外，有时我们还能从调试器控制功能块，无需编写代码以编程方式重建情境就能了解情境工作的具体情况。

交换此信息的典型方法就是让IDE使用由硬件工具生成的XML文件。ARM CMSIS-SVD（软件接口标准——系统视图描述）标准就是一个很好的例子。它是基于XML的硬件描述，旨在让调试器支持高度集成的微控制器。CMSIS是一种面向ARM Cortex微控制器的HAL的标准定义，得到了众多厂商的广泛采用。SVD扩展主要针对硬件描述，如寄存器、存储器、外设等，让从事可编程系统开发的人员真正地大获裨益。

图4：这是一小段XML，介绍了赛普拉斯PSoC Creator调试器有关CAN实施中一个寄存器的情况。CAN_CSR_ERR_SR寄存器的地址、大小和描述均已定义，在寄存器中有5个字段，定义了名称、大小和存取权限。

共享硬件定义的一个重要因素就是能够定义外设寄存器，进而言之，则能提供面向寄存器中字段的存取权限，从而确保调试器认真对待读/写可修改的位。硬件给我们提供clear-on-read位和zero-to-toggle位以及各种其它晶体管能够感应但是软件很难应付的状态处理接口。只有对硬件进行良好的机器生成定义，我们才能保证用户在外设模块上调试寄存器或个别位时不至于浪费时间，或导致意外结果。

有了可编程硬件的高级视图，我们不仅能检查状态寄存器和错误状态，还能实现更多功能。举例来说，如果硬件支持寄存器控制的开关，能实现外设I/O到器件引脚的灵活路由，那么软件开发人员就能从调试器操控器件的内部布线！有些人听到这里可能感觉有些吓人，不过如果SVD信息正确生成，那么我们就能限制允许的变化，确保“安全的”编辑，比如说数字信号上的多路复用器通道选择或两个物理引脚之间的模拟输入切换。

硬件工具为软件开发人员生成调试信息，有望显著缩短应用开发时间。不仅如此，重要的是，我们还有机会在早期检测出硬件设计错误，因为软件开发人员发现混乱和代码重写的不正常情况下更有可能发现意料之外的行为。

面向可编程器件的完整产品

现在，“完整产品”的概念已得到充分地理解和广泛地接受，也成了成功的重要因素。只有最佳的工具或最出色的芯片已经不够了。我们今天使用的可编程解决方案形式多样：可能是全定制的ASIC，其在高度专业化的解决方案中集成了ARM内核和多个IP模块；也可能是更加通用的平台，其集成了可编程芯片和设计工具，诸如Altera和赛灵思推出的FPGA解决方案，或赛普拉斯半导体公司推出的PSoC器件等。虽然这些环境千差万别，但都面临着同样的问题——不能将硬件修改有效地迁移到软件领域，从而影响应用开发。

我认为，这个问题的根源在于项目中使用的硬件设计工具和IDE采用了狭隘的方法。像我这样的软件狂人（开玩笑）总喜欢把所有问题都归咎于硬件工具和工程师，但事实上硬件工具和软件工具集都太过偏向于他们特定的领域了。很难见到二者添加了我以上提到的特性，因为这些特性跟其各自的客户好像没什么关系。我相信这种局面正在发生变化，PSoC Creator等产品支持在可编程硬件上进行器件配置同时还集成第三方IDE（如ARM的Keil μVision IDE）的工具会不断发展。在工程师首选的IDE中实现应用开发，同时让工具获得独有的强大信息并控制硬件平台，这显然是更高效进行产品开发、加速产品上市进程的必由之路。与此同时，减少对工程师的折磨也不失为一件大好事！