CAN-USB Adapter Buffer Management

I'm having a problem with my reliable CAN adapter.

I use `getQueueStatus` to determine the number of bytes in the receive buffer, and then I read the receive buffer using `read(buffer, count, timeout)`, specifying the number of bytes to read.

As long as less than 0x4000 bytes are in the buffer, everything is fine.

If there are more than 0x4000 bytes in the buffer, I can still read the buffer. However, even without receiving any further data (meaning the buffer will not be filled further), the state of the receive buffer remains unchanged.
I expected that the number of bytes reported by `getQueueStatus` in the receive buffer would be reduced by the number of bytes read. However, this is not the case. Also, it appears that the buffer content is not being modified. So, my program ends up reading the same content repeatedly.

Can someone explain this phenomenon?
Does anyone know a solution (e.g., additional API calls that are required)?
What is the buffer size of my CAN-USB adapter, actually (I'm guessing it's 0x4000)?

I am using the adapter under Android using the appropriate D2xx API.

I haven't observed this behavior under Windows (there, I follow the same procedure as described above), but that could also be because the hardware is faster there, and similar buffer issues don't occur in the first place. I may need to reproduce the issue there as well, although the question of how to fix it remains.

Regards,
candev

Hello,

Without knowing the exact implementation, I doubt that the hardware actually has or uses 0x4000 (16384) bytes of RAM.
It is likely an internal buffer of the FTDI driver. I suspect the "problem" lies more in the driver implementation or the way you're using the Android driver.

Found via Google, and may help point you in the right direction.


The current RKS+CAN CANHack hardware, by the way, uses a FIFO buffer for 32 messages.
http://stackoverflow.com/questions/15518214/official-ftdi-android-drivers-read-is-not-working
"With this, there definitely won't be any spills." The FTDI driver is also not necessary. http://www.canhack.de/en/viewtopic.php?t=137

Best regards, Rainer.

Hello Rainer,

Thank you for your reply. The procedure described in the link you provided is exactly the one I use (and it's also the one presented in the documentation and in the sample code).

I've done a little more research and I think the error is indeed in the Android-D2xx driver. In addition to the bug described in the original post, I've found another one: messages are reported as being corrupted. Or rather, the buffer seems to be corrupted. This behavior is also load-dependent. On a dual-core processor with a clock speed of 1 GHz, I experience this issue on Android 4.1.2 starting with 4 messages at 20 Hz each. The more messages I add, the more messages become corrupted. It seems like there are problems syncing with/to InTask.

It's a shame, I guess I'll have to keep lugging that old laptop around with me in the car.

Regards,
candev

To wrap things up: the error, as suspected, was/is in the aforementioned driver. Unfortunately, the manufacturer didn't even bother to respond to the error report. As a result, I decided to get rid of the adapter. The ASCII-based approach is fundamentally incompatible with any reasonably professional application.
As the saying goes: 'The wise person says: 'If you're riding a dead horse, get off!'' The fool says: 'If you're riding a dead horse, make sure the saddle is comfortable – the ride might be a long one.'

'I've been using a (professional) CAN/USB adapter, for which I wrote my own Android driver. The adapter processes a binary protocol. Since then, the application has been running incredibly fast. I can log data recordings with a capacity equivalent to a CD, and while doing so, I can still scroll the UI within the application and listen to MP3s, receive emails, or play games.' In short, even a drive-CAN bus operating at 500 kbit/s will only elicit a tired smile from an Android phone if you're using professional-grade hardware.

Regards,
candev