这是zui奇怪的问题之一。该系统似乎在按预期工作，但遥测数据表明情况并非如此。决定电机转速的“按需输入”为 85%，但幸运的是，电机并没有转起来。我很想挥挥手说这没什么大不了的，或者说这是遥测分析软件的问题，但有些地方不太对劲。现在应该好好研究一下了，进行全系统检查，找到问题原因。

　　这个特殊的系统使用的是 Allegro Microsystems A4964 无刷直流 (BLDC) 电机。我越来越喜欢这个芯片，因为它是一种灵活的电机驱动解决方案，而且把所有可能占用 CPU 周期的控制代码从 () 移走，由专门的硬件芯片执行（图 1）。

　　图 1：A4964 很有用，因为它将无刷直流电机的控制功能从 MCU 迁移至专用硬件。（图片 Microsystems）

　　在这个系统配置中，我利用 SPI 通信接口来设置 32 个片上寄存器，这些寄存器将决定 BLDC 电机的驱动和控制方式。

　　对于该应用，A4964 在安装过程中由初始化程序读取包含所需电机配置参数的配置表完成其配置。伪码（此处仅用于举例）如下所示（列表 1）。

　　副本

　　for(uint8_t WriteIndex = 0; WriteIndex < A4964MaxRegister; WriteIndex  )

　　{

　　// Write value stored in A4964Config at index WriteIndex to the chip

　　}

　　列表 1：所示为读取电机配置参数的初始化程序。（代码 Beningo）

　　从初始化角度来看，这段代码没有什么问题，所以我很快决定检查该应用中经常被调用的主要逻辑。这段代码有点儿意思。该应用所处的环境中存在大量辐射，这可能会影响 RAM 中存储的值。初始化值在启动时被写入 A4964 的 RAM 中，所以为了迅速克服可能发生的“位翻转”，A4964 的被定期读取：如果出现不匹配，则会更新设置。伪代码如下（列表 2）：

　　副本

　　for(uint8_t Index = 0; Index < A4964MaxRegister; Index  )

　　{

　　// Read the A4964 configuration register at location Index

　　// If read value does not match expected value, write configuration value

　　}

　　列表 2：本地辐射可能会影响存储在 RAM 中的值，因此为了应对“位翻转”，A4964 的内存会被定期读取，如果出现不匹配，则更新设置。（代码 Beningo）

　　又出现类似情况，代码非常简单，不可能出错，但芯片中莫名其妙地被写入了不正确的需求输入值。这个值似乎是短暂存在的，在正确值之前，该值在一些遥测值中出现，然后又yi次提供了错误的值。真令人费解！

　　更为有趣的是，没有任何配置值或应用值可以将 85% 的值写入寄存器！那么，这个 85% 的值到底是从哪里来的呢？十进制 85 转换成十六进制时为 0x55。在代码库中有出现 0x55 的地方吗？当然有。0x55 被用作 SPI 上读操作的虚设写字符！但是，读操作是如何被转换为写操作的呢？

　　事实证明，只要我们仔细观察 A4964 的规格书（图 2），答案就非常明显。

　　图 2：数据手册中的一个片段显示了这个问题。寄存器 30 的特点是只写！（图片 Microsystems）

　　寄存器 30 管理电机的“按需输入 (DI)”，是只写寄存器！尝试从该寄存器中读出数据，会导致向该寄存器中写入虚字节！简单的初始化和芯片刷新功能尝试从“按需驶入”寄存器中读取以验证设置，并在无意中写入了一个新的“按需输入”值。系统继续按预期工作，因为对写寄存器的读取操作总是导致随后会写入正确的值，但并不总是足够快，所以错误值没有出现在系统遥测值中。

　　对于 A4964，软件开发者不应在整个内存图中写入配置数据，而是需要在写入寄存器 29 之后停止。zui后两个可寻址的寄存器是特殊的写和只读寄存器。

　　有时，不管我们为正确编写驱动程序或实施软件付出了多少努力，总会有一些奇奇怪怪的问题。奇怪的问题往往是一个学习有关硬件新知识的机会，而且总会形成新的zui佳实践。就是由于这个奇怪的问题，我把“仔细观察只读/只写寄存器”添加到我的列表中，并确保我正确理解、使用这些寄存器。否则，读取那个只写寄存器可能会给系统带来生灾难性后果。