Busprotokoll mögliche Fehler?

[demmy]

Hallo zusammen,

Ich hab mal eine generelle Frage zu Bus-Protokollen speziell im Bezug auf rs485. Wenn ich einen Frame empfange, was muss ich alles überwachen? Zunächst mal das das Frame vollständig eingegangen ist. Und das dann die Checksumme passt. Muss man auch überprüfen ob nachdem die erforderliche Framelänge eingegangen ist noch weitere bytes eintreffen? Also ob das Frame länger ist als erwartet? Kann dieser Fehler überhaupt auftreten? Also dass mehr Bytes empfangen werden als gesendet wurden?
Gibt es weitere Dinge die man überprüfen muss?

Guss

[masasibe]

Hallo demmy,

ich weiß nicht, wie du das genau meinst, aber eigentlich ist
RS485 nur eine Norm für die elektrischen Eigenschaften der Schnittstelle,
nicht aber für das Protokoll.
Du kannst dir also selber eines überlegen oder auf ein bestehendes wie UART
zurückgreifen.

Ich denke, was du alles überprüfen musst, hängt ganz vom verwendeten Protokoll
ab.

mfg masasibe

[demmy]

Hi

ja das Rs485 nur die Hardware beschreibt weiss ich, das meinet ich aber nicht! ;) Mir ging es nur darum, wie kann ich mein Protokoll das ich darüber laufen lasse am sinnvollsten absichern? Es soll aus 1 Byte Adresse , einer festen Datenlänge von 13 Byte und einem Byte Checksumme bestehen. Jetzt ist eben meine Frage, was muss ich alles überprüfen?

1. Das das komplette Protokoll eingetroffen ist.
2. Das die Checksumme passt.
3. Ist es notwendig zu prüfen ob nach den 15 Bytes noch weitere Bytes eintreffen??? (Frame zu lange?) Meine Frage dazu war, ob es bei einem Bus der auf Rs485 Hardware bassiert zu einem Fehler kommen kann, der die Framelänge erhöht, etwa durch Kollision auf dem Bus oder Einstreuung auf der Leitung oder ähnliches?

Welche Bedingungen muss man noch überprüfen um zu sagen das der Frame der empfangen wurde gültig ist?

Gruß

[wkrug]

Wie schon geschrieben wurde hängt das vom Datenframeaufbau ab, den man verwenden will.
Nimmt man da ein USART Protokoll kann man pro Byte noch die Fehlerregister des USART auslesen, ob da ein Frame Error oder sonst was eingetroffen ist.

Auf die richtige Framelänge kann man auch prüfen, ich würde aber lieber ein fest definiertes Startzeichen verwenden, das sonst nirgend anderswo im Rahmen verwendet wird. Dadurch bleibt die Framelänge dann flexibel.

Ich nehm gerne für die Übertragung ASCII Code und benutze als Startzeichen das $ = Dollar oder das @ =ät.
Nutzt man am Ende eines Frames <CR> <LF> kann man so ein Protokoll sehr schön mit einem beliebigen Terminalprogramm debuggen, weil ja die Zeilenumbrüche auch mit drin sind.
Zusätzlich kriegt man schnell wieder einen Anfangs- und einen Endpunkt, falls mal ein Frame versaut wurde.
Die Checksumme mach ich gerne mit EXOR, weils schnell geht. Die ermittelte EXOR Checksumme übertrage ich als hex Zeichen, weil die dann immer gleich viele Stellen hat. Das macht zwar ein wenig mehr Aufwand beim Codieren und Dekodieren hat aber doch wieder Vorteile.

Du könntest Dich zum Beispiel an NMEA 183 orientieren. Ist zwar nicht das neueste, aber auch mit den Fähigkeiten eines Microcontrollers gut zu implementieren.

[theborg]

Hi


1. Das das komplette Protokoll eingetroffen ist.
2. Das die Checksumme passt.
3. Ist es notwendig zu prüfen ob nach den 15 Bytes noch weitere Bytes eintreffen??? (Frame zu lange?) Meine Frage dazu war, ob es bei einem Bus der auf Rs485 Hardware bassiert zu einem Fehler kommen kann, der die Framelänge erhöht, etwa durch Kollision auf dem Bus oder Einstreuung auf der Leitung oder ähnliches?
Gruß

Ich erweiter mal:

4. Overrunerror
5. Frameerror
Punkt 3 erledigt sich durch CRC und Punkt 5
6. Punkt 1 erledigt sich wen du feste Adressen/Gerätekennungen benutzt.
7. Start/Stop Bit (nicht zwingend nötig)
8. feste Daten Länge oder ein Bit was die Datenlänge angibt


Meine momentanen Überlegungen ich nutze eine Feste Datenlänge (56bit) anhand der Antwort des Slave kann der Master sehen ob alles ok ist, Error auswertung ist per Default über das USART Modul, allerdings benutze ich ein 4-Wire RS485 Bus daher sind Kollisionen fast unmöglich, von HW Fehlern mal abgesehen aber die wurden ehr den Bus komplett blocken, die Busfreigabe kommt immer vom Sender des Starttelegrams (RTS/RTR)
http://www.grautier.com/wiki/doku.php?id=protokoll

[demmy]

hi,

ja so in etwa denke ich mir das auch.

Die Teilnehmer haben feste Adressen, die direkt am Teilnehmer per Dip-Schalter eingestellt werden.
Ich habe eine feste Framelänge von 15 Byte.
Es ist ein reiner Master-Slave Bus. Der Master spricht einen Slave an, dieser sendet eine Bestätigung zurück, dann bekommt der Slave seine Daten vom Master und sendet seine Daten zum Master. Dann ist die Kommunikation beendet und der Master geht zum nächsten Slave. Die Daten Sollen per crc8 oder evtl crc16 überprüft werden. Zudem nutze ich den MPCM der µC.

D.h. kommt in einer gewissen Zeitspanne keine Antwort vom Slave zurück, ist irgendwas in der Übertragung schief gelaufen. Der Master versucht erneut den Slave zu erreichen.

Aber was meinst du mit Overrunerror?

[theborg]

Overrunerror ist wenn neue Daten kommen aber die alten noch nicht aus dem REG. geholt wurden b.z.w. das ISR RXbit noch nicht zurückgesetzt wurde b.z.w. wenn durch einen Fehler z.b. >8bit in deinen Frame kommen.

[Klebwax]

Ich habe eine feste Framelänge von 15 Byte.
Es ist ein reiner Master-Slave Bus. Der Master spricht einen Slave an, dieser sendet eine Bestätigung zurück, dann bekommt der Slave seine Daten vom Master und sendet seine Daten zum Master. Dann ist die Kommunikation beendet und der Master geht zum nächsten Slave. Die Daten Sollen per crc8 oder evtl crc16 überprüft werden. Zudem nutze ich den MPCM der µC.

D.h. kommt in einer gewissen Zeitspanne keine Antwort vom Slave zurück, ist irgendwas in der Übertragung schief gelaufen. Der Master versucht erneut den Slave zu erreichen.

Du solltest auch berücksichtigen, daß ein Byte "nicht" ankommt. Das kann passieren, wenn ein Störimpuls das Stopbit trift. Der UART verwirft dann das Byte (er setzt einen Framingerror) und dein Frame erreicht nie die volle Länge.

MfG Klebwax

[demmy]

Ja das habe ich berücksichigt, es wird bei beginn einer jeden Kommunikation ein "Timeout-Timer" gestartet. Wenn nicht das komplette Frame eingegangen ist, bleibt er ja an der Stelle hängen und wartet bis die Daten komplett da sind. Wird dabei die Zeit des Timers überschritten, werden die bereits empfangenen Daten verworfen und es wird auf den Eingang eines neuen Frames gewartet. Ich denke das ist die übliche Vorgehensweise oder?
Selbst wenn ein Frame nicht ganz eintreffen würde und ein Zweiter würde die fehlendnen Bytes auffüllen, müsste ja immer noch die Checksumme stimmen das der Frame gültig ist??

Also Overrun wäre so zu verstehen, dass ein Frame eingegangen ist, dieses aber noch nicht bearbeitet wurde, und das nächste schon eintrifft. Das ist aber doch bei einem Ringbus im Master-Slave betrieb fast unmöglich oder? Da der Master ja nur sendet wenn er vom Slave seine Antwort erhalten hat.

[demmy]

Ahh moment ich glaube ich habe das falsch verstanden. Overrun ist so zu verstehen, das der Eingangsbuffer vollgelaufen ist oder?