Probleme mit serieller Datenübertragung

[Grit]

Hi

mein problem ist etwas kompliziert und ich hoffe jemand kann mir
helfen:

Ich habe einen alten PC der über RS232 an eine externe Hardware mit
600 Baud angeschlossen ist. Über die Hardware werden Telegramme
ausgetauscht in beide Richtungen wobei diese immer 15 Byte lang sind
und der Telegrammanfang durch eine Pause vor dem ersten Telegram
erkannt wird.

Alles läuft Prima. Jetzt muss ich den Aufbau ändern, so daß zwischen
dem Partner A und B ein neuer PC dazwischen geklemmt wird, der die
Daten von A über eine 2. serielle Schnittstelle nach B sendet und
umgekehrt. Aufbau: A <-> neuer PC <-> B

Da die neuen PCs nur noch eine COM Schnittstelle haben, hab ich eine
zusätzliche Karte eingebaut. Auf dem neuen PC sind die beiden
Baudraten auf 600 eingestell (sowohl in der Systemsteuerung als auch
in meiner Umsetzungssoftware) und auch das Frame ist korrekt auf allen
3 Seiten auf 8N1 eingestellt (ebenfalls sowohl in der Systemsteuerung
als auch meiner Software)

Wenn ich jetzt den Rechner A mit dem neuen PC über die
Schnittstellenkarte verbinde und ebenso den Rechner B über die
zusätzliche Karte, dann empfangt der Rechner B von A korrekte
Telegramm. Wenn ich jetzt aber von B was nach A senden will, dann
ignoriert Rechner A das Telegram weil er anscheinend meint es sei
Schrott.

Wenn ich Rechner A an die Onboard-COM schnittstelle hänge, dann
versteht nicht mal mehr Rechner B die Daten und meint es seien keine
Vollständigen Telegramme. Wir haben an Rechner B einen V.24 Analyzer
gehängt. Das Telegramm wird dort aber korrekt angezeigt. Verbinden wir
Rechner A mit B wieder direkt funktioniert auch alles wieder super in
beide Richtungen wo bei bei Rechner B die onBoard-Schnittstelle
verwendet wird.
Kann mir einer von Euch einen Tip geben woran das liegen kann??? Ich
hab schon vermutet, daß Rechner B falsch abtastet. Er tastet ja jedes
Bit ab ob es high oder low ist und wenn der neue Rechner zu schnell
sendet, daß Rechner B dann die falschen Ergebnisse bekommt.
Faszinierenderweise ergab die Aufzeichnung, daß Rechner A 18 ms pro
Byte zur Übertragung braucht während der neue PC bei gleicher Baudrate
16 ms braucht....

Grit

 

[B. MĂźller]

Grit <grka@gmx.de> schrieb:

Funktioniert das Programm von dem alten Rechner auf dem neuen mit
direkter Verbindung (Ăźber beide COM-Schnittstellen) zur externen
Hardware?

Leider läuft das alte Programm nicht auf PCs mit Windows 2000 und ßber
200 MHz (der neue PC hat 2 GHz)

Ok, funktioniert eine Direktverbindung mit z. B. Hyperterminal zwischen
Rechner "neu" und Rechner "A" bzw. "B" einwandfrei? Wie sieht es aus mit
Handshake bzw. den Fifo-Einstellungen?

Wie haben sich die Kabellängen geändert?

Gar nicht. Wir verwenden das selbe Kabel. Wir haben das Kabel zum PC A
von PC B abgezogen und auf den neuen PC aufgesteckt. Kabellänge ist ca
2-2,5 m

Gut, ist das Kabel zwischen "neu" und "B" gleich beschaltet wie das alte?

Wie sieht es mit den Erdverhältnissen aus?

vom Verbindungskabel oder vom PC?

PC - spielt aber bei diesen kurzen Entfernungen wohl keine Rolle.

Wenn alle Tests mit Rechner "neu" Ăźber beide Schnittstellen und mit jeweils
beiden Kabeln mit beiden Rechnern erfolgreich ist - was macht das Programm,
das auf Rechner "neu" zwischen den Schnittstellen vermittelt, mit den
Daten?

¡­­¡ ¡­¡¡ ¡ ¡­ ¡¡¡ ¡ ­¡¡ ­­­ ­¡ ­­­ ­ ¡¡­¡ ¡ ¡ ­¡¡ ­ ¡¡¡¡ ¡ ¡­¡ ­¡
¡¡­¡

 

[B. MĂźller]

Nachtrag:

Grit <grka@gmx.de> schrieb:

Faszinierenderweise ergab die Aufzeichnung, daß Rechner A 18 ms pro
Byte zur Übertragung braucht während der neue PC bei gleicher Baudrate
16 ms braucht....

600 Bd, 8N1 wären 16,666 ms pro Byte. Wie genau ist die Messung?

Soweit ich sehen kann wird auf ms genau gemessen.

Ich gehe mal davon aus, daß bisher kein (Hardware)-Handshake auf der
direkten Verbindung verwendet wurde; das ist bei 600 Bd und Telegrammen mit
15 Bytes auch kein Problem.

In dem neuen Rechner spielt es aber sehr wohl eine Rolle. Wie Du schreibst,
funktioniert die Übertragung von der langsamen Seite ("A") nach "B",
umgekehrt aber nicht. Dazu paßt, daß Rechner "A" meint, die ankommenden
Telegramme seien Schrott. Vermutlich sendet der neue Rechner schon ein
neues Byte, während das alte noch nicht vollständig ßbertragen wurde.

Abhilfe: Warten, bis das Byte vollständig ßbertragen wurde unter Ausnutzung
des Hardware-Fifo auf der anderen Seite oder Nachbildung eines
entsprechenden Fifos durch die Software.

¡­­¡ ¡­¡¡ ¡ ¡­ ¡¡¡ ¡ ­¡¡ ­­­ ­¡ ­­­ ­ ¡¡­¡ ¡ ¡ ­¡¡ ­ ¡¡¡¡ ¡ ¡­¡ ­¡
¡¡­¡

 

[Ulrich Prinz]

Grit wrote:

Hi

mein problem ist etwas kompliziert und ich hoffe jemand kann mir
helfen:

Ich habe einen alten PC der über RS232 an eine externe Hardware mit
600 Baud angeschlossen ist. Über die Hardware werden Telegramme
ausgetauscht in beide Richtungen wobei diese immer 15 Byte lang sind
und der Telegrammanfang durch eine Pause vor dem ersten Telegram
erkannt wird.

Hallo Grit!

Nur noch mal zum Verständnis:

Die externe Hardware ist an der Fehlübertragung nicht beteiligt? Nur die
Kommunikation alter Rechner <-> neuer Rechner macht Probleme?

Wenn Du sagst, dass das Telegramm des alten Rechners bei 600 Baud etwa
18ms lang ist, dann liegt das sehr hart auf der Grenze der Zulässigkeit,
da es gegenüber der Norm von 16,6ms bereits eine Abweichung von satten
10% aufweist.

Kannst Du feststellen, mit welchen Seriellen Chips der Alte PC arbeitet?
Steckt da eine spezielle Karte drinn mit 16450 / 16550 drauf im alten PC?

Dann beachte auch den Tip von B. Müller, dass der neue PC erst dann
Daten senden darf, wenn der Alte das vorangegangene Byte ausreichend
weit verarbeitet hat.

Kabel und Stecker kann man in Deinem Aufbau, sofern sie korrekt
verdrahtet sind, vernachlässigen, bei 600 Baud muss das ganze auch bei
wit über 20m funktionieren, da sind 1-2m uninteressant. Es wird ein
reines Kommunikationsproblem sein.
Hast Du geprüft, ob der alte PC eventuell ein Handshake verwendet und
der neue PC trotz zurückgezogenem RTS/CTS oder DTR/DSR bereits Daten
sendet? Früher wurden diese Leitungen reichlich benutzt, da die PCs
tatsächlich zu lansam waren um auch bei niedrigen Baudraten die Daten
schnell genug zu verarbeiten.
Ich gehe einfach mal davon ausm dass Du die Daten genau kennst und
sicher bist, dass es wirklich 8n1 und nicht 7e1 oder 7n2 oder 7o1 ist.

Aber 18ms für ein Byte sind dicht über 555 Baud... Das ist arg daneben...

Gruß,

Ulrich

 

[Grit]

600 Bd, 8N1 wären 16,666 ms pro Byte. Wie genau ist die Messung?
Soweit ich sehen kann wird auf ms genau gemessen.
Ich gehe mal davon aus, daß bisher kein (Hardware)-Handshake auf der
direkten Verbindung verwendet wurde; das ist bei 600 Bd und Telegrammen mit
15 Bytes auch kein Problem.
Da Rechner A eine uralte Fremdhardware (kein PC)ist, der kein

Hardwarehandshake unterstĂźtzt wurden auch nur die Sende und
Empfangsleitungen verdrahtet und die GND

In dem neuen Rechner spielt es aber sehr wohl eine Rolle. Wie Du schreibst,
funktioniert die Übertragung von der langsamen Seite ("A") nach "B",
umgekehrt aber nicht. Dazu paßt, daß Rechner "A" meint, die ankommenden
Telegramme seien Schrott. Vermutlich sendet der neue Rechner schon ein
neues Byte, während das alte noch nicht vollständig ßbertragen wurde.
Abhilfe: Warten, bis das Byte vollständig ßbertragen wurde unter Ausnutzung
des Hardware-Fifo auf der anderen Seite oder Nachbildung eines
entsprechenden Fifos durch die Software.
Leider kÜnnen wir die Software in Rechner A nicht ändern... wir haben

shcon versucht auf dem neuen Rechner statt 600 Baud nur mit 570 Baud
zu Ăźbertragen, aber geholfen hat es nicht

Grit

 

[Grit]

Funktioniert das Programm von dem alten Rechner auf dem neuen mit
direkter Verbindung (Ăźber beide COM-Schnittstellen) zur externen
Hardware?
Leider läuft das alte Programm nicht auf PCs mit Windows 2000 und ßber
200 MHz (der neue PC hat 2 GHz)
Ok, funktioniert eine Direktverbindung mit z. B. Hyperterminal zwischen
Rechner "neu" und Rechner "A" bzw. "B" einwandfrei?
Also zwischen "neu" und B gibt's keine Probleme. Zwischen "neu" und A

läßt es sich schwer testen weil da ein gewisses Telegrammhandshake
inkl. timing eingehalten werden muss sonst verwirft Rechner A die
Telegramme (A ist kein PC sondern eine externe Hardware)

Wie sieht es aus mit
Handshake bzw. den Fifo-Einstellungen?
Handshake ist nicht mĂśglich, wird von Rechner A nicht unterstĂźtzt und

ist auch nicht verdrahtet. Fifo haben wir versucht hochzudrehen und
auch runterzudrehen. Ändert aber nichts

Wie haben sich die Kabellängen geändert?
Gar nicht. Wir verwenden das selbe Kabel. Wir haben das Kabel zum PC A
von PC B abgezogen und auf den neuen PC aufgesteckt. Kabellänge ist ca
2-2,5 m
Gut, ist das Kabel zwischen "neu" und "B" gleich beschaltet wie das alte?
Nein, da Rechner B mit Rechner A mit einem Kabelverbunden ist was

jetzt zwischen Rechner A und "neu" verwendet wird brauchten wir ein
neues Kabel zw. "neu" und B. HierfĂźr nutzen wir ein ganz normales
Nullmodem kabel

Wie sieht es mit den Erdverhältnissen aus?
vom Verbindungskabel oder vom PC?
PC - spielt aber bei diesen kurzen Entfernungen wohl keine Rolle.
Jeder der Rechner hängt an einer eigenen Steckdose

Wenn alle Tests mit Rechner "neu" Ăźber beide Schnittstellen und mit jeweils
beiden Kabeln mit beiden Rechnern erfolgreich ist - was macht das Programm,
das auf Rechner "neu" zwischen den Schnittstellen vermittelt, mit den
Daten?
Das Programm auf "neu" bekommt die Daten von der einen Com

Schnittstelle und sendet sie im Moment einfach nur an die andere Com
Schnittstelle weiter. Alle zusatzfunktionalitäten haben wir schon
abgeschaltet

Grüße
Grit

 

[Grit]

Danke für den Tip. Ja es wurde in der Tat damit entwickelt, aber leider
haben wir es auch mit dem Patch nicht zum laufen gebracht

"Thilo-Alexander Ginkel" <tg@despammed.com> schrieb im Newsbeitrag
news:9fo1kb.ij2.ln@stargazer.intranet.tgbyte.de...

Grit schrieb:

Funktioniert das Programm von dem alten Rechner auf dem neuen mit
direkter
Verbindung (über beide COM-Schnittstellen) zur externen Hardware?
Leider läuft das alte Programm nicht auf PCs mit Windows 2000 und über
200 MHz (der neue PC hat 2 GHz)

Dann wurde es vermutlich in Borland Pascal 7 entwickelt und lässt sich
u.U.
patchen, so dass es auch mit höheren Taktfrequenzen läuft:
http://www.webplain.de/turbopascal/error200.php

Gruß,
Thilo

 

[B. MĂźller]

Grit <grka@gmx.de> schrieb:

Also zwischen "neu" und B gibt's keine Probleme. Zwischen "neu" und A
läßt es sich schwer testen weil da ein gewisses Telegrammhandshake
inkl. timing eingehalten werden muss sonst verwirft Rechner A die
Telegramme (A ist kein PC sondern eine externe Hardware)

Aha, das ist doch mal ein konkreter Ansatzpunkt. Durch den zusätzlichen
Rechner ergibt sich eine VerzÜgerung von mind. einer Framelänge im
Telegrammhandshake. Sollte das die Ursache sein, daß die externe Hardware
die Telegramme von Rechner "neu" verwirft, wird es mit dieser Konfiguration
nicht funktionieren.

Was kĂśnnte man tun? Ist das alte Programm in der Lage, die gewĂźnschten
Daten auf eine zweite COM-Schnittstelle umzuleiten, kĂśnnte man die Funktion
der Rechner "neu" und "B" einfach vertauschen. Alternativ kĂśnnte der neue
Rechner die Daten auch direkt von der ursprĂźnglichen Verbindung abgreifen
(sniffen). Ohne Hardware-Handshake ist das eine recht einfache Sache.

Das Programm auf "neu" bekommt die Daten von der einen Com
Schnittstelle und sendet sie im Moment einfach nur an die andere Com
Schnittstelle weiter.

Unter BerĂźcksichtigung FĂźllzustandes des Sendpuffers auf der "langsamen"
Schnittstelle? Wie die Analyse zeigt, kommen die Daten auf der einen
Schnittstelle ja schneller an, als sie den Rechner auf der anderen wieder
verlassen können. Die 2 ms Unterschied sind schon größer als eine Bitlänge,
sodaß es ohne Zwischenpufferung zu einem Frameerror kommen »muß«. Diese
mögliche Ursache würde ich als erstes ausschließen. Hilft das nicht, s. o.

¡­­¡ ¡­¡¡ ¡ ¡­ ¡¡¡ ¡ ­¡¡ ­­­ ­¡ ­­­ ­ ¡¡­¡ ¡ ¡ ­¡¡ ­ ¡¡¡¡ ¡ ¡­¡ ­¡
¡¡­¡

 

[Grit]

Also zwischen "neu" und B gibt's keine Probleme. Zwischen "neu" und A
läßt es sich schwer testen weil da ein gewisses Telegrammhandshake
inkl. timing eingehalten werden muss sonst verwirft Rechner A die
Telegramme (A ist kein PC sondern eine externe Hardware)
Aha, das ist doch mal ein konkreter Ansatzpunkt. Durch den zusätzlichen
Rechner ergibt sich eine Verzögerung von mind. einer Framelänge im
Telegrammhandshake. Sollte das die Ursache sein, daß die externe Hardware
die Telegramme von Rechner "neu" verwirft, wird es mit dieser
Konfiguration
nicht funktionieren.
Glaub ich ehrlich gesagt nicht, denn wir senden nur ein Telegramm und da

kommt es nur auf die Zeit zwischen 2 Bytes an und die ist laut Messung weit
unter dem Limit

Was könnte man tun? Ist das alte Programm in der Lage, die gewünschten
Daten auf eine zweite COM-Schnittstelle umzuleiten, könnte man die
Funktion
der Rechner "neu" und "B" einfach vertauschen.
Leider nicht. Der neue Rechner hat die spätere Aufgabe 2 PCs/Programmen zu

ermöglichen ihr Telegramm auf die selbe COM Schnittstelle auf Rechner A zu
senden. Hierfür muss die Software auf dem neuen Rechner die Telegramme von
Rechner B und einem 2. Programm empfangen und koordiniert an Rechner A
senden so daß die Bytes nicht durcheinander gewürfelt werden. Im Moment
läuft aber das 2. Programm nicht so daß nur Daten vom Rechner B kommen

Alternativ könnte der neue
Rechner die Daten auch direkt von der ursprünglichen Verbindung abgreifen
(sniffen). Ohne Hardware-Handshake ist das eine recht einfache Sache.
siehe oben - Aufgabe des Rechner ist es das versenden von 2

unterschiedlichen Datenquellen zum Rechner A zu koordinieren.

Das Programm auf "neu" bekommt die Daten von der einen Com
Schnittstelle und sendet sie im Moment einfach nur an die andere Com
Schnittstelle weiter.
Unter Berücksichtigung Füllzustandes des Sendpuffers auf der "langsamen"
Schnittstelle? Wie die Analyse zeigt, kommen die Daten auf der einen
Schnittstelle ja schneller an, als sie den Rechner auf der anderen wieder
verlassen können. Die 2 ms Unterschied sind schon größer als eine
Bitlänge,
sodaß es ohne Zwischenpufferung zu einem Frameerror kommen ťmuߍ. Diese
mögliche Ursache würde ich als erstes ausschließen. Hilft das nicht, s. o.
Das Problem könnte also tatsächlich diese 2 ms sein? Dann sollte es auch

helfen die Baudrate beim neuen Rechner solange runter zu drehen bis ein Byte
auch 18 ms braucht, oder?! Ich dachte immer, daß wenn 2 Rechner die selbe
Baudrate einstellen die bytes auch die selbe Zeit zur Übertragung
benötigen....

Grüße
Grit

 

[B. MĂźller]

Grit <andy.tess@gmx.de> schrieb:

Sollte das die Ursache sein, daß die externe Hardware die Telegramme von
Rechner "neu" verwirft, wird es mit dieser Konfiguration nicht
funktionieren.

Glaub ich ehrlich gesagt nicht, denn wir senden nur ein Telegramm und da
kommt es nur auf die Zeit zwischen 2 Bytes an und die ist laut Messung
weit unter dem Limit

Gut, das scheidet also aus und vereinfacht die Sache.

Der neue Rechner hat die spätere Aufgabe 2 PCs/Programmen zu ermÜglichen
ihr Telegramm auf die selbe COM Schnittstelle auf Rechner A zu senden.
HierfĂźr muss die Software auf dem neuen Rechner die Telegramme von
Rechner B und einem 2. Programm empfangen und koordiniert an Rechner A
senden so daß die Bytes nicht durcheinander gewürfelt werden. Im Moment
läuft aber das 2. Programm nicht so daß nur Daten vom Rechner B kommen

Ok, damit reduziert sich dein Problem auf die softwaretechnische Umsetzung
der Pufferung von Eingangsdaten.

Das Problem kÜnnte also tatsächlich diese 2 ms sein? Dann sollte es auch
helfen die Baudrate beim neuen Rechner solange runter zu drehen bis ein
Byte auch 18 ms braucht, oder?!

Nein - Du wirst es vielleicht zum Laufen bekommen, ein LĂśsung ist das
nicht. Die Lösung heißt: Pufferung der Daten von einer Schnittstelle zur
anderen - egal in welche Richtung. Um einen Zwischenspeicher fĂźr die beiden
Datenquellen wirst Du sowieso nicht herumkommen, da sie vermutlich
asynchron laufen.

Ich dachte immer, daß wenn 2 Rechner die selbe Baudrate einstellen die
bytes auch die selbe Zeit zur Übertragung benötigen....

Innerhalb der Toleranzen stimmt das auch. Es geht hier aber um Zeiten
kleiner als eine halbe Bitlänge (833 ¾s), im worstcase um noch viel
weniger!

¡­­¡ ¡­¡¡ ¡ ¡­ ¡¡¡ ¡ ­¡¡ ­­­ ­¡ ­­­ ­ ¡¡­¡ ¡ ¡ ­¡¡ ­ ¡¡¡¡ ¡ ¡­¡ ­¡
¡¡­¡

 

[Grit]

Glaub ich ehrlich gesagt nicht, denn wir senden nur ein Telegramm und da
kommt es nur auf die Zeit zwischen 2 Bytes an und die ist laut Messung
weit unter dem Limit
Gut, das scheidet also aus und vereinfacht die Sache.
Stimmt.

Der neue Rechner hat die spätere Aufgabe 2 PCs/Programmen zu ermöglichen
ihr Telegramm auf die selbe COM Schnittstelle auf Rechner A zu senden.
Hierfür muss die Software auf dem neuen Rechner die Telegramme von
Rechner B und einem 2. Programm empfangen und koordiniert an Rechner A
senden so daß die Bytes nicht durcheinander gewürfelt werden. Im Moment
läuft aber das 2. Programm nicht so daß nur Daten vom Rechner B kommen
Ok, damit reduziert sich dein Problem auf die softwaretechnische Umsetzung
der Pufferung von Eingangsdaten.
Tun wir ja schon. Es ist so, daß wir das Telegramm erst dann weitersenden,

wenn es vom neuen PC vollständig empfangen wurde. Sobald wir die 15 Bytes
haben übergeben wir sie an eine DLL von der Firma Langer und diese sendet
sie dann raus

Das Problem könnte also tatsächlich diese 2 ms sein? Dann sollte es auch
helfen die Baudrate beim neuen Rechner solange runter zu drehen bis ein
Byte auch 18 ms braucht, oder?!
Nein - Du wirst es vielleicht zum Laufen bekommen, ein Lösung ist das
nicht. Die Lösung heißt: Pufferung der Daten von einer Schnittstelle zur
anderen - egal in welche Richtung.
Geschieht bereits. Was die Dll macht kann ich leider nicht beeinflussen.

Um einen Zwischenspeicher für die beiden
Datenquellen wirst Du sowieso nicht herumkommen, da sie vermutlich
asynchron laufen.
Buffern tun wir es bereits

Ich dachte immer, daß wenn 2 Rechner die selbe Baudrate einstellen die
bytes auch die selbe Zeit zur Übertragung benötigen....
Innerhalb der Toleranzen stimmt das auch. Es geht hier aber um Zeiten
kleiner als eine halbe Bitlänge (833 ľs), im worstcase um noch viel
weniger!
Ach so.

Grit

 

[Rainer Zocholl]

(Grit) 13.09.03 in /de/sci/electronics:

Ich habe einen alten PC der über RS232 an eine externe Hardware mit
600 Baud angeschlossen ist. Über die Hardware werden Telegramme
ausgetauscht in beide Richtungen wobei diese immer 15 Byte lang sind
und der Telegrammanfang durch eine Pause vor dem ersten Telegram
erkannt wird.

Alles läuft Prima. Jetzt muss ich den Aufbau ändern, so daß zwischen
dem Partner A und B ein neuer PC dazwischen geklemmt wird, der die
Daten von A über eine 2. serielle Schnittstelle nach B sendet und
umgekehrt. Aufbau: A <-> neuer PC <-> B

Da die neuen PCs nur noch eine COM Schnittstelle haben, hab ich eine
zusätzliche Karte eingebaut.

Unnotig. Meistens haben auch die neuen PCs eine 2. Schnittstelle,
nur keinen Sub-D daran! Schau mal auch die Platine ob es
da irgendwo einen unbenutzen 2x5poligen Pfosten Stecker gibt...


Achte darauf das ein PC nicht mehr als 2 normale seriellen Schnittstellen
gleichzeitig bearbeiten kann, auch wenn die Nummerierung bis com4 geht!

Auch sollte man bei 3 Rechnern mit einem Brumschleifen-Problem
rechnen.

Faszinierenderweise ergab die Aufzeichnung, daß Rechner A 18 ms pro
Byte zur Übertragung braucht während der neue PC bei gleicher Baudrate
16 ms braucht....

Was verursacht diesen Unterschied?
Sind die Bits länger oder ist da eine längere Pause zwischen den Bytes?

Das 2. würde zwanglos erklären, warum es mit der Kommunikation
Neu -> A nicht klappt:
Die alte Möhre A ist einfach zu langsam und braucht die 2ms Pause
zwischen den Zeichen um dieses von der Schnittstelle abzuholen.
Wird also überfahren. 2ms erscheinen mir für "uralt Software"
die mit 600bps arbeitet als Interrupt-Latency durchaus
angemessen...

Ein Fifo macht die Sache hier schlimmer, nicht besser.
Es 2GHz Pentium hat kein Problem diese Daten rechtzeitig abzuholen,
auch wenn jedes Bit 16 Interupts geben würde, er also den UART
emulieren könnte.

Alte UARTs reagierten aber sehr sauer, wenn sie überfahren wurden.
Das schon korrekt empfangene Byte wurde gnadenlos übermangelt,
wenn die CPU nicht schnell genug war.

Software handshake nutzte auch nix, weil die die CPU ja
kein Stop schicken kann, wenn sei nicht einmal vom eingetroffenen
Zeichen den Status weis..

Vielleicht wird es etwas besser wenn Du mit 8N2 oder 10N2 sendest..
Die unnützen Bits im Pegel wie die Stopbits stellen.
Aber ich fürchte deine Hardware kann kein 10Nx, also
vor jedem Zeichen sleep_ms(2);

 

[Ulrich Prinz]

Grit wrote:

Hi


Nur noch mal zum Verständnis:
Die externe Hardware ist an der Fehlübertragung nicht beteiligt? Nur die
Kommunikation alter Rechner <-> neuer Rechner macht Probleme?

Also stell dir folgende Konfiguration vor:
"Rechner A <-> neuer PC <-> Rechner B" Rechner A sendet über den neuen
PC an Rechner B und umgekehrt. Die Richtung von A nach B geht, aber
von B nach A ergibt Probleme. Rechnre A meint, daß die Daten schrott
seien obwohl sie laut V.24 Analyzer korrekt aussehen.

Also da sehe ich dann noch die Möglichkeit, dass Rechner A ebenfalls von
Siemens ist und die Schnittstellen auf eine proprietäre Baudrate
angepaßt wurden.... Nur mal so als Idee... Ist Rechner A vielleicht eine
305/306 oder ein R- oder M-Rechner?

Wenn Du sagst, dass das Telegramm des alten Rechners bei 600 Baud etwa
18ms lang ist, dann liegt das sehr hart auf der Grenze der Zulässigkeit,
da es gegenüber der Norm von 16,6ms bereits eine Abweichung von satten
10% aufweist.
Kannst Du feststellen, mit welchen Seriellen Chips der Alte PC arbeitet?

Kann ich mal versuchen herrauszufinden. Ist ein Siemens H4 oder H5 PC
(Uralt also)

Jep, Uralt. Aber scheinbar unverwüstlich

Steckt da eine spezielle Karte drinn mit 16450 / 16550 drauf im alten PC?

Nein, es werden die 2 OnBoard seriellen Com Ports verwendet


[...]

Hast Du geprüft, ob der alte PC eventuell ein Handshake verwendet und
der neue PC trotz zurückgezogenem RTS/CTS oder DTR/DSR bereits Daten
sendet? Früher wurden diese Leitungen reichlich benutzt, da die PCs
tatsächlich zu lansam waren um auch bei niedrigen Baudraten die Daten
schnell genug zu verarbeiten.

Nein leider unterstützt der Rechner A keinerlei Handshake. Es wurden
auch nur die 2 Drähte verlötet (Sendeleitung, Empfangsleitung und
Erdung) Da Rechner A keine kein PC ist können wir auch daran nichts
ändern

OK, dann scheidet das wirklich aus. War aber vorher noch nicht so gesagt

worden, daher hätte es ja sein können

Ich gehe einfach mal davon ausm dass Du die Daten genau kennst und
sicher bist, dass es wirklich 8n1 und nicht 7e1 oder 7n2 oder 7o1 ist.

Ja wir haben die Einstellungen übernommen mit denen Rechner B bisher
zu Rechner A kommuniziert hat. Die selben Einstellungen sind auch
genommen worden for die Kommunikation zwischen neuem Rechner und
Rechner B


Aber 18ms für ein Byte sind dicht über 555 Baud... Das ist arg daneben...

Okay wir können ja auf dem neuen Rechner mal versuchen mit 556 Baud zu
senden...

Wenn er das kann... Ist eine weile her, dass ich einen 16x50

programmiert habe, aber kann man da das Teilerverhältnis der
TX/RX-Clocks so frei programmieren? Bei meinen Controllern geht das, da
die alle per Timer gesteuert werden. Aber bei einem 16x50 war das
Verhältnis doch fest... Ich weiß es nicht auswendig. Das Datenblatt dazu
liegt in der Firma.

Wenn Ihr die Software auf dem neuen PC beeinflussen könnt bzgl. des
SIO-Handlings, dann achtet bitte darauf, dass die modernen seriellen
Bausteine einen Empfangs- und einen Sende-FIFO haben. Wenn Ihr also das
Senden eines zweiten Bytes gegenüber eines vorangegangenen Bytes
verzögern wollt, dann müßt ihr nicht nur das Tx-FIFO empty Bit abfragen,
sondern auch das TX-Buffer Bit prüfen. Der SIO meldet nämlich den
TX-FIFO schon leer, wenn das byte in das Senderegister übertragen wurde.
Damit ist der FIFO tatsächlich leer, aber gesendet wurde noch nix. Das
noch als Nachtrag zu B. Müllers Beitrag.

Gruß,

Ulrich

Grüße
Grit

 

[Grit]

Also da sehe ich dann noch die Möglichkeit, dass Rechner A ebenfalls von
Siemens ist
Ja ist er

und die Schnittstellen auf eine proprietäre Baudrate
angepaßt wurden
Was heißt das denn?

.... Nur mal so als Idee... Ist Rechner A vielleicht eine
305/306 oder ein R- oder M-Rechner?
Gute Frage, hab ich ehrlich gesagt keine Ahnung, da ich das System bisher

immer als Black Box angesehen habe.

Wenn Du sagst, dass das Telegramm des alten Rechners bei 600 Baud etwa
18ms lang ist, dann liegt das sehr hart auf der Grenze der Zulässigkeit,
da es gegenüber der Norm von 16,6ms bereits eine Abweichung von satten
10% aufweist.
Kannst Du feststellen, mit welchen Seriellen Chips der Alte PC arbeitet?

Kann ich mal versuchen herrauszufinden. Ist ein Siemens H4 oder H5 PC
(Uralt also)
Jep, Uralt. Aber scheinbar unverwüstlich
*LACH* Stimmt

Nein leider unterstützt der Rechner A keinerlei Handshake. Es wurden
auch nur die 2 Drähte verlötet (Sendeleitung, Empfangsleitung und
Erdung) Da Rechner A keine kein PC ist können wir auch daran nichts
ändern
OK, dann scheidet das wirklich aus. War aber vorher noch nicht so gesagt
worden, daher hätte es ja sein können
Sorry dachte ich hätte es erwähnt

Aber 18ms für ein Byte sind dicht über 555 Baud... Das ist arg
daneben...
Okay wir können ja auf dem neuen Rechner mal versuchen mit 556 Baud zu
senden...
Wenn er das kann... Ist eine weile her, dass ich einen 16x50
programmiert habe, aber kann man da das Teilerverhältnis der
TX/RX-Clocks so frei programmieren? Bei meinen Controllern geht das, da
die alle per Timer gesteuert werden. Aber bei einem 16x50 war das
Verhältnis doch fest... Ich weiß es nicht auswendig. Das Datenblatt dazu
liegt in der Firma.
Weiß ich auch nicht, die Software von Langner scheint aber bei "krummen"

Zahlen ermal nicht zu meckern und laut Analyser macht es einen unterschied
ob ich 600 oder 570 einstelle

Wenn Ihr die Software auf dem neuen PC beeinflussen könnt bzgl. des
SIO-Handlings, dann achtet bitte darauf, dass die modernen seriellen
Bausteine einen Empfangs- und einen Sende-FIFO haben. Wenn Ihr also das
Senden eines zweiten Bytes gegenüber eines vorangegangenen Bytes
verzögern wollt, dann müßt ihr nicht nur das Tx-FIFO empty Bit abfragen,
sondern auch das TX-Buffer Bit prüfen. Der SIO meldet nämlich den
TX-FIFO schon leer, wenn das byte in das Senderegister übertragen wurde.
Damit ist der FIFO tatsächlich leer, aber gesendet wurde noch nix. Das
noch als Nachtrag zu B. Müllers Beitrag.
Danke für den Tip

Güße
Grit

 

[Rainer Zocholl]

(Heiko Nocon) 15.09.03 in /de/sci/electronics:

Rainer Zocholl wrote:

Achte darauf das ein PC nicht mehr als 2 normale seriellen
Schnittstellen gleichzeitig bearbeiten kann, auch wenn die
Nummerierung bis com4 geht!

Das stimmt nicht.

Unter allen heute gängigen OS kannst du natürlich mit den
Standardtreibern _mindestens_ soviele "normale serielle
Schnittstellen" (also 16550-kompatible UARTs) über den ISA-Bus
betreiben, wie du freie IRQs dafür hast.

Du mußt halt bloß Karten nehmen, die sich auf was anderes als IRQ 3
und 4 konfigurieren lassen

Ebend!
Das meinte ich mit "aufpassen".

und du mußt bei non-PnP-Karten dem OS dann
auch noch sagen, welcher IRQ denn nun für die Schnittstelle zu
benutzen ist.

Und über den PCI-Bus angeschlossen können sowieso nahezu beliebig
viele dieser UARTs betrieben werden. Das dann allerdings nicht mit den
Standardtreibern der OS.

Die müssen dann Interrupt sharing erlauben.
Denn auch mit PCI hat man nicht mehr resourcen.

 

[Heiko Nocon]

Rainer Zocholl wrote:

Und über den PCI-Bus angeschlossen können sowieso nahezu beliebig
viele dieser UARTs betrieben werden. Das dann allerdings nicht mit den
Standardtreibern der OS.

Die müssen dann Interrupt sharing erlauben.

Richtig. Das müssen alle Treiber für PCI-Geräte, denn so legt die Norm
das fest.
Auch wenn sich das nach fast zehn Jahren PCI offensichtlich immer noch
nicht bis zum letzten Treiberprogrammierer herumgesprochen hat. (

 

[Grit]

Hi

hab das Problem heute mit dem Osziloskope gefunden!!! Der Empfänger
erwartete 2 statt 1 Stopbit!!!!!!!!!!!!! Kleine Ursache, große Wirkung ;-))
Bin nur überrascht, daß die Rückrichtung funktionierte...

Nochmal dickes Dank an alle
Grit

 

[Christian Müller]

"Grit" <andy.tess@gmx.de> schrieb im Newsbeitrag
news:bk7jvp$fs6$00$1@news.t-online.com...

Hi

hab das Problem heute mit dem Osziloskope gefunden!!! Der Empfänger
erwartete 2 statt 1 Stopbit!!!!!!!!!!!!! Kleine Ursache, große Wirkung
;-))
Bin nur überrascht, daß die Rückrichtung funktionierte...

Weiss zwar nicht genau, um welches Thema es ging, aber zwei Stopbits senden
ist wie Eines plus Pause. Umgekehrt kommt dann schon das neue Startbit, wenn
der Empfänger noch beim zweiten Stopbit ist.

Ich hatte mal so ein Problem mit 7 Datenbits und Parität die dann doch 8
Datenbits waren, oder 7 Datenbits und Parität even oder Scheisse, ich weiss
nicht mehr genau, jedenfalls hab ich das dann mit nem geliehenen
Speicheroszi rausgefunden und mir geschworen: So ein Oszi oder Diagnosegerät
musst Du immer dabei haben!!!

Gruss Chregu

 

[Grit]

Hi

ja letzteres hab ich mir auch heute geschworen ;-)) Schade, daß der V.24
Analyzer nicht sowas kann und anzeigt

Grüße
Grit

"Christian Müller" <chregu@tiscalinet.ch> schrieb im Newsbeitrag
news:3f676a08$1_1@news.tiscalinet.ch...

"Grit" <andy.tess@gmx.de> schrieb im Newsbeitrag
news:bk7jvp$fs6$00$1@news.t-online.com...
Hi

hab das Problem heute mit dem Osziloskope gefunden!!! Der Empfänger
erwartete 2 statt 1 Stopbit!!!!!!!!!!!!! Kleine Ursache, große Wirkung
;-))
Bin nur überrascht, daß die Rückrichtung funktionierte...

Weiss zwar nicht genau, um welches Thema es ging, aber zwei Stopbits
senden
ist wie Eines plus Pause. Umgekehrt kommt dann schon das neue Startbit,
wenn
der Empfänger noch beim zweiten Stopbit ist.

Ich hatte mal so ein Problem mit 7 Datenbits und Parität die dann doch 8
Datenbits waren, oder 7 Datenbits und Parität even oder Scheisse, ich
weiss
nicht mehr genau, jedenfalls hab ich das dann mit nem geliehenen
Speicheroszi rausgefunden und mir geschworen: So ein Oszi oder
Diagnosegerät
musst Du immer dabei haben!!!

Gruss Chregu

 

[B. MĂźller]

Grit <andy.tess@gmx.de> schrieb:

hab das Problem heute mit dem Osziloskope gefunden!!! Der Empfänger
erwartete 2 statt 1 Stopbit!!!!!!!!!!!!! Kleine Ursache, große Wirkung ;-)

Und plĂśtzlich sind auch die 2 ms Differenz verschwunden. ;-)

Bin nur überrascht, daß die Rückrichtung funktionierte...

Ist ganz logisch: TX = 8N2 / RX = 8N1 muß funktionieren, umgekehrt nicht.
FĂźr solche Messungen ist es immer ganz hilfreich, in einer Schleife 0x0F
oder 0xAA auszugeben.

Nochmal dickes Dank an alle

Nett, daß Du die Lösung gepostet hast, 8N2 ist (nach meinen Erfahrungen)
wirklich recht ungewĂśhnlich.

¡­­¡ ¡­¡¡ ¡ ¡­ ¡¡¡ ¡ ­¡¡ ­­­ ­¡ ­­­ ­ ¡¡­¡ ¡ ¡ ­¡¡ ­ ¡¡¡¡ ¡ ¡­¡ ­¡
¡¡­¡