STM32 RS485中断试验笔记

串口1按照开发板的试验，正常了，开始串口6做RS485通信试验，配置都按照串口1的中断配置，只是多了一个485模块的管脚配置，测试的时候发现，只能发送数据，不能接收，进入不了接收中断，很奇怪，测量了控制管脚，控制电平是正常的，就是进不了接收中断。代码改来改去的，就是进不去。晚上下班回去还在想，问题没解决，就是一直想问题。标准库里面，配置管脚的时候是接收和发射两个管脚分开配置的，HAL库就一起配置了
开发板的UART1的HAL配置也是分开配置的

GPIO_Initure.Pin=GPIO_PIN_9; //PA9 GPIO_Initure.Mode=GPIO_MODE_AF_PP; //复用推挽输出 GPIO_Initure.Pull=GPIO_PULLUP; //上拉 GPIO_Initure.Speed=GPIO_SPEED_FAST; //高速 GPIO_Initure.Alternate=GPIO_AF7_USART1; //复用为USART1 HAL_GPIO_Init(GPIOA,&GPIO_Initure); //初始化PA9GPIO_Initure.Pin=GPIO_PIN_10; //PA10 HAL_GPIO_Init(GPIOA,&GPIO_Initure); //初始化PA10

然后cubemax生成的代码是一起配置的

GPIO_Initure.Pin=GPIO_PIN_6|GPIO_PIN_7； GPIO_Initure.Mode=GPIO_MODE_AF_PP; //复用推挽输出 GPIO_Initure.Pull=GPIO_PULLUP; //上拉 GPIO_Initure.Speed=GPIO_SPEED_HIGH; //高速 GPIO_Initure.Alternate=GPIO_AF8_USART6; //复用为USART6 HAL_GPIO_Init(GPIOC,&GPIO_Initure); //

之前的标准库也是分开配置的，我怀疑是不是接收管脚不应该配置为上拉，第二天，我就把代码改为GPIO_Initure.Pull=GPIO_NOPULL;
然后，奇迹来了，居然可以进去中断了，进入之后还有数据不对问题，开发版那种接收中断函数

if((__HAL_UART_GET_FLAG(&USART2_RS485Handler,UART_FLAG_RXNE)!=RESET))//接收中断 { HAL_UART_Receive(&USART2_RS485Handler,&res,1,1000); if(RS485_RX_CNT<64) { RS485_RX_BUF[RS485_RX_CNT]=res; //记录接收到的值 RS485_RX_CNT++; //接收数据增加1 } }

接收数据没有任何协议的，发现有时候会卡死，改为串口1那种稍微加点协议的，好些了。
然后突想再验证一下是不是上拉的原因进不了中断，把上拉改回去，结果让我吃惊，居然又可以进入中断了，就是说能否进入中断似乎跟上拉不上拉没有关系，是不是很神奇。无解。
【STM32 RS485中断试验】先这样吧，先测试收发数据，UART1，UART6，定时500ms不断的收发数据，对应电脑的两个串口不断的收发。然后出现新问题了，用不了几秒的时间，就卡死了，查原因，死在接收中断里面了，定位问题，出现在 HAL_UART_Receive(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout); 函数里面，执行 __HAL_LOCK(huart); 锁死了，
网上查了一下，这个是HAL库的大坑啊，也有解决方法，最简单粗暴的方法就是注释掉，虽然有人不推荐，也有人说不影响收发数据。我就使用这个简单的方法吧，测试一下数据，正常了，不卡死了。