|
Anzeige
|
Linux: kann man DTR auf ttyUSBx abschalten?ttyUSB setzt beim Öffnen der Schnittstelle das DTR-Signal – der Bootlader braucht ihn, weil er nur nach einem Hard-Reset die Kontrolle bekommt. Allerdings ist DTR für ein laufendes Programm auf dem Arduino "tödlich". Kann man gtkterm irgendwie beibringen, beim Start DTR nicht zu setzen? man stty
Damit ist dann allerdings dauerhaft der Zugriff auf beide Steuerleitungen der Schnittstelle gesperrt. Und es werden dann wohl auch die die vier Feedback-Leitungen nicht mehr ausgewertet. Wenn das nicht akzeptabel ist, kommt man nicht darum herum, sich den ganzen Wahnsinn der termio-Konfigurationen anzutun, um das gewünschte Ziel zu erreichen. Mein Gott, wie liebe ich Windows im Allgemeinen und .net im Speziellen. Da ist das mit einem simplen <PortInstance>.DtrEnable = false; abgehandelt... Das ist wahrer Programmier-Komfort.
Fast vergessen: Das funktioniert auch mit mono unter Linux.
Na ja, erstens und zweitens ist das nun wirklich keine Raketenwissenschaft. Drittens und viertens nimmt der ganz besonders bequeme Mensch vermutlich sogar eine zu seiner Programmiersprache passende Bibliothek. Oder installiert sich auf einer wenige Exabyte großen Festplatte Mono/Stereo oder gar Quadro.
Bei minicom kann man die DTR drop-time auf 0 setzen (kein DTR). Configure minicom -> Modem and dialing Ob das unter gtkterm auch geht, kann ich nicht sagen.
Nein, sicher nicht. Aber doch recht schwierig zu durchschauen. Das ist nur eine Auswirkung dessen, dass man mittlerweile grandios historische Sachen unbedingt am Leben erhalten will. Allein die Tatsache, das es die termio-Struktur mittlerweile in drei Versionen gibt, zeigt das. Das ist Mist. Da haben die Schnittstellen-Designer massiv geschlampt. Nun ist allerdings ja nicht so, dass es unter Win32 nicht auch immer mal wieder Struktur-Updates und *Ex-Funktionen gibt. Aber da reicht es dann, immer die neueste Version und Struktur zu verwenden, um alles tun zu können. Da ist es NIEMALS nötig, sich mit einem Mischmasch rumzuschlagen. Sprich: Die KÖNNEN Abwarts-Kompatibilität. Linux kann das nachweisbar nicht. Ganz sicher jedenfalls nicht, was diese vermaledeite termio-Sache betrifft. Und nun du...
Das liegt aber weniger an Windows als an der API. Das Windows-Pendant zu termios ist eher das: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setcommstate
Mit Qt auch. Da heißt die Funktion setDataTerminalReady().
Nö, ich bin Pragmatiker. ›Man pages‹ lesen, dann wird das einmal kurz programmiert und gut iss. Ganz ohne innere Verspannung… Gibts dafür unter Linux tatsächlich kein Programm, mit dem man das meinetwegen aus einem Skript heraus vor dem gtkterm-Aufruf erledigen kann? Eigentlich wäre doch stty der Kandidat dafür, aber der scheitert schon, wenn das Gerät am anderen Ende der Leitung noch nicht aktiv ist, weil dann /dev/ttyUSB0 – oder welche Nummer auch immer – nicht existiert. Dass die Nummern bei mehreren angeschlossenen Geräten von der Reihenfolge des Anschlusses abhängen, ist ja auch noch so ein Unding. Das gibts wohl nur bei USB…
... wenn DU dafür keine udev-Regeln geschrieben hast und so dumm warst, Adapter ohne eingebaute eindeutige Seriennummern zu kaufen. fchk
Danke für die Blumen… Wie komme ich an die Seriennummer eines Arduino Nano?
dmesg -c Arduino Anstecken dmesg Aha. Aber es bleibt ein Schrott: ein Arduino Nano ist nicht gerade ein Teil, das man in der udev-DB verdrahten will – dazu fliegen einfach zu viele davon in der Bastelecke herum.
Wenn es ein Chinese ist, garnicht, die CH340 haben keine Seriennummer. Das gefällt mir als Windows-Nutzer sehr gut: Jeder hat die gleiche Portnummer, solange ich ihn an den selben PC-Port stecke. FTDI oder SiLab mit Seriennummer zählen unter Windows den Port hoch, bis es nicht mehr reicht - so hat also jedes Ding zwei Seiten. Was passiert denn unter Linux, wenn Du einen anderen Nano an den selben Port steckst, sollte da nicht auch die Nummer gleich bleiben?
Linux nimmt die erste freie Nummer und erzeugt damit ein /dev/ttyUSBn. Wenn man keine weiteren seriellen Geräte am USB hat, dann bekommt der immer die ttyUSB0. (Früher wurden die Devices nach dem Verbindungsabbau nicht so schnell freigegeben und so bekam man auch mal ttyUSB1, wenn ttyUSB0 noch da war.) Das Problem bei der Geschichte ist eben, dass die ttyUSBs verschwinden, wenn keine Verbindung mehr besteht und so kann stty auch keine Einstellungen vornehmen.
IIRC können udev-Regeln beim Einstöpseln Skripte aufrufen.
Ganz genau so ist es! Und das machen sie zB. mit:
Du erwartest von einem Programm, dass du damit die Parameter eines noch gar nicht existierenden Device einstellen kannst?
Du musst dich jetzt schon entscheiden. Entweder werden die Namen der Geräte nach der Reihenfolge des Einsteckens gewählt oder jedes bekommt einen festen Namen. Beides findest du "Mist", also wie willst du es denn nun haben?
Wenn nichts da ist, gibt's ja auch nichts, das man einstellen könnte.
Microsoft will das doch auch schon wieder ersetzen, und drehen mal wieder ihre eigene Runtime ( https://learn.microsoft.com/de-de/dotnet/core/install/linux-debian ). Ausprobiert habe ich das nicht, ich lade mir solchen Scheiss nicht auf den Rechner.
Man kann mit udev auch symlinks machen, wie bei /dev/disk/by-*/. Mach dir halt einen symlink alla /dev/ttyUSB-1.2.3 -> /dev/ttyUSB0 oder so mit den Portnummern hinten dran. Edit, ich habe das jetzt nicht ausprobiert, aber eventuell irgendwie so:
Und wie willst du es anstellen, dass der Bootlader das DTR bekommt, das er braucht, aber im Terminal-Betrieb DTR unterdrückt wird?
Du Schlaumeier… Dass es das Device nicht gibt, oder es an eine bestimmte Geräte-ID gebunden ist, die der Nano nicht hat, ist das Problem. Da muss ich c-hater in Beziehung zu Windows mal ausnahmsweise Recht geben – wenigstens das haben die so gebacken bekommen, dass es praxistauglich ist.
Ach, und wie macht Windows das dann? Mal so ganz nebenbei gefragt: Was für ein ominöser Bootloader soll das denn sein? WIMRE macht das Arduino Zeug die Schnittstelle mit 1200bd auf und sofort wieder zu. Dann im Anschluss mit - ich meine - 115200bd und so erkennt's der Bootlader und meldet sich. Wenn diese Abfolge nicht eingehalten wird geht's sofort in die eigentliche Applikation. PS. Ein DTR (Data Terminal Ready) ist ein völlig normales Signal und sollte für die Arduino-Applikation alles aber ganz bestimmt nicht
sein.
Der vom Arduino – Nano in dem Fall.
Nein, der Nano macht das sehr trickreich, indem er aus dem Zustandswechsel von DTR einen Reset-Puls ableitet. Der Bootlader erkennt den Reset und wartet auf den Verbindungsaufbau. Wie der Boot ausgelöst wurde, ist dem MCUSR zu entnehmen.
Ist es aber, weil durch DTR eben ein Reset ausgelöst wird…
Na ja, ›trickreich‹ wäre jetzt der letzte Begriff der mir dabei einfiele.
OK, scheint als wenn das Ding von echten Profis entwickelt wurde…
Die Alternative wäre Handanlegen, um den Bootlader zu aktivieren – bei BT-Übertragung mit den üblichen kleinen Adapterplatinchen bleibt da nichts anderes, weil die DTR nicht übertragen. So ist das schon einigermaßen komfortabel, hat aber eben die genannte Schattenseite…
Die vollautomatische Alternative ohne Krücken hatte ich bereits beschrieben.
Das kostet Platz im Bootlader und würde wohl heißen, dass der eine Seite mehr belegt, denn er ist im Moment gerade so groß, dass er mit einer auskommt.
Wie bekommt man es hin, das Setup zu speichern? Bei endet Save setup as dfl mit "Cannot write to /etc/minicom/minirc.dfl". Das Teil als root auszuführen ist wohl nicht das Mittel der Wahl… Einfach mal die manpage lesen könnte schon etwas Aufschluss geben... https://www.man7.org/linux/man-pages/man1/minicom.1.html
oder mal hier gucken: https://cris.bytesnblades.net/2009/03/24/managing-minicom-settings/ Das Teil ist gewöhnungsbedürftig… Aber DTR abstellen, funktioniert. Ich würde gerne ein log mitschreiben und habe den Logfile Path auf /tmp/minicom.log gesetzt. Ein Log wird nicht geschrieben – es scheint auf ~/<dateiname> zu bestehen. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
