Ich beabsichtige, einige Atmega-basierte Home-Monitoring-Chips zu bauen. Ich möchte Temperatur, Luftfeuchtigkeit und aktuelle Werte überwachen. Die Überwachung des Strompegels würde mit einem induktiven Aufnehmer an Wechselstromleitungen erfolgen. Zusätzlich möchte ich einige Pins auf jedem Monitor haben, die als ferngesteuertes GPIO verwendet werden können.
Mein Plan ist es, Attiny84-Chips zu verwenden, um dies zu implementieren. Jede Karte würde mit +15 VDC und +7 VDC gespeist. Ich kann dies mit Reglern der Serie 780x auf +5 VDC und +12 VDC regeln, um die Chips und andere Sensoren oder Relais mit Strom zu versorgen, die ich mir wünsche.
Für die Stromversorgung werden zwei Paare im Cat5e-Kabel verwendet. Geräte sind miteinander zu verketten. Dadurch bleiben zwei Paare im Kabel übrig. Nach dem, was ich gelesen habe, scheint RS-485 eine attraktive Lösung für Daten und Kontrolle zu sein. Das letzte Gerät benötigt einen angeschlossenen Abschlusswiderstand, aber das sollte einfach sein.
Wenn ich das richtig verstehe, fügt das Hinzufügen eines Chips zu meiner Schaltung wie einem MAX485 nur die physische Fähigkeit zur RS-485-Signalisierung hinzu. Ich brauche noch eine Software-Implementierung für die Kommunikation und darüber hinaus ein aktuelles Protokoll für mehrere Geräte, um Daten auszutauschen. Ich hätte bis zu 12 Geräte, die mit einem einzigen Master verkettet sind. In einem Halbduplex-RS-485-System verhält sich der Bus im Grunde genommen wie eine Party-Leitung.
Das Master-Gerät würde die folgenden Funktionen in der Reihenfolge während jeder Kommunikationsrunde ausführen.
Senden eines Synchronisationssignals. Dies wäre ein bekanntes Bytemuster, gefolgt von einem Bezeichner und einer Prüfsumme. Die Kennung wäre eine eindeutige Kennung für diese Kommunikationsrunde. Zusätzlich würde diese Datensequenz die Kennung eines Slave-Geräts enthalten, das in dieser Runde Daten senden darf.
Warten auf eine Nachfrist. Diese Kulanzfrist wird verwendet, damit ein unbekanntes Gerät eine Anforderung zum Beitritt zum Netzwerk an den Master senden kann.
Empfangen von Daten von dem Slave-Gerät, das in den in Schritt 1 gesendeten Synchronisierungsdaten angegeben ist.
Senden von Steuerbefehlen an eine beliebige Anzahl von Slave-Geräten. Dies umfasst GPIO-Befehle und Join-Netzwerkbestätigungen. Alle Steuerbefehle müssen später vom Slave bei einer Übertragung zurück zum Master bestätigt werden.
Die Slave-Geräte befinden sich in einem von zwei Zuständen
Vom Meister nicht anerkannt. Es synchronisiert das Synchronisationssignal und sendet in der Kulanzperiode. Im Idealfall sendet der Master in Schritt 4 der nächsten Kommunikationsrunde eine Bestätigung zurück. Wenn das Gerät dies nicht empfängt, wartet es eine zufällige Anzahl von Runden, bevor es es erneut versucht. Auf diese Weise können Kollisionen in der Kulanzfrist, die durch mehrere Geräte verursacht werden, die versuchen zu senden, schließlich behoben werden.
Vom Meister bestätigt. Das Gerät überträgt Sensordaten, wenn dies durch das vom Master gesendete Synchronisationssignal angezeigt wird. Während dieser Zeit sendet das Gerät auch Bestätigungen von Steuerbefehlen zurück. Es ignoriert die Kommunikation zu und von anderen Slaves mit dem Master.
Die Idee dahinter ist, dass die RS-485-Implementierung im Atmega-Controller nur Software sein wird. Das Gerät kann offensichtlich nicht ständig Daten senden und empfangen, oder es wäre als Sensorgerät nicht nützlich. Die Länge einer Runde in der realen Welt muss groß genug sein, damit der Fehler in den im Oszillator eingebauten Chips unbedeutend ist. Auf diese Weise kann die Synchronisation basierend auf dem Signal vom Master für mehrere Runden beibehalten werden, ohne dass tatsächlich Daten empfangen oder gesendet werden müssen.
Während der Verbindungsphase ermöglicht dies die Synchronisation, sodass der Slave den Zeitraum für die Übertragung einer Verbindungsanforderung korrekt identifizieren kann.
Sobald sich der Slave im Netzwerk befindet, kann das Gerät erkennen, wann es auf die Berechtigung zum Senden und Empfangen von Daten warten muss. Dies bedeutet auch, dass das Gerät die Option hat, eine oder mehrere Kommunikationsrunden zu "überspringen", um Sensormessungen durchzuführen, GPIO zu befehlen oder was auch immer ich brauche. Die Theorie besagt, dass, wenn das Gerät nur Sensordaten senden durfte, es nicht sofort wieder angefordert werden darf und auch keine neuen Daten vorliegen.
Das Problem dabei ist, dass, da ein Slave für mindestens eine Runde effektiv aus der Kommunikationsschicht ausscheidet, alle Befehle an Slaves mit einer Nachricht zurück an den Master bestätigt werden müssen. Dadurch kann der Master Befehle einfach bis zur Bestätigung erneut übertragen. Dies bedeutet auch, dass Befehle Zustandsbeschreibungen und keine Zustandsänderungen sein sollten. Es besteht eine sehr reale Chance, dass ein Slave einen Befehl mehr als einmal ausführt. Ich weiß nicht genau, wie Bestätigungen funktionieren, aber es wird wahrscheinlich nur eine Nachricht sein, die aus einer Identifikationsnummer und einer Prüfsumme besteht.
Welche Prüfsumme ich auch immer in diesem System verwende, sie muss billig zu berechnen sein, da ich sie auf Chips ausführen werde, die nur eine Taktrate von etwa 8 MHz haben und 8-Bit-Computer sind.
Der größte Nachteil dieses Systems ist, dass die Slaves, wenn sie aus irgendeinem Grund alle aus- und wieder eingeschaltet werden, kollidieren, wenn sie versuchen, sich in der Nachfrist dem Netzwerk anzuschließen. Dies bedeutet, dass es sehr lange dauern kann, bis alle wieder dem Netzwerk beitreten.
Vermisse ich damit etwas Bedeutendes? Gibt es große Entscheidungen, die ich völlig ignorieren muss? Ist mein Verständnis von RS-485 als große Parteilinie korrekt?