libusb文件,libusb.lib和usb.h。里面块传输部分usb_bulk_read只能读取char类型的数据,远远不能满足需要

 我来答
匿名用户
2013-05-06
展开全部
哈哈,选我吧!你把发过去的unsignedint拆成2个unsingedchar,高位那个为0,发过去后然后接受到的两个合并为一个unsignedint。问一下,这是16位的么?
我没有弄过这个通讯.我猜测应是端unsignedchar型发生了隐式转换,成为了unsingedint(或unsignedshortint)型,因此高8位均为0了。接受到的时候,将比特流按8位来解析,于是产生了2个数据,还有一个为0.
你可以尝试传入一个负数(char型的),应该会产生结果很大差异,因为这时候隐式转换将符号位作为值就有问题了。高8位都是1。接受到的数据0就应该会变成255。
(上述都只是我的猜测)具体工作原理不知....
我说下我的解决思路:
unsignedcharconvertDate[2];
unsignedcharmask=0xFF;
unsignedinttransportDate;//待传输的数据
convertDate[0]=transportDate//低位字节
convertDate[1]=(transportDate>>8)//高位字节
将这个数组的两个字节发送过去,然后在那端进行合并。
接受那边每次接受两个数据进行一次转换
unsingedintreceiveDate=0;
receiveDate=rConvertDate[1]//存储高位
receiveDate<<=8;//移动到高位
receiveDate=rConverDate[0]//存储低位
合并得到的receiveDate就是转换得到的。
然后,你在自己写发送端、接收端数据处理函数对收发数据进行上述的处理。这样转换后显示应该会正常吧。
最后说下:就是传递的参数说了是unsigned的,别传入负值了,不然转换解析也会有问题。会转换成很大的unsignedint值。
匿名用户
2013-05-06
展开全部
不会
已赞过 已踩过<
你对这个回答的评价是?
评论 收起
匿名用户
2013-05-06
展开全部
不会
已赞过 已踩过<
你对这个回答的评价是?
评论 收起
收起 更多回答(1)
推荐律师服务: 若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询

为你推荐:

下载百度知道APP,抢鲜体验
使用百度知道APP,立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。
扫描二维码下载
×

类别

我们会通过消息、邮箱等方式尽快将举报结果通知您。

说明

0/200

提交
取消

辅 助

模 式