硬件驱动程序(硬件驱动程序属于系统软件吗)

　　每个嵌入式软件应用程序都必须在某个时候访问最低级别的固件并控制硬件。驱动程序的设计和实现对于确保系统能够满足其实时要求至关重要。下面是每个嵌入式开发人员在设计驱动程序时应该考虑的五个技巧。

　　技巧1——使用设计模式

　　设计模式是对软件中重复出现的问题的解决方案。开发人员可能会从零开始重新发明解决方案，浪费宝贵的时间和预算，或者可以打开他的解决方案工具箱，选择最适合问题的解决方案。自微处理器诞生以来，低级驱动程序就一直存在，并且是一个众所周知的问题。那么为什么不利用现有的解决方案呢?

　　驱动程序设计模式通常分为四类:位爆炸、轮询、中断驱动和直接存储器访问(DMA)。当微控制器没有执行该功能的内部外设，或者当所有这些内部外设都已用完而需要另外一个时，开发人员选择位爆炸模式。位爆炸解决方案可能是有效的，但是通常需要相当数量的软件开销来实现该能力。bit bang模式实际上是让嵌入式开发人员手动实现一个通信协议或外部行为。

　　轮询模式只是以循环方式监视事件。轮询模式对于简单的系统是很好的，但是许多现代应用程序需要中断。中断提供了在事件发生时立即处理事件的能力，而不是等待代码来手动检查事件。DMA模式允许另一个外设处理数据传输需求，并让驱动程序无需干预。

　　技巧2——了解实时行为

　　实时系统满足截止日期的能力始于它的驱动程序。写得不好的驱动程序将是低效的，并为毫无戒心的嵌入式开发人员提供了损害其系统性能的可能性。驱动程序有两种风格，设计师应该考虑;阻塞和非阻塞。阻塞驱动程序阻止任何其他软件执行，直到驱动程序完成其工作。例如，USART驱动程序可能会将一个字符放入发送缓冲区，并在继续发送之前等待发送结束标志，而不是继续发送。

　　另一方面，非阻塞驱动程序通常利用中断来执行它的功能。使用中断可以防止驱动程序在等待事件发生时阻止软件执行。USART驱动程序可能会将一个字符放入发送缓冲区，但主软件会继续执行下一条指令。传输结束标志的设置会触发一个中断，允许驱动程序采取下一个操作。

　　无论何种类型，为了保持实时性能并帮助防止系统故障，嵌入式开发人员必须了解他们的驱动程序的平均和最坏情况下的执行时间。系统的完整性潜在地处于危险之中，如果系统是安全关键的，可能更危险。

　　技巧3——面向重用的设计

　　时间和预算都很紧张，为什么要重新发明轮子呢?重用、可移植性和可维护性是驱动程序设计中的关键要求。这些特性中的许多可以通过硬件抽象层的设计和使用来说明。

　　硬件抽象层(HAL)为开发人员提供了一种创建标准接口来控制微控制器外设的方法。抽象隐藏了实现细节，而是提供了可见的功能，例如Usart_Init和Usart_Transmit。其理念是任何USART、SPI、PWM或其它外设都具有所有微控制器都支持的共同特性。HAL的使用隐藏了低级的、设备特定的细节，允许应用程序开发者关注应用程序需求，而不是低级硬件如何工作。同时，HAL提供了一个可重用的容器。

　　技巧4——请参考数据手册

　　在过去的几年里，微控制器变得有点复杂。曾几何时，人们可能想了解的关于微控制器的一切都包含在一张约500页的数据手册中。如今的32位微控制器除了所有的勘误表之外，通常还包含由器件数据手册、系列数据手册和每个外设的数百页数据手册。如果嵌入式开发人员真的想完全理解该部分，他们需要阅读几千页的文档。

　　不幸的是，要真正正确地实现一个驱动程序，所有这些数据表都是必需的。一开始，开发人员应该收集和整理每个数据表以及其中包含的信息。通常需要咨询他们中的每一个人才能启动并运行外设。关键信息分散(和隐藏)在每种类型的数据表中。

　　技巧5——小心外围故障

　　将一些驱动程序从一个系列的微控制器移植到另一个系列。制造商和数据手册都暗示这两个系列的PWM外设是相同的。另一方面，运行PWM驱动器表明，尽管如此，两者之间还是有很大不同。驱动程序处理的是原来的零件，而不是新零件。仔细查看数据手册后，才发现一个完全不相关的数据手册中有一个脚注，称PWM外设在上电时处于故障状态，隐藏在模糊寄存器中的一个位需要清零。

　　在开始实施驱动程序时，识别外设故障和任何看似无关的故障寄存器。

　　总结

　　驱动程序的设计和实现是嵌入式系统开发的重要组成部分。进一步探索驱动程序设计模式以及如何构建可以访问互联网的嵌入式系统对嵌入式开发人员来说非常重要。