在标准库下配置的stm32f103x的spi在引入rtthread后收发的消息就错了，为什么？

答案对人有帮助，有参考价值 0

在标准库环境下配置的STM32F103x SPI功能在引入RT-Thread后出现收发错误，通常是由以下原因导致的。请逐步排查：

1. 时钟配置冲突

• 问题：RT-Thread初始化时会重新配置系统时钟（如 SystemClock_Config()），覆盖了标准库的时钟设置，导致SPI时钟源（如APB2）频率异常。


• 解决：
  
  
  
  • 检查 board.c 中的时钟初始化函数（如 SystemClock_Config()）是否与你的配置一致。
  
  
  • 确保 SPI 外设的时钟源（如PCLK2）和分频系数设置正确：
    

    RCC_APB2PeriphClockCmd(RCC_APB2Periph_SPI1, ENABLE); // 启用SPI时钟
    
    SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_4; // 分频系数

  
  

2. 中断优先级冲突

• 问题：RT-Thread使用Systick、PendSV等系统中断，若SPI中断优先级过高（数值过小），可能抢占系统中断导致异常。


• 解决：
  
  
  
  • 将SPI中断优先级设置为 ≥3（数值越大优先级越低）：
    

    NVIC_InitStruct.NVIC_IRQChannelPreemptionPriority = 3;  // 抢占优先级
    
    NVIC_InitStruct.NVIC_IRQChannelSubPriority = 0;         // 子优先级

  
  

3. SPI总线未加互斥锁

• 问题：多线程环境下，多个任务可能同时访问SPI总线，导致数据竞争。


• 
  

  解决：

  
  
  
  
  • 
    

    使用互斥锁保护SPI操作：

    
    

    static rt_mutex_t spi_mutex = RT_NULL;
    
    
    
    // 初始化互斥锁（在app_init线程中）
    
    spi_mutex = rt_mutex_create("spi_mutex", RT_IPC_FLAG_FIFO);
    
    
    
    // SPI操作前加锁
    
    rt_mutex_take(spi_mutex, RT_WAITING_FOREVER);
    
    SPI_TransmitReceiveData(...); // 执行SPI传输
    
    rt_mutex_release(spi_mutex);  // 操作后解锁

    
    
  
  
  
  

4. SPI初始化顺序错误

• 问题：用户代码在RT-Thread初始化前调用SPI初始化，后续被RT-Thread的硬件初始化覆盖。


• 
  

  解决：

  
  
  
  
  • 
    

    将SPI初始化移到RT-Thread启动之后（如在main_thread_entry中）：

    
    

    int main(void) {
    
       rt_thread_startup(rt_thread_create("init", app_init, RT_NULL, 1024, 8, 20));
    
       return 0;
    
    }
    
    
    
    void app_init(void *param) {
    
       SPI1_Init(); // 在此处初始化SPI
    
       while (1) { /* 应用逻辑 */ }
    
    }

    
    
  
  
  
  

5. 堆栈溢出

• 问题：线程或中断栈过小导致SPI收发时数据损坏。


• 解决：
  
  
  
  • 增大SPI相关线程的栈大小（如从512调整到1024）：
    

    rt_thread_t tid = rt_thread_create("spi_th", thread_entry, RT_NULL, 1024, 15, 10);

  
  
  • 检查SPI中断函数是否调用RT-Thread API（如发送信号量），若是，需增大中断栈（通过RT-Thread Settings调整）。
  
  

6. DMA冲突（若使用DMA）

• 问题：RT-Thread的DMA驱动与用户配置冲突。


• 解决：
  
  
  
  • 统一使用RT-Thread的SPI设备框架操作DMA，避免混合标准库配置。
  
  

排查步骤

1. 
   

   检查时钟频率
   
   在SPI初始化后打印APB2时钟频率，确认是否为预期值（如72MHz）：

   
   

   rt_kprintf("APB2 Freq: %d Hzn", SystemCoreClock);

   
   


2. 
   

   简化测试
   
   创建一个单线程任务，仅执行SPI回环测试（MISO短接到MOSI），排除多线程竞争问题。

   
   


3. 
   

   逻辑分析仪抓包
   
   使用仪器检查SCK、MOSI、MISO波形，确认：

   
   
   
   
   • 时钟极性（CPOL）和相位（CPHA）是否匹配从设备。
   
   
   • 数据传输是否被异常打断。
   
   
   
   


4. 
   

   切换为RT-Thread SPI框架
   
   避免直接操作寄存器，使用RT-Thread的设备驱动接口：

   
   

   struct rt_spi_device *spi_dev;
   
   spi_dev = (struct rt_spi_device *)rt_device_find("spi10");
   
   struct rt_spi_configuration cfg = {
   
      .mode = RT_SPI_MASTER | RT_SPI_MODE_0 | RT_SPI_MSB,
   
      .data_width = 8,
   
      .max_hz = 1 * 1000 * 1000, // 1MHz
   
   };
   
   rt_spi_configure(spi_dev, &cfg);
   
   rt_spi_send(spi_dev, tx_buf, sizeof(tx_buf)); // 发送数据

   
   

总结

重点关注 时钟配置冲突、中断优先级 和 多线程互斥 这三个最常见原因。通过逐步隔离问题（如先禁用所有线程仅测试SPI），结合硬件信号分析，即可定位根本原因。