关于驱动程序设计的5个小技巧

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

提示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外设处于故障状态，并且需要清除隐藏在混淆寄存器中的单个位。

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

更进一步

驱动程序设计和实现是嵌入式系统开发的关键组件。为了进一步探索驱动程序设计模式以及如何构建可以访问互联网的嵌入式系统，请考虑参加我在EDN姊妹刊物 Design News 上关于“设计模式和互联网”的下一个CEC课程。 2015年10月19日这一周。我们将在STM32上介绍I2C设备的驱动程序设计，并使用Electric Imp创建一个连接互联网的气象站。