3

Hey I have been trying to work on this for some time but I am just getting no where

I am trying to get bytes in from a USB device, this works fine for one or two lines coming in but when it gets to quite a few it just doesn't work.

I am using this line of code to bring in data:

conn.bulkTransfer(epIN, buffer, 57600, 500);

is there any way to do a USB transfer over and over again until there is no more data coming in? Because the amount of data coming in can be anything from 8 bytes to a few MB

In reply to user387184

Would something like this work to transfer large amounts of data?

while ( conn.bulkTransfer(epIN, buffer, 57600, 500) > 0 ){
    \\do some stuff
}
FabianCook
  • 20,269
  • 16
  • 67
  • 115
  • U can put this statement(conn**.**bulkTransfer) in a **while loop** until u get a **-1** as return value from this statement(u will get a **-1** when there is nothing to receive from an USB device). That will solve the problem. – DJphy May 16 '15 at 06:15

2 Answers2

2

When trying to communicate with a (ultimately) serial device as you have downstream of the converter, it is quite useful if the protocol is designed such that messages sent and received have terminating characters. This prevents you having to guess if more data will be coming in another few milliseconds. Newline is a very common choice. For example:

Host: What is your name?\n

Device: Sir Galahad of Camelot.\n

Host: What is your favourite colour?\n

Device: Blue\nNo, yellow\n

Given that the device has terminated the response with \n after "Blue" the host won't be expecting to see the second clarifying answer. Typically what would happen if the device "broke the rules" this way is that the host won't read "No, yellow" until it looking for the answer to whatever it asks next, at which point it would probably reject it as an implausible response, and issue a reset command to the device. (Some protocols have a "pre-pend the response with a repeat of the question" scheme to protect against such confusion)

There are of course two other well known possibilities apart from using a terminating character: one would be very abbreviated codes - single character or potentially unprintable binary - having expected length responses (possibly different depending on the beginning of the code). The other is having something in the way of a packet structure - an identifiable header, a length field, and then data.

The main point though is that "wait and see if there is any more" protocols are primarily used between two people or between a person and an automated system. When automated systems talk to each other, they tend instead to use a protocol which defines how you know if there will be any more. If the creator of your ultimate downstream endpoint device's firmware knew their business, there will be evident rules for when you should, and should not, expect more data.

Chris Stratton
  • 39,853
  • 6
  • 84
  • 117
  • Coming back to all this. The device I was using had no expected end to it. We couldn't say this is the end or anything. The data would keep coming until there is no more. Each line separated with a new line character. With small amounts of data this was fine. But when it was returning several thousands of lines it wasn't so easy. In the end I just kept on going till there was no more data to collect by checking the lengths of the data coming in. – FabianCook Nov 04 '12 at 00:54
1

If your USB connection really stops receiving data if there is no more data then all you need to do is to put a while receivedBufferIsNotEmpty around your statement since:

lenOfReceivedBuffer = conn.bulkTransfer(epIN, buffer, 57600, 500);

gets 0 in lenOfReceivedBuffer if no more data can be found on the port using 500ms timeout.

You may also increase the timeout a bit, if your sending side is too slow.

user387184
  • 10,953
  • 12
  • 77
  • 147
  • Looking at the code above would I be able to use that to get a "stream" of data? – FabianCook Jun 07 '12 at 13:46
  • 1
    yes, try this - however I would tend to assign the len to a variable and then log it, to see what you actually get. Are you 100% sure that there will be no data bytes on the port when the sender has ceased sending data? – user387184 Jun 07 '12 at 13:49
  • Well I'm using a ftdi USB adapter, it links the tablet to a serial device which only outputs when its recieved input, I'm sending the device a command and the device sends back the data – FabianCook Jun 07 '12 at 13:52
  • what "serial device" are you connected to? Does your connection cable have any kind of electronics built in? – user387184 Jun 07 '12 at 13:54
  • Its a proprietary device, it has electronics in it yet, but I can not go into details sorry, the connection has the ftdi interface. – FabianCook Jun 07 '12 at 13:57
  • 1
    which kind of connection cable are you using? Is this actually directly "connected" to the "proprietary device" or do you have a USB connection cable separate from the "proprietary device" and need to plug this into your "proprietary device"? – user387184 Jun 07 '12 at 14:00
  • Okay it works like this [Acer Iconia A500 (Running Android 4.0.3) >> USB to serial converter (FTDI) >> device] – FabianCook Jun 07 '12 at 14:02
  • I just realized that you already asked a similar question and gave the answer yourself here http://stackoverflow.com/questions/10429615/transferring-data-usb, sorry as long as I do not really know what kind of cable connection you use and at least what kind of connected proprietary device it is not really possible to know how it may behave when sending the data. I have connected several different devices using different kinds of cables, and they all behave somewhat differntly and are not really compatible - unfortunately – user387184 Jun 07 '12 at 14:10
  • That question was a different problem, that one was to do with baud rate. This is to do with lots of data transfer. I believe I had provided enough information here, the device is a very simple receive and send device and that's it. Its other functions are more complicated tho, however they have no effect on the transfer, what is it you need to know about the cable and device for? I don't think the device will be sending out any false data. – FabianCook Jun 07 '12 at 14:22
  • Depending on the connection cable/connected device FTDI serial USB connections behave differntly. Can you at least answer if you have a separate connection cable from the device or of the device directly has the cable attached. Also If you have a separate cable, is there electronics inside the cable. Many FTDI connections have electronics that creates and sends data bytes that do not belong to the real data you are looking for - I cannot give further advice without more info about the connection cable/connected device, sorry :-) – user387184 Jun 07 '12 at 14:48
  • @user387184 you are asking irrelevant questions, please stop. Communications downstream of the FTDI usb-serial converter are not as complicated as you are trying to imply. The downstream device may or may not send data, it's not challenging to handle both cases. Nothing so far indicates that flow control is being used in a mandatory way. – Chris Stratton Jun 07 '12 at 15:18
  • @Chris Stratton, depending on the connection cable, there may certainly by dummy data created and send by the cable itself - in particular if one uses a cable with built in FTDI serial-USB converter chip. In these cases I have NOT FOUND one single connection cable that DID NOT produce such dummy/trash data, which would make my above suggested approach not be applicable anymore. Anyway,obviously SmartLemon did not have such a connection cable, since otherwise the approach would not have worked. Also the trash data produced is always of different nature - This is quite CHALLENGING to handle :-)! – user387184 Jun 07 '12 at 15:38
  • @user387184 Not only have you been repeatedly harassing the asker with the same question, you've ignored the repeated reply. **An FTDI usb-serial converter cable is being used**. Properly used, such cables do not produce "trash data" in the serial stream- if they did, they would be useless. Please take any further followup to chat. – Chris Stratton Jun 07 '12 at 15:44
  • coming back to this... there was no "dummy data" coming in, in the end I just had to check for the length of the data to be zero. – FabianCook Nov 04 '12 at 00:55