对于嵌入式来说，嵌入式应用软件都会在特定时候访问底层固件和进行硬件控制，嵌入式驱动程序的设计是满足嵌入式系统最关键的一步，学习嵌入式对嵌入式驱动程序设计是比较关键的，那么如何学嵌入式驱动程序设计成为了关键，在这里业界大牛总结了一些嵌入式驱动程序设计的小窍门，对学习嵌入式驱动程序设计还是老有用了。

首先就是我们在做嵌入式驱动程序设计使用设计模式时，在这里有一个注意的点，认真看哦：

对于设计模式来说，设计模型就是一个用来处理那些在软件中会重复出现的问题的解决方案。 开发人员可以选择浪费宝贵的时间和预算从无到有地重新发明一个解决方案，也可以从他的解决方案工具箱中选择一个最适合解决这个问题的方案。在微处理器出现之初，底层驱动已经很成熟了，那么，为什么不利用现有的成熟的解决方案呢?

在这里就有一个小技巧咯，驱动程序设计模式大致分属以下4个类别：Bit bang、轮询、中断驱动和直接存储器访问(DMA)。

Bit bang模式：当微控制器没有内外设去执行功能的时候，或者当所有的内外设都已经被使用了，而此时又有一个新的请求，那么开发者就应该选择Bit bang设计模式。Bit bang模式的解决方案很有效率，但通常需要大量的软件开销来确保其实施的能力。Bit bang模式可以让开发者手动完成通信协议或外部行为。

轮询模式用于简单地监视一个轮询调度方式中的事件。轮询模式适用于非常简单的系统，但许多现代应用程序都需要中断。

中断可以让开发者在事件发生时进行处理，而不用等代码手动检查。

DMA(直接存储器访问)模式允许其它外围设备来处理数据传输的需求，而不需要驱动的干预。

有现成的那么就可以利用现成的，这样又高效又快。

重用设计这个了解吗

当你在时间和预算都很紧张的时候，为什么还要再造轮子呢?在驱动程序开发中，驱动设计的关键的要求就是重用、便携性和可维护性，那告诉你一个方法就是，这些特征都可以通过硬件抽象层的设计和使用来说明。硬件抽象层(HAL)为开发人员提供一种方式来创建一个标准接口去控制微控制器的外设。抽象隐藏实现细节，取而代之的是提供了可视化功能，如 Usart_Init和Usart_Transmit。这个方法就是让任何USART、SPI、PWM或其他外设具备所有微控制器都支持的共同特点。她就相当于提供了一个容器。

再来一个小窍门就是了解实时行为

一个实时系统是否能满足实时需求取决于它的驱动程序。写入能力差的驱动是低效的，并可能使不知情的开发者放弃系统的性能。设计者需要考虑驱动的两个特点：阻塞和非阻塞。一个阻塞的驱动程序在其完成工作之前会阻止其他任何软件执行操作。例如，一个USART驱动程序可以把一个字符装入传输缓冲区，然后一直等到接收到传输结束标志符才继续执行下一步操作。

另一方面，非阻塞驱动则是一般利用中断来实现它的功能。中断的使用可以防止驱动程序在等待一个事件发生时拦截其他软件的执行操作。USART的驱动程序可以将一个字符装入传输缓冲区然后等主程序发布下一个指令。传输结束标志符的设置会导致中断结束，让驱动进行下一步操作。

无论哪种类型，为了保持实时性能，并防止系统中的故障，开发人员必须了解驱动的平均执行时间和最坏情况下的执行时间。一个完整的系统可能会因为一个潜在的风险而造成更大的安全问题。

这个就是需要动手了，翻翻参考数据手册

微控制器在过去的几年里变得越来越复杂。以前想要完全了解一个微控制器需要掌握由一个大约包含500页组成的单一数据手册。而如今，一个32位微控制器通常包含由部分的数据手册、整个微控制器系列的资料表、每个外设数以百计的资料以及所有的勘误表组成的数据手册。 开发人员如果想要完全掌握这部分的内容需要了解几千页的文件。

不幸的是，所有这些数据手册都是一个驱动程序能真正合理实现所需要的。开发人员在一开始就要对每个数据手册中包含的信息进行收集和排序。通常它们中的每一个都需要被访问以使外设启动和运行。 关键信息被分散(或隐藏)在每种类型的数据手册中。

谨防外设故障

最近我刚好有机会把一系列的微控制器驱动移植到其他的微处理器上。制造商和数据手册都表明PWM外设在这两个系列的微控制器之间是相同的。 然而，实际情况却是在运行PWM驱动器的时候两者之间有很大的不同。该驱动程序只能在原来的微控制器工作，而在新系列的微控制器上却无效。

在反复翻看数据手册之后，我在数据手册中一个完全不相关的注脚里发现了PWM外设上电时会处于故障状态，需要将一个隐藏在寄存器中的标志位清零。在驱动程序实现的开始，确认外设可能出现的故障并查看其他看似无关的寄存器错误。

这些都是在嵌入式驱动程序设计的小窍门，会让你更快速高效的来学习嵌入式驱动程序设计，这样你就不会在这个上面浪费更多的时间，又快又高效，这些小窍门学起来，对以后的各种嵌入式学习都是用帮助的哦。