Arduino Truck Licht und Funktions Modul mit Bus Erweiterung

[gismow]

Moin Marina,

herzlichen Glückwunsch, das sieht doch prima aus.

Allerding möchte ich noch eine kleine Anregung geben. Wenn mal bei der Übertragung etwas verloren geht, dann kann es dir passieren dass die Übertragung aus der Synchronisation läuft. Es können z. B. Bytes fehlen. Daher möchte ich dir empfehlen jeden Datensatz mit einem STX zu beginnen und mit einem ETX enden zu lassen. Dies gibt dem Empfänger die Möglichkeit unvollständige Datensätze zu erkennen und auch den Anfang des nächsten Datensatzes sauber zu finden.

Hast du ein eigenes IR Protokoll entwickelt? Wenn nein und die eine Standard Library nutzt, dann brauchst du eigentlich die Prüfsumme nicht.

IR ist schön wenn du z. B. durch den Königsbolzen gehst, da ist es "schön dunkel", aber wenn du z. B. eine Deichsel überbrücken musst, dann hast du Fremdlicht und äußere Einflüsse die zu beschädigten Datenpaketen führen können.

 

[Magraina]

Hey Peter,

Vielen Dank und Danke für den Vorschlag!
Ja sowas hatte ich mir auch überlegt, aber dieses Problem kann es bei mir so nicht geben.

Es gibt im Prinzip 2-3 gängige Arten denn Anfang eines Telegramms vernünftig auszuwerten. Entweder mit Start und (gegebenenfalls) Stopp Bits/Bytes, ggfs. Anhand der parität oder anhand von Zeit.
Darüber habe ich tatsächlich lange überlegt, welche Methode mir lieber ist.
Ich kenne ja viele industrielle Protokolle, von Berufswegen.

Der Punkt ist, dass diese Start und Stopp Bytes einzigartig sein müssen, um Fehlinterpretationen zu vermeiden.
Im restlichen Telegramm sollten diese am besten gar nicht vorkommen können.
Und das gefällt mir nicht, wenngleich es durchaus gängige Praxis ist und eine gute Methode ist.
Aber so viel Komplexität möchte ich nicht haben.
Zudem braucht es zusätzliche Bytes, wobei das relativ ist verglichen mit der Unterbrechung meines Protokolls.

Jedenfalls, in meinem Fall ist ein sync Problem unproblematisch.

Ist ein Telegramm unvollständig oder korrumpiert dann wird es entweder direkt aufgrund der Länge verworfen oder aufgrund der CRC Prüfung verworfen und der Puffer wird komplett geleert, für das nächste Telegramm.
Beim nächsten Kommunikationszyklus der einen dezenten Zeitabstand hat ist man dann automatisch am Anfang des Telegramms und ist synchron.

Wenn ich zum Beispiel den Auflieger einstecke, dann ist er praktisch sofort synchron. Es geht beim ersten Mal höchstens ein einziges Telegram schief.

Ich hab da wirklich keine Bauchschmerzen.
Wenn die Pausenzeit vernünftig definiert ist, dann ist das absolut kein Problem.


Ich hab das Protokoll speziell für ne Serielle Schnittstelle geschrieben. Theoretisch kann man es aber auch genauso für IR verwenden. Physikalisch funktioniert das im Prinzip genau gleich.
Für die Serial Lib brauche ich den CRC. Wobei ein CRC sicherer ist als eine reine Prüfsumme.

Ich hab mich ja bewusst für eine Kabelverbindung entschieden, weil ich es haben will, wie im Original!
Daher kein IR, BT oder ähnliches.