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
1 | Control settings: |
2 | [-]clocal disable modem control signals |
Norbert schrieb: > man stty >
1 | Control settings: |
2 | > [-]clocal disable modem control signals |
3 | >
|
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.
C-hater schrieb: > Das ist wahrer Programmier-Komfort. Fast vergessen: Das funktioniert auch mit mono unter Linux.
C-hater schrieb: > 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. 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.
Moriz schrieb: > Kann man gtkterm irgendwie beibringen, beim Start DTR nicht zu setzen? 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.
Norbert schrieb: > Na ja, erstens und zweitens ist das nun wirklich keine > Raketenwissenschaft. 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...
C-hater schrieb: > Mein Gott, wie liebe ich Windows im Allgemeinen und .net im Speziellen. > Da ist das mit einem simplen > <PortInstance>.DtrEnable = false; > abgehandelt... 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 > Fast vergessen: Das funktioniert auch mit mono unter Linux. Mit Qt auch. Da heißt die Funktion setDataTerminalReady().
C-hater schrieb: > Und nun du... 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…
Moriz schrieb: > 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
Frank K. schrieb: > ... wenn DU dafür keine udev-Regeln geschrieben hast und so dumm warst, > Adapter ohne eingebaute eindeutige Seriennummern zu kaufen. Danke für die Blumen… Wie komme ich an die Seriennummer eines Arduino Nano?
Moriz schrieb: > 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.
Moriz schrieb: > Wie komme ich an die Seriennummer eines Arduino Nano? 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?
Manfred P. schrieb: > 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.
Moriz schrieb: > 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.
Ein T. schrieb: > IIRC können udev-Regeln beim Einstöpseln Skripte aufrufen. Ganz genau so ist es! Und das machen sie zB. mit:
1 | RUN+="/etc/udev/rules.d/device.run" |
Moriz schrieb: > 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. Du erwartest von einem Programm, dass du damit die Parameter eines noch gar nicht existierenden Device einstellen kannst? Moriz schrieb: > 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. 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? Moriz schrieb: > Das Problem bei der Geschichte ist eben, dass die ttyUSBs verschwinden, > wenn keine Verbindung mehr besteht und so kann stty auch keine > Einstellungen vornehmen. Wenn nichts da ist, gibt's ja auch nichts, das man einstellen könnte.
C-hater schrieb: > C-hater schrieb: >> Das ist wahrer Programmier-Komfort. > > Fast vergessen: Das funktioniert auch mit mono unter Linux. 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.
Rolf M. schrieb: > Entweder werden die Namen der > Geräte nach der Reihenfolge des Einsteckens gewählt oder jedes bekommt > einen festen Namen. 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:
1 | # %p oder $devpath oder $attr{devpath}
|
2 | KERNEL=="ttyUSB?", SUBSYSTEMS=="usb", SYMLINK+="ttyUSB-%p" |
:
Bearbeitet durch User
Ein T. schrieb: > IIRC können udev-Regeln beim Einstöpseln Skripte aufrufen. Und wie willst du es anstellen, dass der Bootlader das DTR bekommt, das er braucht, aber im Terminal-Betrieb DTR unterdrückt wird?
Rolf M. schrieb: > Du erwartest von einem Programm, dass du damit die Parameter eines noch > gar nicht existierenden Device einstellen kannst? 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. > Wenn nichts da ist, gibt's ja auch nichts, das man einstellen könnte. Ach, und wie macht Windows das dann?
:
Bearbeitet durch User
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
> tödlich
sein.
Norbert schrieb: > Mal so ganz nebenbei gefragt: Was für ein ominöser Bootloader soll das > denn sein? Der vom Arduino – Nano in dem Fall. > 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. 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. > PS. Ein DTR (Data Terminal Ready) ist ein völlig normales Signal und > sollte für die Arduino-Applikation alles aber ganz bestimmt nicht > >> tödlich > > sein. Ist es aber, weil durch DTR eben ein Reset ausgelöst wird…
Moriz schrieb: > Nein, der Nano macht das sehr trickreich, indem er aus dem > Zustandswechsel von DTR einen Reset-Puls ableitet. Na ja, ›trickreich‹ wäre jetzt der letzte Begriff der mir dabei einfiele. Moriz schrieb: > Ist es aber, weil durch DTR eben ein Reset ausgelöst wird… OK, scheint als wenn das Ding von echten Profis entwickelt wurde…
Norbert schrieb: > 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…
Moriz schrieb: > Die Alternative wäre Handanlegen, um den Bootlader zu aktivieren Die vollautomatische Alternative ohne Krücken hatte ich bereits beschrieben.
Norbert schrieb: > 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.
:
Bearbeitet durch User
Alexander S. schrieb: > Bei minicom kann man die DTR drop-time auf 0 setzen (kein DTR). > Configure minicom -> Modem and dialing 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
1 | -s, --setup |
2 | Setup. Root edits the system-wide defaults in |
3 | /etc/minirc.dfl with this option. When it is used, minicom |
4 | does not initialize, but puts you directly into the |
5 | configuration menu. This is very handy if minicom refuses to |
6 | start up because your system has changed, or for the first |
7 | time you run minicom. For most systems, reasonable defaults |
8 | are already compiled in. |
9 | |
10 | configuration |
11 | The configuration argument is more interesting. Normally, |
12 | minicom gets its defaults from a file called "minirc.dfl". |
13 | If you however give an argument to minicom, it will try to |
14 | get its defaults from a file called "minirc.configuration". |
15 | So it is possible to create multiple configuration files, |
16 | for different ports, different users etc. Most sensible is |
17 | to use device names, such as tty1, tty64, sio2 etc. If a |
18 | user creates his own configuration file, it will show up in |
19 | his home directory as ".minirc.dfl" or |
20 | ".minirc.configuration". |
21 | |
22 | Save setup as dfl |
23 | Save the parameters as the default for the next time the |
24 | program is started. Instead of dfl, any other parameter name |
25 | may appear, depending on which one was used when the program |
26 | was started. |
27 | |
28 | Save setup as.. |
29 | Save the parameters under a special name. Whenever Minicom is |
30 | started with this name as an argument, it will use these |
31 | parameters. This option is of course privileged to root. |
32 | |
33 | FILES |
34 | Minicom keeps it's configuration files in one directory, usually |
35 | /var/lib/minicom, /usr/local/etc or /etc. To find out what |
36 | default directory minicom has compiled in, issue the command |
37 | minicom -h. |
oder mal hier gucken: https://cris.bytesnblades.net/2009/03/24/managing-minicom-settings/
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.