浅谈分布式多节点嵌入式系统中RS485总线指令冲突解决及性能优化

一、问题

RS485总线多节点竞争总线时，是否遇到过，由于缺乏冲突检测机制，发生指令冲突？系统实时性如何保障？如何解决了？采用主从轮询方式？同样也会因高延迟加剧冲突！笔者在项目开发过程中就遇到过这样的问题，既要保证实时性，又要解决总线指令冲突，同时还不能修改硬件，只能通过软件去改善这个问题。

二、背景

简单先介绍下项目背景，系统节点共15个，都是独立的功能模块，模块间通过RS485通讯，系统是封闭的，因此通讯协议采用的是自定义。主控模块可以控制子模块启停，同时子模块还会将运行状态上传到总线，子模块相互间写作也是通过指令控制，系统复杂度可想而知。

三、解决方案

下面聊聊是如何解决这个”既要、又要、同时还“的问题的。 先来谈谈总线指令冲突的改善的解决思路 。想要解决指令冲突问题，先对系统通讯协议做了下了解，协议的一帧是定长的；在从模块的中断回调函中分析，可以通过指令字判断当前是否有指令在接收。因此，在接收指令时设置一个标志位g_tx_block_flag，模块要发送指令时先检测这个标志位是否有效，有效暂停发送，无效则发送指令。所有子系统都参照这个修改，从而有效改善指令冲突的问题。 void user_rs485_bus_callback(uart_callback_args_t p_args) { / TODO: add your own code here / uint8_t data; g_rs485_uart_event = (uint8_t)p_args->event; if(UART_EVENT_RX_CHAR == p_args->event) { data = (uint8_t)p_args->data; if((data == FRAME_KEY)&&(g_rx485_index==0)){ g_rx485_tmp_buff[g_rx485_index++] = data; g_tx_block_flag = true; } } } 其次，对系统性能优化 。通过对协议的分析，总线上传输的大量消息中，并不是所有的指令都与子系统相关，通过总线消息过滤，可以减少节点子系统的处理负担，提高系统效率，并能确保关键指令能够在子系统中得到及时的处理。 //接收指令过滤，仅处理与子系统相关的指令 bool rx_cmd_filtering(uint8_t cmd_data) { bool retValue=false; switch(cmd_data) { case RX_CMD_FILTER_A0: case RX_CMD_FILTER_A1: case RX_CMD_FILTER_A2: case RX_CMD_FILTER_A3: retValue=true; break; } return retValue; } / Callback function */ void user_rs485_bus_callback(uart_callback_args_t p_args) { / TODO: add your own code here */ uint8_t data; g_rs485_uart_event = (uint8_t)p_args->event; if(UART_EVENT_RX_CHAR == p_args->event) { data = (uint8_t)p_args->data; if((data == FRAME_KEY)&&(g_rx485_index==0)){ g_rx485_tmp_buff[g_rx485_index++] = data; g_tx_block_flag = true; } else if(g_rx485_index==1) { if(rx_cmd_filtering(data)) g_rx485_filter_sate = 1; //当前子系统有指令需要处理 else g_rx485_filter_sate = 0; g_rx485_tmp_buff[g_rx485_index++] = data; } else { g_rx485_tmp_buff[g_rx485_index++] = data; if((g_rx485_index+1)>FRAME_LEN) { g_rx485_index=0; if(g_rx485_filter_sate) { xQueueGenericSendFromISR(g_485buf_queue, g_rx485_tmp_buff, NULL, queueSEND_TO_BACK); g_tx_block_flag = false; } } } } } 有兴趣的小伙伴，可以下载工程了解下 项目工程下载链接：