(dev) For a project for a client (yes, I do contract work) I need to talk to a number of USB dev ...
Posted on 2013-02-19, 15 comments, 59 +1's, imported from Google+/Chainfire

NOTICE: This content was originally posted to Google+, then imported here. Some formatting may be lost, links may be dead, and images may be missing.

... ices from Android. One of these is an Arduino Nano based board with an FTDI chip to do RS232-over-USB communication.

You might expect your average Android device to support this directly in the kernel, as 'big' Linux does, but you'd be forgetting this is Android, and nothing really works on Android.

I've tried a number of libraries that claim to support this way of communicating with the Arduino using this chip, but none of them actually worked. I've seen quite a few crashes (both in Java and native code) and freezes, and some of these projects have code in it that anybody can see isn't going to work when you execute it - even if you have no relevant experience with the APIs or protocols.

However, FTDI Chip released a new library just before I left on vacation ( http://www.ftdichip.com/Android.htm ), that I finally got around to test out today. 

The good news ? It actually works. A few hours of playing around, and only about a 100 lines of production code later, the Arduino communication is finally working, stable, and integrated into the solution. I'm just sorry this library wasn't released a few weeks earlier - before I got started with other libs.

The bad news ? Though it's somewhat documented, there doesn't seem to be any source available for this library, and it's not completely bug-free. You'll have to figure out what does and doesn't work simply by trying.

For example, the openByUsbDevice method does not seem to work at all (and was of course the one I wanted to use), and it fails silently. You can use one of the other open... methods that do work, of course, but not until after you've wasted precious time trying to figure out why this one doesn't (I still don't know).

Another snag is that reading data from USB doesn't work from the main thread (while oddly enough, writing data does). Of course, you should never do such a thing in the main thread in production code anyway, but when you're trying to get a feel for an unknown library and doing some quick and dirty tests, these rules usually go out the window.

It's not really a problem or bug that reading doesn't work from the main (UI) thread, but what is a problem is that it fails silently. The read method will happily report that it has read X bytes and no error has occurred, while it has actually done no such thing. Luckily there's a debug line in logcat that indicates data could not be read, or would probably never have figured out what the problem was.

I can and will recommend this library, as it seems to be the only one that somewhat works, but beware of it's newishness and be prepared to hit some snags like those mentioned here.

FTDI Android

doug kuchna commented on 2013-02-19 at 13:02:

lulz, this just got a good laugh around the office:

"but you'd be forgetting this is Android, and nothing really works on Android."

Gad Krumholz commented on 2013-02-19 at 14:36:

So because ftdi driver was not built into kernel (on stock devices) ftdi is now including it as a ndk jni library to be used from userspace?

Chainfire commented on 2013-02-19 at 14:40:

+Gad Krumholz I wouldn't assume it uses ndk or jni, seems to me to be pure java using the USB host API. But I must admit I have not checked that out.

Gad Krumholz commented on 2013-02-19 at 14:46:

+Chainfire oh yeah... Jar files for android can't include jni stuff yet, i forgot about that. If it's fully done in Java you could always try to decompile the classes in the jar using apktool to try and patch the silent failure/make it work the way you need?

Gary Parks commented on 2013-02-19 at 15:49:

That explains a lot. I was looking for a way to do serial port stuff but could not find any apps. Unfortunately I never got passed basic Java.

Joe Philipps commented on 2013-02-19 at 20:06:

Are loadable modules feasible under Android?  if FTDI doesn't come with one's ROM, I'm thinking that might be the way to go.  But then again, that would probably require rooting.

Chainfire commented on 2013-02-19 at 20:44:

+Joe Philipps yes, loadable kernel modules are possible, but they do indeed require root, and many different versions.

jerrick Davis commented on 2013-02-19 at 21:34:

+Chainfire what are your contract rates

Chainfire commented on 2013-02-19 at 21:48:

+jerrick Davis that wholly depends on the project !

jerrick Davis commented on 2013-02-19 at 21:49:

Cool Ill be in contact :-)

Guenther Schmid commented on 2013-02-20 at 07:09:

+Chainfire  We use (in a customer project) the Microchip MCP2200 without problems so far. The crazy stuff is, that most Android devices come without the USB-Host permission (even Galaxy Nexus) - that's something i really don't understand.

Chainfire commented on 2013-02-20 at 11:25:

+Guenther Schmid What do you mean come without the USB host permission ? Most recent devices can do USB host using Android's USB host API. The Galaxy Nexus very first firmwares had an issue, but this was quickly resolved. The Nexus 4 indeed doesn't support it (major cockup by LG), but the GalNex, Nexus 7, Nexus 10, all recent high-end Samsungs (since the S2), the latest Sony's, various Asus devices, even the latest HTCs support it ...

Guenther Schmid commented on 2013-02-20 at 13:01:

+Chainfire Host API and everything is there. But the android.hardware.usb.host.xml in /system/permissions is missing in nearly all devices i got so far. That leads to troubles using the API - which can be avoided by simply placing this file...

Chainfire commented on 2013-02-20 at 21:47:

+Guenther Schmid seriously? I know this problem on some devices, but I haven't seen it on any serious products (only el cheapo's). Certainly not the Galaxy Nexus.

Guenther Schmid commented on 2013-02-21 at 06:11:

+Chainfire Well, we had the same problem on Galaxy Nexus and Nexus7 (bought here in Austria). Maybe Google has resolved the issue meanwhile...

Anyhow, we still have the problem that the USB-API before v17 has no counter for the received bytes (at least none that works correctly) - so there is a problem with async transfer. But for this we're looking for a work around together with Microchip at the moment. So maybe one day we'll have a fully working USB-Serial Adapter available ;-)

This post is over a month old, commenting has been disabled.