Das funzt im Ernstfall auch nicht, schon BS2000 kriegte das nicht hin und ich hab bei Thyssen schon eine Zentrale mit 5 Tandem Non-Stop Rechnern zum stehen gekriegt :-) Ich hatte nur einen simplen Z80 mit
4MHz bei 9600Bd und 3964R Protokoll (neben HART der größte Schwachsinn, der mir für Datenübertragung je unter die Finger gekommen ist).
Es geht eben nix über 20mA CL :-) Nur leider etwas langsam, aber 1000m sind damit kein Problem im Walzwerk.
Sach ich doch! Und wenn Du da ein falsches Nullmodem hast, wo sich die Rechner jeweils selbst befriedigen... Dann ist hängen im Schacht angesagt!
Sie könnten es theoretisch wissen, wenn man die DB25 Steckverbinder richtig einsetzt und benutzt. Nur blöderweise hat IBM das dann bei den PCs mit den DB9 auch noch grantenmässig verschlunzt.
ACK
Da hab ich bisher noch nix mit zu tun gehabt. Aber Siemens SPS-sen sind auch nicht ohne :-)
Braucht aber trotzdem Hardware-Handshake - auch das BS kann nicht beliebige Mengen puffern, wenn die empfangende Applikation die Daten gerade nicht annimmt.
Wenn das Interrupthandling zu langsam ist, hilft es Dir auch nicht, die Handshakes auf einen anderen Eingang zu legen - beim
16550 läuft das alles per Interrupt.
Aber: was hat die Unfähigkeit von MS jetzt mit der Belegung eines Nullmodemkabels zu tun?
Sehen will (aber ohne M$ auf dem Rechner) ;-)
Also nun mal Butter bei die Fische - was soll denn nun passieren?
Was zählt, ist die RS232-Spec und nicht das Datenblatt eine bestimmten (welchen?) UARTs. Also: Was soll Dein komisch belegtes Nullmodem-Kabel besser machen als das von uns vorgeschlagene?
cu Michael
--
Some people have no respect of age unless it is bottled.
Wolfgang schreibt zwar immer UART-Spec, meint aber eigentlich RS232-Spec. In den UART-Specs vom 8250/16450/16550 steht nat=C3=BCrlich g= ar nichts zum Thema "Bedeutung der Handshake-Leitungen", da diese Dinger die Pegel einfach nur weitergeben. Einzige Ausnahme ist, dass eines der Eingangssignale nur eine Flanke auf die Detektion gibt, wenn ich mich richtig erinnere ist es das, was f=C3=BCr RI gedacht ist. Und erst recht interpretieren diese einfachen UARTS kein Hardware-Handshake. Das bedeutet, dass der FIFO *immer* leergesendet wird, egal ob "Clear to send" gerade an ist oder nicht, und dass weder DTR noch RTS von alleine abgeschaltet werden, wenn der Empfangsfifo volll=C3=A4uft.
In den orgininalen RS232-Spec wird von Halbduplex-=C3=9Cbertragung ausgegangen, und RTS/CTS-Handshake wird daher ganz anders interpretiert: RTS bedeutet: Die DTE m=C3=B6chte senden. Die DCE soll sich darum k=C3=BC= mmern, den Kanal zu erhalten. CTS bedeutet: Kanal wurde erfolgreich belegt, DTE darf jetzt senden. DCD bedeutet: Carrier da, also hat die andere Seite den Kanal belegt, und k=C3=B6nnte senden. DSR bedeutet: DCE ist kommunikationsbereit. DTR bedeutet: DTE ist kommunikationsbereit.
Unter wortgetreuer Auslegung des Standards ist es daher sinnvoll, den RTS-Ausgang "Ich will senden" mit dem DCD-Eingang "Es k=C3=B6nnen Daten ankommen" auf der Gegenseite zu verbinden, ebenso DTR "Ich bin kommunikationsbereit" mit dem CTS-Eingang "Du darfst senden".
De fakto wird es aber anders gemacht, egal was der Standard dazu sagt. DCD besagt zwar immernoch, dass der Carrier da ist, hat aber nur noch Diagnosefunktion, in dem es anzeigt, ob die Vollduplex-Verbindung immernoch vorhanden ist. Solange keine St=C3=B6rung auftritt, ist DCD imm= er High. Da kein Halbduplex mehr vorkommt, ist RTS "Request to send" sinnlos geworden, da bei vorhandener Verbindung *immer* gesendet werden kann. Da DTR die Bedeutung "Computer ist prinzipiell darauf eingerichtet, Daten zu =C3=BCbertragen" =C3=BCbernommen hat, ist die jetz= t =C3=BCbliche Interpretation: Wenn DTR weg, dann soll das Modem auflegen, = da sowieso nichts =C3=BCbertragen werden kann, und hat nichts mit der momentanen Empfangsbereitschaft zu tun. Das unn=C3=BCtze RTS wird daher jetzt als RTR interpretiert "Ready to receive", und zeigt in, dass gerade jetzt Daten empfangen werden d=C3=BCrfen. Diese Konvention ist inzwischen inormiert worden (im Rahmen von RS-232-E), was aber einige Standardfanatiker nicht wahrhaben wollen.
Mit RS-232-E ergibt sich f=C3=BCr ein Nullmodem-Kabel die =C3=BCbliche Be= legung, bei der CTSRTS f=C3=BCr das Hardwarehandshaking verwendet wird.
Die schlussendliche Lehre daraus ist, dass man nicht am Standard kleben soll, sondern wenn man "etwas programmiert, wo Personen zu Schaden kommen k=C3=B6nnen", bitte informiert, wie die eingesetzten Ger=C3=A4te d= ie Schnnittstellenpegel interpretieren. Und das steht im Handbuch der Ger=C3=A4te, nicht im RS232-Standard! H=C3=A4ufig ist es sogar konfigurie= rbar.
Als Beispiel: Ich habe hier im Labor ein Ger=C3=A4t, bei dem ein Jumper zwischen RTR und RTS umschaltet, in dem das Signal invertiert(!) wird. RTS ist immer aus, es sei denn, ein Befehl, der eine Antwort erfordert, ist eingegangen. Dann wird RTS angeschaltet, auf CTS gewartet, die Antwort gesendet und RTS wieder ausgeschaltet. Setzt man den Jumper auf die andere Position, erh=C3=A4lt man RTR, da das Ger=C3=A4t w=C3=A4hrend = des Sendens der Antwort nicht bereit ist, weitere Befehle zu empfangen, aber sonst stets empfangsbereit ist.
Ich habe in das Datenblatt zum 8250 und zum 16550 geschaut. Die Handshake-Leitungen haben keinerlei Einfluss auf den Transmitter oder Receiver. Sie koennen maximal IRQs ausloesen. Zumindest der UART im PC ist also ein ziemliches Spardesign welches das gesamte Handshake der Software aufbuerdet.
Mag sein, das es bessere UARTs gibt, aber leider ist man beim typischen PC auf ein 8250-Derivat festgelegt.
Genau davon rede ich die ganze Zeit! Wenigsten bis hierhin sind wir uns einig. Aber das HW-HS nutzt nur, wenn richtig verkabelt wurde und dafür taugt Eurer Schwundlösung nicht, mein Null-Modem funzt immer!
Theoretisch, aber die Rechnung ohne M$ gemacht... su.
Ganz einfach: Wenn Du den gegnerischen CTS nicht abdrehen kannst, ist Ende im Gelände. s.u.
Das ist ein M$ Problem: die haben (zumindest bis W98) den IR zugemacht, solange die Maus mit was zu verschieben beschäftigt war. Hat übelste Konsequenzen gehabt. Ich hatte bei Daimler Benz in D seinerzeit den einzigen Prüfstand, der mit einen PC unter DOS lief. Wurde mehrfach wegen des unmoderne Krams angemacht. Als ich (mit deren Einverständnis) mal vorgeführt habe, wie man Windoof Rechner lähmt, waren alle froh, dass mein Prüfplatz in DOS lief und das bis heute :-) Wer zuletzt lacht, lacht am besten!
Seufz! Klartext: Eure Schwundlösung onaniert nur, jede Seite steuert mehr oder weniger ihre eigenen Handshake Signale.
Richtig ist: RTS (HW sorgt für passiv werden) hängt am TX-ShiftReg und muss den DSR des Gegners betätigen, damit dessen RX freigeben wird (auch eine HW Funktion!). Der Gegner wiederum gibt mit DTR an, das er empfangsbereit ist und steuert damit den CTS des anderen TX an, der damit das TX-ShiftReg startet. Wird der eigene (SW)Empfangsbuffer (zu) voll, setzt man DTR auf passiv und das ganze beruhigt sich ordentlich.
Die FIFOs in manchen UARTs helfen etwas bei schlampigen Programmierern und schlampiger Verbindung. Aber nicht unter allen Umständen!
Das richtig aus den RS232 Specs rauszulesen, gelingt nicht jedem. QED. Drum mein Hinweis auf die UART HW Funktionen. Den Hinweis dazu und welche UARTs als Beispiel, habe ich schon gepostet.
Ansonsten: Glauben heisst nix wissen. Ich weiss es!
Ich hab jetzt keine Zeit und Lust in den 8250 Specs nachzusehen, die Z80 SIOs haben aber die HW Funktionen garantiert, dass der CTS den TX freigibt, der RTS am TX-ShiftReg hängt, DSR den RX freigibt...
Das erklärt vieles. Damit ist es natürlich von der Antwortzeit des BS abhängig.
Es gibt UARTs die sogar XON/XOFF in Hardware steuern können.
Auch könnte man auf der Gegenseite tricksen, z.B. periodisch wechselnde 'Handshake-Leitungen oder XON/XOFF' erwarten. Wechselt nichts mehr, dann wartet man eben auf den nächsten Wechsler und sendet erst dann weiter. Zusammen mit dem FIFO im PC würde das reichen einen Überlauf streng zu verhindern.
Ich habe von PCs diesbezüglich wenig Ahnung. Der Urahn ist wohl der 8250 und auf dessen Funktionalität kann man sich also verlassen, auf mehr eher nicht.
Nur für mich nochmal, da ich mittlerweile die Übersicht die ich nie hatte gänzlich verlor: Du hast gerade eine Lösung für Windoof-Rechner aufgezeigt, die garantiert funzt?
Nein, was funzt bei Windoof garantiert, ausser das nicht funzen?
Ich versuche nur darzustellen, warum die landläufigen Null-Modems flasch belegt sind und wie man sich eine üble Zufalls-Fehlerquelle vom Hals hält. Und falls am anderen Ende ein ordentliches UART samt ordentlichem OS hängt, hast Du keinerlei Probleme. Obendrein schärft die Beschäftigung mit einem ordentlichen UART den Blick.
Wenn das sauber gemacht ist und Du sicherstellst, dass ein XOFF nicht verschütt geht... ggf. mehrere senden, bis nix mehr kommt, könnte helfen. Bei einer Vollduplex Verbindung stelle ich mir das mit XON/XOFF aber nicht wirklich lustig vor.
Vor zwanzig Jahren hatten die PCs 8250 oder 16450 verbaut. Kein FIFO. Kein Hardware-Handshake im UART. Letzteres haben auch die aktuelleren
16550 nicht. Und was Wolfgang nicht wahrhaben will, ist dass die aktuelle Konvention f=C3=BCr Ger=C3=A4te mit serieller Schnittstelle am PC *nicht*= das ist, was damals sein Z80-UART gemacht hat. Da der UART selber nichts macht, hat hi= er die Software freie Hand (und viel Gelegenheit, Handshake zu verschlafen), und durchgesetzt hat sich nunmal DTR/DSR als Zeichen dass die andere Seit= e da ist, und RTS/CTS f=C3=BCr das Handshaking.
Weiterhin wurden Festplattendatan damals in einer Interruptroutine per Port-I/O versendet, was bei den ISA-typischen 1,5M/s f=C3=BCr einen Sekto= r nun mal 300us dauert. Normalerweise hat man sich die M=C3=BChe gespart, weite= re Interrupts w=C3=A4hrenddessen zuzulassen, und selbst wenn: Die Festplatte= hat eine h=C3=B6here Interruptpriorit=C3=A4t als die serielle Schnittstelle. = Ein Zeichen bei 115200 dauert knapp 90us. Das knallt zuverl=C3=A4ssig, weshalb das da= mals =C3=BCbliche Shareware-Programm Telix zum Beispiel die Option hatte, DTR = w=C3=A4hrend des Datentr=C3=A4gerzugriffs zu deaktivieren, was zeigt, dass damals DTR = als Handshakeleitung (so wie Wolfgang es bei aktuellen Ger=C3=A4ten verwenden= will) tats=C3=A4chlich genutzt wurde.
Mit 9600 (also 1ms pro Zeichen) wird es so schnell zwar nicht knapp, aber wer nat=C3=BCrlich schlecht geschriebene Software verwendet, kann auch da= nn =C3=84rger kriegen. Und High-End-PC sch=C3=BCtzt nicht davor, dass z.B. das Windows-= Programm "Terminal", Vorg=C3=A4nger von HyperTerminal eingesetzt wurde, und einem = das Windows-3.1-Multitasking Kn=C3=BCppel zwischen die Beine wirft.
Jup, und dieses Design haben dann viele nachgebaut, der 8250 und seine Derivate waren wohl einen Tick billiger. Teilweise gabs auch fehlerhafte Designs (Beim 6551 schaltet ein inaktiv werdendes CTS den Transmitter ab, sofort, ohne darauf zu warten, dass das aktuelle Byte komplett gesendet wird).
Auch bei den kleinen AVR hat man nur TxD und RxD in Hardware, alles andere darf man per Software erschlagen.
So schoen andere UARTs sind, wir muessen leider in fast allen Faellen mit dem 8250 bzw. Nachfolger zurechtkommen.
Das ist für einfache Diagnosefunktionen OK. Wer damit größere Datenmengen übertragen will, braucht inband-signalling als Handshake, das ist erst Recht ekelhaft, wenn man eigentlich 8-Bit-Daten transparent übertragen will.
cu Michael
--
Some people have no respect of age unless it is bottled.
Kann ich doch - indem ich RTS abdrehe, nehme ich der gegenseite CTS weg, und schon ist Ruhe.
Kann es sein, daß Du meine Belegung überhaupt nicht genau angesehen hast? Ich will *nicht* RTS+CTS *lokal* kreuzen!
Du fängst schon wieder an, Microsoft-Probleme als Beispiel zu nehemn und daraus die allgemeine Schlußfolgerung zu ziehen, daß das alle so verkehrt machen müssen.
Nein.
Das ist bei den PC-üblichen UARTs seit dem 8250 nicht so (wenn Du schon so gerne DOS/Windows anführst, wird der dort gängige UART ja als Referenz durchgehen): RTS wird in Software gesteuert, und DSR landet in einem Bit im MSR-Register und löst maximal einen Interrupt aus, weitere Hardware-Funktionen oder gar Verbindungen zum TX-Schieberegister gibt es nicht (ohne FIFO wäre das auch reichlich zweckfrei: das aktuelle Zeichen muß eh zu Ende gesendet werden, und ohne FIFO kommt da nichts nach, ohne daß die CPU aktiv wird).
Ich sehe nicht, wieso das besser funktionieren soll als meine Lösung mit RTS/CTS - abgesehen davon, daß es *heute* UARTs mit reichlich FIFO gibt, die den Handshake per RTS/CTS tatsächlich in Hardware können (TL16C550C, OX16C950), den per RTS/DSR aber nicht.
BTW: der gute alte MC68681 hatte schon (nur) Anschlüsse für RTS/RTR und CTS, und konnte die selber bedienen, MC6850 und die neueren TL16C550C ebenfalls. Einen DSR-Eingang mußte man per Portbit und Software bedienen, auch hier macht also ein gekreuztes RTS/CTS Sinn, weil es ohne CPU-Intervention zu einem funktionierenden Handshake in Hardware führt, bidirektional.
Da hat man zwischen "Puffer zu Voll" und "DTR passiv" genau die Interruptlatenzzeit, die zu Überläufen führen kann.
Jein. Die FIFOs erlauben höhere Latenzen, ohne daß Überläufe auftreten. Bei einem BS, das ausreichend lange die Interrupt sperrt, hilft das überhaupt nichts, und korrekt funktionierende Treiber sind in jedem Fall Voraussetzung - kaputte Software per Hardware ausgleichen zu wollen, klingt wirklich krank, paßt aber zu DOS/Windows.
cu Michael
--
Some people have no respect of age unless it is bottled.
Sagte ja schon mit XON/XOFF. Für transparente 8-Bit Daten geht das nicht. Wird aber auch seltenst im Embedded Bereich gebraucht, da dann sowieso eine Form von Fehlersicherung auf höherer Ebende notwendig wird z.B. für Dateiupdates.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.