同一个句柄则会导致阻塞。如 果应用程序的多个线程都需要调用 DLL 的 API,那么必须使每个调用者分别使 用各自的句柄 handle,可以在主线程中 OpenDevice 后,用 GetDeviceName 获取 设备名称,然后由各线程调用 CreateFile 分别打开 USB 设备获得各自的句柄, 再用于 API 调用, * 单片机是否要对 USB 传输的数据进行校验 USB 传输本身是带 CRC16 校验的包传输, CH375 自动检查 CRC16, 如果它检 查通过,那么实际出错概率非常之低,如果 CH375 检查 CRC16 未通过,那么它 会和计算机约定重传几次直到 CRC 正确,所以正常情况下单片机不需要考虑数 据校验和数据重传。 * 关于丢数据、计算机调用 API 返回出错、数据错误等 1、丢数据通常是这样,上位机准备读取 5 个字节,而下位机上传 8 个字节, 那么 CH372 的 DLL 及驱动程序在收到 8 个字节后, 只将应用程序所需的 5 个字 节返回,而丢弃后面 3 字节。 2、 正常情况下 USB 传输不会出错, 如果返回错误通常是 USB 设备断开、 USB 传输超时(超时太短)、或者单片机程序有误,写入无效的数据长度等(例如向 端点 2 写入长度 65 等)。 3、 数据错误通常是这种情况: 应用程序未检查 API 返回时 USB 传输的实际长 度,以为有足够数据返回,可能实际上没有,当然缓冲区中的数据是无效的。例
如,应用程序准备读取 512 字节,而单片机只上传 200 字节,那么 API 返回时 的实际长度只有 200,如果应用程序不检查该长度而以为是 500,那么就会认为 后面的数据错误。类似情况是 USB 超时太短,计算机接收到一半时因为超时提 前返回,长度不足。 * 想自己做 U 盘、做定制功能的 USB 鼠标等 使用 CH372、CH375 的外置固件模式,外置固件模式下与市面上大多数 USB 接口芯片的使用方法差不多
。我们网上可以提供自己动手做 U 盘的
全套低成本
方案/源程序/样品等。做 USB 鼠标也有源程序供参考。 * 单片机通过 CH375 能否从其它带 USB 端口的仪器中采集数据?能否操作其它 USB 设备、例如 USB 打印机等 理论上可以,实际上有个条件,就是必须了解被操作方的 USB 传输的具体细 节,例如通过哪些端点收发数据,数据的格式是怎样的。例如,USB 打印机是 符合 USB 类规范的,所以 USB 传输的细节是公开,当然能够进行 USB 传输操 作,但是如何打印出文字还需要了解打印描述语言。对于带 USB 端口的仪器, 因为通常都不符合类规范,所以需要知道其传