| Ich nutze: C-Control II Station, OSOPT V3.0 |
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?
// 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)
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.
//------------------------------------------------------------------------------
// 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);
}
}
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:
> >
> > HWCOM bei 19200 fehlt sporadisch das letzte Byte
> >
> > 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
> >
> >
Antwort schreiben
Antworten:
Re: Bug im OS - eigentlich nicht (von Günni - 3.11.2005 20:49)Re: Bug im OS - eigentlich nicht (von Christian Jost - 6.11.2005 9:51)