Java bulkTransfer无法按预期工作。为什么以及如何解决这个问题?

Java bulkTransfer无法按预期工作。为什么以及如何解决这个问题?,java,android,usb,android-service,Java,Android,Usb,Android Service,我有一个服务,它打开一个设备,向它发送数据,然后从该设备接收答案,一切正常,但测试显示一些奇怪的结果。如果有必要,我会发送命令并在不同的线程中获得答案 这是处理接收的线程 public void receiveThread() throws Exception{ byte[] buffer = new byte[80]; int i; while(true) { if((USBint != null) && (USBendIn !=

我有一个服务,它打开一个设备,向它发送数据,然后从该设备接收答案,一切正常,但测试显示一些奇怪的结果。如果有必要,我会发送命令并在不同的线程中获得答案

这是处理接收的线程

public void receiveThread() throws Exception{
    byte[] buffer = new byte[80];
    int i;
    while(true)
    {
        if((USBint != null) && (USBendIn != null))
        {
            i = USBcon.bulkTransfer(USBendIn, buffer, 2, 1);
            if(i > 0)
            {
                String s2 = new String(buffer);
                String s1 = bytesToHex(buffer);
                showToast("data received (" + i + ") :\n" + s1 + "\n" + s2);
            }
        }
        Thread.sleep(20);
    }
}
在onstart命令中设置USBcon和USBendIn。一个是连接,另一个是方向为的端点

注意在第i行=USBcon.bulkTransferUSBendIn,buffer,2,1; 我尝试了长度和超时参数的不同变化,它们都给出了完全相同的结果。 USBcon.bulkTransferUSBendIn,缓冲区,23000//这应该等待2个字节,然后等待大约3秒钟。如果在这3秒钟之前收到2个字节,则函数应返回2并仅接收这2个字节

USBcon.bulkTransferUSBendIn,缓冲区,1003000//这应该等待100个字节,然后等待大约3秒钟,如果3秒钟后收到的某些字节少于100,则应返回此数字

USBcon.bulkTransferUSBendIn,缓冲区,2,1//这应该等待2个字节,然后等待大约1毫秒。如果1ms内没有任何输入,则应返回0

我甚至试过这个I=USBcon.bulkTransferUSBendIn,buffer,10,-20;猜测负超时也是可以接受的

这4个例子都做了同样的事情。我以随机长度等间隔接收一些字节。我应该接收的整个消息是24个字节,有时我会将其分为3部分,例如:1个字节+8个字节+15个字节,有时我会一次全部接收到。即使我声明只想接收2个字节,它们也会被放入缓冲区。这将显示长度参数中的错误。超时也不起作用。无论我写什么作为超时,函数在一段时间后返回,无论接收到多少字节,都无法判断有多少超时。即使是负增长时期也是如此。即使是长度为240的Integer.MAX_值,它也会每隔3秒左右接收24个字节=>它应该等待近半分钟,但没有

只有两次此函数的行为有所不同,那就是当我输入0作为长度时。服务启动后2-3秒,平板电脑会自动重新启动。但是,将长度设置为负值没有任何作用,没有重新启动,也没有收到任何数据


所以。。发生了什么事?这对我的服务来说不是什么大问题,但我不喜欢不信任系统功能的情况。让我想知道还有什么不能正常工作。

如果您需要24个字节,为什么不要求全部24个字节?通常,当我处理一个协议时,我会这样对待它,发送命令,请求响应。当我使用一个读线程时,我要么有流,要么有未定义的数据进入。在这种情况下,您只需始终发布一个未完成的读取,以获得尽可能多的数据。然后,当数据进入时,将其放入缓冲区。然后,主线程可以根据需要从缓冲区中提取数据。有时数据可能会意外地被接收到。无论如何,无论我做什么,我都不会改变这样一个事实,即函数只是忽略了这两个参数,如果忽略了这两个参数,就会完全崩溃。USB的本质是主机启动传输。因此,当您发出批量传输时,您是在说您需要一些数据。这取决于你知道你应该收到多少,如果不知道,这就是为什么连续阅读是首选。我认为UsbConnection不会为您保存数据,在IN端点上使用bulkTransfer会向设备发出IN-packet请求,它会给您提供当时必须提供的数据量。在我看来,底线要么是询问您期望的数据量,要么设置一个连续读卡器。即使我确切知道我期望的字节数并将其作为参数长度输入,它仍然会做同样的事情。我得到随机长度的数据包的随机数,这些数据包加起来就是我所期望的。如果给函数一个高超时值,人们会期望函数在返回小于预期长度的数据包之前等待那么长的时间。