-         

Ergebnis 1 bis 10 von 10

Thema: Busprotokoll mögliche Fehler?

  1. #1
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    29.07.2011
    Beiträge
    340

    Busprotokoll mögliche Fehler?

    Anzeige

    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

  2. #2
    Erfahrener Benutzer Fleißiges Mitglied Avatar von masasibe
    Registriert seit
    21.01.2011
    Beiträge
    181
    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

  3. #3
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    29.07.2011
    Beiträge
    340
    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ß

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    1.892
    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.

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    30.09.2006
    Ort
    Hamburg
    Alter
    35
    Beiträge
    988
    Zitat Zitat von demmy Beitrag anzeigen
    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
    Legastheniker on Bord !

    http://www.Grautier.com - Projektseite
    http://www.grautier.com/wiki/doku.php?id=bt-index - BT-BUS

  6. #6
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    29.07.2011
    Beiträge
    340
    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?
    Geändert von demmy (14.05.2012 um 22:21 Uhr)

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    30.09.2006
    Ort
    Hamburg
    Alter
    35
    Beiträge
    988
    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.
    Legastheniker on Bord !

    http://www.Grautier.com - Projektseite
    http://www.grautier.com/wiki/doku.php?id=bt-index - BT-BUS

  8. #8
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.03.2011
    Beiträge
    1.400
    Zitat Zitat von demmy Beitrag anzeigen
    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
    Strom fließt auch durch krumme Drähte !

  9. #9
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    29.07.2011
    Beiträge
    340
    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.

  10. #10
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    29.07.2011
    Beiträge
    340
    Ahh moment ich glaube ich habe das falsch verstanden. Overrun ist so zu verstehen, das der Eingangsbuffer vollgelaufen ist oder?

Ähnliche Themen

  1. ADC Ungenauigkeit, mögliche Fehlerquellen?
    Von hunni im Forum AVR Hardwarethemen
    Antworten: 10
    Letzter Beitrag: 20.02.2012, 15:56
  2. Mögliche Projekte
    Von piatch im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 2
    Letzter Beitrag: 22.11.2010, 09:55
  3. niedrigste mögliche motorspannung beim L293B?
    Von pointhi im Forum Elektronik
    Antworten: 3
    Letzter Beitrag: 12.10.2010, 17:48
  4. Wo ist der Fehler?
    Von Ezalo im Forum Robby RP6
    Antworten: 8
    Letzter Beitrag: 12.08.2010, 17:48
  5. ISP Fehler
    Von Thetis im Forum AVR Hardwarethemen
    Antworten: 4
    Letzter Beitrag: 04.10.2006, 17:26

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •