一般出现死机的现象是375的读写函数挂起了主线程,造成消息不能响应,在做大量数据传输时,下位机在传输多个整包之后,再传一个零头包.如果多个整包已经可以把数据传完了,那在最后还要再传一个零长度的包,这样就可以通知上位机通信结束.请问如何实现，有无例程提供？

例子可以自己写一个,发零头包只是一种解决方法,下面有更详细的说明: * 设计的计算机端应用程序在读写USB时有时会死机，而计算机的其它程序一切正常 1、这种死机实际上是计算机端程序以为下位机会收发数据，而实际下位机没有，导致计算机一直等待。 一般情况下，在计算机与单片机的应用层应该有一定的约定：如何传数据、传多少、什么时候传、 双方如何同步，如果双方没有约定好，那么可能出现甲方以为乙方会传而乙方未传则会导致甲方一直 等待。最佳的解决方法是，设计良好的程序结构和双方约定，确保不出现上述的“以为”，另外再辅 助以超时解决方法，超时解决方法是，甲方收发数据，如果乙方正忙，那么甲方只等待一定时间而非 一直等待。新版的驱动程序都支持超时CH375SetTimeout，如果设置超时为200毫秒，那么超过200毫 秒收不到数据，甲方也不会一直等待下去，但是主程序应该分析这种情况是什么原因。建议超时值大 于正常情况下最大传输时间的2倍以上，最小要有数毫秒，因为计算机忙时正常传输时间也会增大。 2、类似情况还有，应用程序调用API准备接收80字节，而单片机只打算上传64字节，那么在计算机收到 64字节之后，因为不足所需要的80字节，所以继续等待后面的数据。原因是，USB传输最大包是64字 节，所以单片机上传64字节不能说明后面没有数据（真正的80字节传输是先传64再传16）。解决方法 是，单片机在64字节之后再上传0字节，当计算机收到0到63字节时，认为后面没有数据（因为USB最 后一个包的长度才可以少于最大包长度64），从而不管应用程序需要多少字节而提前退出接收。 3、另外还有一种失误，单片机程序在收到上传成功中断后未解锁CMD_UNLOCK_USB，导致CH372/CH375拒 绝处理后面的USB传输，而计算机程序不知道，会一直等待下去，除非超时退出。 4、如果要求的传输速度不高（小于20K字节每秒），那么可以参考CH37X调试工具中的调试程序，它使用 单个数据包的请求加应答方式，每个回合的USB操作都是计算机发下去一个命令包（含数据），然后 单片机返回应答包（含数据），因为双方约定有序，所以理论上绝对不会出现死机情况。 5、默认情况下的DLL是同步操作I/O，所以打开设备的同一句柄handle同一时候只能用于一个API，如果 同时有多个API使用同一个句柄则会导致阻塞。如果应用程序的多个线程都需要调用DLL的API，那么 必须使每个调用者分别使用各自的句柄handle，可以在主线程中OpenDevice后，用GetDeviceName获 取设备名称，然后由各线程调用CreateFile分别打开USB设备获得各自的句柄，再用于API调用，