Re: Probleme mit serieller Daten übertragung

Also zwischen "neu" und B gibt's keine Probleme. Zwischen "neu" und A

inkl. timing eingehalten werden muss sonst verwirft Rechner A die Telegramme (A ist kein PC sondern eine externe Hardware)

ist auch nicht verdrahtet. Fifo haben wir versucht hochzudrehen und

Nein, da Rechner B mit Rechner A mit einem Kabelverbunden ist was jetzt zwischen Rechner A und "neu" verwendet wird brauchten wir ein

Nullmodem kabel

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

abgeschaltet

Grit

Grit schrieb:

die Telegramme von Rechner "neu" verwirft, wird es mit dieser Konfiguration nicht funktionieren.

(sniffen). Ohne Hardware-Handshake ist das eine recht einfache Sache.

Schnittstelle? Wie die Analyse zeigt, kommen die Daten auf der einen Schnittstelle ja schneller an, als sie den Rechner auf der anderen wieder

Konfiguration

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

Funktion

Rechner B und einem 2. Programm empfangen und koordiniert an Rechner A

siehe oben - Aufgabe des Rechner ist es das versenden von 2 unterschiedlichen Datenquellen zum Rechner A zu koordinieren.

helfen die Baudrate beim neuen Rechner solange runter zu drehen bis ein Byte

Grit

Stimmt.

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

Geschieht bereits. Was die Dll macht kann ich leider nicht beeinflussen.

Buffern tun wir es bereits

Ach so.

Grit

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

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.

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);

Ja ist er

Was heißt das denn?

Gute Frage, hab ich ehrlich gesagt keine Ahnung, da ich das System bisher immer als Black Box angesehen habe.

Sorry dachte ich hätte es erwähnt

daneben...

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

Danke für den Tip

Güße Grit

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

Ebend! Das meinte ich mit "aufpassen".

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