我觉得还有一个问题，就是冲突的解决，如果双方同时发起通讯，不管是双方同时打算发0或者1，还是一方发0，另一方打算发1，都会导致双方死等。即使在发送之前判断了线上电平的状态也没用，可能在你判断的时候，电平还是1，但是在你判断完了准备拉低的时候，对方也在做同样的事，这样的冲突是不能忽略的，因为它会导致双方同时进入死等，直到掉电。解决的方法也不是没有，就是加入一个发送超时的判断，等一段时间之后收不到应答就认为发送失败，可是这样的话，又可能因为对方正在忙别的事没顾上去启动receive（）而导致误判。所以，我觉得，楼主的想法是好的，但是第一个问题是代码太简陋，考虑得不够周全，代码中的while太多，可能会导致死锁的概率大幅增加；第二个问题是通讯调度的过程完全是不可控的，谁先发起谁就是发送方，对方只能作为接收方，这可能也会导致冲突的发生。为了解决这两个问题，又需要大幅增加代码，代码的和判断条件的增加又会迅速降低通讯效率，所以，距离实用可能还有很长的路要走。