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?
_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
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
