tf_archiv Posted December 30, 2011 at 03:48 PM Share Posted December 30, 2011 at 03:48 PM 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 Quote Link to comment Share on other sites More sharing options...
tf_archiv Posted December 30, 2011 at 03:48 PM Author Share Posted December 30, 2011 at 03:48 PM 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 Quote Link to comment Share on other sites More sharing options...
JoergK Posted January 12, 2014 at 06:49 PM Share Posted January 12, 2014 at 06:49 PM 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 Quote Link to comment Share on other sites More sharing options...
benatweb Posted January 12, 2014 at 09:55 PM Share Posted January 12, 2014 at 09:55 PM 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. Quote Link to comment Share on other sites More sharing options...
remotecontrol Posted January 13, 2014 at 06:57 PM Share Posted January 13, 2014 at 06:57 PM 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. Quote Link to comment Share on other sites More sharing options...
Quantasy Posted June 8, 2018 at 01:51 PM Share Posted June 8, 2018 at 01:51 PM 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. Quote Link to comment Share on other sites More sharing options...
borg Posted June 8, 2018 at 03:09 PM Share Posted June 8, 2018 at 03:09 PM 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 Quote Link to comment Share on other sites More sharing options...
photron Posted June 8, 2018 at 07:31 PM Share Posted June 8, 2018 at 07:31 PM 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. Quote Link to comment Share on other sites More sharing options...
photron Posted June 15, 2018 at 05:43 PM Share Posted June 15, 2018 at 05:43 PM 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. Quote Link to comment Share on other sites More sharing options...
Nic Posted June 16, 2018 at 07:00 PM Share Posted June 16, 2018 at 07:00 PM 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 Quote Link to comment Share on other sites More sharing options...
photron Posted June 18, 2018 at 02:38 PM Share Posted June 18, 2018 at 02:38 PM 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. Quote Link to comment Share on other sites More sharing options...
Nic Posted July 5, 2018 at 06:50 AM Share Posted July 5, 2018 at 06:50 AM 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. Quote Link to comment Share on other sites More sharing options...
photron Posted July 5, 2018 at 03:40 PM Share Posted July 5, 2018 at 03:40 PM 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.