记录:STM32F407 SPI 驱动MS5611
发布网友
发布时间：2024-10-02 03:42
共1个回答
热心网友
时间：2024-10-07 20:42
通过使用HAL库，成功实现了对MS5611的驱动，获取到了PROM值。
然而，当尝试使用固件库时，遇到了问题，未能成功驱动。尽管按照手册中的时序编写代码，并在Debug中观察到数据，但数据的存储出现了问题。在接收24位数据时，SPI接口*为8位，因此定义了byte[3]来存储数据。在Debug断点观察下，发现byte[0]的值与HAL库相同，为0xFE，而byte[1]和byte[2]的值为0x00，这与预期不符。
在网上查找资料后，问题依旧未能解决。为了解决此问题，我尝试了使用模拟I2C的方法解决问题。在这一过程中，MS5611的时序要求十分严格，因此延时函数的运用极其重要。在使用I2C读取PROM时，出现了数据全部为0xFF的情况，但在keil Debug中运行时却有数据。这提示可能是Debug的延时时间过长导致。
意识到问题后，我调整了延时函数的构造。由于在中断中读取数据，只能通过for循环来模拟延时。经过多次测试，确定了合适的延时次数，即在循环中令j小于2000。考虑到板子的晶振频率为8MHz，这可能解释了精度的差异。
最终，成功读取了数据，并按照芯片手册的指导设计了算法，计算出了气压值。随后，通过“气压-海拔：经验换算公式”计算海拔高度，并与气象台的数据进行对比，确认结果在误差范围内。至此，困扰许久的问题得到了解决，我感到十分高兴。
热心网友
时间：2024-10-07 20:42
通过使用HAL库，成功实现了对MS5611的驱动，获取到了PROM值。
然而，当尝试使用固件库时，遇到了问题，未能成功驱动。尽管按照手册中的时序编写代码，并在Debug中观察到数据，但数据的存储出现了问题。在接收24位数据时，SPI接口*为8位，因此定义了byte[3]来存储数据。在Debug断点观察下，发现byte[0]的值与HAL库相同，为0xFE，而byte[1]和byte[2]的值为0x00，这与预期不符。
在网上查找资料后，问题依旧未能解决。为了解决此问题，我尝试了使用模拟I2C的方法解决问题。在这一过程中，MS5611的时序要求十分严格，因此延时函数的运用极其重要。在使用I2C读取PROM时，出现了数据全部为0xFF的情况，但在keil Debug中运行时却有数据。这提示可能是Debug的延时时间过长导致。
意识到问题后，我调整了延时函数的构造。由于在中断中读取数据，只能通过for循环来模拟延时。经过多次测试，确定了合适的延时次数，即在循环中令j小于2000。考虑到板子的晶振频率为8MHz，这可能解释了精度的差异。
最终，成功读取了数据，并按照芯片手册的指导设计了算法，计算出了气压值。随后，通过“气压-海拔：经验换算公式”计算海拔高度，并与气象台的数据进行对比，确认结果在误差范围内。至此，困扰许久的问题得到了解决，我感到十分高兴。
热心网友
时间：2024-10-07 20:42
通过使用HAL库，成功实现了对MS5611的驱动，获取到了PROM值。
然而，当尝试使用固件库时，遇到了问题，未能成功驱动。尽管按照手册中的时序编写代码，并在Debug中观察到数据，但数据的存储出现了问题。在接收24位数据时，SPI接口*为8位，因此定义了byte[3]来存储数据。在Debug断点观察下，发现byte[0]的值与HAL库相同，为0xFE，而byte[1]和byte[2]的值为0x00，这与预期不符。
在网上查找资料后，问题依旧未能解决。为了解决此问题，我尝试了使用模拟I2C的方法解决问题。在这一过程中，MS5611的时序要求十分严格，因此延时函数的运用极其重要。在使用I2C读取PROM时，出现了数据全部为0xFF的情况，但在keil Debug中运行时却有数据。这提示可能是Debug的延时时间过长导致。
意识到问题后，我调整了延时函数的构造。由于在中断中读取数据，只能通过for循环来模拟延时。经过多次测试，确定了合适的延时次数，即在循环中令j小于2000。考虑到板子的晶振频率为8MHz，这可能解释了精度的差异。
最终，成功读取了数据，并按照芯片手册的指导设计了算法，计算出了气压值。随后，通过“气压-海拔：经验换算公式”计算海拔高度，并与气象台的数据进行对比，确认结果在误差范围内。至此，困扰许久的问题得到了解决，我感到十分高兴。
