Hallo, ich will eine Heizungssteuerung für unser System im Haus aufbauen, weil die Alte (originale) ihren Geist aufgegeben hat. Ich habe bereits eine Platine mit einem µC erstellt aber programmtechnisch ist es sehr schwierig Temperaturdaten auzuwerten, die zu verarbeiten und anschließend entsprechende Pumpen anzusteuern - geschweige denn noch eine Uhrzeiteingabe, wann die Heizung sich ein bzw. ausschalten soll. Deshalb will ich das Projekt aufs neue beginnen mit mehreren µC und die Arbeit auf diese weise verteilen. Ich habe mir das folgendermase vorgestellt: 1. Eine Einheit, die alle Thermofühler auswertet und die fertige Temp. in °C bereithält, damit der Master diese nur abfragen muss. (LM75 Fühler an einen PCF) 2. Einen weiteren µC der die Pumpen ansteuert (ca. 8stk. über Relais) 3. Eine seperate Einheit für die Uhr/Kalenderfktion 4. Einen EEPROM für das Speichern der Konstanten (z.B. mindest Raumptemperatur usw.) 5. LCD und Tastatur 6. Master, bei dem alles zusammenläuft und alles koordiniert wird Nun muss ich alle Einheiten miteinander verbinden, da habe ich an den I2C Bus gedacht. Jedoch ist es so, dass wenn ein Fühler z.B. eine Mindesttemperatur unterschreitet, soll er ein Signal an den Master geben. Bei einem I2C Bus ist dies ja aber nicht möglich, dass die Slaves ohne Aufforderung etwas senden. Des Weiteren möchte ich mit der Tastatur auch die Konstanten im EEPROM über LCD ändern können, sowie die Fühlerwerte ablesen können, etc. Ich will damit sagen das ich mehr als einen Master in meinem Aufbau hätte. Master die Senden und Empfangen müssten, damit alles reibungslos funktioniert. Seht ihr vielleicht einen alterenativen Denkansatz für mein Projekt? Für Anregundenn bin ich sehr dankbar! MfG Adam
Was ist so schwierig dran, das ein einem einzigen Controller zu erledigen? Geht problemlos. Multimaster-I2C scheint mir das nicht wirklich zu vereinfachen. Und ist hier auch nicht nötig, eine Open-Drain "Interrupt"-Leitung wird ja wohl noch drin sein.
Ja aber das ganze wird zu komplex, oder nicht? Ich habe 8 pumpen, ca. 10 fühler + lcd + tastatur + eeprom und das noch die kalenderfktion. Ich müsste ja jeden Port der reihe nach abfragen ob da etwas passiert ist, oder nicht? Und bei einem µC wird das doch bischen viel. Oder denke ich da falsch?
Ich würde garnicht so viele verschiedene µC verwenden. I2C enthält normalerweise auch immer eine IRQ-Leitung, um den Master auf eine Änderung hinzuweisen. Wenn du trotzdem mehrere µC per I2C verbinden willst, dann würde ich doch einfach vorschlage, ein Master, der die Clients zyklisch abfrägt. Ob die Pumpe nach 0,1sek oder nach 0,2sek eingeschalten wird, ist doch egal. Der Master fragt also alle anderen "Module" alle 100 oder 500ms ab und erfährt früh genug, was er wissen muss.
Eine Heizungssteuerung ist jetzt wirklich keine zeitkritische Anwendung. Wenn Du ein 1-Sekunden-Raster hättest in dem verschiedenen Temperaturfühler eingelesen werden und Pumpen gesteuert werden sollen ist das immer noch schnell genug (braucht auch beides keine Priorität zu haben - darf evtl. auch mal 10 ms verzögert abgearbeitet werden). Nimm einen entsprechend großen (Pinanzahl, Speicher) uC und einen Uhrenbaustein (den würde ich schon extern machen) und Du solltest alles an "Logik" haben was Du brauchst - der Rest sind dann halt die Temperaturfühler, Relais für die Pumpen, LCD und ein paar Tasten. Wichtig bei der Planung ist auch eine gewisse Störungssicherheit und Failsafe-Schaltung, damit wenn der uC abstürzt nicht der Brenner anbleibt oder so... Einen Interrupt bei Unterschreitung eines Wertes ist sowieso nicht notwendig da man sowieso zyklisch die Temperaturwerte einlesen sollte. I2C über größere Distanz ist übrigens auch nicht zu empfehlen, da die Leitung max. eine Kapazität von 400pF haben darf. Willst Du verteilte Temperaturmessung machen wäre wegen der Leitungslänge und Anzahl der Kabel CAN oder RS485 eine Möglichkeit untereinander zu kommunizieren. Würde aber dann zusätzliche Bausteine bedeuten als Signalumsetzer.
Exakt dieses Thema hatte mich nach längerer Pause wieder in die nierigeren Gefilden der Computertechnik gebracht. Ähnliches Gebilde wie bei dir, realisiert mit Mega32, plus zweite per RS485 angebundene Bedieneinheit im Wohnbereich, realisert mit Tiny2313. Du scheinst es einfacher zu finden, getrennte Prozesse in getrennten Controllern zu realisieren. Wenn man von eine einzelnen klassischen Hauptprogramm ausgeht, mag das passen. Zwingt einen aber niemand dazu, das auch so zu machen. Was du da vorhast, ist nichts anderes als Multitasking in Hardware. Was ich statt dessen verwendet habe, ist Multitasking in Software (AvrX). Wobei AvrX mit seinem unweigerlich preemptiven Multitasking Fallstricke aufweist, die bei kooperativem Multitasking nicht auftreten, insofern nicht jedem zu empfehlen. Das ganze geht natürlich auch anders, z.B. Hauptschleife ruft diverse separate Module für die jeweiligen Abläufe auf, jedes mit seiner State-Machine. Ich mag's mit RTOS lieber, aber das ist sicherlich Geschmacksache und hat wohl auch etwas mit Erfahrung+Vorstellungskraft bei nebenläufiger Programmierung zu tun.
Hallo, Vielleicht könnte dich diese Seite interessieren: http://mikrocontroller.cco-ev.de/de/heizung.php Da hat jemand genau das aufgebaut was du bauen möchtest. Dort wurde nur ein AVR Controller (ATMEGA 32) verwendet. Es wird ua. der Quellcode für den AVR und ein Windows Programm für die Einstellung der Heizkurven zu Verfügung gestellt. Der einzige Nachteil ist das dieses Gerät auf einer Art Testplatine (AVR-Ctrl) aufgebaut ist, aber auch dafür findet man dort Unterlagen. Der Nachteil kann aber auch ein Vorteil sein.;-) Ich finde dieses Projekt sehr gut. gruss ralf
Hi! Ich würde davon abraten zig verschiedene Prozessoren zu verwenden, das macht die Sache wesentlich komplizierter. Du musst für jeden Prozessor eigene Software schreiben, und Dir Protokolle ausdenken wie die einzelnen Komponenten letzendlich miteinander kommunizieren. Ich selbst habe mir auch eine komplette Heizungsregelung realisiert, bestehend aus einem ATMega16. An der Platine habe ich eine serielle Schnittstelle, ein 4x27 LCD, 4 Taster, 16 Temperatureingänge und 10 Relaisausgänge. Das schafft der Mega16 spielend! Lediglich die Temperaturwandler habe ich in einen anderen Prozessor ausgelagert (2x Tiny26, die ich so programmiert habe dass sich jeder wie 8x LM75 verhält) und ist per I2C an den Mega16 angebunden. Die Schaltung steuert Heizungsmischer, Ölbrenner, Solarpumpe, Brauchwasserpumpe, Mischer für Feststoffkessel u.a. An die serielle Schnittstelle hab ich kürzlich noch eine Erweiterung angeschlossen, die die Temperaturdaten auf einen SQL Server schreibt: http://db0fhn.efi.fh-nuernberg.de/~dl6nek/heizung/ Falls du noch Tips brauchst, einfach fragen. So eine Heizungsregelung ist ein sehr interessantes Projekt, obgleich sowas nicht an einem Wochenende fertig wird. Gruß Ich
Danke für die Zahlreichen antworten. Genau soetwas habe ich auch vor Wesserbisser. Wie funktioniert das denn bei dir, dass der µC z.b. die Fühlerabfragt und gleizeitig deine Eingaben per Taster empfängt und parallel dazu noch die LCD ausgabe steuert. Das ist mein Problem, ich weiß nicht wie ich das Software mäßig lösen soll, deshalb kam die Idee mit den mehreren µC, aber die werde ich wohl nun verwerfen :)
Ich bin auch der Meinung, dass es ein µC tut. Die paar Funktionen sollte n locker mit einem µC zu erschlagen sein. Anders wäre es, wenn die Funktionseinheiten räumlich weiter auseinander wären. Wenn du noch den Uhr/Kalender über I2C machst (PCF8573) hat der µC sowieso kaum noch was zu tun. Die I/Os lassen sich ja kurz überschlagen: 10 LM75 -> 2x I2C -> 4 Pins (Uhr und ext. EEProm kann auch hier dran) 8 Relais 8 Pins LCD 7 Pins Tastatur 5 Pins ? RS-232 2 Pins Sind doch gerade mal 26 Pins. ATMega16 sollte völlig ausreichen. Gruß Thomas
Alles klar, mit den Pins komme ich hin. Hardware mäßig klappt das alles, aber wie bereits oben erwähnt. Wie realisiere ich das Softwaremäßig? Er fragt jeden Fühler einzelln ab, vergleich mit dem Wert im EEPROM und schaltet entsprechend die Pumpen. Aber wie realisiere ich z.B. eine Menüführung, während er die Fühler prüft ... multitasking? Oder ein Trick?
@Wesserbisser Ich habe auch vor so etwas bei mir zu realisieren, bin aber noch auf Ideensuche. Mich würde zum Beispiel interessieren wie du denn Ölbrenner ansteuerst. Ich hab da nirgends richtige Informationen gefunden. Ich habe da nur so eine wage Idee davon, welche Leitung welche Funktion hat. Meine Steuerung ist noch ganz. Die hat nur wenig Komfort. Ausserdem klappt die Temperaturregelung bei sehr kaltem und wärmeren Wetter nicht so wie ich mir das vorstelle. Ich habe zwar versucht mit den Heizkurven das hinzubekommen, aber nur mit mässigem Erfolg. Ich kann dort auch keine Schaltprogramme einstellen, nur Schaltzeiten. Also muss ich am WE zB. in den Keller um die anzumachen oder ich heize während der Woche umsonst. Dies ist meine Motivation für so ein Projekt. Wie ich oben schrieb ist meine Steuerung noch ganz. Deshalb wollte ich diese mit getricksten Temperaturwerten regeln( Temperaturfühler überbrücken). Da hört sich dein Projekt aber wesentlich besser an. Den irgendwann geht so eine Steuerung ja doch mal kaputt. Hast du dein Projekt dokumentiert, zB. Schaltpläne? Würdest du das hier posten? Ich hätte jedenfalls auch Interesse. gruss ralf
Das einzige was evtl. Interrupts auslösen muß ist die Tastatureingabe und die Serielle. Alles andere kann bedient werden wann dafür Zeit ist (wir reden hier von ms). Selbst wenn Du mit dem Einlesen des nächsten Temteraturwertes wartest bis der neue Text auf dem Display geschrieben ist sind höchstens ms vergangen - eine Zeit die Du Subjektiv nicht messen können wirst. Es ist nichts zeitkritisches an einer Heizungssteuerung. Es würde sogar reichen die Temperaturen im 30sek-Rhytmus abzufragen wenn nicht grade einer das Fenster aufgemacht hat. Schalten wirst Du voraussichtlich immer nur auf ganze Grad C - und wie schnell ändert sich das wohl in einer Wohnung? :) Dennoch würde ich wahrscheinlich die Temperatur im Sekundentakt oder schneller einlesen da der uC sowieso nix zu tun hat... Auch hier kann man dann natürlich wieder Sicherheit einbauen, da innerhalb einer Sekunde die Temperatur nicht um mehrer 10°C ändern kann - dann liegt wahrscheinlich eher eine Störung im Fühler oder der Referenzspannung/Konvertierung vor (oder auf der Leitung). Ich würde die Sache wahrscheinlich so angehen, dass ich die Ein-/Ausgabe (Menü/Serielle) zuerst machen würde und den Rest (Temperatur/Pumpen) dann in einer Schleife abarbeiten würde - vielleicht sogar mit Pausen über einen Timer.
Vorsicht mit den LM75! Bei einer Heizung sind die Fühler mitunter weit entfernt (bei mir z.B. Solarfühler auf dem Dach), die nahesten sind auch schon ca. 1m. Über diese Entfernung taugt I2C einfach nichts (und jetzt bitte keine Links mit dem Kommentar "Der macht das auchso"). I2C ist gemacht um innerhalb einer Platine oder eines Gerätes zu kommunizieren, alles andere ist Pfusch. Ich habe NTC-Rohranlegefühler verwendet, der Vorteil ist dass die Widerstandsänderung relativ groß ist und man hardwaremäßig pro Fühler mit einem Widerstand auskommt. Die Linearisierung mache ich in den Tinys mit einem Ausgleichspolynom 2. Grades. Das funktioniert für diese Anwendung mehr als ausreichend gut, Auflösung habe ich 1/10 °C genommen, der Temperaturwert wird für jeden Kanal als signed short (16bit) ausgelesen und repräsentiert die Temperatur in der Einheit 1/10 °C. Im EEPROM der Tinys habe ich für jeden Kanal 3 Koeffizienten hinterlegt, so dass man auch mit unterschiedlichen Fühlern innerhalb eines Tinys arbeiten kann. Angesprochen werden diese Tinys wie gesagt genauso wie ein LM75, nur kann man eben den Kanal auswählen der als nächstes gelesen werden soll. Nun zur Software: Schaumal in die Codesammlung, da gibts ein paar sehr gute Beiträge (z.B. von Peter Danegger) zum Thema "Task-Scheduling" und "Menüführung". Zusammengefasst geht das ungefägr so: Man lässt einen Timer laufen, der z.B. mit 1kHz einen Interrupt aufruft. In der ISR werden unterschiedliche Zählervariablen hochgesetzt und bei Erreichen des gewünschten Wertes wird ein Flagbit in einer Flagvariablen gesetzt. In der main-Funktion wird einfach ständig abgefragt ob so ein Flag gesetzt ist und dann ggf. eine Aktion ausgeführt. Ich hänge mal einfach hier mein Heizungsprojekt für den Mega16 an. Vielleicht kannst du Dir daraus auch einige Infos zur Menüprogrammierung etc. ziehen.
>>Aber wie realisiere ich z.B. eine Menüführung, während er die >>Fühler
prüft ... multitasking? Oder ein Trick?
Wie bei allen Problemen hilft es, die große Aufgabe in viele kleine zu
zerlegen und nach Wichtigkeit zu werten.
Bei Verwendung eines einzigen µPs (wie es auch alle anderen hier
empfehlen) wird dieser geschätzt maximal nur 1-5% seiner Rechenleistung
für die eigentliche Steuerung/Regelung brauchen. Die restliche
Verarbeitungszeit kann er damit beschäftigt sein, 1. im Hintergrund per
Timerinterrupt die Tastatur abzufragen, 2. bei Bedarf Texte aufs Display
zu schreiben, 3. Ausgänge zu aktualisieren und 4. die Sensoren zyklisch
einzulesen.
Die Verwendung eines RTOS hat seine Vorzüge, wenn man damit umgehen
kann. Bei einer zeitlich unkritischen Aufgabe wie Heizungssteuerung muß
es aber nicht von Vorteil sein, zumal es auch seine Tücken zeigen kann,
wenn die 'Kiste' unverhofft aus nicht ersichtlichem Grund stehen
bleibt.
Vorschlag: per Interrupt wird die Tastatur abgefragt und bei
Tastendruck der zugehörige Tastencode in der Variablen TASTE abgelegt.
Eine Funktion LESE_TASTE() liefert das Ergebnis von TASTE oder eine 0,
wenn keine Taste gedrückt wurde. Die Funktion wird in jedem Menü
fortlaufend aufgerufen, da die Bedienung durch den Benutzer höchste
Priorität hat. Bei Tastendruck wird entsprechend reagiert (Display,
Ausgang, +++) und letztlich auf neuen Tastendruck gewartet.
In der Funktion LESE_TASTE() wird jetzt (beispielsweise) eine Variable
XXX hochgezählt und abhängig von ihrem Wert eine andere Funktion
aufgerufen, die nur eine Aufgabe erledigt, aber auch nicht viel Zeit
braucht: bei 1 -> LESEN_SENSOR1, 2 -> LESE_SENSOR2, ... 22 ->
LESE_UHRZEIT, 23 -> BEWERTE_SENSOREN, 24 -> BEREITE_AUSGABEWERTE, setze
FERTIG_FLAG und XXX wieder auf Startwert.
Die AUSGABE_WERTE werden erst dann ins Display geschrieben, wenn kein
Benutzermenü mehr offen ist. Da jede einzelne Routine kurz ist, bekommt
der Benutzter auf Tastendruck sofort eine Reaktion - trotzdem läuft die
Steuerung im Hintergrund weiter.
Wie beschrieben kann man klein (Tastatur/Display) anfangen und dann
nach Bedarf erweitern. Ohne jetzt ein Buch zu schreiben, hast Du
hoffentlich meinen Ansatz verstanden; es gibt noch andere
Vorgehensweisen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.