Keiang's electronics hobby side

This website deals with the topics of electronics, digital signal processing and embedded programming.

flag-english flag-german
 

Digitale, temperaturabhängige Lüfterregelung mit USB-Interface - Projektbeschreibung

Projektbeschreibung, Schaltplan, Platinenlayout, Downloads


 

USB Temperaturregelung PCcool V1.4

 


Beschreibung der Hardwarekomponenten



Mikrocontroller AN2131

cypressDas Kernstück dieser Temperatur- / Lüfterregelung ist der MikrocontrollerAN-2131 von der Firma Cypress. Dieser Mikrocontroller verfügt bereits eine interne USB-Schnittstelle, oder besser gesagt über die notwendige Logik, um mit dem USB-Bus kommunizieren zu können. Damit ist es relativ einfach und schnell möglich eine Hardware-Anwendung für den USB-Bus zu entwickeln. Den Mikrocontroller von Cypress gibt es jedoch nur als SMD-Version, was damit den manuellen Aufbau einer Schaltung etwas erschwert. Zudem existiert er nur als 3,3V-Version, womit meistens ein zusätzlicher Spannungsregler in der Schaltung erforderlich ist.

Die Architekur dieses Controllers beruht auf einem erweiterten 8051-Kern der intern mit einen Takt von 24MHz arbeitet. Er besitzt 8 kByte internen RAM, welcher für ausführbaren Code und Daten genutzt werden kann. Einen internen nicht flüchtigen Flash- oder Eeprom-Speicher für Code oder Daten besitzt der Mikrocontroller keinen. Jedoch kann relativ einfach durch einen externen I2C-Baustein der Datenspeicher auf bis zu 64 kByte erweitert werden. Da die Firmware bei dem Controller nur in den flüchtigen RAM-Speicher geladen werden kann, bedeutet dies natürlich das diese nach einem Neustart nicht mehr vorhanden ist und erneut geladen werden muss. Der Controller hat hierfür zwei Konzepte wie dies automatisch realisiert werden kann:

  1. Firmware wird vom Windows Treiber über den USB-Bus in den Controller geladen
  2. Controller lädt über den I2C-Bus die Firmware aus einen externen Eeprom

Das erste Konzept hat den großen Nachteil, dass die Schaltung erst arbeitet wenn Windows den Bootvorgang und damit verbunden das Laden der Treiber abgeschlossen hat. Auch wäre die Schaltung nicht mehr als stand-alone Anwendung nutzbar, womit dieses Konzept für den geplanten Einsatzbereich nicht sinnvoll ist.

In dem zweiten Konzept wird zwar ein weiteres Bauteil benötigt, ein Eeprom mit I2C-Interface, jedoch ist dieses bereits sehr günstig zu bekommen. Die Firmware kann recht einfach ohne zusätzliche Hardware ( Programmiergerät etc.) in das Eeprom geflasht werden. Dazu muss die Schaltung lediglich mit dem USB verbunden sein. Mit Hilfe einer Software kann unter Windows die Firmware direkt in das Eeprom geschrieben werden.

Der Mikrocontroller sucht nach einen Neustart an einer festen Adresse auf dem I2C-Bus nach dem Eeprom und lädt die Firmware vollständig in seinen internen Code-RAM und startet sie.

 

I2C-Bus

I2C BusEin weiterer Vorteil des AN-2131 ist der integrierte I2C-Bus, der aber auch bei den relativ wenigen Ein- /Ausgängen des Mikrocontrollers benötigt wird. Mit Hilfe des I2C-Bus kann unter anderem die Anzahl der IO-Ports auf sehr einfache Weise erweitert werden. Dazu wird einfach ein Port-Expander Baustein, in meinem Fall der "PCF 8574P", mit dem I2C-Bus verbunden. Damit mehrere von diesen Port-Expandern zugleich an dem Bus betrieben werden können, ohne das sie sich gegenseitig stören, bekommen sie über 3 Eingänge eine feste Adresse zugewiesen. Mit Hilfe dieser 3 Adresseingänge können 8 verschiedene Bausteine angesprochen werden. Für den Fall das mehr wie 8 Bausteine benötigt werden würden gibt es noch einen 2. Typ, der "PCF8574AP". Dieser ist über andere Adressen wie der "PCF8574P" ansprechbar. Somit könnte ein System ohne Probleme auf bis zu 16 Bausteinen erweitert werden. Die Ansteuerung der Portexpander, über den I2C-Bus, geschieht sehr einfach da der µC "AN-2131" das I2C-Bus Protokoll bereits fertig implementiert hat. Somit muss lediglich "gesagt" werden wie die Adresse des Portexpander's lautet und schon können Daten ausgetauscht werden, ohne sich mit timing-Zeiten oder dem genauen Protokoll des I2C-Buses auseinander setzen zu müssen. Mit einen kleinen Unterprogramm kann eine verwendung der Bausteine dann soweit vereinfacht werden, dass der Port eines Portexpander's so einfach wie ein interner Port angesprochen werden kann. Einen kleinen Nachteil hat die Sache allerdings, da der I2C-Bus ein serieller Bus ist und bei dem AN2131 mit 91kHz läuft, können nur begrenzt schnell Daten ausgetauscht werden. Für normale Anwendungen wie z.B. ein CLCD (Text LCD) ist das absolut ausreichend, bei einem größeren GLCD wird es allerdings schon problematisch wenn eine Animationen realisiert werden soll.

Da auch in meiner Schaltung die Ein- und Ausgänge des Mikrocontrollers sehr bald verbraucht waren habe ich einen von diesen Port-Expander Bausteinen dazu benutzt um die Ausgabe an ein LCD/GLCD bzw.dem "Led-Display" zu realisieren. Für die Ansteuerung des "Led-Displays" waren jedoch nochmals zusätzliche Steuerleitungen nötig, deswegen habe ich einen 2. Port-Expander Baustein auf dem Led Anzeige Modul integriert, der die notwendigen Leitungen erzeugt. Dazu aber weiter unten mehr...

 

USB-BUS

Der µC "An2131" besitzt eine USB1.1 Schnittstelle. über diese Schnittstelle können alle aktuellen Daten der Regelung (Temperaturen, Drehzahlen, Temp. -abweichungen, Temp.- Steigungen etc) unter Windows ausgelesen und dargestellt werden. Dazu habe ich eine Software unter "Visual Studio .Net" in C# entwickelt. Genauere Infos zu der Software gibt es hier: Windows Software. Mit dieser Software können auch alle Einstellungen /Konfigurationen vorgenommen werden.

Die USB-Schnittstelle von dem µC und der eigentliche 8051er Core, in dem die Regelungsroutinen laufen, sind fast vollständig getrennt. Nur "fast" deswegen, weil natürlich die Daten noch von der Regelung an den USB-Core gesandt werden müssen. In ihrer eigentlichen Aufgabe haben diese beiden getrennten Cores jedoch nichts mit einander zu tun. Das bringt den großen Vorteil das die

USB Windows Treiber

Regelungsalgorithmen in dem 8051er Core nicht von dem USB Anschluss, und damit von Windows, beeinflusst werden. D.h. im Klartext das selbst wenn der PC abstürzt und damit im dümmsten Fall den USB blockiert etc. die Regelung davon nicht beeinflusst wird und normal arbeitet. Das geht sogar soweit, das der USB-Anschluss im laufenden Betrieb ständig ein und ausgesteckt werden kann ohne auch nur im geringsten die Regelung in ihrer Arbeit zu stören.

Die Daten werden über den USB via Bulk-Transver an/von Windows übertragen. Der Bulk-Transver hat die Eigenschaften eine sichere (Datenüberprüfung) Datenübertragung zu gewährleisten. Er bietet zwar keine sehr hohe Bandbreite an, aber das wird auch bei den wenigen Bytes, die übertragen werden müssen, gar nicht benötigt. (pro übertragung 3* 64Bytes) Dadurch das der Bulk-Transver keine sehr hohe Priorität unter den verschiedenen Übertragungsarten hat, ist sichergestellt das die Regelung mit diesem Protokoll nicht andere wichtige USB-Geräte blockiert. Zwar hat das auch den "Nachteil" das die Daten nicht sofort an Windows gesendet werden können, sondern evtl ein paar ms länger brauchen, aber für die Regelungseigenschaften spielt das keine entscheidende Rolle da die gesamte Regelung von dem Mikrocontroller übernommen wird und dieser normal weiter arbeitet wenn der USB gerade "besetzt" ist.

 

Temperatursensoren DS18S20

DS18S20Die Erfassung der verschiedenen Temperaturen geschieht mit Hilfe der Temperatursensoren "DS18S20" von Dallas. Diese haben den Vorteil, dass sie die Wandlung des Temperaturwertes in einen digitalen Wert bereits selber vornehmen und man sich somit nicht um einen Abgleich oder Messfehler, aufgrund von Leitungswiderständen etc., kümmern muss. Für die Temperatursensoren gibt es auf der Lüfterregelung insgesamt 3 Anschlüsse an die bis zu 8 Sensoren angeschlossenen werden können. Weil diese Anschlüsse alle parallel geschalten sind, spielt es auch keine Rolle welcher der Anschlüsse benutzt wird. Da die Sensoren in einen Bus-System arbeiten hätte auch ein einziger Anschluss gereicht, jedoch hielt ich es so für praktischer da dadurch nicht alle Sensoren an einer einzigen Leitung hängen müssen. Standardmäßig bieten die Sensoren eine Auflösung von 0,5°C an, jedoch kann mit Hilfe der "Restdaten" des Sensors eine Auflösung von mind. 1/16°C erreicht werden. Einige Sensoren erreichen sogar eine Auflösung von bis zu 0,01°C. Diese hohe Auflösung wird benötigt um sichere Trendmessungen machen zu können, also um sagen zu können ob die Temperatur gerade steigt oder fällt.

Die Kommunikation zwischen den Sensoren und dem µC geschieht über das 1-Wire Bus Protokoll von Dallas. Die Umsetzung dieses Protokolls, an einen Portpin des µC, war eine der aufwendigeren Aufgaben, da dafür ein sehr genaues timing eingehalten werden muss und bereits ein Interrupt die Datenübertragung vernichtend stören kann. Dank dem 1-Wire Bus wird aber nur eine einzige Portleitung des µC für theoretisch unendlich viele Sensoren benötigt. Die Unterscheidung zwischen den Sensoren wird über eine fest eingelaserte Seriennummer realisiert. Um eine gewisse Datensicherheit in dieses Protokoll zu bekommen gibt es die Möglichkeit ein CRC-Byte, welches der Sensor mit jeder Datenübertragung mitschickt, auszuwerten. Über dieses CRC-Byte kann erkannt werden, ob in den empfangenen Daten (64Bit Daten + 8Bit CRC) ein fehlerhaftes Bit / Byte vorhanden ist und im gegebenen Fall die Daten nochmals abgerufen werden. Dazu wird das CRC-Byte in dem µC nach einen bestimmten Verfahren nachgerechnet und mit dem CRC-Byte, welches von dem Sensor empfangen wurde, verglichen. Sind beide identisch dann sind die empfangenen Daten gültig und können weiter verarbeitet werden. Über das CRC-Byte kann auch überprüft werden ob ein Sensor überhaupt geantwortet hat. Wenn z.B. ein Sensor nicht antworten sollte, dann werden von dem µC nur "1" gelesen. Das kommt daher das ein pull-up Widerstand den Bus immer auf high "1" zieht und Daten nur derart übertragen werden das entweder der Master (µC) oder der Slave (Temperatursensor) den Bus auf low "0" ziehen. Dadurch kann verhindert werden das selbst wenn beide zugleich senden würden, es einen Kurzschluss gibt, was die IO-Ports zerstören würde. Wenn nun also ein Sensor nicht antworten sollte, werden für alle 8 Datenbytes und das CRC-Byte der Wert 0xff gelesen. Da aber der Wert 0xff für diese 8 Datenbytes (alle 0xff) kein gültiges CRC-Byte ist, genügt es wenn man nur dieses auswertet. Man muss also nicht noch alle Datenbytes auf den Wert 0xff "abklopfen" um herauszubekommen ob ein Sensor überhaupt geantwortet hat. Ein kleines Programm um das CRC-Byte "von Hand" nachrechnen zu können gibt es hier: Calculate CRC8 for most of the Dallas Chips

Die Sensoren haben einen Arbeitsbereich von -55°C bis 125°C, seit der Firmwareversion 2.1.7 kann dieser Arbeitsbereich auch voll ausgenutzt werden. Vor dieser Firmwareversion war es nicht möglich neg. Temperaturen anzeigen zu lassen. Das wurde wie gesagt mit dieser Version geändert so das jetzt neg. Temperaturen mit einem "-" Vorzeichen richtig auf dem LCD und auch in der Windows-Software angezeigt werden.

Bei der Entwicklung der Firmware (in Assembler) war die Erfassung der Lüfterumdrehungszahl eines der Hauptprobleme. Eine Möglichkeit wäre natürlich gewesen die Umdrehungen (Impulse) pro Minute zu zählen, jedoch wäre dann nur einmal pro Minute ein Ergebnis rausgekommen und das auch nur gemittelt über diese Minute. Deswegen habe ich mich dafür entschieden die Zeit von einer Umdrehung des Lüfters zu messen, mit Hilfe der Timer Interrupts (dank an hell-bread für die Idee), und anschließend mit Hilfe einiger mathematischen 32bit Berechnungen (1/Zeit * 60) die korrekte Umdrehungszahl pro Minute auszurechnen (seit Firmware V1.7.2 geändert, um auch niedrigere Drehzahlen erfassen zu können) Bei der Berechnung der Drehzahl sollte man darauf achten das ein Lüfter normalerweise 2 Impulse pro Umdrehung ausgibt, es gibt sogar Lüfter die mit 4 Impulsen pro Umdrehung arbeiten (langsam drehende Lüfter von Papst).

 

Beleuchtungsanschlüsse

Die Schaltung verfügt über zwei geschaltete Beleuchtungsanschlüsse, einer davon schaltet gegen 5V / 200mA und ist für Hintergrundbeleuchtungen von LCD's gedacht ( eventuellen Vorwiderstand nicht vergessen ! ). Der 2. Anschluss schaltet aktiv gegen 12V und kann mit max. 80mA belastet werden, dieser ist für z.B. zusätzliche LEDs in dem Gehäuse etc. gedacht. Diese beiden Anschlüsse werden in dem Modus regulated und full-power aktiviert und im Modus night automatisch abgeschalten.

 

DC-DC Wandler

Da es durchaus noch oft LCDs gibt die eine externe negative Spannung für die Kontrastleitung benötigen, ist auf dem Board ein optionaler DC-DC Wandler vorgesehen. Mit ihm kann eine negative Spannung von -12V bis +12V für die Kontrastleitung des LCD's erzeugt werden. Bei Verwendung von einem LCD das keine negative Kontrastspannung benötigt, kann der relativ teure DC-DC Wandler durch zwei einfache Drahtbrücken ersetzt werden.

 


Firmware


 

besondere Funktionen der Firmware

  • Notabschaltung bei verschiedenen Alarmen / Fehlern
  • aktivierbarer Anlaufboost für jeden Lüfterkanäl ( sehr nützlich für träge 120mm Lüfter )
  • für jeden Lüfterkanal eigene untere Drehzahlbegrenzung
  • Überwachung von Pumpenfördermenge ( über Durchflussmesser oder Tacholeitung von Pumpe )
  • Steuerung einer 12V Pumpe z.B. die Laing-DDC ( über analoge Spannungsregelung, kein PWM )
  • Verwaltung von 8 Lichtkanälen sowie Möglichkeit für eigene Lichtsequenzen
  • verschiedene Arten der Temperaturregelung
  • Sensoren und zugehörige Lüfter können beliebig verknüpft werden, auch mehrfache Verknüpfungen sind möglich
  • Überwachung aller Sensoren auf eine einstellbare maximale Temperatur, bei Überschreiten werden verschiedene Aktionen gestartet

 

Die Schaltung wurde so entworfen, dass selbst wenn noch keine Firmware in die Regelung geflasht wurde oder eine teilweiser Ausfall der Hardware vorliegt, die Lüfter mit 100% laufen. Erst wenn der Bootvorgang der Regelung abgeschlossen und alles einwandfrei initialisiert wurde, werden die Lüfter in der Drehzahl geregelt.

In den ersten Versionen wurde die Firmware noch bei jedem Windowsstart über den USB in das RAM der Regelung geladen, was natürlich den Nachteil hatte das die Regelung erst arbeitete nachdem der Windows Bootvorgang abgeschlossen war. Mit der Firmwareversion 2.1.5 wurde das geändert und die Firmware wird seitdem fest in das Eeprom der Regelung geflasht. Um die Firmware in die Regelung zu flashen wird kein spezieller Programmieradapter o.ä. benötigt, sondern es kann alles über das USB-Interface abgewickelt werden. Dadurch werden Firmware updates einiges einfacher.

Der Mikrocontroller ( µC ) lädt nach jedem einschalten ( POR = power on reset ) selbstständig die Firmware aus dem Eeprom in sein RAM und startet sie. Dabei aktiviert der µC auch gleich die USB-Schnittstelle und meldet sich bei Bedarf unter Windows an (Enumeration).

Bei der Entwicklung der Firmware war es mir besonders wichtig das die Regelung auch im stand-alone Betrieb genutzt werden kann. D.h. das die Regelung für den Betrieb kein Windows etc. braucht und damit auch an Orten eingesetzt werden kann wo kein Pc in der Nähe ist. Die Regelungsalgorithmen und viele weitere Funktionen wie z.B. LCD-Ansteuerung, Sensorverwaltung über 1-Wire Bus von Dallas, Service-Menüs laufen alle in dem 8051er Core ab und nicht unter Windows. Der Grund ist ein recht einfacher, wenn Windows ausfallen würde, dann macht eine Windows verwaltete Regelung nicht mehr viel Sinn. Hier lag aber auch das größte Problem bei diesen Projekt. Es musste eine komplette Verwaltung der angeschlossenen Hardware und dazu ein vernünftiger Regelungsalgorithmus in weniger wie 8kByte untergebracht werden. 8kByte deswegen weil der Controller nicht mehr an Ram besitzt. In der Programmiersprache "C" wäre das nicht machbar gewesen, da hier der Code durch umfangreiche Bibliotheken und unnötige Sprünge zu schnell aufgebläht und damit die 8kByte Grenze gesprengt worden wäre. Aus diesem Grund, aber auch aus Performancegründen, wurde die Firmware vollständig im Assembler geschrieben und ist mittlerweile über 7kbyte stark, das mag nicht viel klingen, ist aber für einen reinen Assemblercode ungeheuer viel.

Ein weiteres Problem in der Firmware waren die recht vielen math. Routinen, die dazu gebraucht wurden um z.B. die richtige Temperatur der Sensoren auf 0,1°C genau, die Drehzahl ( rpm ) der Lüfter oder um die genaue Temperatursteigung der Sensoren berechnen zu können. Der µC bietet mit seinem 8051 Befehlssatz jedoch nicht viele math. Befehle um sowas machen zu können, um genau zu sein gibt sogar nur 4 Befehle für so etwas und das auch nur mit einer Genauigkeit von 8bit. (weil natürlich ein 8bit Controller). Um hier nicht wieder zuviel Platz für irgendwelche math. Bibliotheken zu verschwenden, habe ich nur eine 16bit Routine implementiert mit der alle genaueren Berechnungen abgedeckt werden konnten. Die restlichen Berechnungen / Algorithmen konnte ich mit Tricks wie right-shift = geteilt durch 2, 2er Komplement = neg. Zahl, etc. bewerkstelligen.

 


Notalarm / Notabschaltung


 

Bei folgenden Alarmen wird der Notalarm / Notabschaltung aktiviert:

  • Temperatur eines Sensors liegt über dem eingestellten Wert ( overtemp. )
  • ein Temperatursensor ist ausgefallen
  • Wasserdurchfluss liegt unter dem eingestellten Alarmwert

 

Bei einen Notalarm werden von dem Mikrocontroller folgene Aktionen getätigt:

  • setzen aller Lüfterkänäle auf volle Leistung ( Mode "full power" )
  • aktivieren der Relais auf der Erweiterung "Notabschaltung"
  • eine an die Erweiterung "Pump Control" angeschlossenen Pumpe wird auf maximale Leistung gefahren
  • PC wird mit Hilfe der Erweiterung "Notabschaltung" runter gefahren / abgeschalten
  • an Windows Software wird ein Fehlercode gesendet

 

Bei folgenden Fehlern wird unter Windows kurz eine Nachricht angezeigt aber keine Notabschaltung aktiviert, da die Regelung weiter arbeiten bzw. den Fehler beheben kann:

  • Text LCD antwortet nicht / ist ausgefallen
  • Mikrocontroller hat einen Datenfehler in den Sensordaten entdeckt ( CRC Fehler )
  • Spannungsversorgung eines Temperatursensor's hat einen Wackelkontakt
  • speichern von Einstellungen auf dem Eeprom schlug fehl

 


Bestückungspläne, Platinenlayout


 

Schaltplan

Schaltplan PCcool V1.4

 

Bestückungsplan (Namen)

Bestückungsplan

 

Bestückungsplan (Werte)

Bestückungsplan



Jumper / Pinbelegung

Jumper, Pinbelegung

 


Downloads


Platinenlayout der Lüfterregelung "PcCool V1.4d"

Schaltplan der Lüfterregelung "PcCool V1.4d"

 

 


KeiAng

Published on: Monday, November 14 2011 (4983 reads)
Copyright © by Keiang's electronics hobby side

[ Go back ]

 

Electronic Projects