STM32F103 硬件SPI驱动DAC8563

目录

程序目的

展开设计

SPI初始化

DAC8563数据手册分析

设定DAC值

存在问题

软件IO模拟正常

硬件SPI向软件模拟IO靠拢

尝试解决

调整硬件SPI速率

CS引脚不得常低

调整CS引脚与MOSI引脚的时序

调试总结

工欲善其事必先利其器

站在巨人的肩膀上,事半功倍


程序目的

使用STM32F103RCT6芯片驱动DAC8563芯片,采用硬件SPI驱动DAC芯片,输出所需的电压值。STM32使用SPI2,引脚IO PB13/14/15,DAC856是16位DAC芯片,需要发送16位(2个字节)来控制输出DAC数值。

展开设计

SPI初始化

DAC8563数据手册分析

建议重视DAC8563的数据手册,重点是下图中红色框线内的命令,我们此时需要的命令只有两条:0x18 设定通道A的DAC值,0x19设定通道B的DAC值。命令的格式是:CMD+VALUE_H+VALUE_L,先发送命令字节,再发送16位DAC值的高8位,最后发送16位DAC值的低8位。3个字节中,命令占1个字节,数据占2个字节。

存在问题

软件IO模拟正常

使用硬件SPI发送函数向DAC8563发送命令,DAC芯片无输出;由于怀疑DAC8563芯片损坏,需要先验证DAC芯片可用。故使用软件IO模拟SPI的方式发送命令,DAC芯片可以正确输出,由此判断DAC8563并未损坏。

硬件SPI向软件模拟IO靠拢

1、在确保DAC8563正常后,使用示波器观察SPI2的SCK/MOSI引脚,有波形发出,CS引脚拉低,由此确定SPI2硬件启动了发送。

2、确认了SPI2可用后,SPI通信需要定义空闲是SCK电平状态,即SPI参数配置的SPI_CPOL的值。软件SPI的SCK引脚在无数据发送时是低电平,所以我们配置为SPI_CPOL_Low。另一个需要注意的参数是边沿触发设置,一个是第一个时钟跳变沿触发SPI_CPHA_1Edge,另一个是第二个时钟跳变沿触发SPI_CPHA_2Edge。但测试发送,二者对最终的结果影响不大。

3、软件SPI发送先发高位,再发低位,所以硬件SPI配置为大端模式,即SPI_FirstBit_MSB

尝试解决

经过上述调整,DAC8563仍未正常工作。笔者不得不尝试其他方式以期望解决问题。

调整硬件SPI速率

怀疑SPI速率过高或过低,DAC8563无法正常工作,通过调整SPI的分频系数调整SPI速率,排除速率影响。

CS引脚不得常低

软件IO方式模拟SPI的CS引脚当且仅当有数据发送需求时才拉低,而硬件方式CS引脚常低,调整程度,使用命令单独控制CS引脚在发送数据时拉低,在数据发送完毕后再拉高。

调整CS引脚与MOSI引脚的时序

尝试了几个小时后,突然发现软件IO模拟SPI的程序里,CS引脚拉低后,增加了一段us级延时;但是使用硬件SPI并没有延时,会不会问题就出在这里呢?功夫不负有心人,加上这个延时后,DAC8563正常工作了,笔者如释重负。实践出真知,对于SPI通信,数据传输的前后,CS引脚都需要拉低延时一会儿。

那么,这个延时必然是影响了SPI通信的时序,故而这个延时不仅要有,而且要恰到好处,不可过短,不可过长,经过我测试发现,延时的us数与SPI的分频系数保持一致即可。例如分频系数是4,那么延时4us即可保证SPI正常通信。

调试总结

工欲善其事必先利其器

如果没有示波器,很难通过波形分析问题。对于SPI/I2C等波形协议的项目,示波器是必不可少的。

站在巨人的肩膀上,事半功倍

此次调试中,硬件SPI不可用但是软件IO模SPI正常的情况下,我们采用硬件设置向软件靠拢的方式,不失为解决问题的一个好的方法。这种比葫芦画瓢的方式,其实就是对照法,目的是2个:1、定位问题,确保DAC芯片是可用的,那么硬件SPI方式驱动不成功的话问题就出在软件上;2、排查问题,使用示波器,一步步分析软件IO模拟方式与硬件SPI的差异,等到差异消除了,二者一致了,自然问题就解决了。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 成长之路 设计师:Amelia_0503 返回首页