Zubehör für Android-Geräte mit USB-Host

Das Android-Zubehör-SDK ist darauf angewiesen, dass das Zubehör über einen USB-Host verfügt. Mein Verständnis ist jedoch, dass neuere Versionen von Android (3.1, 2.4?) USB-Host-Unterstützung im Kernel haben. Und ich weiß, dass viele vorhandene Android-Geräte Hardwareunterstützung für Hosts haben (die meisten Tablets sicherlich, Moto Droid, HTC Droid Incredible usw.).

Meine Frage ist also, was bei einem Android-Gerät mit USB-Host der einfachste / billigste Weg ist, dies mit einem Mikro zu verbinden? Das erste, was mir in den Sinn kommt, ist die Verwendung eines FTDI USB-> Serial-Chips und eines Mikros mit UART. Aber ich weiß nicht, ob die FTDI-Treiber auf Android-Geräten installiert werden können. Wie auch immer, es gibt wahrscheinlich eine viel bessere Lösung.

Ich würde eine Lösung bevorzugen, die kein gerootetes Android-Gerät erfordert, wäre aber auch daran interessiert, einige dieser Optionen zu hören.

kein Link im Moment, aber ich habe mir das genau angesehen und sie planen nicht, dass Android USB OTG unterstützt oder direkt ein Host ist. Dies bedeutet, dass Sie wirklich ihre Spezifikation verwenden müssen.
@Kortuk "sie" bedeutet, dass Google dies möglicherweise nicht plant, aber "sie", was bedeutet, dass Android-Gerätehersteller dies bereits haben, insbesondere im Fall einiger der Wabentabletten - einige haben sogar USB-A-Anschlüsse, sodass kein Adapter erforderlich ist. Eingebaute Treiber sind jedoch wahrscheinlich für Dinge wie Massenspeicher, Tastaturen und Mäuse gedacht, keine Ahnung, ob sie FTDI-Treiber enthalten oder ob dies Kernel-Mods erfordern würde.
@ChrisStratton, möchten Sie ein Produkt entwickeln, das auf einigen verschiedenen Herstellern basiert, die Entscheidungen getroffen haben, bevor Google eines angekündigt hat, das es jetzt hat. Ich wünschte, sie hätten sich entschieden, USBonthego zu unterstützen
@Kortuk Da das ADK-Protokoll eine ziemlich hässliche Lösung ist, die erfordert, dass das Zubehör eine externe Stromversorgung zum Laden des Android-Geräts bereitstellt, würde ich sagen, dass der Kompromiss wirklich vom Markt abhängt. Wenn das Zubehör für die Verwendung mit einem bestimmten Android-Gerät verkauft wird, kann es je nach gerätespezifischer Funktionalität in Ordnung sein (in einigen Fällen kann der Preis des Zubehörs den des angeschlossenen Tablets in den Schatten stellen). Umgekehrt kann die Verwendung eines handelsüblichen PC-orientierten USB-Zubehörs im extremen Low-End-Bereich trotz der begrenzten Kompatibilität auch eine gute Lösung sein, da nur geringe Investitionen erforderlich sind.
@ChrisStratton, ich wünschte immer noch, sie hätten sich für die volle Unterstützung von USB-OTG entschieden
Wow, das ist verrückt. Warum sollten sie usb otg/host nicht in den Kernel einfügen? Werden Tablet-Besitzer nicht generisches Zubehör verwenden wollen?
Jetzt bin ich verwirrt. Die Android 3.1-API sagt ausdrücklich, dass sie die Interaktion sowohl mit USB-Zubehör (d. h. Dinge mit Host-Modus) als auch mit USB-Geräten (Dinge ohne Host) unterstützt, einschließlich Dingen wie Massentransport usw. Läuft dieser Host-Modus also nicht auf dem Android-System? ?
@Chinasaur Interessant ... Ich sehe, dass dies alles neu in 3.1 ist (seit: API Level 12). USBManager scheint auch ein USB-Host-Manager zu sein. Ich denke, dies impliziert, dass USB-OTG tatsächlich nativ unterstützt wird, obwohl ich nichts in der API sehe, um das Umschalten zwischen Host und Gerät auf Anwendungsebene zu ermöglichen - ich vermute, es wird dies automatisch tun, je nachdem, was gerade ist verbunden wurde. Möchten Sie eine Antwortzusammenfassung als Antwort verfassen? Ich würde mich freuen, alle verfügbaren Optionen zu sehen.
@ Jon, scheint ich veraltet zu sein, werde es mir ansehen.
Ah cool, hoffentlich werden sie es wirklich unterstützen! Scheint besonders verrückt zu sein, da die Community mit gerooteten Telefonen die notwendigen Kernel-Module bereits ziemlich ausgearbeitet hat. Und da das Android-Zubehörmodell, das auf einem Zubehör mit Host basiert, bereits so ziemlich nur ein „Segen“ eines bestehenden Community-Projekts (des USB Host Shield) ist, erscheint es besonders widersprüchlich, die Möglichkeit nicht zu nutzen, dass das Android-System Host auf seinem unterstützt besitzen!
Es klingt also so, als wäre es vielleicht der einfachste Weg, mit einem Android-Gerät mit Host-Fähigkeit zu arbeiten, ein Mikro zu bekommen, das eine bestimmte Art von USB-Gerät emulieren kann. Ich weiß nicht viel über verschiedene Standard-USB-Geräte; Irgendwelche Links für einen einfachen Überblick über die Fähigkeiten verschiedener für die Interaktion mit dem Host?
@Chinasaur, hier ist eine Liste aller USB-Geräteklassen: usb.org/developers/devclass_docs#approved Die meisten USB-Mikros haben Beispielcode für HID (Tastatur/Maus) und Massenspeicher. Vielleicht können Sie diese zu Ihrem Vorteil nutzen. Auch wenn Sie eine Antwortzusammenfassung schreiben könnten, wäre dies sehr zu schätzen. Ich denke, diese Informationen könnten für andere hilfreich sein, die diesen Weg gehen möchten.

Antworten (5)

Der billigste Weg? Verwenden Sie einen µC mit eingebautem USB. Viele der pic18 und höher haben dies. Das gilt auch für viele andere Hersteller von µC.

Der einfachste Weg? Wie Sie bereits gesagt haben, konvertieren Sie es mit einer Form von Konvertierungschip wie dem FTDI auf TTL-Pegel in RS-232.

Ja, es könnte durchaus Probleme mit Treibern für beide Lösungen geben, aber es ist wahrscheinlicher, dass FTDI standardmäßig unterstützt wird. Die erste Lösung hat jedoch den Vorteil, dass Sie den µC so aussehen lassen können, wie Sie es möchten.

Oh, und nebenbei - einige der High-End-PICs (z. B. einige pic32-Chips) haben auch einen USB-Host eingebaut. Ich dachte nur, ich erwähne es...

Warum die Ablehnung? Etwas konstruktive Kritik wäre nett...

Ich bin kein Android-Experte, aber FTDI hat einen App-Hinweis veröffentlicht, in dem beschrieben wird, wie Sie Treiberunterstützung für ihre USB-to-Serial-ICs in den Android-Kernel einbauen können .

Ich weiß nicht, ob dies auf einem Produktionstelefon möglich ist oder ob dieser Treiber bereits in Telefone integriert ist (ich bezweifle es). Meiner Meinung nach hat Google eine gute Spezifikation für Open Accessory erstellt, die höchstwahrscheinlich auf dieser und der nächsten Generation von Android-Geräten verfügbar sein wird, da sie alle auf die neueren Android-Betriebssystemversionen aktualisiert werden.

Im Fall von Open Accessory schaltet das Telefon auf ein Gerät um und das Zubehör ist der Host. Die Implementierung eines eingebetteten USB-Hosts ist etwas komplizierter als die Verwendung eines FTDI-USB-zu-Seriell-ICs, aber es gibt einige ziemlich gute anwendungsspezifische Mikros, die Hardwareunterstützung für den USB-Stack bieten, und es gibt einige Beispiele für das Open Accessory-Protokoll auf einigen dieser Mikros implementiert. Angesichts der Tatsache, dass die Unterstützung für Open Accessory bereits im Betriebssystem vorhanden ist (oder in naher Zukunft für alle Geräte verfügbar sein wird), denke ich, dass dies der richtige Weg ist.

Ja, aber dies ist die "alte" Methode, die vor der offiziellen Unterstützung liegt - mit Ausnahme von integrierten Funktionen wie Tastaturen und Mäusen erwarten die Android-USB-Host-APIs in einzelnen Apps enthaltenen Benutzermoduscode, um rohe USB-Operationen zu übertragen. Konzeptionell ähnelt es einer Desktop-App, die gegen libusb geschrieben wurde, anstatt sich auf einen Kernel-Treiber für das Peripheriegerät zu verlassen.

Update: Ich habe dies auf das Community-Wiki umgestellt

Es sieht so aus, als würde Android USB-Host im Kernel unterstützen. Android 3.1 hat dies bereits, ich denke, Android 2.4 wird es zurückportiert haben, und Android 4 wird es sicherlich haben. Wenn Sie also ein Mikro haben, das ein geeignetes USB-Slave-Gerät emulieren kann, sollten Sie in der Lage sein, ziemlich einfach und kostengünstig mit Android zu kommunizieren, solange Ihr Android-Gerät USB-Host-fähig ist. Die meisten älteren Geräte (z. B. Droid, Droid Inc) sind hardwarefähig, und neue Geräte sollten es sein.

Ich weiß nicht genau, mit welchen USB-Slave-Geräten von Android aus leicht zu interagieren ist ( hier ist eine Liste vorhandener Gerätetypen ), aber Tastatur (dh HID) ist sicherlich einfach auszuprobieren.

Bearbeiten: Die Android-USB-Host-APIs basieren auf der Idee, dass in Anwendungen enthaltener Benutzermoduscode rohe USB-Übertragungen an Peripheriegeräte durchführt. Anstelle des "Kernel-Treiber"-Modells ist dies also das Modell "Anwendung versteht Peripheriedetails" - konzeptionell sehr ähnlich zu Desktop-Programmen, die libusb oder ähnliches verwenden, um mit einem Peripheriegerät zu kommunizieren. Die Ausnahmen wären HID-Geräte wie Tastaturen und Mäuse, die Android mit sich selbst spricht und in der erwarteten Weise verwendet, um Eingaben für das System im Allgemeinen bereitzustellen. Es ist auch erwähnenswert, dass (mit Ausnahme einiger Geräte, bei denen der Hersteller etwas anderes getan hat) USB-Massenspeicher nicht vom System implementiert werden, sodass eine App, die ein solches Gerät verwenden möchte, sowohl den Dateisystemcode als auch den implementieren muss USB-Massenspeicherprotokoll gegen die rohen Android-USB-APIs.

Es gibt eine AVR-Bibliothek, die einen USB-Stack bereitstellt: http://fourwalledcubicle.com/LUFA.php . Damit sollten Sie in der Lage sein, Tastatur- oder andere Geräteemulationen von einem USB-fähigen AVR durchzuführen. Es ist nicht allzu schwierig, dies in Ihren generischen AVR-Firmware-Build aufzunehmen. Wie Mihailo in den Kommentaren betont, stellen Sie sicher, dass Sie eine Oszillatorfrequenz verwenden, die mit USB kompatibel ist (8 oder 16 MHz). Ich bin mir nicht sicher, ob es möglich ist, dies auf Standard-Arduino-Hardware zum Laufen zu bringen.

Es sieht so aus, als wäre der einfachste Weg, dies zu erreichen, das neue Arduino Leonardo Board: http://arduino.cc/blog/2011/09/17/arduino-launches-new-products-in-maker-faire/

Ich bin mir sicher, dass bald billigere/einfachere/kleinere Leonardo-Klone herauskommen werden, oder rollen Sie Ihre eigenen!

ATMega8u2 ist das billigste, das Sie kaufen können, ATMega32u4 ist wie ein größerer Bruder (in Leonardo enthalten). Für ein minimales Board braucht man buchstäblich 5 passive Komponenten, damit es funktioniert. Außerdem verfügt es über einen DFU-Bootloader (Device Firmware Upgrade), sodass Sie es zum Programmieren einfach an einen USB-Anschluss anschließen – kein externer Programmierer erforderlich. LUFA wird mit vielen Beispieltreibern (Tastatur, Maus, Joystick, ...) geliefert und es ist kinderleicht, sie zu erstellen und zu testen (und sie anschließend an Ihre Bedürfnisse anzupassen). Stellen Sie nur sicher, dass Sie 8 oder 16 MHz Quarz verwenden, sonst funktioniert USB nicht.
Alles tolle Punkte; Danke! Mit billiger meine ich, dass ein Arduino Leonardo-kompatibles Gerät billiger herauskommt als die offiziellen 20 Dollar. Aber natürlich ist es wahrscheinlich noch billiger, es selbst zusammenzubauen, und wie Sie sagen, ziemlich einfach. Ich habe meine Antwort bearbeitet, um einige Ihrer Punkte widerzuspiegeln.
BTW, ist das der Grund, warum Arduino 16 MHz hat? Ich fand das immer eine komische Wahl...
Wahrscheinlich ist es, ich bin mir nicht sicher, dass ältere Arduino (die, die ich habe) einen FTDI-USB-zu-Seriell-Chip hatten, die neueren haben ATMEGA8U2. Ich habe mir die Schaltpläne der neuen nicht angesehen. Wenn sie nur einen Kristall verwenden, würde ich sagen, dass dies daran liegt, dass ATMEGA8U2 dies erfordert.

Ich bin mir nicht sicher, was Sie genau mit billig meinen, aber ich glaube nicht, dass es Probleme mit der Verwendung von FTDI UART-> USB-Chips wie FT232RL oder Prolific PL2303 gibt. Sie sind billig.

Dennoch gibt es offensichtlich zwei Möglichkeiten, dies zu tun:

  1. Holen Sie sich eine MCU mit USB-Unterstützung:

Vorteile:

A. Sie benötigen keinen externen Chip, um Pegel umzuwandeln oder ein Protokoll zu implementieren.

Nachteile:

A. Sie müssen das USB-Protokoll mit der von Ihnen benötigten Klasse (wie CDC, HID usw.) in Ihrer Firmware selbst implementieren.

B. Sie müssen eine VID und PID kaufen, wenn Ihr MCU-Hersteller die Verwendung der Standard-VID und -PID nicht zulässt.

  1. FTDI-Chip verwenden:

Vorteile:

A. Sie müssen das Protokoll nicht implementieren. Eine einfache UART-Kommunikation wäre in Ordnung.

B. Android unterstützt FTDI perfekt. Ich bin mir nicht sicher, was "Treiber in Android Phone installieren müssen" bedeutet, aber meiner Erfahrung nach ist das einzige, was Sie brauchen, um ein Gerät in Android zu erkennen, VID und PID, die Sie in den Intent-Filter Ihrer Aktivität einfügen, vorausgesetzt, dass Android und Host unterstützen beide die Klasse, die Sie implementieren möchten.

Nachteile:

A. Wenn Sie sich den Chip leisten können, ich glaube nicht, dass es welche gibt.

Ein Vorschlag:

Wenn Ihre MCU keine anderen Funktionen als die USB-Kommunikation ausführt (Prozesse in parallelen Threads ausführen oder mehrere Interrupt Request Subroutinen implementieren, ereignisorientierte Callbacks haben oder mit zu vielen Peripheriegeräten verbunden sind), dann entscheiden Sie sich für eine MCU mit USB-Unterstützung, andernfalls ist der FTDI-Chip immer besser Option, da sie nur einen UART der MCU verwendet und ihn überhaupt nicht überlastet.

Haben Sie das Arduino ADK- Board in Betracht gezogen? Es nutzt Google ADK , um die Kommunikation mit Android zu erreichen.

Danke, aber das ADK benötigt das Zubehör, um den USB-Host zu implementieren (daher ist es viel teurer als ein Standard-Arduino / Micro). Die Idee dieser Frage ist es, die Implementierung eines USB-Hosts zu vermeiden.