Im Prinzip wäre das ähnlich meinem Vorschlag. Bei mir wäre es dann auf 'ne DMX-Lampe und'n DMX-2-Achs-Motor rausgelaufen, und auf'n DMX-Sender (ob der nun Standalone oder als Brücke zwischen PC und dem Rest läuft...).
Ich habe das DMX-Protokoll so verstanden:
- Ein Telegramm beginnt mit "Break" (88µs Low) und "Mark after Break" (mindestens 8µs High).
- Es folgt ein Startbyte mit dem Wert "0", übertragen mit "8N2"@250kBaud
- Danach kommen (bis zu) 512 Bytes ("8N2"@250kBaud), die jetzt einfach den 512 Kanälen entsprechen.
Die Empfänger leiten alle empfangenen Signale weiter, zählen dabei nach dem Startbyte bis ihr (ggf auch mehrere) Kanalbyte empfangen wurde, und setzen dieses um.
Die 88µs entsprechen 2Bytes mit "8N2"@250kBaud, da alle Bits 0 sind ist das ein "falsch übertragenes/empfangenes" Byte. Ich hab mich da jetzt noch nicht reingekniet - aber eventuell kkönnte man die beiden Bytes trotzdem Empfangen, wobei der UART dann einen "Frame Error" signalisiert (wäre für die Slaves das Signal, das ein neues Telegramm folgt).
Diese "falschen Bytes" kann man mit der UART-Hardware selbst nicht senden, also in Software 88µs Low halten, dann High setzen. Dann den UART aufschalten (ist im Idle high), und dann (wenn insgesamt die 8µs rum sind) das Start- und die Kanalbytes als "normale" UART-Bytes senden.
Letztendlich hat man also 512 Kanäle ("Adressen"), mit jeweils einem Byte (also Auflösung 256).
Das Durchschleifen der Bytes (inklusive Break und Mark) entsricht einer Parallelschaltung bzw einem Bus, an dem alle Empfänger abzweigen.
(Elektrisch muß das Signal ab einer gewissen Länge/Empfängerzahl sicher "aufgefrischt" werden, ggf auch wegen Reflektionen terminiert.).
Wenn ein Empfänger mehrere Bytes (mehr als 256 Zustände) braucht, muß er halt auf mehrere Adressen reagieren. Wenn man die Lampe also als 3x8Bit RGB auslegt, wären das 3 Kanäle (Adressen), wenn man die Motoren als 2x8Bit X/Y auslegt, wären das 2 Adressen.
Klar kann man das in einen hinreichend potenten Controller implementieren (der dann eben auf die 5 Adressen reagiert), aber wenn man Lampe und Motor(en) auf getrennten (ggf kleineren) Controllern realisiert, ist der Code überschaubarer, und ausserdem kann man zB. den Code der Lampe direkt in weitere Controller flashen, die dann quasi als "fester Kopf" leuchten könnten. Oder den Motor-Code auf irgendwelche anderen beweglichen Objekte. Dem Controller müssen dann nur die jeweiligen Adressen zugeordnet werden. Ließe sich also schön erweitern
Hmm... 250kBaud sind natürlich schon 'ne Hausnummer... ein Byte (8+3Bits) entspräche ca 350 Takten@8MHz Controllertakt - sollte man also straff programmieren.
Ob's in Bascom da was fertiges gibt, weiß ich nicht - unter Assembler sollte das sicher machbar sein...
Sind natürlich alles nur Ideen - generell gilt: je gründlicher man am Anfang ein Konzept konstruiert, umso einfacher hat man es später bei der Implementierung und Wartung/Erweiterung/Wiederverwertung des Codes. Insbesondere, wenn man das Ganze in sinnige einzelne Module zerlegt hat, die Eigenständig lauffähig sind.
Daumenhoch.
LotadaC