dsjsjf 发表于 2015-6-11 22:10
我之前都是开一段缓存，中断接收了就往里存，然后别的程序再从缓存里取了解析 ...
你这样接收一个字节就要进入一次串口中断吧？
主程序来不及处理，会被覆盖掉吧
这也不是啥好办法，407这么快的速度，中断很快就运行完了，而且还能进行简单的包头包尾判断，如果没有什么开销的话用中断未尝不可，倒是发送数据需要用DMA，查询方式太恶心了，回头都改了。
DMA确实要简单点。
creep 发表于 2015-6-11 22:48
你这样接收一个字节就要进入一次串口中断吧？
是的
学习学习:lol
moyanming2013 发表于 2015-6-11 16:52
那“查询DMA的状态”是否也会一直在占用CPU啊？
怎么会“一直”呢，查询一下，有就收，没有就干别的事，函数就是Idle_Proc()。
用DMA+一段缓冲，可以放宽查询的时间间隔要求，而不是来一个字符中断一下地搞。
中断还是留给重要的事情。
如果软件任务简单用几个中断当然无所谓，但任务多了，如USB芯片、FPGA等等好多地方都要中断，而公司又明确不允许使用RTOS，那么...
每个程序任务的背景都不尽相同，我的代码也只是一种思路罢了。
這個方法還不錯
lusonghua 发表于 2015-6-16 10:36
怎么会“一直”呢，查询一下，有就收，没有就干别的事，函数就是Idle_Proc()。
用DMA+一段缓冲，可以放宽 ...
嗯，看来DMA+查询确实有使用的场景。
如果要是数据多了DMA缓冲区够用么？
moyanming2013 发表于 2015-6-16 11:25
嗯，看来DMA+查询确实有使用的场景。
如果要是数据多了DMA缓冲区够用么？ ...
考虑的不应该是数据多了或少了的问题，而是最“严酷”条件的问题，即如果UART带宽100%使用时，查询DMA状态的时间间隔问题。
因为UART是很慢的外设，给个一定长度的buffer，就有相当宽裕的容许间隔。只要保证在时间间隔内程序必定能够再次查询到DMA状态即可。这个对于一般的ARM都不成问题（如果这样都有问题，那真得考虑CPU选型了）。
当然，还是那句话，别阻塞。