mikrocontroller.net

Forum: PC Hard- und Software Minicom empfängt keine Daten über serielle Schnittstelle


Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: K. Hegy (hegy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: K. Hegy (hegy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: K. Hegy (hegy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Konfiguration zeigt das HW Handshake nur für ttyUSB0.
Hast Du das bei allen anderen ebenfalls ausgeschaltet?

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
minicom -D /dev/tty....

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stty -a

zeigt alles in lesbarer Form an...

Autor: Erwin Meyer (nobodyy)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: K. Hegy (hegy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf F. (Firma: G.) (benutzername0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: K. Hegy (hegy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: K. Hegy (hegy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
...

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 :)

Autor: Erwin Meyer (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.