串口的模式有binary和ASCII，在哪里找，取决于你用的什么方法。是API还是控件之类的，搜一下你用的技术加上关键字binary。

LZ也得具体一点说说你用的哪种方法实现的串口。

ProcessCommand完成得很快（通常只有几毫秒），所以不会卡住读取线程。不需要等待命令执行，就开始读取新的数据。

命令使用（系统系统线程池上的）子线程并发执行。

所有的线程都可以不开。

实际的系统是为了性能和用户（UI交互时）操作体验而设计的。如果你只是完成基本逻辑，永远也不用考虑使用线程的。所以说，如果你在“还看不懂基本逻辑”的时候，你只要把 ThreadPool.QueueUserWorkItem(...)  这句话外边的“壳儿”去掉、仅留下里边的代码，就行了。

我们只是习惯了而已，设计一个通讯程序，首先会定下“哪个操作必须异步执行”的规则，然后写程序。并不是所有人都习惯使用线程。

程序我临时写的，没有测试，只是保证不会出现语法错误而已。如果有执行错误，你自己调试、改一下。

关键是数据结构和流程问题，只要你看懂就行了。

感谢上面那位大大，虽然没看太懂，主要是我水平未够。经过努力，我已经做成功了。下面分享下：

接收到的信息（list中的内容），不一定只有一个命令（例如发消息的设备很多、发送速度远比上位机处理速度快），可能有多2个甚至多个。你的程序是假设每一次接收到“一个”命令，只执行一次命令就结束。

你的程序并不能保证正确，只是说你现在的测试环境“恰好”设备比较慢、而双绞线距离比较短、主机比较空闲，因此基本上都能恰好每当设备发来一条消息时能够满足 list[list.account-1]==0xD0&&list[list.account-2]==0xDE 这个条件。如果你能兼容“收到多条命令”的形式（甚至你能发挥想象力先来制造一个此类测试，然后再解决bug），程序将来用到实际的各种生产环境中才会比较可靠。

另外将来让程序变成一个教正规、可为中型应用而扩展的“设计升级”的建议：

1. DataReceive中的程序，应该清晰地是处理这个Receive流程的。你应该把判断任务类型和调用处理程序的代码，从这段程序中分离出去，不应该在这里出现一堆的 if...else 判断。

2. 将来还是要在子线程中执行命令解析和调用处理程序过程，而 Receive程序应该仅仅在从list中去掉一条条命令之后，立刻返回（不等命令执行就返回）。以免造成通讯延迟、甚至程序死锁。

另外，if。。。else这个处理速度应该很快吧。你指的意思是在Receive程序里面开启一个线程吗，在这个线程里用来处理数据吗。