Cooperating radiator monitoring 114: Unterschied zwischen den Versionen
Xoquox (Diskussion | Beiträge) |
Xoquox (Diskussion | Beiträge) |
||
| Zeile 78: | Zeile 78: | ||
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. | 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. | + | 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. |
| + | {{clear}} | ||
==== Lösungsansätze ==== | ==== Lösungsansätze ==== | ||
Version vom 14. November 2012, 12:37 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.
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.
