Für ein Master-Slave System (1 zu n) soll eine simple Methode der Datenübertragung angewandt werden. Die Übertragung erfolgt seriell und byteweise: - erstes Byte: Salve-Adresse - zweites Byte: Kommando an Slave - drittes Byte: XOR aus 1. u. 2. Byte Alle Slaves lesen alle Bytes mit und schieben sie durch einen 3-Byte-Puffer. Nur wenn die Bedingungen erfüllt sind (Adresse stimmt, 3. Byte ergibt XOR aus Adresse und Kommando) reagiert der Slave. Kann man annehmen, dass so ein System sicher ist? Also schlimmstefalls reagiert ein Slave wegen Übertragungsstörungen nicht, aber es kommt niemals vor, dass ein falscher Slave anspricht ... ?
Frank schrieb: > erstes Byte: Salve-Adresse Gaius Julius Casar hat Adresse 0x00. Der Master also ;) Frank schrieb: > (1 zu n) Die Slaves haben also die Adressen von 0x01 bis 0xFF. Frank schrieb: > Alle Slaves lesen alle Bytes mit und schieben sie durch einen > 3-Byte-Puffer. Nur wenn die Bedingungen erfüllt sind (Adresse stimmt, 3. > Byte ergibt XOR aus Adresse und Kommando) reagiert der Slave. Als Byteweiser Puffer mit Byteweisem Schieben. Das heißt aber auch, dass die SPI des steuernden Prozessors immer Synchron bleiben muss. Der Master kann erst bei einer Rückantwort des Slave überhaupt ven dessen Busteilnahme ausgehen. Wenn unerwünschte Glitches auf dem Takt kommen, naja. Der Schutzmechanismus mit XOR ist im Prinzip ein Parity auf Bits gleicher Bitnummer der Adresse und des Kommandos. Das System ist über diese zwei Bits nach Hamming 1-erkennend. Reicht dir das aus? Mit UART-Funktionen am SPI-Modul des Prozessors könnte man sogar einen zweidimensionalen Parity schaffen... mfg mf
Als "sicher" ist das wohl nicht zu bezeichnen, wenn nicht mal klar ist, ob der Slave das für ihn bestimmte Kommando überhaupt mitbekommen hat. Den Hammingabstand sollte man auf 3 erhöhen, so dass zumindest Einzelfehler bei der Übertragung ausgebügelt werden können und man über deren Häufigkeit ein Maß für die Streckenqualität hat, ohne dass die Übertragung gleich zusammenbricht.
Ich würde Prüfsummen empfehlen, die simple Defekte wie eine permanent 0 liefernde Leitung nicht als gültigen Frame erkennen. Gibt es eine eindeutige Methode, den Anfang eines Frames zu erkennen? Oder kann es sein, dass ein Slave aus irgendeinem Grund anfängt, immer das zweite Byte als Adresse, das dritte als Kommando und das nachfolgende erste als Checksum zu interpretieren? Oder ist sogar eine bitweise verschobene Interpretation nicht auszuschliessen?
Wieviele Leitungen? Welches System (syncron/asyncorn)? Geschwindigkeit? Länge der strecke?
_Gast schrieb: > Wieviele Leitungen? - insgesamt 4: Plus, Masse, Daten RX, Daten TX > Welches System (syncron/asyncorn)? - UART, 8N1, 1200 Bit/s, TTL-Pegel > Länge der strecke? - 20 Meter 6pol. Flachbandkabel mit aufgepressten Steckerwannen, bis zu 40 Slaves, am Ende 10k Pulldown (positive TTL-Logik). Die Slaves senden nur, wenn sie "Gefragt" werden, TX-Leitungen per Dioden ver-"odert". @Werner: Durch die vorgegebene Bedingung kann deine Befürchtung eigentlich nicht eintreten. Jedes Byte wird von allen Slaves empfangen und in eine 3-Byte-Queue geschoben, das älteste fällt dabei jeweils heraus bzw. weg. Nach jedem Empfang eines Bytes wird die Prüfung gemacht und nur wenn die genannten Bedingungen zutreffen ((a ist eine gültige und die eigene Adresse) UND (b ist ein gültiges Kommando) UND (c ist der XOR-Wert aus a mit b)), reagiert der Save ... Wenn ich da keinen Denkfehler drin habe (deshalb die Frage hier im Forum), sollten diese Zustände quasi ein-eindeutig sein, oder?
Das, was Du bislang beschrieben hast, ist Deine Wunschvorstellung, wie sich das Protokoll bzw. die Busteilnehmer verhalten sollen. Es fehlt jedoch jegliche Untersuchung der möglichen Fehler und eine darauf basierende statistische Betrachtung. Es ist nicht möglich, ein "perfektes" Protokoll zu entwickeln, sondern nur die Eintrittwahrscheinlichkeit a) korrigierbarer, b) nicht korrigierbarer, aber feststellbarer, c) nicht feststellbarer Fehler auf ein spezifiziertes Niveau zu senken. Auf jeden Fall genügt es nicht, bei einem UART-basierten Protokoll auf Bitfehler in den (acht) Nutzdatenbits zu schauen, sondern es müssen dabei auch die Start- und Stopp-Bits mit herangezogen werden.
Hi >- UART, 8N1, 1200 Bit/s, TTL-Pegel >> Länge der strecke? >- 20 Meter 6pol. Flachbandkabel mit aufgepressten Steckerwannen, bis zu >40 Slaves, am Ende 10k Pulldown (positive TTL-Logik). Nimm RS485. MfG Spess
spess53 schrieb: > Nimm RS485. Nimm CAN-Treiber (MCP2551, PCA82C250). Ist wie RS-485, bloß man muß nicht extra die Richtung umschalten. Peter
Frank schrieb: > - UART, 8N1, 1200 Bit/s, TTL-Pegel Nimm 9E1. Mit dem 9. Bit wird die Adresse signalisiert (Multi-processor Communication Mode) und Parity (even) schadet ja nicht. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.