Busprotokoll mögliche Fehler?

**theborg** · 14.05.2012, 18:43

Zitat von demmy

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** · 14.05.2012, 20:54

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** · 14.05.2012, 23:40

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** · 15.05.2012, 06:17

Zitat von demmy

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** · 15.05.2012, 19:23

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.