/ 你不知道数据包的大小所以无论无何不可能实时响应的，因为你不知道何时结束是吧

可以考虑在发包前先加上包大小然后在启动dma

原帖由 huo_hu 于 2012-10-19 18:31 发表
你不知道数据包的大小所以无论无何不可能实时响应的，因为你不知道何时结束是吧

可以考虑在发包前先加上包大小然后在启动dma

想法不错，但实现也许不行。因为数据包是走协议的，要判断帧标志以及数据帧格式正确性，收到一个数据就认为是包大小抗干扰将会比较差，且一旦有干扰将无法给包定界。

既然你是有协议的，那都还好办的啊，例如modbus 地址判断完后有数据长度标识，然后把这个数据长度读入DMA 的长度。再做DMA 的读取。
       还有就是超时定义超时了就直接关闭DMA 读数据好了，一帧的时间不可能无限长的，只要是协议长数据帧一定会分有后继帧，后继帧虚等前一帧数处理完后回应才发后继帧的，所以这里定义一下最长长度帧的超时计时 就好了

原帖由 虚V界 于 2012-10-21 13:35 发表
既然你是有协议的，那都还好办的啊，例如modbus 地址判断完后有数据长度标识，然后把这个数据长度读入DMA 的长度。再做DMA 的读取。
       还有就是超时定义超时了就直接关闭DMA 读数据好了，一帧的时间不可能无限 ...

目前使用包格式类似Modbus，帧标志+源地址+目标地址+功能码+数据区字节数+数据区+CRC16。数据区最大长度为250个字节。
大部分情况下每包数据在0~40个字节之间，只有文件读写时会达到最大值250，只数据区接收时使用DMA可能改善不大啊。

包超时的想法很妙呀！你的想法是在接收数据区长度时启动DMA，同时启动超时定时器吗？呵呵，高手，这个办法确实有效解决了数据接收时的CPU开销。协议前段处理CPU开销看起来很验省下来了。STM32确实有些美中不足啊。

TI的M3 UART做得比较好就是有一个16级深的FIFO，我可以选择在接收端满了7/8产生时产生中断，同时也不必担心对端数据已经发送完成接收FIFO还没满不能产生中断的情况，因为可以选择接收超时中断（32个位时间没数据就认为接收超时）。这样对端包发送完最多32个位时间内就可以得到处理，收到14个字节才需CPU中断处理一次，CPU开销降低了很多。
使用STM32真的感觉很难兼顾低CPU开销与快速处理， 呵呵，STM32才开始用，也许是我菜没找到完美的方法吧。