Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > Hallo André > > Besten Dank für deine Antwort. > > > Was bei Dir passiert, wird eher ein Pufferüberlauf sein, als ein Empfangsfehler. > Wieso meinst du dass es an einem Pufferüberlauf liegen könnte? > > > Auch wäre ein nicht korrektes Fehlerhandling in Deinem Fall möglich. > Ja könnte sein, hoffe ich aber nicht. > > > Auch sollten in Datenrahmen mit Flexiblen Größen immer die Anzahl der > > der Rahmengröße mitgesendet werden. Einfach ein Start oder Stopzeichen > > zu senden, ist bei einer RSxxx-Kommunikation eher unüblich. > Ja, die Länge wird mitgesendet. Ich hatte beim letzten Eintrag nicht alles beschrieben. > Aber vielleicht ist ja gerade dieses Byte bei der Übertragung verändert worden, deshalb warte > ich zuerst auf das Stoppzeichen und kann dann in aller Ruhe die Daten (inkl. Länge) prüfen. > > > Bedenke, daß der Empfangspuffer Standardmäßig nur 32Byte hat. > > Da Dein Datenrahmen bereits 31 Byte hat, würde ich den Puffer mind. auf das doppelte setzen. > > Im Handbuch steht leider fälschlicherweise, daß der Puffer 64Byte hat. > Ja habe ich beachtet. Habe den Puffer auf 1024 Byte gesetzt (entspricht das dann je 512 Bytes > für den Empfangs-/Sendebuffer?) > > > Was bei Dir auch sein kann, wäre eine Simple Störung, die hin und wieder > > bei RS232 auftreten kann. > Wäre möglich aber ich denke nicht dass es daran liegt, da das System noch nicht im produktiven > Einsatz ist und die Kabellänge ca. 1m beträgt. > > Ich muss vielleicht noch erwähnen, dass ich einen USB zu seriell Wandler verwende, da mein > Laptop keine serielle Schnittstelle mehr hat. Vielleicht gibt es hier irgend ein Problem. > > Ich finde es einfach merkwürdig, dass die Daten ankommen, sobald ein weiteres Byte vom PC > an die C-Control gesendet wird, d.h. sie gehen nicht verloren oder werden verfälscht. Nach einer > gewissen Zeit gibt es sogar eine Verschiebung um 2 Bytes. > > Für mich scheint es so als ob der Buffer-Counter nicht richtig inkrementiert/dekrementiert wird. > Könnte es nicht daran liegen, dass es irgend einen Fehler bei der Synchronisierung gibt? Ich weiss > natürlich nicht wie es im Hintergrund abläuft. Wahrscheinlich ist es ein Ringbuffer mit zwei Zeigern > und einer Zählvariable. Könnte es nicht sein, dass der Zugriff auf diese Zählvariable nicht sauber > synchronisiert ist? Werden die Daten mit Hilfe der Interrupt-Routine der seriellen Schnittstelle > in den Buffer eingetragen? > > <code> > // Protokoll > // Auf ein DLE folgt ein spezielles Zeichen. > // Ist das DLE gewünscht, so wird es verdoppelt. > // |------------| > // | DLE = 16 | 1 Byte > // | STX = 02 | 1 Byte > // |------------| > // | Laufnummer | 1 Byte (DLE ist nicht erlaubt.) > // |------------| > // | Länge | 1 Byte (falls = DLE => 2 Bytes) > // |============| > // | Daten | > // | Daten | 0..10 Bytes (falls = DLE's => max 20 Bytes) > // | Daten | > // |============| > // | CRC 1 | 1 Byte (falls = DLE => 2 Bytes) > // | CRC 2 | 1 Byte (falls = DLE => 2 Bytes) > // |------------| > // | DLE = 16 | 1 Byte > // | ETX = 03 | 1 Byte > // |------------| > // Total: 8 ... 31 Bytes (bei max. 10 Datenbytes) > </code> > > Jedes Paket wird 3x verschickt mit der Hoffnung, dass mindestens eines Fehlerfrei übertragen > wird. In beide Richtungen (PC => C-Control und umgekehrt) wird dasselbe Protokoll verwendet. > > Hier ist meine Empfangsroutine. Diese schaut nur auf die Start und Endbedingung. Prüfsumme, > Länge etc. werden an einer anderen Stelle geprüft. > <code> > //------------------------------------------------------------------------------ > // Empfängt ein Frame von der seriellen Schnittstelle > // > // data < ein Buffer für die zu empfangenen Daten > // length > Grösse des Buffers. > // returns < int : Übertragungsstatus: > // >=0 : Anzahl empf. Bytes. > // -2 : Bufferüberlauf. > //------------------------------------------------------------------------------ > function _receiveFrame(byte data[], int length) returns int > { > int pos; > byte oldValue, newValue; > > pos = 0; > oldValue = 0; > newValue = 0; > > // Warte auf Startbedingung... > do > { > wait hwcom.rxd(); > oldValue = newValue; > newValue = hwcom.get(); > } > while(oldValue != DLE | newValue != STX); > > wait hwcom.rxd(); > newValue = hwcom.get(); > > // Empfange Daten... > loop > { > // Warte auf Datenbyte... > oldValue = newValue; > wait hwcom.rxd(); > newValue = hwcom.get(); > > // 2 DLE's heben sich auf... > if (oldValue == DLE & newValue == DLE) > { > wait hwcom.rxd(); > newValue = hwcom.get(); > } > > if (oldValue == DLE & newValue == STX) > { > // Fehler: Startbedingung während der Datenübertragung erhalten! > // => neu beginnen... > pos = 0; > wait hwcom.rxd(); > newValue = hwcom.get(); > continue; > } > > // Auf Endbedingung prüfen... > if (oldValue == DLE & newValue == ETX) > { > return pos; > } > > // Auf Bufferüberlauf prüfen... > if (pos >= length) return -2; > > data[pos] = oldValue; > pos = (pos + 1); > } > } > </code> > > > Gruss Christian > > > Hallo Christian, > > > > Nicht alles, was nicht auf Anhieb funktioniert, kann man einfach mit > > einem Bug im OS erklären. > > Ich konnte dieses Problem bisher nicht reproduzieren, da es scheinbar > > nur mit der Baudratenabweichung zu tun hat. > > Hier kann man Softwaretechnisch wenig machen. > > Das ist Hardwarebedingt, da die 20MHz Takt kein vielfaches > > einer RS232 Baudratenfrequenz ist > > > > Was bei Dir passiert, wird eher ein Pufferüberlauf sein, als ein Empfangsfehler. > > Auch wäre ein nicht korrektes Fehlerhandling in Deinem Fall möglich. > > Auch sollten in Datenrahmen mit Flexiblen Größen immer die Anzahl der > > der Rahmengröße mitgesendet werden. Einfach ein Start oder Stopzeichen > > zu senden, ist bei einer RSxxx-Kommunikation eher unüblich. > > Üblich ist eher ein Startzeichen, dann die Anzahl der Bytes (meist nur der Datenbytes) > > und dann die Prüfsumme. > > Bedenke, daß der Empfangspuffer Standardmäßig nur 32Byte hat. > > Da Dein Datenrahmen bereits 31 Byte hat, würde ich den Puffer mind. auf das doppelte setzen. > > Im Handbuch steht leider fälschlicherweise, daß der Puffer 64Byte hat. > > Was bei Dir auch sein kann, wäre eine Simple Störung, die hin und wieder > > bei RS232 auftreten kann. > > > > Den einzigen Bug, den ich bei hwcom bisher feststellen konnte, hängt mit > > dem Handshaking zusammen. > > > > MfG André H. > > > > > > > Hallo > > > > > > Bei mir ist auch das Problem mit der seriellen Schnittstelle aufgetreten: > > > > > > <a href="http://www.cc2net.de/Foren/CC2Net_Forum/lesen.php?eintrag=8130" target="_blank">HWCOM bei 19200 fehlt sporadisch das letzte Byte</a> > > > > > > Das Problem tritt bei mir auch bei 9600 Baud auf. > > > > > > Mein Protokoll beinhaltet 8..31 Bytes. Da die Länge dynamisch ist, wird mit speziellen Zeichen gearbeitet: > > > > > > DLE STX (= Start) > > > Daten > > > ... > > > Daten > > > Prüfsumme > > > DLE ETX (= Stop) > > > > > > Also kann ich nicht die vorgeschlagene Lösung von André H. benutzen. Ausserdem kann der der PC zu > > > jedem Zeitpunkt Daten senden.. > > > > > > Gibt es eine andere Lösung? Tritt der Fehler nur einmal auf d.h. gibt es nur eine Verschiebung um ein > > > Byte oder werden es mit der Zeit immer mehr? Ansonsten könnte ich ein Byte mehr schicken > > > (mein Protokoll verzeiht das) aber wenn nach einer halben Stunde bereits zwei Bytes fehlen > > > etc. so ist das kaum brauchbar. > > > > > > Es wäre schön wenn dieser Bug möglichst schnell gefixt werden könnte, da es sich um einen > > > schwerwiegenden Fehler handelt. > > > > > > Besten Dank, > > > > > > Christian > > > > > >
