Kann man neben den Lösung den Umweg über den PC zu gehen unter Android auch dire

[tf_archiv]

Ist es möglich bei gerooteten Android Handy mit USB-OTG hostmode Port direkt zugriff auf die Bricks per USB zu bekommen? Ohne wie in einer anderen Frage erklärte Lösung über IP? Vermutlich muss zur Stromversorgung dann ein Step-Down Powersupply herhalten.

 

Beispiel: Galaxy Nexus mit USB Hostmode Port gerootetes Android Custom Kernel um eventuell notwendige KernelModule zu kompilieren?

 

MasterBrick Step-Down Powersupply

[tf_archiv]

Die Frage hier ist m.E. die, ob Android einen PC ersetzen kann. Frage: Wenn Du einen USB-Stick an dein Handy im Hostmode anschließt, wird dieser als Speicher erkannt?

Gruß Pascal

[JoergK]

Hallo,

 

Auch ich möchte meine Anwendung über usb vom Handy aus steuern.

 

Da ich tinkerforge so verstanden habe, dass es ohne rechnersteuerung nutzlos ist, muss also eine kostengünstige alternative herhalten. Die meisten haben ja ein smartphone zuviel (gibt ja immer wieder so schöne neue Dinger

 

Daher die Auffrischung dieses Threads. Hat schon jemand Erfahrung sammeln können mit o.g. USB-OTG hostmode (ja die Dinger erkennen usb-sticks).

 

Da ich für meine Anwendung nur Basis-Komponenten (Master|IO16) nutze um ein Proof of Concept durchzuführen, will ich mir vorerst kein sau teures wlan-brick anschaffen, nur um zu sehen, dass mein Konzept so nicht funktioniert. Um Erfahrungsberichte wäre ich und sicherlich auch tinkerforge dankbar. Denn dann hätten die einen neuen kunden, der den ein oder anderen mitbringen wird

 

Beste Grüße

Jörg

[benatweb]

Das Problem sollte vmtl. weniger der USB-OTG Modus sein - sondern eher, ob du die nötigen Dependencies für den brickd (Host-Programm für die USB-Verbindung zum Brick) irgendwie auf dem Smartphone installieren kannst:

 

http://www.tinkerforge.com/de/doc/Software/Brickd_Install_Linux.html#brickd-install-linux

 

Schätze, das zu versuchen (es sei denn, du kennst dich mit Android-Interna gründlich genug aus) wird den Aufwand nicht wirklich lohnen...

 

Ein Raspberry Pi oder die Ethernet-Extension dürften die einfachere Alternative sein falls es wirklich nicht am Rechner hängen kann.

[remotecontrol]

Ich wär mir nicht sicher, ob sich der brickd so einfach mit dem Android NDK übersetzen lässt und dann auch noch die USB-Dependencies vorhanden sind.

 

Ich kann auch nur empfehlen, zuerst mal den Stack per WIFI anzubinden oder Ethernet und dazu die passende App auf dem Handy zu schreiben. Das ist noch überschaubar. Und danach kann man ja einen brickd in Java für Android schreiben  .

 

OTG hat auch noch den Nachteil, dass das Handy zu der Zeit nicht geladen wird -> für Dauerbetrieb nicht so gut geeignet.

[Quantasy]

Ich wollte mal nachfragen, ob sich da was tun lässt?

Wenn ich's richtig verstehe, soll das Android im USB-Host-Mode an das Masterbrick angehängt werden. Dabei ist ein laden offenbar möglich:

 

https://electronics.stackexchange.com/questions/34741/can-an-android-tablet-serve-as-usb-host-and-be-charged-simultaneously-through-a

 

 

Den brickd direkt auf dem 'alten' Android laufen zu lassen und das TF-Konstrukt damit über USB zu speisen (Mit Daten und mit Energie), wäre ein geniales Recycling-Projekt (Gibt sicher EU-Subventionen dafür ;-)  )

 

Dabei würde sogar ein kurzzeitiger Powerloss vom 'alten' Akku des Android-Phones überbrückt werden.

 

Würde das TF-Team sowas in Angriff nehmen wollen?

Wenn nicht, gäbe es eine genauere Spez des brickd, sodass das in einer Projektarbeit extern erarbeitet werden kann?

 

Oder gilt hier: Code = Doc? (Ist nur eine Frage, keine Anschuldigung)

 

Ziel:

brickd als .apk runterladen können und TF-Bricks über USB am Android-Gerät anschliessen.

 

 

 

[borg]

Grundsätzlich sollte es denke ich möglich sein brickd für Android mit dem NDK zu portieren (in der bestehenden Codebasis, ohne ein neues Projekt anzufangen). Die einzige wichtige Abhängigkeit die wir haben ist libusb und die scheint man mit dem NDK auch zum laufen zu bekommen: https://github.com/libusb/libusb/tree/master/android

 

Wir sind natürlich für Patches/Pull Requests offen, auch Erfahrungswerte welche Schwierigkeiten etc es bei einem Portierungsversuch gab wären bereits hilfreich.

 

Die Idee brickd für Android zu portieren hatten wir natürlich auch bereits, steht bei uns allerdings nicht hoch auf der Prioritätenliste.

 

Edit: Als Bachelorarbeit o.ä. könnte ich mir das auch gut vorstellen.

 

Edit2: Unser Protokoll ist hier definiert: https://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html

[photron]

Ich habe da mal gerade einen ersten Schuss gemacht. Im brickd git unter src/build_data/android/brickd liegt jetzt ein Android Studio Projekt, dass mittels NDK den brickd C Code in eine Android App verpackt.

 

brickd an sich funktioniert und ich kann mich von meinem PC aus mit Brick Viewer auf mein Android Phone verbinden.

 

Was noch fehlt ist eine funktionierende libusb Version. libusb kann für Android kompiliert werden. Dem Android Studio Projekt unter src/build_data/android/brickd habe ich eine kompiliert libusb Version beigelegt. Aber der libusb_init Aufruf schlägt fehl, da die offizielle libusb Version nicht mit den Restriktionen eines nicht-gerooteten Android Phones umgehen kann.

 

Das ist ein bekanntes Problem, aber kein großes Problem, denke ich. Es finden sich genug Forks von libusb auf GitHub, die sich mit diesem Problem befassen. Da muss man sich jetzt nur das passende heraussuchen.

[photron]

libusb funktioniert jetzt auch. Es fehlen noch ein paar Dinge, das ganze ist aber jetzt erstmal grundsätzlich funktional und funktioniert auch runter bis Android 4.4.

[Nic]

Hammer! Damit habt ihr den Bricks nochmal einen richtigen Quantenschub gegeben

 

Konnte das Projekt nach Upgrade auf Android Studio v3, downloads des NDK und einigen Zusatzlibs prima bauen und per ADB Remote Connection auf ein (Ur-)altes WikoBloom mit Android 4.4.2 deployen und starten.

Im Gradle ist MinSdk API 15 also Support bis runter auf Android 4.0.3.

 

Allerdings muss der Brick-Stack vor dem App-Start am USB-Port angeschlossen werden. Ein Enumerate durch Hotplug geht nicht. Auf einem Win10 und BrickViewer kann ich mich mit dem Stack verbinden und die Bricks/Bricklets werden gelistet. Super!

 

Also wenn man jetzt noch in der Main-Activity UI die Log-Ausgaben zeigt und in der Android API z.B. das USB-Connect Event abgreifen könnte, um ein Enumerate auszulösen, wäre für mich schon Weihnachten

[photron]

Nic, freut mich das es funktioniert. Das zeigt mir, dass ich z.B. nicht vergessen habe die Hälfte der relevanten Dateien zu committen

 

Ich habe jetzt auch Hotplug hinzugefügt.

 

Zwei Dinge die jetzt noch fehlen: eine Möglichkeit die Konfiguration zu ändern und das Log einsehen zu können.

[Nic]

Wenn mit der aktuellen Android Version die Orientierung des Gerätes verändert wird (Hoch- zu Querformat), erzeugt die App die Main Activity neu und vermutlich auch den Service des Brickd. Es scheint die App/Service hängt sich auf und lässt sich nur mittels eines Task-Managers vernünftig killen.

[photron]

Standardmäßig ist es so, dass Android eine Activity bei Config Änderungen wie Rotation neustartet. Die brickd App startet im onCreate der Activity den Service uns stoppt ihn im onDestroy. Im Service läuft der eigentliche brickd Code.

 

Das Problem hier ist jetzt, dass der Service in einem extra Thread die C main() Funktion von brickd aufruft. Der Neustart der Activity und des Service führt jetzt dazu, dass main() verlassen und dann nochmal aufgerufen wird.

 

Das ist etwas was in der normalen Version von brickd nicht passiert. Wenn dort main() verlassen wird, dann endet der Prozess. Daher kommen einige Teile des brickd C Codes nicht damit klar, dass main() ein zweites mal aufgerufen wird. Weil beim zweiten Aufruf von main() gewissen Annahmen, die der Code über den Zustand des Programms macht, nicht mehr gelten.

 

Die kurzfristige Lösung ist es den Neustart der Activity und damit des Services und damit des zweiten main() Aufrufs zu unterbinden. Dazu muss die Activity angeben, dass es die Config Änderungen wie Rotation selbst behandeln kann und daher nicht neugestartet werden muss. Das habe ich jetzt erstmal eingebaut.

 

Die langfristige Lösung wird sein dem C Code beizubringen, dass main() auch mehrfach aufgerufen werden kann. Potentiell muss auch das Verhältnis von Activity und Service zu einander anders gebaut werden.