Cooperating radiator monitoring 114: Unterschied zwischen den Versionen
Xoquox (Diskussion | Beiträge) (Nutzerverweis geändert) |
Xoquox (Diskussion | Beiträge) |
||
| Zeile 82: | Zeile 82: | ||
[[Datei:OW_Debug_3.JPG|thumb|200px|left|Interrupts werden Ignoriert]] | [[Datei:OW_Debug_3.JPG|thumb|200px|left|Interrupts werden Ignoriert]] | ||
| − | + | Im aktuellen Zustand kommt zwar eine Kommunikation mit dem Master zustande, aber wir gerade nach wie vor aus dem Takt, wodurch nach wenigen Übertragenen Bits der Master abbricht. Wie im Bild links zu sehen werden unsere Bits (x) und Komplement-Bits (Cx) korrekt gesendet und vom Master bestätigt (Ax). Dies geht hier für genau 4 Bits (12 Flanken am Bus) richtig. Dann verpassen wir eine Flanke (X) und kommen mit unseren Interrupt erst zum darauf folgenden. Dies verschiebt die Kommunikation, der Master stellt einen Fehler (E) fest und löst einen Reset aus. | |
| − | |||
| − | Dies kommt vermutlich von einer unsauberen erkennung am PCint. Dieser Löst wohl im Logikübergang ab und zu falsch aus, wenn der Pin noch keinen festen zustand hat. Bei Tests war hier innerhalb weniger Takte ein Zustandswechsel zu beobachten. | + | Dies kommt vermutlich von einer unsauberen erkennung am PCint. Dieser Löst wohl im Logikübergang ab und zu falsch aus, wenn der Pin noch keinen festen zustand hat. Bei Tests war hier innerhalb weniger Takte ein Zustandswechsel zu beobachten. Eine genaue Ursache konnte bisher noch nicht ermittelt werden. Unschön ist auch dass das Datenblatt des ATmega169P keine genauen Angaben macht, ab welchem Zustand genau ein Logikwechsel am Pin als solcher auch Interpretiert wird. |
| + | |||
| + | Eine "Entprellung" der Datenleitung ist wohl unumgänglich, wenn auch etwas Zeitkritisch, da wir nur maximal 15µS Zeit haben die Fallende Flanke zu erkennen und darauf zu reagieren um selbst die Leitung für eine 0 auf Low zu ziehen. | ||
{{clear}} | {{clear}} | ||
Version vom 16. November 2012, 08:06 Uhr
 Status: unstable | |
|---|---|
| |
| Beschreibung | Steuerung und Überwachung von HR20 Thermostaten per 1-Wire |
| Autor: | xoQUox, schinken |
| Version | 1 |
| PayPal | 
|
Beschreibung
Idee
Um die Heizkosten im Backspace zu minimieren, möchten wir unsere Heizungen zentral über einen einfachen Bus steuern. Zusätzlich sollen über diesen Bus noch weitere Temperaturfühler und Erweiterungen ausgelesen und gesteuert werden können.
Planung
Für die Realisierung versuchen wir die Heizungsthermostate per 1-Wire Bus steuerbar zu machen. Zusätzlich sollen an diesen Bus auch DS18S20 Temperaturfühler angebracht werden. (vgl. DS1820TOUSB)
Die Daten soll von einem 1-Wire Master gesteuert werden, der auch die Regelung der Thermostate, die Raumtemperaturüberwachung und ein Webinterface bereit stellt.
Arbeitsverteilung
Die integration der Busfunktionalität auf Softwareebene übernimmt xoQUox. Für die Entwicklung der Bedienebene und Steuerung ist schinken verantwortlich, dies wird auf Basis eines Raspberry Pi realisiert.
Honeywell HR20
Hardware
Das Honeywell HR20 ist ein gängiges µC gesteuertes Heizungsthermostat. Seine große Verbreitung und die Tatsache das es bereits einige Projekte für alternative Betriebssoftware gibt, bietet die ideale Grundlage.
- 3 Tasten
- 1 Stellrad mit Drehgeber.
- LC-Display
- Stellmotor für Heizungsventil
- Prozessor: AVR ATmega169P
- 10 Zugängliche Pins: JTAG, RX(PE0)/TX(PE1), 1 GPIO (PE2), VCC, GND
Es gibt von diesem Thermostat auch eine ältere Version die mit einem NEC µC arbeitet. Wir beziehen uns jedoch nur auf die aktuelle Variante mit dem AVR.
Open HR20
Die Software Open HR20 wurde von Dario Carluccio, Jiri Dobry und Thomas Vosshagen entwickelt. Diese Software ist ein funktioneller Nachbau der Original-Software und ist als GPL-2 lizensiert.
1-Wire
Software Vorlage
Als Vorlage für die 1-Wire implementierung verwenden wir "1-Wire Device mit AVR-Mikrocontroller" von Tobias Müller, veröffentlicht unter der GPL-3 Lizenz. Mit dieser Software ist es möglich, einen 1-Wire Slave rein in Software zu implementieren.
Umsetzung
Original Arbeit der 1-Wire Slave Quellcode mit dem INT0 des AVRs, dieser ist jedoch bei unserem ATMega169P schon als Line für das Display des HR20 in Verwendung. Als Alternative verwenden wir den PCINT2 der glücklicherweise an die externe Pinleiste geführt wurde. Die Pin Change Interrupts der ATMegas sind jedoch viel simpler aufgebaut als der externe Interrupt INTx . Es können nur Logikänderungen am Pin, nicht aber welche Flanke, erkannt werden. Außerdem teilen sich 8 Pins je einen PC Interrupt. Beim Aufruf des Interrupts muss also noch eine abfrage auf den richtigen Pin und seinem Zustandswechsel erfolgen um die Flankenfunktionalität nachzubilden.
Proof of concept
Wie oben beschrieben haben wir beim HR20 nicht den für die 1-Wire integration benötigten INT0 frei. Des weiteren wird auch der 8-Bit Timer (Timer0) bereits in der Open HR20 Software verwendet. Da wir diese so gut wie Unverändert lassen wollen, ist es nötig den externen Interrupt auf den bereits beschriebenen PCINT2 zu legen und auch der Timer Overflow muss von Timer0 auf den 16-Bit Timer1 umziehen. Um dies zu Testen wurde das Projekt OW_Simple gestartet. Dabei handelt es sich um die 1-Wire Slave Vorlage mit allen Änderungen für den ATmega169P des HR20 sowie den Anpassungen der Interrupts. Ziel ist es die 1-Wire Funktionalität als Standalone Software auf dem HR20 zum laufen zu bekommen.
Probleme
Um eine Flankenerkennung für einen Pin Change Interrupt am ATMega zu realisieren, muss man sich den letzten Pin-Zustand merken und beim erneuten Aufruf der Interrupt-Funktion mit dem aktuellen Zustand vergleichen. Nun hat man jedoch das Problem, das alle Interrupts des AVRs gleich priorisiert sind und sich nicht gegenseitig unterbrechen dürfen. Fällt ein Interrupt während der Laufzeit eines anderen an, so wird erst nach Beendigung des aktuellen der neue ausgeführt. Dabei stellt sich jedoch das Problem, das sich in dieser Zeit der Zustand des Pins schon geändert haben kann.
Wir haben keine Möglichkeit bei diesem Typ den Zustand zum Zeitpunkt des Logikwechsels am Pin festzustellen. Dadurch kann es dazu kommen, das wir zwar einen Pinchange-Interrupt bekommen, aber bei der Ausführung die händische Detektion der Flanke fehlschlägt. Wir bekommen nicht alle Bits vom Master mit und kommen aus den Takt.
Erste Versuche die "Wartezeiten" des Timerinterrupts gezielt zu verkürzen zeigten erste Postive Ergebnisse. Die Anzahl der verschluckten Pinchange-Interrupts wurden weniger. Die genauere Analyse ergab jedoch auch, wie gut auf dem Bild rechts zu sehen, das unser Slave die Leitung zu spät auf Low zieht um eine Logische 1 auf den Bus zu schreiben. Und zwar erst wenn die Flanke wieder am steigen ist. Dies kann man gut auf dem Bild rechts an den kurzen Spitzen beim 10 und 13 Bit des unteren Graphen erkennen.
Die Zeiten des Timers sind fest in der 1-Wire Software vorgegeben. Per Defines können diese zwar verändert werden, sind aber zur Laufzeit fest im Programm. Es könnte also sein das die Software nicht immer mit jedem 1-Wire Master vom Timing her zusammenarbeiten kann und erst die passente Werte Messtechnisch oder durch Versuche ermittelt werden müssten.
Im aktuellen Zustand kommt zwar eine Kommunikation mit dem Master zustande, aber wir gerade nach wie vor aus dem Takt, wodurch nach wenigen Übertragenen Bits der Master abbricht. Wie im Bild links zu sehen werden unsere Bits (x) und Komplement-Bits (Cx) korrekt gesendet und vom Master bestätigt (Ax). Dies geht hier für genau 4 Bits (12 Flanken am Bus) richtig. Dann verpassen wir eine Flanke (X) und kommen mit unseren Interrupt erst zum darauf folgenden. Dies verschiebt die Kommunikation, der Master stellt einen Fehler (E) fest und löst einen Reset aus.
Dies kommt vermutlich von einer unsauberen erkennung am PCint. Dieser Löst wohl im Logikübergang ab und zu falsch aus, wenn der Pin noch keinen festen zustand hat. Bei Tests war hier innerhalb weniger Takte ein Zustandswechsel zu beobachten. Eine genaue Ursache konnte bisher noch nicht ermittelt werden. Unschön ist auch dass das Datenblatt des ATmega169P keine genauen Angaben macht, ab welchem Zustand genau ein Logikwechsel am Pin als solcher auch Interpretiert wird.
Eine "Entprellung" der Datenleitung ist wohl unumgänglich, wenn auch etwas Zeitkritisch, da wir nur maximal 15µS Zeit haben die Fallende Flanke zu erkennen und darauf zu reagieren um selbst die Leitung für eine 0 auf Low zu ziehen.
Lösungsansätze
Da wir gern unabhängig von der Geschwindigkeit des Masters sein möchten und vor allem Sicherstellen wollen, das die Slave Software auch Fehlerfrei mit anderen 1-Wire Mastern zusammen arbeiten kann, ist eine dynamische Anpassung der Zeitintervalle zur Laufzeit nötig.
Raspberry Pi
Software
1-Wire
Als 1-Wire Master wird das OWFS 1-Wire File System verwendet.
