6

The Android Accessory SDK relies on the accessory having USB host. However, my understanding is that newer versions of Android (3.1, 2.4?) have USB host support in the kernel. And I know many existing Android devices have hardware support for host (most tablets surely, Moto Droid, HTC Droid Incredible, etc.).

So my question is, given an Android device that has USB host, what will be the simplest/cheapest way to interface this with a micro? The first thing that comes to mind is using an FTDI USB->serial chip and a micro with UART. But I don't know if the FTDI drivers can be put on Android devices. Anyway, there's probably a much better solution.

I'd prefer a solution that doesn't require a rooted Android device, but would be interested to hear some of these options too.

Chinasaur
  • 213
  • 3
  • 9
  • no link right now but I was watching this carefully and they are not planning to make Android support USB OTG or Being a host directly. This means that you really have to use their spec. – Kortuk Jul 12 '11 at 04:30
  • @Kortuk "they" meaning Google may not be planning to, but "they" meaning android device manufacturers already have, particularly in the case of some of the honeycomb tablets - some even have USB "A" ports so no adapter is needed. However, built in drivers are likely to be for things like mass storage, keyboards, and mice, no idea if they include FTDI drivers or if that would require kernel mods. – Chris Stratton Jul 13 '11 at 05:22
  • @ChrisStratton, do you want to make a product built around a few different manufacturers that made decisions before google announced one, which it now has. I wish they had decided to support USBonthego – Kortuk Jul 13 '11 at 07:59
  • @Kortuk as the ADK protocol is a rather ugly solution requiring that the accessory provide external power to charge the android device, I'd say the tradeoff really depends on the market. If the accessory is sold for use with a specific android device depending on device-specific functionality may be fine (In some cases, the price of the accessory may dwarf that of the attached tablet). Conversely, at the extreme low end, being able to use an off the shelf PC oriented USB accessory can also be a fine solution despite the limited compatability, since there's little investment. – Chris Stratton Jul 13 '11 at 17:22
  • @ChrisStratton, still wish they had decided for full support of USB-OTG – Kortuk Jul 13 '11 at 17:23
  • 1
    Wow, that is crazy. Why would they not put usb otg/host into the kernel? Aren't tablet owners going to want to be able to use generic accessories? – Chinasaur Jul 14 '11 at 02:24
  • 1
    Now I'm confused. The Android 3.1 API says explicitly that it supports interaction with both USB accessories (meaning things with host mode) and USB devices (things without host), including things like bulk transport, etc. So isn't this host mode running on the android system? – Chinasaur Jul 14 '11 at 02:37
  • @Chinasaur Interesting... I see that all of this is new in 3.1 (Since: API Level 12). USBManager appears to be a USB Host manager as well. I think this implies that USB-OTG is actually going to be natively supported although I don't see anything in the API to allow switching between Host and Device at the application level - I'm guessing it will do this automatically depending on what just got connected. Care to write up an answer summary as an answer? I'd be interested in seeing all the choices available now. – Jon L Jul 14 '11 at 17:14
  • @Jon, seems I am out of date, will look into it. – Kortuk Jul 14 '11 at 18:08
  • Ah cool, hopefully they are really going to support it! Seems especially crazy not to since the community with rooted phones has already pretty much worked out the kernel modules necessary. And as the Android Accessory model based on an accessory with host is already pretty much just a "blessing" of an existing community project (the USB Host Shield) it would seem especially inconsistent not to leverage the possibility of the Android system supporting host on its own! – Chinasaur Jul 16 '11 at 02:32
  • 1
    So it sounds like maybe getting a micro that can emulate a specific kind of USB device may be the easiest way to work with an Android device that has host capability. I don't know much about different standard USB devices; any links for a simple run down of the capabilities of different ones for interacting with the host? – Chinasaur Jul 16 '11 at 02:34
  • 2
    @Chinasaur, Here's a list of all USB device classes: http://www.usb.org/developers/devclass_docs#approved Most USB micros have example code for HID (keyboard/mouse) and Mass storage. Perhaps you can use these to your advantage. Also, if you can write up an answer summary, it would be much appreciated. I think this info could be helpful to others wanting to go down this road. – Jon L Jul 29 '11 at 17:00

5 Answers5

4

The cheapest way? Use a µC with USB built in. Many of the pic18 and upwards have this. So do many other makes of µC.

The simplest way? As you already state - convert it to RS-232 at TTL levels with some form of conversion chip like the FTDI.

Yes, there could well be problems with drivers for both solutions, but it is more likely the FTDI will be supported out of the box. However, the first solution has the advantage that you can make the µC look like whatever device you want it to look like.

Oh, and as an aside - some of the high end PICs (eg some pic32 chips) have USB host built in as well. Just thought I'd mention it...

Majenko
  • 55,955
  • 9
  • 105
  • 187
4

I'm no expert on Android but FTDI released an app note detailing how you can build in driver support for their USB to Serial IC's into the android kernel.

I don't know if this is feasible to do on a production phone, or if any phones have this driver already built in (I doubt it). In my opinion, Google has laid out a good specification for Open Accessory which will most likely be available on this generation of Android devices and the next given that they all update to the newer Android OS versions.

In the Open Accessory case, the phone switches over to a device and the accessory is the host. Implementing an embedded USB Host is a bit more complicated than using an FTDI USB to Serial IC but there are some pretty good application-specific micros out there that have hardware support for the USB stack and there are some examples out there of the Open Accessory protocol implemented on some of these micros. Given that the support is already in the OS for Open Accessory (or will be in the near future for all devices), I think this is the way to go.

Jon L
  • 4,258
  • 1
  • 22
  • 33
  • Yes, but this is the "old" way predating official support - with the exception of built-in capabilities like keyboards and mice, the Android USB host APIs expect user-mode code contained in individual apps to talk raw USB operations. Conceptually, it's a lot like a desktop app written against libusb, rather than relying on a kernel driver for the peripheral. – Chris Stratton Jul 22 '14 at 17:31
4

Update: I switched this over to community wiki

It looks like Android is going to support USB Host in the kernel. Android 3.1 already has this, I think Android 2.4 will have it back ported, and surely Android 4 will have it. Therefore if you have a micro that can emulate an appropriate USB slave device, you should be able to communicate with Android fairly simply and cheaply as long as your Android device is hardware capable of USB Host. Most older devices (e.g. Droid, Droid Inc) are hardware capable, and new devices should be.

I don't know exactly which USB slave devices are easy to interact with from Android (here's a list of existing device types), but surely keyboard (i.e. HID) is an easy one to try.

Edit: The Android USB host APIs are based around the idea of having user-mode code contained within applications make raw USB transfers to peripherals. So instead of the "kernel driver" model, this is the "application understands peripheral details" one - conceptually very similar to desktop programs which use libusb or similar to talk to a peripheral. The exceptions would be HID devices such as keyboards and mice which Android talks to itself and utilizes in the expected fashion to provide input to the system in general. It's also worth noting that (with the exception of a few devices where the vendor has done otherwise) USB mass storage is not implemented by the system, so an app which wants to use such a device has to to implement both file system code and the USB mass storage protocol, against the raw android USB APIs.

There is an AVR library that provides a USB stack: http://fourwalledcubicle.com/LUFA.php. With this you should be able to do keyboard or other device emulation from a USB enabled AVR. Including this in your generic AVR firmware build is not too difficult. As Mihailo points out in the comments, make sure you use an oscillator frequency compatible with USB (8 or 16 MHz). I'm not sure whether it's possible to get this working on standard Arduino hardware.

It looks like the easiest way to approach this may be the new Arduino Leonardo board: http://arduino.cc/blog/2011/09/17/arduino-launches-new-products-in-maker-faire/

I'm sure cheaper/simpler/smaller Leonardo clones will come out soon, or roll your own!

Chris Stratton
  • 33,282
  • 3
  • 43
  • 89
Chinasaur
  • 213
  • 3
  • 9
  • 1
    ATMega8u2 is the cheapest you can go, ATMega32u4 is like a bigger brother (featured in Leonardo). For a minimal board you literally need 5 passive components to make it working. Also it has a DFU (Device Firmware Upgrade) Bootloader so you just plug it in a USB port for programming - no external programmer required. LUFA comes with lots of example drivers (Keyboard, Mouse, Joystick, ...) and it's dead simple to make and test them (and subsequently tailor them to your needs). Just make sure you use 8 or 16 MHz crystal, otherwise USB won't work. – Mihailo Sep 20 '11 at 08:31
  • All great points; thanks! By cheaper I mean an Arduino Leonardo compatible will come out cheaper than the official $20. But of course putting it together yourself is probably cheaper still and as you say pretty straightforward. I edited my answer to reflect some of your points. – Chinasaur Sep 20 '11 at 09:09
  • BTW, is this why Arduino is 16MHz? I always thought that was a weird choice... – Chinasaur Sep 20 '11 at 09:14
  • Probably it is, I'm not sure, older Arduino (the one I have) had FTDI USB to Serial chip, the newer ones have ATMEGA8U2. I haven't looked at schematics of the new ones, if they are using only one crystal I'd say it is because ATMEGA8U2 requires it. – Mihailo Sep 20 '11 at 14:33
0

I am not sure what do you exactly mean by cheap, but I don't think there is any problem using FTDI UART->USB chip like FT232RL or Prolific PL2303.. They're cheap.

Still obviously there are two ways to do this:

  1. Get an MCU with USB support:

Advantages:

A. You won't need any external chip to convert levels or implement any protocol.

Disadvantages:

A. You will need to implement the USB protocol with the Class you need (Like, CDC, HID, etc.) in your firmware all by yourself.

B. You will need to buy a VID and PID if your MCU manufacturer does not allow to use the default VID and PID.

  1. Use FTDI chip:

Advantages:

A. You don't need to implement the protocol. A simple UART communication would be fine.

B. Android supports FTDI perfectly. I am not sure what, "need to install the drivers in Android Phone" means but in my experience the only thing you need to recognize a device in android is VID and PID, which you put into intent-filter of your activity provided that Android and Host both supports the class you want to implement.

Disadvantages:

A. If you can afford the chip, I don't think there are any.

A suggestion:

If your MCU does not do any function (run processes in parallel threads or implements several Interrupt Request Subroutines, have event oriented callbacks or interfaced with too many peripherals) other than USB communication then go for a MCU with USB support otherwise FTDI chip is always better option as it only uses an UART of MCU and does not overload it at all.

krushna ratnaparkhi
  • 31
  • 4
-1

Have you considered Arduino ADK board? It exploits Google ADK to achieve communication with Android.

avra
  • 1,872
  • 3
  • 14
  • 21
  • 1
    Thanks, but the ADK requires the accessory to implement USB Host (thus it's much more expensive than a standard Arduino/micro). The idea of this question is to avoid implementing USB Host. – Chinasaur Sep 20 '11 at 12:32