Hallo, ich bin auf der Suche nach einem Terminalprogramm das VT100-Kommandos versteht, auf Android läuft und über USB und FTDI-Chip mit einem Microcontroller spricht. Auf dem PC geht das perfekt mit Teraterm. Ich habe da diverse AT_mega-Anwendungen, die komplett embedded laufen, und nur zur Inbetriebnahme einige Parameter einzustellen haben. Da rentiert sich kein eigenes Windows-Gui auf dem PC, das man dann auch noch versionskompatibel mitpflegen muss. Aber direkt über Kommandozeile eingeben ist doch zu umständlich. Drum hab ich da vor vielen Jahren mal so eine semigraphische Oberfläche geschrieben, die kaum Speicher braucht und auf der Microcontrollerapplikation mit läuft. Und die läuft halt über VT100-Kommandos. Die Kommunikation zwischen Handy und AT-Mega funktioniert schon, nur mein Terminal versteht halt keine ESC-Sequenzen. Ich weiß, es ist uralt-Zeugs, aber wäre halt schön, wenn man nicht immer das Notebook mitschleppen müsste und einfach das Handy anstöpseln könnte. Hat da jemand einen heißen Tipp?
Als Programm würde z.B. picocom unter Termux funktionieren.
Aber das Problem ist vermutlich:
auf Android läuft und über USB und FTDI-Chip mit einem
Für den FTDI-Chip brauchst Du ein Android-ROM was den passenden Kerneltreiber für FTDI enthält.
Wenn Du Dir nen Lineage etc. selbst baust kein Problem, wenn das Android vom Gerätehersteller kommt habe ich so meine Zweifel ob das mit einkompliert ist.
Für den FTDI-Chip brauchst Du ein Android-ROM was den passenden Kerneltreiber für FTDI enthält.
Wieso sollten sie nicht dabei sein? Nicht nur die Sensoren unserer Firma nutzen diese (und auch andere) Bridges für die Verbindung mit der dazugehörigen App. Bisher ist mir kein Android-Handy bekannt, mit dem das nicht gehen würde.
Gruß Jobst
Bin nicht sicher ob es VT100 unterstützt aber grundsätzlich funktioniert diese App sehr gut unter jedem Android:
https://play.google.com/store/apps/details?id=de.kai_morich.serial_usb_terminal
Für den FTDI-Chip brauchst Du ein Android-ROM was den passenden Kerneltreiber für FTDI enthält.
Wieso sollten sie nicht dabei sein?
Weil der Smartphone -Hersteller die Treiber nicht mitkompiliert hat. Und selbst wenn, bekommen normale Apps keinen Zugriff auf /dev/ttyUSB etc.
Macht aber nichts, o.g. App greift direkt auf das USB-Gerät zu über das US Manager API von Android, und implementiert die FTDI Treiber im Userspace über diese Library: https://github.com/mik3y/usb-serial-for-android . Dadurch ist es völlig egal welche Treiber im Kernel mitgeliefert sind.
Nicht nur die Sensoren unserer Firma nutzen diese (und auch andere) Bridges für die Verbindung mit der dazugehörigen App
Wie greift die App auf die serielle Schnittstelle zu? open("/dev/ttyUSB...") geht IIRC nicht (im Allgemeinen).
Bin nicht sicher ob es VT100 unterstützt
Ziemlich sicher nicht, da steht
"'Serial USB Terminal' ist ein zeilenorientiertes Terminal Programm"
Das ist also genausowenig ein Terminalprogramm wie es "hterm" ist, sondern nur ein serieller Monitor mit der Möglichkeit, komplette Zeichenketten an die Gegenstelle zu senden.
Ein Terminalprogramm emuliert ein Terminal (wie eben vt100) und sendet daher jeden einzelnen Tastendruck unmittelbar an die Gegenseite, denn anders ist so etwas wie z.B. vi oder ein beliebiger anderer Editor über die serielle Verbindung nicht verwendbar.
Durch die modische Verwässerung und Neudefinition etablierter Begriffe wie z.B. "Terminal" wird das natürlich immer unverständlicher.
Ein Terminal ist ein Stück Hardware, das ist ein (kleiner) Computer mit Bildschirm und Tastatur, der über eine serielle Schnittstelle mit irgendeinem Gegenstück kommuniziert. Das Terminal sendet Tastendrücke an die Gegenstelle, und empfängt Steuerkommandos von dieser, die die Bildschirmausgabe steuern. Verbreitet ist da der VT100-Befehlssatz, es gab aber auch viele andere Terminals (vt52, tvi950 etc. pp.)
Terminalprogramme unter Windows sind so etwas wie Hyperterminal (war früher mal im Lieferumfang von Windows enthalten), Teraterm oder auch putty.
Das hier wäre ein Terminalprogramm für Android:
https://www.kanda.com/sena-bterm-android.php
allerdings fehlt da die USB-Unterstützung, das möchte gerne via BT kommunizieren.
Das hier wäre ein Terminalprogramm für Android:
https://www.kanda.com/sena-bterm-android.php
allerdings fehlt da die USB-Unterstützung, das möchte gerne via BT kommunizieren.
Das wäre ja noch viel komfortabler, es gibt ja BT<->Seriell Konverter mit Batteriebetrieb oder 9 bis 36 Volt für Tragschiene oder HC0x oder...
Gibt es so Programm vielleicht auch für iOS?
Ziemlich sicher nicht, da steht
"'Serial USB Terminal' ist ein zeilenorientiertes Terminal Programm"
Ja stimmt, es ist kein vollwertiges Terminal und kann kein VT100. Man könnte auf Basis der gleichen Technologie ( usb-serial-for-android Library ) ein VT100-Terminal implementieren, aber ob sich das lohnt...
Durch die modische Verwässerung und Neudefinition etablierter Begriffe wie z.B. "Terminal" wird das natürlich immer unverständlicher.
Eigentlich wäre der korrekte Begriff "Terminal emulator".
Die Kommunikation zwischen Handy und AT-Mega funktioniert schon, nur mein Terminal versteht halt keine ESC-Sequenzen.
Aus Interesse, was für ein Terminal nutzt du...?
Das Programm heißt Serial USB Terminal V1.57, das funktioniert super und unterstützt ziemlich viele USB-Chips, aber ist halt kein echtes Terminal. Aber wenn das sena-bterm vt100 emuliert, nehm ich halt das. Ob ich ein USB-Kabel oder einen BT-Adapter anstecke ist mir eigentlich egal. Ich werds mal testen. Ich brauch was fertiges, hab keine Ahnung von Android und will mich da auch nicht zu weit eingraben. Bei Microcontrollern und den Schnittstellen drumrum fühl ich mich wohler.
Ich brauch was fertiges, hab keine Ahnung von Android und will mich da auch nicht zu weit eingraben. Bei Microcontrollern und den Schnittstellen drumrum fühl ich mich wohler.
Fertig gibt es z.B. die /Airconsole/. Auf die kann man per Netzwerk (Ethernet, WLAN-AP/Client), oder per Bluetooth verbinden. Dank Akku kann die auch mobil verwendet werden. Für Android wäre z.B. der ConnectBot oder seine Forks tauglich. Die können ganz selbstverständlich auch eine VT100-Emulation.
Ganz billig ist der Spass aber nicht.
Gibt es so Programm vielleicht auch für iOS?
Für USB-Seriell-Adapter gibt es das nicht, weil die nicht "MFI" (made for ios) sind.
Von Startech gibt es das hier https://www.startech.com/de-de/netrsapp, was eine Netzwerkverbindung zu einem Ethernet-Deviceserver voraussetzt.
Und es gibt das hier:
https://redpark.com/usb-c-serial-cable/
Das ist ein mit iOS funktionierender USB-Seriell-Adapter, aber die App dafür muss man sich selbst schreiben ...
(Apples Lizenzgebaren ist mehr als bizarr)
Evtl. reicht eine Webseite: https://googlechromelabs.github.io/serial-terminal/ https://webserial.io/ o.Ä.
Allerdings: Wenn der USB-Seriell Treiber im Kernel fehlt, verwenden die das "web-serial-polyfill", was direkt auf das USB-Device zugreift, und den Treiber in Javascript nachimplementiert. Momentan nur CDC-ACM, Support für FTDI, Prolific, CH340, CP210x ... fehlt.
Bei eigenen Devices hätte man sogar die Möglichkeit, die Webseite im USB-Descriptor zu verlinken. Gerät anstöpseln, Notification bestätigen, GUI öffnet sich im Browser und kann über WebSerial mit dem Device kommunizieren... Zumindest in der Theorie schick. Inzwischen von ESP32&co überholt worden, wo der µC genug Speicher hat, um die ganze Webseite selber über WLan bereitzustellen.
Bei eigenen Devices hätte man sogar die Möglichkeit, die Webseite im USB-Descriptor zu verlinken
Und man hätte die Möglichkeit ganz auf Serial zu verzichten und direkt ein natives USB-Protokoll mit dem UsbManager zu implementieren.
(Apples Lizenzgebaren ist mehr als bizarr)
Typisch Apple halt. Wer extra Geld für einen besonders schönen goldenen Käfig ausgibt... 🤷♂️
Ja also Danke für die ganzen Tips, aber ich hab gesehen, was ich suche, das gibts einfach nicht. Oder zumindest nicht einfach ;-) Und nein, ich will mich nicht mit Apples Lizenzpolitik beschäftigen und auch keinen Webserver auf uralte Motorsteuerungen basteln. Ich hab hier noch ein uraltes Webbook mit Win-XP, da läuft Teraterm mit vt100-Emulation drauf, und da kommt ein 80ct USB-RS232 Adapter dran. Mehr brauch ich nicht.
Ich hab gestern in einem Roboterforum gesehen, dass da einer vor 2 Jahren genau das selbe gesucht hat und nach 5 Seiten Diskussion auch aufgegeben hat :-)
(Apples Lizenzgebaren ist mehr als bizarr)
Nicht ganz. Die Idee eine serielle Schnittstelle uber USB als virtuelle serielle dazustellen ist eigentlich ziemlich bizarr und fuehrte ja auch zu vielen Problemen wegen des gaenzlich unterschiedlichen Timingverhalten und den USB-Blockgroessen. Aber weil es halt erlaubt das Programmierer schoen doof bleiben koennen hat sich das naetuerlich stark verbreitet. Dafuer hat halt der eine oder andere Programmierer ein paar graue Haare mehr wenn er auf ein Protokoll getroffen ist das etwas schraeg/alt ist. .-)
Vanye
Ich bringe mal ESPTerm [1] ins Spiel. Es entspricht zwar nicht ganz der gewünschten Spezifikation, ist jedoch trotzdem eine Alternative.
Das ESPTerm spricht mit der zu koppelnden Hardware über Tx und Rx des ESP. Die Kommunikation mit Android oder IOS oder, oder erfolgt über ein Web-Interface des ESPTerm. Auf der Hardware läuft echte VT102 Kommunikation.
Ich sag es nur ungern, aber ziemlich cool! Fuehl ich mich gleich wieder wie in 1990. :-D
Vanye
Ich bringe mal ESPTerm [1] ins Spiel. Es entspricht zwar nicht ganz der gewünschten Spezifikation, ist jedoch trotzdem eine Alternative.
Das ESPTerm spricht mit der zu koppelnden Hardware über Tx und Rx des ESP. Die Kommunikation mit Android oder IOS oder, oder erfolgt über ein Web-Interface des ESPTerm. Auf der Hardware läuft echte VT102 Kommunikation.
Eine serielle Verbindung über ein Socket, kann ein ESP8266 schon mit der originalen Firmware. Und das vermutlich performanter als so ein Webgefrickel.
Von HP gab es sowas vor Jahrzehnten nämlich auch schon. Da konnte man ein HP-Terminal als Javaapplet im Browser laufen lassen. Das war eher eine träge Masse als ein Terminal. Immerhin war es nur Zigarettenschachtelgross, und ersparte den Platz für ein echtes (HP-)Terminal. Andere Emulationen waren auch gar nicht vorgesehen...
Jobst M. schrieb:
Wieso sollten sie nicht dabei sein?
Weil der Smartphone -Hersteller die Treiber nicht mitkompiliert hat.
Ja, das ist eine komplexe Kausalität, welche der Ursprung der Tatsache zu sein scheint.
Ganz anderes Thema: Warum sollte der Hersteller die Treiber nicht mitkompilieren? Vor allem bei Beachtung der Tatsache, dass das eigene Produkt dann weniger Peripherie unterstützt als es Konkurenzprodukte können?
Und selbst wenn, bekommen normale Apps keinen Zugriff auf /dev/ttyUSB etc.
Jobst M. schrieb:
Nicht nur die Sensoren unserer Firma nutzen diese (und auch andere) Bridges für die Verbindung mit der dazugehörigen App
Wie greift die App auf die serielle Schnittstelle zu? open("/dev/ttyUSB...") geht IIRC nicht (im Allgemeinen).
Wie genau, weiß ich nicht mehr. Sie greift darauf zu. Ich habe vor 7 Jahren einfach mal gegoggelt wie man das macht, ein Proof-of-concept geschrieben, das hat funktioniert. Und wie das Ding dort heißt, ist mir eigentlich auch vollkommen egal. Die dürfen auch gerne COMn: oder anders heißen. Tatsache ist, dass man einfach aus Java heraus mit einer einfachen App ohne Klimmzüge Zugriff auf die UART-Bridges hat.
Unter Linux gibt es minicom, welches ANSI und VT100/102 unterstützt. Für Android gibt es einen Port: microcom - Keine Ahnung, was das kann. Wäre aber einen Versuch wert.
Gruß Jobst
Warum sollte der Hersteller die Treiber nicht mitkompilieren?
Weil Apps den Treiber sowieso nicht nutzen können und er somit sinnlos ist. Der einzelne FTDI Treiber ist zwar nicht groß, aber wenn man auf Verdacht alle Treiber mit kompiliert summiert es sich schon auf.
Wie genau, weiß ich nicht mehr. Sie greift darauf zu. Ich habe vor 7 Jahren einfach mal gegoggelt wie man das macht, ein Proof-of-concept geschrieben, das hat funktioniert
Dann funktioniert es mit aktuellen Android Versionen wahrscheinlich nicht mehr...
Weil Apps den Treiber sowieso nicht nutzen können und er somit sinnlos ist.
Na, unsere App nutzt sie doch! (Und andere ebenso!)
Dann funktioniert es mit aktuellen Android Versionen wahrscheinlich nicht mehr...
Doch, hat auch erst ein Update bekommen (Weil Goggel das so wollte) Die Kunden kaufen und nutzen es!
Gruß Jobst
Na, unsere App nutzt sie doch! (Und andere ebenso!)
Da würde mich wirklich interessieren wie das geht. Auf meinem Smartphones geht das nicht so. Nur mit der usb-serial-for-android Library, welche eben keinen Kernel Treiber nutzt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.