Um die Kernel-Meldungen bei einem Crash zu sichern verwende ich in der /etc/default/grub von Ubuntu diese Zeile: GRUB_CMDLINE_LINUX="console=ttyS0,115200n8 console=tty1 noplymouth" Und mit dem Oszilloskop sehe ich das das funktioniert, an Pin 3, hinter dem Nullmodemkabel an Pin 2. Aber mit Minicom, und als root, sehe ich nichts über ttyS1 (zweite serielle Schnittstelle) und auch nicht über ttyUSB0 (USB-Adapter). Die ~/.minirc.dfl sieht wie folgt aus, hier für ttyUSB0: # Kein Hardware Handshake (rtscts No) benutzen. # Keine Flusskontrolle (xonxoff No) benutzen. # No modem initialization pu port /dev/ttyUSB0 pu baudrate 115200 pu bits 8 pu parity N pu stopbits 1 pu rtscts No pu xonxoff No pu minit pu mreset pu mhangup Testweise habe ich auch von ttyS1 nach ttyUSB0 gesendet mit echo -n testdaten > /dev/ttyS1 aber Minicom zeigt nichts. Ebenso ist es mit cat /dev/ttyS1 und jpnevulator --read --ascii --timing-print --tty /dev/ttyS1 Die Baudraten und andere Parameter (bis auf IRQs und Ports) sind laut setserial -a $DEVICE; stty -F $DEVICE -a gleich. Wieso kann trotzdem nichts eingelesen werden?
Generell, was nicht geht ist auf einen ser. Port was rauszusenden und gleichzeitig mit minicom den ser. Port abzulauschen. Das liegt am Kernel, der die Hardwareschnittstelle nur einem Prozess zur Verfügung stellt. Du müsstest also 2 serielle Port haben und beide verbinden, den einen zum schreiben und den anderen zum auslesen. Um aber an einem seriellen Port Daten zu schreiben und auch gleichzeitig zu lesen, kann man socat dafür gebrauchen. Das Tool klemmt sich zwischen Kernel und Hardware und kann eben die gesendeten Daten auf einem Port auch abhören, wobei socat ein virtuellen Port baut und das darüber macht, wenn ich es richtig im Kopp habe. Aber mit socat ist es nicht so ganz einfach. Für meine Abhörmaßnahme habe ich folgenden Befehl gebraucht (mein Läppie hat nur einen ser. Port /dev/ttyUSB0 mit dem USB-Gerät), wobei das genannte "link=./tty0", also ./tty0 ein Symlink nach irgendwas war.....müsste ich nochmal nachsehen wie das allen ineinanderhängt. ~$> socat -d -d -d /dev/ttyUSB0,raw,echo=0,ignoreeof SYSTEM:'tee input.txt | socat - "PTY,link=./tty0,raw,echo=0" | tee output.txt' socat Beschreibung: Mehrzweck-Relais für bidirektionale Datenübertragung Socat (für SOcket CAT) legt zwei bidirektionale Byte-Streams an und überträgt Daten zwischen ihnen. Datenkanäle können Dateien, Pipelines, Geräte (Terminal oder Modem, etc.) oder Sockets (Unix, IPv4, IPv6, Raw, UDP, TCP, SSL) sein. Es ermöglicht die Erzeugung von Kindprozessen, Protokollierung und Ablaufverfolgung, verschiedene Modi für Interprozesskommunikation und viele weitere Optionen. Es kann beispielsweise als TCP-Relais (einmalig oder als Daemon), als externer »socksifier«, als Shell-Schnittstelle zu Unix-Sockets, als IPv6-Relais, als Ersatz für »netcat« und »rinetd« oder zur Umlenkung TCP- orientierter Programme auf eine serielle Schnittstelle verwendet werden. Auch kann eine relativ sichere Umgebung (chroot und su) für die Ausführung von Client- oder Server-Shell-Skripten innerhalb von Netzwerkverbindungen eingerichtet werden. Socat unterstützt seit Version 1.7.0 sctp. Homepage: http://www.dest-unreach.org/socat/
:
Bearbeitet durch User
K. H. schrieb: > Generell, was nicht geht ist auf einen ser. Port was rauszusenden und > gleichzeitig mit minicom den ser. Port abzulauschen. > Das liegt am Kernel, der die Hardwareschnittstelle nur einem Prozess zur > Verfügung stellt. Du müsstest also 2 serielle Port haben und beide > verbinden, den einen zum schreiben und den anderen zum auslesen. Das mache ich doch: Der Kernel gibt aus auf ttyS0, ich empfange auf ttyS1 oder ttyUSB0. Aber bisher empfange ich nichts, außer mit dem Oszilloskop.
Dann ist es entweder ein Konfigurationsfehler, Verkabelungsfehler oder
Schnittstelle defekt.
Probier es doch mal mit den Allroundtool 'cat', z. b. so:
Terminal1:
echo "blabla" > /dev/ttyS1
Terminal 2:
cat /dev/ttyUSB0
Oder umgekehrt oder beides.
Frage, ist das "console=..." ohne dev... richtig? Und darf es 2x in
die Zeile?
> GRUB_CMDLINE_LINUX="console=ttyS0,115200n8 console=tty1 noplymouth"
K. H. schrieb: > Dann ist es entweder ein Konfigurationsfehler, Verkabelungsfehler oder > Schnittstelle defekt. > > Probier es doch mal mit den Allroundtool 'cat', z. b. so: > Terminal1: > echo "blabla" > /dev/ttyS1 > > Terminal 2: > cat /dev/ttyUSB0 > > Oder umgekehrt oder beides. Da kommt nichts. > Frage, ist das "console=..." ohne dev... richtig? Und darf es 2x in > die Zeile? > >> GRUB_CMDLINE_LINUX="console=ttyS0,115200n8 console=tty1 noplymouth" Ja: When multiple consoles are listed output is sent to all consoles and input is taken from the last listed console. The last console is the one Linux uses as the /dev/console device; only the last device will show startup messages and act as a console in single-user mode!
Erwin M. schrieb: > Da kommt nichts. Dann soll/wird da wohl was im Eimer sein. Denn das, was ich oben geschrieben habe sind doch die Basics um die Funktionalität der Schnittstellen zu checken. Kann natürlich sein, dass das nicht 100% richtig ist, aber im Internetz gibt es genügend Anleitungen, wie es dann gehen würde. Ich denke da an stty und so'n Zeug. Aber wenn du den USB-irgendwas an- und abstöpselt, gibt es mit ~$> dmesg | tail eine Mitteilung darüber, dass /dev/ttyUSB0 existiert bzw. dafür verwendet wird?
K. H. schrieb: > Aber wenn du den USB-irgendwas an- und abstöpselt, gibt es mit > ~$> dmesg | tail > eine Mitteilung darüber, dass /dev/ttyUSB0 existiert bzw. dafür > verwendet wird? Ja, Minicom und andere würden sich auch beschweren wenn da nichts wäre.
Hast Du schon den Schleifentest gemacht? Also einfach mal RX und TX der gleichen Schnittstelle verbinden. Damit kannst Du alle Schnittstellen erst mal einzeln testen. Um einen Fehler bei minicom auszuschließen wäre auch ein Versuch mit cutecom eine Möglichkeit.
Die Konfiguration zeigt das HW Handshake nur für ttyUSB0. Hast Du das bei allen anderen ebenfalls ausgeschaltet?
Also ich habe mal getestet mit einem LOGILINK AU0033, einem dreiadrigen Nullmodemkabel von der ersten zur zweiten Buchse und ohne Konfiguration einfach mit echo und cat. Das funktioniert. Es funktioniert auch ein Backup und Restore der Einstellungen mit To save settings stty -g < /dev/ttyS1 >ttyS1.settings # to restore stty < /dev/ttyS1 `cat ttyS1.settings` Also im Prinzip funktioniert es, aber mir ist aufgefallen das Minicom die Einstellungen verändert von 4000:5:1cb2:0:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0 :0:0:0:0:0:0:0 nach 1:0:1cb2:0:3:1c:7f:15:4:5:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0: 0:0:0:0:0:0 Wahrscheinlich hat sich beim Testen dadurch etwas verklemmt, so das ich auch beim Kopieren der Einstellungen von ttyS0 nach ttyS1 mit cat nichts auslesen kann.
:
Bearbeitet durch User
Erwin M. schrieb: > Also im Prinzip funktioniert es, aber mir ist aufgefallen das Minicom > die Einstellungen verändert Was passiert wenn Du die minicom config leer lässt und das Programm mit dev Parameter aufrufst? Also:
1 | minicom -D /dev/tty.... |
Es zeigt sich das ich mit Übernehmen der Konfiguration von ttyS0 nach ttyS1 eine Kommunikation bekomme, aber das funktioniert nicht von einem Rechner zum anderen: Mit der Konfiguration, mit der ich von Rechner A ttyS0 nach ttyS1 einlesen kann (4000:5:1cb2:0:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0: 0:0:0:0:0:0:0:0), empfange ich beim Rechner B nichts und auch umgekehrt. Offenbar hängen die hunderte Konfigurations-Bits von der Hardware ab und sind gemäß Murphys Law kein bischen portabel, müssen jeweils neu ermittelt werden, weil die Anzahl an möglichen Kombinationen ungefähr der Anzahl der Atome im sichtbaren Universum entspricht. Zudem zeigt sich beim Rechner B, das er ttyS0 nach circa einer Minute umkonfiguriert auf 4000:5:cbd:0:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0: 0:0:0:0:0:0:0 Und im Oszilloskop sehe ich das der Ruhepegel bei um +10 V ist, aber der sollte bei -10 V sein, wo er auch beim Rechner A ist. Aber im Prinzip ist das Problem gelöst und praktisch auch auf Rechner A.
stty -a zeigt alles in lesbarer Form an...
Angehängte Dateien:
Anbei ist ein Bild von der vermurksten ersten seriellen Schnittstelle onboard, vom X11SAE (Supermicro). Bei der zweiten sieht es ebenso aus aber mit Nullmodemkabel, echo und cat sieht man das die sich nicht verstehen. Nachdem der Support von Microsoft nicht weiterhalf nahm ich eine Karte, eine RocketPort, 96460-5 Rocket 16 PCI und damit sehe ich auch die Kernel-Meldungen von einem anderen Rechner. Aber darüber bekomme ich keine Kernel-Meldungen und wie lsof zeigt läuft darauf keine Konsole (agetty). Ich vermute es liegt daran das der Treiber erst als Modul beim Booten geladen wird. Was kann man da machen?
Erwin M. schrieb: > Anbei ist ein Bild von der vermurksten ersten seriellen Schnittstelle Was ist daran vermurkst? Stell mal die Zeitbasis wesentlich kleiner und vllt. die Sampling-Rate höher (steht auf 25 kHz wenn ich das richtig gesehen habe). Aus Erfahrung würde ich sagen, dass die Signalform gut aussieht, bei dem was da zu sehen ist.
Erwin M. schrieb: > Anbei ist ein Bild von der vermurksten ersten seriellen Schnittstelle Das soll wohl heissen: Anbei ist ein vermurkstes Bild von der ersten seriellen Schnittstelle Georg
K. H. schrieb: > Erwin M. schrieb: >> Anbei ist ein Bild von der vermurksten ersten seriellen Schnittstelle > > Was ist daran vermurkst? Schon der Ruhepegel ist falsch, weil oben (+10 V), siehe https://de.wikipedia.org/wiki/RS-232 Da wurde wohl die Schnittstelle am Gegenteiltag produziert (https://welcher-tag-ist-heute.org/aktionstage/gegenteiltag).
:
Bearbeitet durch User
Rolf F. schrieb: > Schon der Ruhepegel ist falsch, weil oben (+10 V), siehe > https://de.wikipedia.org/wiki/RS-232 Könnte auch ein Messfehler oder Einstellungssache sein.
> Generell, was nicht geht ist auf einen ser. Port was rauszusenden und > gleichzeitig mit minicom den ser. Port abzulauschen. > Das liegt am Kernel, der die Hardwareschnittstelle nur einem Prozess zur > Verfügung stellt. Das ist ein Gerücht ohne Substanz. Es ist überhaupt kein Problem, mehrfach eine serielle Schnittstelle zu öffnen. minicom selbst verhindert das nur über ein manuelles Extra-Locking "gegen" sich selbst. Interessant wirds nur beim Lesen, da schnappen sich mehrere Prozesse gegenseitig die Daten weg. Solange aber nur einer liest, geht alles ganz normal.
Georg A. schrieb: > Das ist ein Gerücht ohne Substanz. Warum? Ich habe selber das Problem gehabt. Ein Prozess sendet über die serielle Schnittstelle Daten und empfängt welche. Also, warum nicht mit einem anderen Prozess die Daten abgreifen? Irgendwo stand geschrieben, dass das eben nicht geht. Und das waren keine Halbwissenden, die das schrieben. Es stand eben ganau so da, wie ich es ganz oben schrieb. Der Kernel bzw. die Treiber sind nicht dafür gedacht, mehr wie einen Prozess an einer physikalischen Schnittstelle zu bedienen. Das hat soweit ich weiß handfeste Gründe. Nicht umsonst hat irgendwer das Tool 'socat' kreiert. Es macht genau das, was ich will, aber es benutzt zur Datenweitergabe, senden wie empfangen, einen virtuellen Port, der zwischen dem Ursprungsprozess und der realen Schnittstelle eingeschoben wird. Der Ursprungsprozess sendet und liest also die Daten zu bzw. von einem virtuellem Port. Dieser virtuelle Port stammt von 'socat' und socat macht das, was ich will, nämlich die Daten 1:1 durchreichen, also vom virtuellen Port an den realen Port und umgekehrt. Dabei werden die Daten kopiert und in Dateien geschrieben. Selbst mit den Boardmitteln wie 'echo' und 'cat' usw. geht das Datenablauschen nicht. Stattdessen wartet bspw. ein 2. 'cat' Prozess darauf, dass der erste 'cat' Prozess den Port freigibt. Der Treiber bedient keinen zweiten Prozess, dieser steht dann in der Warteschlange oder gibt die Fehlermeldung zurück, dass der Port belegt ist oder sowas. Aber das ist jetzt ein Nebenkriegsschauplatz (oder wie man das nennt).
Georg A. schrieb: >> Generell, was nicht geht ist auf einen ser. Port was rauszusenden und >> gleichzeitig mit minicom den ser. Port abzulauschen. >> Das liegt am Kernel, der die Hardwareschnittstelle nur einem Prozess zur >> Verfügung stellt. > > Das ist ein Gerücht ohne Substanz. Es ist überhaupt kein Problem, > mehrfach eine serielle Schnittstelle zu öffnen. Das kommt darauf an. Beispielsweise kann man sie exclusiv verwenden mit open_excl(). Aber wenn die Kernel-Meldungen ausgegeben werden, läuft parallel noch ein (a)getty darauf. Damit hat man dann eine Shell, in der die Kernel-Meldungen erscheinen.
K. Hegy: > Also, warum nicht mit einem anderen Prozess die Daten abgreifen? Irgendwo > stand geschrieben, dass das eben nicht geht. Und das waren keine > Halbwissenden, die das schrieben. Es stand eben ganau so da, wie ich > es ganz oben schrieb. Der Kernel bzw. die Treiber sind nicht dafür > gedacht, mehr wie einen Prozess an einer physikalischen Schnittstelle > zu bedienen. Doch, sie sind dafür gedacht, sogar "by design". Wären sie es nicht, könnten mehrere Prozesse das Device gar nicht gleichzeitig aufmachen. Gibt ja durchaus andere Devicetypen, wo das so ist und dann "Device busy" beim zweiten Öffnen rauskommt. Im Gegensatz zB. zu Netzwerk via UDP ist halt nur der Empfang nicht Mehrprozesstauglich, d.h. Daten werden nicht auf alle lesenden Prozesse dupliziert. Wobei "Lesen" bei RS232 erst dann gilt, wenn ein read aufgerufen wird und nicht schon beim open. Würden sich die Prozesse mit ihrem read irgendwie zeitlich absprechen, sodass keiner dem anderen was wegschnappen kann, würde auch das gehen. Schreiben ist ohnehin kein Problem (wenn das koordiniert erfolgt, kommt auch kein Matsch raus...). Wenn ein Prozess nach dem Open zB. R+W macht und ein anderer nur W, geht das völlig problemlos ohne das irgendwas explodiert oder was klemmt. > Nicht umsonst hat irgendwer das Tool 'socat' kreiert. Aber nicht wegen den den seriellen Ports, schliesslich heisst es socket cat... > Selbst mit den Boardmitteln wie 'echo' und 'cat' usw. geht das > Datenablauschen nicht. Stattdessen wartet bspw. ein 2. 'cat' Prozess > darauf, dass der erste 'cat' Prozess den Port freigibt. Schon mal ausprobiert oder nur vermutet? Das tut völlig einwandfrei und parallel, wie man zB. sehen kann, wenn man strace davor setzt. Beide cats machen open und read bzw. write. > Der Treiber bedient keinen zweiten Prozess, dieser steht dann in > der Warteschlange oder gibt die Fehlermeldung zurück, dass der > Port belegt ist oder sowas. Nicht bei /dev/ttyS* oder den USB-Equivalenten, da musst du was verwechseln. > Aber das ist jetzt ein Nebenkriegsschauplatz (oder wie man das nennt). Aber trotzdem kein Grund, Gerüchte zu streuen ;) Erwin Meyer: > Beispielsweise kann man sie exclusiv verwenden mit open_excl(). Was aber explizit passieren muss, sowohl "echo blub > /dev/ttyS0" als auch cat machen das nicht.
Inzwischen zeigte sich das es vielleicht ein Kontaktproblem ist, von Mainboard zum DB-9-Stecker: Beim X8SAX ist Pin 5 auf Masse (laut DMM) und damit wie es sein sollte, beim X11SAE kein einziger Pin, obwohl ich bei beiden als Kabel zum Anschluß vom Board das Inline 33208B verwende (1:1, d. h. Pin 1 nach 1 usw., an zwei ovp Exemplaren gemessen) und das auch den "Serial port definitions", die bei beiden Boards gleich sind, entspricht. Da muss ich mit dem Durchgangsprüfer testen ob der Pin 5 direkt auf dem X11SAE wirklich Masse ist und die Kabel alle 1:1 zur Buchse verbinden.
:
Bearbeitet durch User
Also ich habe nachgemessen beim Mainboard und beim Kabel und dabei zeigte sich Doppelmurks: 1. Beim Kabel Inline 33208B ist eine kalte Löststelle, so das Pin 5 des DB-9-Steckers nicht angeschlossen ist. 2. Die Pin-Spezifikation vom X11SAE stimmt nicht: Die Pins haben nicht, wie unter anderm bei IDE üblich (https://de.wikipedia.org/wiki/ATA/ATAPI#Steckerbelegung) und auch im Manual auf Seite 2-20 in Draufsicht beschrieben die Belegung 1 2 3 4 5 6 ... sondern 1 6 2 7 3 8 ...
Das mit den vertauschten Pins ist ein übliches Problem bei MB-Anschlüssen. Meistens ist die Belegung eben nicht so, dass man sie mit einem 2x5 Schneidklemmstecker und einem dsub9 in Schneidklemm machen kann. Diese Adapter werden immer gelötet. Industrieboards haben die Schneidklemm-Variante imo aber häufiger. Ich piepse da immer durch, wo gnd jetzt wirklich rauskommt.
Georg A. schrieb: > Das mit den vertauschten Pins ist ein übliches Problem bei > MB-Anschlüssen. Das wäre ja kein Problem, wenn das dokumentiert wäre. Supermicro dokumentiert aber nicht wo die denn den Pin 2 bei COM1 und COM2 hinsetzen und das der nicht dort ist wo er üblicherweise ist, beispielsweise bei IDE-Anschlüssen, ist schlicht eine Frechheit - zumal der Pin 2 bei allen anderen zweireihigen Stiftleisten auf dem Mainboard woanders eingezeichnet ist, also wie bei IDE-Anschlüssen.
:
Bearbeitet durch User
> und das der nicht dort ist wo er üblicherweise ist, > beispielsweise bei IDE-Anschlüssen, ist schlicht eine Frechheit "Üblich" ist da eben nichts, ausser dass mit steigender "Professionalität" des Boards genau diese Variante häufiger wird ;) Allerdings ist in dem Manual, das ich so auf die Schnelle gefunden habe, die Belegung eigentlich recht offensichtlich und korrekt abgebildet. Es sind zwei Spalten für die beiden Reihen, sodass die Nummerierung der Pins da eben der Zuordnung zu den RS232-Pins entspricht. D.h. da geht ein Adapterkabel mit einem DSUB9-Schneidklemm-Stecker. So oder so ist das die logischere Variante. Es ist eher eine Frechheit, dass bei Consumer-Mainboards genau das nicht geht, weil sie sich an die "normale" Nummerierung von 2reihigen Pinheadern (ala IDE) halten, die aber beim Übergang zu DSUB mit der anderen Zählweise eigentlich keinen Sinn macht. [Beispiel ftp://europe.asrock.com/Manual/X99%20Extreme4.pdf (Seite 25)] Ich will aber nicht behaupten, dass ich da nicht auch schon ein paar mal reingefallen bin. Erfahrung ist das, was man hat, nachdem man sie gebraucht hätte :)
Georg A. schrieb: >> und das der nicht dort ist wo er üblicherweise ist, >> beispielsweise bei IDE-Anschlüssen, ist schlicht eine Frechheit > > Allerdings ist in dem Manual, das ich so auf die Schnelle gefunden habe, > die Belegung eigentlich recht offensichtlich und korrekt abgebildet. Es > sind zwei Spalten für die beiden Reihen, sodass die Nummerierung der > Pins da eben der Zuordnung zu den RS232-Pins entspricht. Nein, da ist nur eine Liste der Signale mit der Pin-Nummer, aber die Positionen sind nicht genannt - außer für Pin 1 und Pin 10, aber die lassen tausende mögliche Pinbelegungen zu ( 8! = 40320 ). Und auf den Seiten 2-18 bis 2-20 ist ausführlich der Anschluß Front Control Panel beschrieben, der ebenfalls eine zweireihige Stiftleiste ist, bei dem aber auch der Pin 2 eingezeichnet ist und aus dem sich die Belegung 1 2 3 4 5 6 ... ergibt. Zusätztlich ist auch direkt neben die Pins in der Zeichnung deren Belegung geschrieben. Und beides (Numerierung u. Beschriftung) fehlt zu COM1 und COM2. Das beide bei einer anderen zweireihigen Stiftleiste weggelassen werden ist Schlamperei und das zudem bei COM1 und COM2 eine ganz andere Belegung verwendet wird, ist eine nicht nachvollziehbare Inkonsistenz, denn im Manual wird nicht verraten wird welche der möglichen 40320 verschiedenen Pin-Belegungen denn verwendet wird.
:
Bearbeitet durch User
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.