Datenübertragungsballade
In den ersten Zeilen meiner Textblutung möchte ich Folgendes sagen: Es wurde viel darüber geschrieben, ich werde auch meine Vision schreiben. Standardschnittstellen für die Übertragung von Informationen sind großartig, aber für meine Bedürfnisse bieten sie nicht genügend zufriedenstellende (gut oder fast) Datenübertragung. Ich werde versuchen, einige Ergänzungen vorzunehmen, um dies in den Zustand zu bringen, der zu mir passt.Es gibt 2 oder mehr Geräte in einem ausreichend großen Abstand (1 bis 100 Meter), zwischen denen Daten übertragen werden müssen. Nachdem ich einige Schnittstellen (rs232 / 422/485, I2C, Ethernet) untersucht hatte, kam ich zu dem Schluss, dass sie entweder keine eindeutige Datenübertragung garantieren, auch nicht viele Kabel mochten und keine Antwort darauf geben, dass die Informationen akzeptiert werden. Ich habe mich für die RS485-Schnittstelle entschieden - sie kann weit von ihren Vorteilen entfernt sein, 2 Drähte, Sie können eine Reihe von Geräten gleichzeitig anschließen, es ist einfach, (UART) ist auf fast jedem Controller.In meinem Fall ist das klassische Schema 1, das den Rest der Sklaven führt, für mich geeignet. Der Nachrichtenalgorithmus lautet wie folgt: Daten werden in Austauschzyklen übertragen, ein Austauschzyklus besteht aus einer Nachricht, die vom Master an den Slave übertragen wird. Als Antwort empfängt der Master die Nachricht vom Slave, alle anderen schweigen. Implementieren Sie auf derselben Basis eine Datenanforderung von einem Slave-Gerät.
Ein Austauschzyklus.Um meine Datenübertragungsanforderungen zu erfüllen, muss ich nur zwei Fragen lösen. Frage 1: Die Überprüfung des übertragenen Bytes basiert auf der RS-485-Schnittstelle selbst, garantiert jedoch kein zuverlässig übertragenes Byte. Wenn ein Byte in der Schnittstelle selbst gefunden wird, wird es aus den empfangenen Daten verworfen, es kann jedoch weiterhin das falsche Byte übertragen werden - wenn es sich geändert hat (es ist fehlerhaft geworden) ) eine gerade Anzahl von Bits in einem Byte. d.h. Es ist eine Überprüfung der Anzahl der übertragenen Bytes und der Gültigkeit der Bytes in den übertragenen Daten erforderlich.Frage zwei: Empfangen einer Antwortnachricht an die gesendete.Zur ersten Frage: Dieses Schema wird vorgeschlagen: das Anfangsbyte, das Byte der Anzahl derübertragenen Zeichen in der gesamten Nachricht, etwas anderes, das Prüfsummenbyte (BCS), das Endbyte.
Hinweis: Das Prüfsummenbyte sollte als Modulo 2 betrachtet werden.Auf der Grundlage des vorgeschlagenen Schemas kann beurteilt werden, dass der Follower nicht verfügbar ist, wenn die Antwort nicht zurückgegeben wurde. In diesem Fall sind Optionen möglich, wenn eine beschädigte Nachricht den Follower erreicht und er nicht darauf antwortet oder die Nachricht ihn erreicht und er die Antwort sendet, die Antwort jedoch schlecht wird und der Anführer sie ignoriert.Um dies zu korrigieren, wurde akzeptiert: Wenn die Antwort nicht kommt (oder kommt, aber unzuverlässig), wiederholen Sie (die Häufigkeit ohne Wahnsinn) den aktuellen Austauschzyklus. Der folgende Fehler kann hier auftreten. Angenommen, wir senden einen Befehl, der dem Gerät mitteilt, dass Sie die Lautstärke um +1 Einheit erhöhen müssen. Wenn die Nachricht den Slave erreicht, führt er den Befehl zum Erhöhen der Lautstärke aus und sendet die Antwort "OK, ich habe getan, was Sie wollten". Es kann sich jedoch herausstellen, dass die Antwort schlecht ist und der Präsentator nicht versteht, dass der Befehl bereits ausgeführt wurde, und die Nachricht erneut sendet. Infolgedessen wird beim Empfang eines Befehls auf der Slave-Seite die Lautstärke bereits um +2 Einheiten erhöht. Um dieses Phänomen zu vermeiden, ist es üblich, eine Kennung (NS - Nachrichtennummer) der Nachrichtendifferenz einzuführen. Wenn die Nachrichtennummer wiederholt wird, handelt es sich um eine wiederholte Nachricht, und der angegebene Befehl muss nicht ausgeführt werden.aber senden Sie einfach die vorherige Antwortnachricht.Ich gebe hier auch 2 weitere Parameter ein - dies ist die Nummer (Code) des Geräts, an das Daten übertragen werden, und die Nummer (Subcode), die angibt, welcher Befehl ausgeführt werden soll (oder welche Daten in der Nachricht enthalten sind).
Als Ergebnis werde ich alles zusammenfügen und den Algorithmus durchgehen. Am Beispiel der Erhöhung des Schwellenwerts des Relais um die Temperatur um 5 Grad Celsius und der Erfassung des aktuellen Temperaturmesswerts vom Slave für einen Austauschzyklus: Ichgeneriere die übertragenen Daten vom Master:
Wenn die Nachricht empfangen wird, betrachtet der Slave 2 Bytes. Wo ist die Anzahl der gesendeten Bytes? Wenn die Anzahl der gesendeten Bytes gleich der Anzahl der empfangenen Bytes ist, hat die Nachricht keine Bytes verloren. Dann betrachten wir das Startbyte (Zeichen), wenn es = '$' ist, und auch das Endbyte (Zeichen), wenn es = ' # '- Dies ist eine Nachricht von an die Slave - Reisen.Ich werde sofort die möglichen Nachrichtenoptionen vom Master zum Slave mit Fehlern in den Anfangs- und Endbytes sowie die Option mit einem Fehler in der Anzahl der Bytes in der Nachricht prüfen. Ich werde sofort eine Reservierung von 3 Parameterwerten vornehmen, die ich als korrekt 2 und 3 betrachten werde, d. H. Wenn 2 von 3 möglichen Parametern übereinstimmen, halte ich die Nachricht für gültig.1. Startbyte = '$', Anzahl der empfangenen Bytes = 7 (Anzahl der gesendeten Bytes = 7), das Endbyte ist nicht gleich '#';
2. das Anfangsbyte ist nicht gleich '$', die Anzahl der empfangenen Bytes = 7 (die Anzahl der gesendeten Bytes = 7), das Endbyte = '#';
3. Startbyte = '$', Anzahl der empfangenen Bytes = 7 (Anzahl der gesendeten Bytes = 7, Anzahl der Bytes ist nicht 7), Endbyte = '#'.
Als nächstes berechnen wir die Prüfsumme der verbleibenden 3 Bytes (Bytes 3, 4, 5). Wenn sie mit dem BCS übereinstimmt, analysieren wir die Daten weiter. Wir suchen nach diesem Gerät für diese Daten und was darauf zu tun ist. In unserem Fall lautet der Slave-Code 55 und Subcode 2 sagt über die Notwendigkeit, weitere 5 Grad zum Schwellenwert des Relais und in der Antwortnachricht hinzuzufügen, um die aktuellen Temperaturdaten zu senden. Ich überprüfe den NS, wenn er nicht der vorherigen Nachrichtennummer entspricht, führe den Befehl aus und addiere 5 Grad zum aktuellen Wert des Relaisschwellenwerts. Wenn sie gleich sind (NS), führe ich die angegebenen Aktionen nicht aus und fahre dann mit der Bildung einer Antwortnachricht fort.Anwendung des Schemas ['$'] [Anzahl der gesendeten / empfangenen Bytes] [...] ['#'] - mit hoher Wahrscheinlichkeit garantiert, dass eine solche Kombination in den übertragenen Daten nicht gefunden werden kann, und provoziert eine falsche Nachricht.Ich bilde die vom Slave übertragenen Daten basierend auf der empfangenen Nachricht:
Das Verarbeitungsprinzip lautet wie folgt: Sehen Sie sich 2 Bytes an, in denen die Anzahl der gesendeten Bytes liegt, wenn die Anzahl der gesendeten Bytes gleich der Anzahl der empfangenen Bytes ist und auch das Startbyte = '@' und das Endbyte = '&' - dies ist eine Nachricht vom Slave an den Master. Bei Bedarf verwende ich den 2-aus-3-Mechanismus, ähnlich dem oben beschriebenen, nur für die Antwortnachricht (für die Zeichen '@' und '&'). Beim Empfang dieser Nachricht analysiert der Host die Prüfsumme 9 (vom 3. bis zum 11.) Byte. Wenn die Prüfsumme übereinstimmt, werden die Daten in der Nachricht als zuverlässig angesehen und die weitere Datenanalyse wird fortgesetzt. Wenn der Code, der Subcode und der NS der gesendeten und empfangenen Nachrichten übereinstimmen, analysieren wir weiterhin die Antwort auf die vom Host gesendete Nachricht. Als nächstes folgt die Analyse der empfangenen Daten.in meinem Fall bedeutet im 6. Byte ein Wert von 1, dass der Befehl zum Erhöhen von 5 Grad auf den Relaisschwellenwert erfolgreich war, die verbleibenden 5 Bytes zeigen die aktuellen Temperaturablesungen an, das 7. Byte ist ein Flag, das die Zuverlässigkeit der übertragenen Temperatur anzeigt (d. h. Ich denke über die Option nach, dass der Slave eingeschaltet ist und reagiert, aber der Sensor funktioniert möglicherweise nicht.) Und 4 Byte Float-Temperaturwerte vom Typ.Die Verwendung von 2 Testzeichen am Anfang und Ende einer Nachricht mit hoher Wahrscheinlichkeit garantiert, dass im Fehlerfall die Nachrichten vom Slave und vom Master nicht verwechselt werden. Auch zufällige (nicht zufällige) Daten im Kanal beeinträchtigen den Austausch nicht.Ein wenig über die Datenübertragung des Slaves zum Slave und eine zentralisierte Nachricht an alle Slaves vom Master.Zuerst wird die letzte - die Übertragung vom Master durch den Slave durch Zuweisen des Gerätecodes 255 ausgeführt, der dem Slave mitteilt, dass dies eine zentralisierte Nachricht ist, dann bleibt nur das Problem der gemeinsamen Subcodes zu lösen, es ist auch möglich, nach Gerätecodes zu gruppieren, d.h. Zuweisen des Gerätecodes 254 und 3 oder 4 Geräte erhalten eine Nachricht mit diesem Code, der Rest ignoriert sie natürlich. Der Teil des Sendens von Antworten von Slaves sollte hier nicht funktionieren, d. h. Es ist nicht garantiert, dass die Follower diese Nachrichten eindeutig akzeptiert haben!Bei der vom Master implementierten Datenübertragung des Slaves zum Slave sendet der Master eine Nachricht an den Slave (Slave1), von der Informationen an den anderen Slave (Slave2) gesendet werden sollen. Slave1 sendet eine Antwort an den Master, während der Slave2 auf diese Antwort wartet und die Daten zu sich nimmt. Auch hier gibt es keine Garantie für eine eindeutige Nachrichtenübermittlung von Slave1 an Slave2, dies muss berücksichtigt werden!Schnittstellenfähigkeiten Anzahl der theoretisch verbundenen Geräte ca. 250, Befehle / Datentypen bis zu 248 für jedes Gerät, die Länge der nützlichen Informationen in der Nachricht beträgt bis zu 250 Bytes.Sprechen Sie über Fallstricke:Die gesamte Datenübertragung ist so ausgelegt, dass sie pünktlich arbeitet, d. H. Bestimmte Verzögerungen zwischen Nachrichten sollten beachtet werden. Ich empfehle außerdem, dass Sie eine feste Verzögerung zwischen der vom Master gesendeten Nachricht und der Antwort des Slaves vornehmen, damit der Slave Daten generieren und diese vollständig an den Kanal übertragen kann.Der Moment des Organisierens der Antworten des Slaves ist ebenfalls wichtig. Es kann vorkommen, dass der Slave beschäftigt war und mehrere Datennachrichten gleichzeitig in seinem Kanal hatte. Sie sollten vermeiden, dass Antworten auf veraltete Nachrichten (da der Leiter nicht mehr auf sie wartet) ignoriert werden und nur die neuesten Befehle ausführen Nachrichten und geben Sie eine Antwort darauf.Separat möchte ich das Problem der Synchronisation von Geräten nach Zeit hervorheben - es sollte berücksichtigt werden, dass die Zeitsynchronisation des Slaves beim Empfang einer Nachricht die Berücksichtigung der Zeitverzögerung für das Senden von Daten an den Kanal erfordert (bei einer Geschwindigkeit von 9600 wird eine Nachricht von 10 Bytes für ungefähr 11 ms übertragen) und der Moment, in dem der Interrupt am Ende ausgelöst wird Empfangen von Daten auf der Slave-Seite Wenn keine Unterbrechung vorliegt, sollten Sie die Zeit berücksichtigen, zu der das Eintreffen von Daten im Gerätepuffer usw. überprüft wird.Es ist auch erwähnenswert, dass das erneute Senden einer Nachrichtenschleife auch Nuancen hinzufügt. Ich empfehle, das Senden von Nachrichten ohne Wiederholungen für die Zeitsynchronisation zu verwenden und Nachrichten mit einem neuen NS zu verfassen.PSIch habe Zweifel, dass ich hier etwas Neues entdeckt habe, all dies wird bis zu einem gewissen Grad irgendwo in verschiedenen Schnittstellen verwendet! Mit der leichten Hand des Autors dieses Scribbles und der Anwendung dieses Protokolls in meinen Entwicklungen möchte ich diesem Datenübertragungsprotokoll den Namen „SRDB2“ geben. Source: https://habr.com/ru/post/de398791/
All Articles