|
4.2 Beschreibung Knotensoftware („C“-Implementation)Die Knotensoftware wurde von dem Grundgerüst/Rahmenprogramm abgeleitet.
Daraus resultiert dann eine Form der Projektsoftware. Die Projektsoftware
ist das Hauptprogramm zu einem Projekt bzw. alle Dateien/Module die zum
Projekt gehören, nicht aber die Include-Files aus dem "\inc"-Verzeichnis.
So ist RelS (RelaisApplikation) zum Beispiel eine Projektsoftware, "relais.c"
zählt dagegen zu den Include-Files. In den Include-Files sind die
grundlegenden Funktionen zur Steuerung der Hardware abgelegt. Diese können
dann von mehreren Projekten eingebunden werden.
4.2.1 ProjektsoftwareDie bereits entstandene Projektsoftware ist hier aufgeführt und soll als Beispiel/Vorlage für Erweiterungen dienen. 4.2.1.1 Grundgerüst/RahmensoftwareDie aktuelle Rahmensoftware (Rahm1.10) benötigt ohne Erweiterungen 1660 Bytes Programmspeicher. Hiermit ist eine grundlegende Buskommunikation und das Signalisieren eintreffender Telegramme abgedeckt. Das eigentliche Hauptprogramm/Hauptaufgabe der Software muß noch, genau wie die Routinen zur Abarbeitung von eintreffenden Telegrammen, ausformuliert/erstellt werden. Die Datei DefProjekt.h ist für Definitionen (Konstanten, Prototypen, Variablen) gedacht, die genau zu diesem speziellen Projekt gehören. Sie übernimmt also die Aufgabe, die eigentlich Rahm1.10.h abdecken müßte. Einige der Include-Files brauchen Definitionen aus dieser Datei, deswegen wurde der Dateiname "DefProjekt.h" für jedes einzelne Projekt festgelegt. Eingebundene Includefiles müssen dem makefile bekannt gemacht werden. Die Funktionen von Knotenbefehl werden im Abschnitt Includefiles can.c beschrieben. Hier folgt eine kurze Auflistung der Rahmensoftware, dieser Teil kann bei der Vorstellung der übrigen Projektsoftware somit entfallen: /******************************************************************************
Hier folgen die Include-Anweisungen:
}
}
} Routinen zur Bearbeitung eingehender CAN-Telegramme: /*********************************************************************
//
Routinen eintragen, die aufgerufen werden sollen, wenn ein Telegramm auf
einem MO eingetroffen ist
}
4.2.1.2 RelS (RelaisSoftware)RelS steuert die IO-Applikation (Relaiskarte) mit bis zu 4 Relais/ 4 Tastern. In der Hauptprogrammschleife werden die an die CAN-Controller Porterweiterung angeschlossenen Taster zyklisch abgefragt. Bei Änderungen werden die vordefinierten Telegramme verschickt, und die lokal auszuführenden Schaltvorgänge erledigt. Detailierte Beschreibung siehe Kapitel 3.2. Verwendete Includefiles: can.h sendtele.h relais.h
4.2.1.3 232S (RS232Software)Die 232Software ist momentan noch nicht nach C portiert, daher hier der Verweis auf die Assembler-Version in Kapitel 4.1.2.2.
4.2.1.4 RolR (RolladenRelais)Diese Software beruht auf der Hardware der IO-Applikation. Es werden,
je nach Einstellung beim Compilieren (in DefProjekt.h), etweder 2 Rolläden
(MO1 und MO2) unterstützt, oder ein Rolladen (MO1) und 2 frei verwendbare
Relais (MO3 und MO4). Leider ist die Wiederholpositioniergenauigkeit bei vielen kleinen Bewegungen nur sehr gering, d.h. zehnmal 2% senken ist nicht identisch mit einmal 20% senken. Damit sich im Laufe der Zeit keine größeren Differenzen zwischen gewünschter Rolladenposition und tatsächlicher Position ergeben, wird die programminterne Positionsvariable bei jeder Fahrt an den Anschlag (oben oder unten) neu kalibriert. Dazu wird der Rolladen 10% weiter gefahren als nötig, so ist sichergestellt, daß er wirklich an den Anschlag gefahren ist. Für die Positionsvaribale bedeutet dies, daß sie den Wert 1 einnimmt für Rolladen ganz offen, und den Wert 99 für ganz geschlossen (bei 0 bzw. 100 würde eine ständige Rekalibrierung durchgeführt und das Relais würde nie abgeschaltet). Durch die Endabschalter in den Rohrmotoren besteht keine Gefahr für den Motor/Rolladen bei der Kalibrierung. Die aktuelle Position und die anzufahrende Position lassen sich per Statusabfrage-Kommando an den Rolladen auslesen. Der "Rolladen" sendet dazu ein Telegramm an eine anzugebende Adresse. Das Telegrammformat zur Steuerung der Relais/Rolladen wird im Kapitel
4.2.2.5 rolladen.h ausführlich beschrieben
4.2.1.5 Dimm (Dimmersoftware)Steuert bis zu 16 Sensordimmer (SLB0587) + 4 Relais Verwendete Includefiles: can.h sendtele.h timer.h relais.h
4.2.1.6 MenS (MenüSystemSoftware)Die Menüsoftware ist eine Dialogsoftware für den Benutzer. Über den angeschlossenen Cursortasterblock und ein LCD Display kann er durch die Untermenüs navigieren. Die Navigation wird mit einer Statemaschine gelöst. Jeder Tastendruck läßt die Statemaschine in einen anderen Zustand springen, dabei wird auch die Displayausgabe aktualisiert.
Verwendete Includefiles: can.h sendtele.h timer.h funktionen.h canports.h lcd.h uart.h
4.2.1.7 DMen (DimmerMenüsoftware)Die DimmerMenüsoftware basiert auf der Menüsoftware und deren Hardware. Sie wurde ergänzt durch eine Tastenmatrix, die sparsamer mit der Anzahl der verwendeten Portpins umgeht. Die "Dimmerdirekttasten" senden beim Niederdrücken einen Dimm-Befehl an die Dimmerknoten, beim Loslassen wird ein Dimm-Stop-Befehl verschickt. Zusätzlich können noch Wandtaster angeschlossen werden, die die herkömmlichen Lichtschalter ersetzen. Zum Einsatz (unter der Tasterplatine angeordnet) kam hier die Nachfolgeversion des ursprünglichen Buskopplers (Foto: Buskoppler(kleiner)).
Verwendete Includefiles: can.h sendtele.h timer.h funktionen.h canports.h lcd.h
4.2.1.8 Ther (Thermometersoftware)
Verwendete Includefiles: can.h sendtele.h timer.h funktionen.h lcd.h ds1820.h
4.2.1.9 ZSUr (ZeitSchaltUhR)Die Hardware der Zeitschaltuhr besteht, neben dem obligatorischen Buskoppler, aus einem oder mehreren I2C-EEProms (24C64, 64kBit) und optional aus einem LCD-Display (2x16), das die aktuelle Zeit ausgibt. Die externen EEProms werden über den I2C-Bus angesprochen. Die Firmware ist so ausgelegt, daß mehrere 24C64-Speicherbausteine angeschlossen werden können, dadurch wird das Speichervermögen des Zeitschaltknotens erhöht. In der Standardbestückung mit 8kByte besteht so ausreichend Platz für 512 Schaltzeitpunkte und Telegramme. Die Schaltzeitpunkte können folgendermaßen aussehen:
Die Hardware der Zeitschaltuhr besitzt selbst keinerlei Bedienknöpfe, die Telegramme müssen per PC in den Knoten übertragen werden. Ausnahme hiervon: Die kurzTelegramme sind dafür gedacht, daß andere Knoten (z.B. IO-Applikation, Taster) solche kurzTelegramme verschicken. Diese dürfen dann, wegen der Beschränkung der CAN-Nutzdatenlänge von 8 Bytes, nur 4 Datenbytes umfassen (->kurzTelegramm). Die interne Uhr des Zeitschaltknotens wird durch ZeitTelegramme (CAN-ID 50) entweder vom PC oder vom DCF77-Knoten abgeglichen/gestellt.
Zuänachst werden die nächsten zu versendenden Telegramme aus den einzelnen Bereichen gelesen und die entsprechenden Variablen vorbesetzt. Dabei werden Telegramme, die zu einem vergangenen Zeitpunkt verschickt werden sollten, ignoriert. (wichtig, wenn Knoten z.B. zurückgesetzt wird und wieder anfahren soll). Die Hauptprogrammschleife ruft nacheinander die Routinen zur Abarbeitung der einzelnen Zeitschaltarten (einmal, täglich, wöchentlich und kurz) auf. Jeder 256. Durchgang (etwa alle 13s) wird die Displayausgabe (hh:mm) aktualisiert. Es kann also vorkommen, daß die angezeigte Zeit für kurze Zeit nicht der aktuellen Zeit entspricht. Die Schaltarten "einmal", "täglich" und "wöchentlich" sind sich in ihrem Ablauf sehr ähnlich. Zunächst wird geprüft, ob die Zeit des nächsten zu versendenden Telegramms erreicht ist. Ist dies der Fall, so wird das Telegramm verschickt und das nächste aus dem Speicher geladen und die Variablen (die das nächste Telegramm und den Zeitpunkt repräsentieren) wieder neu besetzt. Dies ist möglich, da die PC-Software sicherstellt, daß die Telegramme in chronologischer Reihenfolge in den Speicher geschrieben werden. Deshalb mußte auch eine Trennung zwischen wöchentlicher und täglicher Telegramme stattfinden, da nur so eine eindeutige chronologische Reihenfolge eingehalten werden kann. Trifft ein kurzTelegramm ein, so wird der Schaltzeitpunkt aus der aktuellen Uhrzeit und der relativen Zeitangabe (in Sekunden) aus dem Telegramm berechnet. Dies ist bei einem Zielzeitpunkt am nächsten Tag relativ codeintensiv. Die errechneten und übergebenen Werte werden in externenEEProm an einer freien Stelle abgelegt. Da die Telegramme nicht in der Reihenfolge eintreffen, in der sie auch ausgeführt werden sollen (z.B. 30minuten-Timer vor 10minuten-Timer) müssen alle möglichen Schaltzeitpunkte und Telegramme in jeder Sekunde ausgelesen werden und ihr Schaltzeitpunkt mit der momentan aktuellen Zeit verglichen werden. Das Vorhalten aller Telegramme im Speicher kommt aus Platzgründen nicht in Frage. Da das Auslesen aus dem externen EEProm einige Zeit in Anspruch nimmt, wurde die maximale Anzahl der KurzzeitTimer auf 16 begrenzt. Theoretisch könnten bis zu ca. 40 Telegramme pro Sekunde aus dem Speicher ausgelesen werden. Es muß aber neben dem Auslesen auch noch die normale Buskommunikation (Knotenbefehle, extEEPromLesen...) abgewickelt werden. Für das Beschreiben des externen EEProms sind folgende Befehle notwendig:
Um den Protokolloverhead klein zu halten (die CAN-Telegramme beinhalten ja bekanntlich nur 8 Nutzbytes) wird für jeden Befehl eine eigene CAN-ID reserviert. Der Knoten muß nach dem Programmieren durch ein spezielles
Telegramm zurückgesetzt werden (Uhrzeit bleibt erhalten). Im Anhang (Kap 6.11) werden die
Telegrammformate und die
Speicherorganisation
tabellarisch aufgeführt: Verwendete Includefiles: can.h sendtele.h timer.h funktionen.h lcd.h i2c.h 24C64.h zeit.h
4.2.1.10 MeIR (MenüsystemIR)Das MenüsystemIR bietet die Möglichkeit per IR-Fernbedienung bestimmte Telegramme zu versenden, um damit beispielsweise Lampen, Rolläden, Steckdosen usw. zu steuern. Die Hardware besteht, neben einem Buskoppler, lediglich aus einem IR-Empfänger (z.B. TSOP1736), dessen Ausgang an PD2/Int0 angeschlossen ist. Die Dekodierung der eintreffenden IR-Signale wird von den Routinen im Modul ir.c übernommen. Als Fernbedienung kann jede RC5 kompatible Fernbedienung herhalten. Für meine Zwecke setze ich eine alte Hauppauge Fernbedienung ein (Bild mit Tastencodes). Da die Hardware keine weiteren Eingabe- oder Ausgabeeinheiten besitzt, kann sie diskret in einer Zimmerecke verschwinden. Der TSOP1736-Empfänger (in Verbindung mit meiner Fernbedienung) ist so empfangsstark, daß eine direkte Sichtverbindung nicht notwendig ist. Für die Bedienerführung habe ich mir folgendes Menüschema überlegt und implementiert: Durch drücken der <- (Zurücktaste, hier: "reserved") verzweigt die Statemaschine immer wieder in ihren Anfangszustand. So kann jederzeit ein angefangener "Pfad" abgebrochen und in eine definierte Ausgangsituation zurückgesprungen werden. Lesebeispiel: Rolladen Wohnzimmer soll etwas gesenkt werden. Notwendige Tastendrücke:
Wird in einem Zustand nicht innerhalb einer konfigurierbaren Zeit eine Taste gedrückt, so kann davon ausgegangen werden, daß keine weitere Aktion gewünscht wird. Die Statemschine springt danach wieder in ihren Ausgangszustand (so wird verhindert, daß der Knoten in einem Zustand "hängenbleibt", der ja mangels Ausgabeeinheit vom Benutzer nicht erkannt werden kann). Verwendete Includefiles: ir.h, ...
4.2.1.11 RSte (RolladenSteuerung)Die Rolladensteuerung wurde für den Buskoppler_v2 entwickelt, weil
die normale Zeitschaltuhr (ZSUr) wegen fehlender direkter Eingriffsmöglichkeit
für diesen Anwendungszweck zu unflexibel ist.
Das Menüsystem erklärt sich hier am besten selbst.
4.2.2 IncludesDie Includefiles bilden die Grundlage der Knotensoftware. Auf den Funktionen, die in den "Includes" abgelegt sind, basiert die Projektsoftware. Im folgenden werden die einzelnen Include-Files kurz vorgestellt, ihre Funktion umrissen und eventuelle (Software)Schnittstellen beschrieben. Um die Kompatibilität zu früheren Projekten zu gewährleisten, werden Softwareänderungen, die den Codeumfang erhöhen würden, nur per #ifdef-Anweisung in den Include-Quellcode aufgenommen. Um diese Erweiterungen nutzen zu können, müssen die entsprechenden #define-Konstanten in die projektbezogene Includedatei "DefProjekt.h" aufgenommen werden.
4.2.2.1 can.h: grundlegende BuskommunikationHier sind die Funktionen zusammengefaßt, die für alle Knoten gelten sollen und die sich auf die Kommunikation mit dem CAN-Bus beziehen.
4.2.2.2 sendtele.h: Telegrammversand
4.2.2.3 timer.h: TimerInitialisierungen
4.2.2.4 relais.h: Taster und Relais(erweiterte Beschreibung für v3.x+ - bitte hier klicken).Routinen: TasterAbfragen, TastLokal Routinen: TelegrammRelais[1-4] ParameterByte:
Mittels Statusabfrage-Telegramm läßt sich der aktuelle Relaiszustand herausfinden. Dies kann zum Beispiel für PC-Visualisierungen von Interesse sein. Dazu wird ein Paket mit folgendem Format an die CAN-ID des Relais geschickt.
Datenbyte1 und 2 enthält die Adresse (Antwort IDB0 und IDB1) des anfragenden Knotens. Schließlich muß der befragte Knoten wissen an welche Adresse er die Antwort senden soll. Beispiel: Der PC (repräsentiert durch RS232Applikation mit Knotennummer
2, MO13 -> ID 245 ->IDB0=0x1E, IDB1=0xA8) interessiert sich für
den Zustand des Relais Nr. 3 (-> MO3) an Knotennr. 1 (-> ID: 219).
Dazu verschickt er ein CAN-Telegramm mit der ID 219 und folgendem Inhalt: Das Antworttelegramm des angesprochenen Relais sieht so aus:
Datenbyte 1 und 2 enthält hier die Adresse (CAN-ID) des Relais. So kann der Empfänger festellen welches Relais gerade geantwortet hat. Im obigen Beispiel ergäbe sich folgende Antwort:
4.2.2.5 rolladen.h: spezielle RolladenroutinenTelegrammverarbeitung für Rolladen1 (eintreffend auf MO1) und/oder
für Rolladen2 (eintreffend auf MO2). ParameterByte:
(Position 0 und 100 kalibrieren gleichzeitig die interne Stellung) Beispiel 1: Rolladen 1 an Knoten 50 soll in Position 96 fahren
(fast geschlossen). Hierzu wird ein Telegramm mit der CAN-ID 1001 und
dem einzigen Datenbyte mit dem Wert 0x60 (=96dez.) verschickt.
Mittels Statusabfrage-Telegramm läßt sich die aktuelle Rolladenposition und die Zielrolladenposition herausfinden. Dies kann zum Beispiel für PC-Visualisierungen von Interesse sein. Dazu wird ein Paket mit folgendem Format an die CAN-ID des Rolladens geschickt.
Beispiel: Der PC (repräsentiert durch RS232Applikation mit
Knotennummer 2, MO13 -> ID 245 ->IDB0=0x1E, IDB1=0xA8) möchte
die Momentanposition des 1.Rolladens an Knoten 50 erfahren (ID=1001).
Dazu sendet er ein Paket an den RS232-Knoten nach vorgegebenen
Format. Der Inhalt des CAN-Telegramms mit der CAN-ID 1001 sieht dann
folgendermaßen aus: Der angesprochene CAN-Knoten bzw. die Funktion, die die eintreffenden Telegramme für den Rolladen abarbeitet, antwortet darauf dann nach folgendem Schema:
In Datenbyte1 und 2 stehen die Adresse (CAN-ID) des angesprochenen Rolladens. So kann der Empfänger des Telegramms erkennen, von welchem Absender das Telegramm verschickt wurde. Datenbyte 0 und 3 sind nur ein Echo der Anfrage. Datenbyte 4 enthält die geforderten Daten. Im obigen Beispiel würde die Antwort des angesprochenen Rolladens
z.B. so aussehen:
4.2.2.6 funktionen.h: diverse Funktionen, z.B. sprintfHier sammeln sich diverse Funktionen an, die nirgendwo thematisch passen. Bisher sind in funktionen.h folgende Funktionen zusammengefaßt:
4.2.2.7 canports.h: entprellte Taster und Tastenmatrix an der CAN-ControllerPorterweiterungCANPort0Taster/ CANPort1Taster: MatrixTastatur:
4.2.2.8 lcd.h: Betrieb eines LCDsDie lcd-Routinen erlauben die Ansteuerung eines HD44780-kompatiblen PunktmatrixDisplays.
Die Routine LCDInit, die für die Initialisierung des LCDs
zuständig ist, ist auf ein 2x16 Zeichen Display ausgelegt. Neu (2002-05-24): "#define LCDDEFCHAR" erweitert lcd.h um die Funktionalität eigene Zeichen auf dem LC-Display darstellen zu können. Dazu wird die Funktion "LCDDefChar" mit den Parametern für die Nummer des zu definierenden Zeichens (0..7) und der Zeichenkette (bzw. einen Zeiger darauf), die das Zeichen repräsentiert, aufgerufen. Die Software SpezialChar von B.Müller (http://www.mme-berlin.de/avr/indexd.htm) ist zum Zeichnen sehr hilfreich. Die so definierten Zeichen werden dann so: sprintf(Puffer, "%c",CGRAM_CHAR0); in einen String gebracht.
4.2.2.9 uart.h: UART-Kommunikation (RS232)Hauptsächlich kommen hier die Routinen UARTInit und UARTSend zur Anwendung. Ihre Bedeutung erschließt sich aus ihrem Namen. Die Baudrate ist auf 9600,8,N,1 eingestellt.
4.2.2.10 ds1820.h: TemperaturSensor DS1820 auslesenKommunikationsroutinen zum Datenaustausch mit einem Dallas DS1820 Temperatursensor über das/die 1wire-Protokoll/Anbindung. Die Routinen DS1820_reset, DS1820_write_byte, DS1820_readbyte, DS1820_convert_temp und DS1820_get_temp sind im Datenblatt zum DS1820 beschrieben und weitgehend selbsterklärend. Der Anschluß des Sensors ist an PortC4 des AVRs vorgesehen, siehe Kapitel 2.4.4.
4.2.2.11 I2C.h: I2C-Bus Steuerung und DienstprimitiveDie Anbindung des I2C Busses an den AVR wird, wie in Kap. 2.4.6 beschrieben, durchgeführt. I2C.h beinhaltet folgende Routinen:
Bemerkung: Die Adresse setzt sich aus den 7 I2C-Adressbits zusammen, allerdings in ihrer eigentlichen Wertigkeit. Diese werden dann noch 1 Bit nach links geschoben und das LSB mit der Lese/Schreibrichtung verodert. (Beispiel: (Basis)-Adresse eines PCF8574 ist somit 0x20, das von der Routine dann auf 0x40 bzw. 0x41 verändert wird ) Diese Funktionen stellen die Diensteprimitive zur Verfügung, auf die von weitergehenden Funktionen aus aufbauenden Includes zurückgegriffen wird. I2CRead/WriteSlave kann beispielsweise direkt mit einen PCF8574 kommunizieren. Neu (2002-05-24): Per "#define I2C_400kHz" kann die Busfrequenz auf ca. 400kHz erhöht werden (in DefProjekt.h unterzubringen). Diese Einstellung gilt dann für alle I2C-Slaves. Kann auch nur ein Slave nicht mit der erhöhten SCL-Frequenz umgehen, so darf dieses #define nicht benutzt werden. (24C64 kann mit 400kHz betrieben werden, aber LM75 beispielsweise nicht).
4.2.2.12 24C64.h: Anbindung eines I2C SpeicherbausteinsDer serielle Speicherbaustein 24C64 (hier: ST24C64; 8kByte Speicherplatz) läßt sich mit Hilfe der Bibliothek 24C64.h beschreiben und auslesen. Alle implementierten Funktionen können dabei auf einen Adreßraum von 64kByte zugreifen. Die Adressierung des genauen Speicherbausteins geschieht in der Routine und muß daher von aufrufenden Programmteilen nicht beachtet werden. Beim Anschluß der Hardware ist darauf zu achten, daß die einzelnen Speicherbausteine in ihrer konfigurierbaren Adresse aufeinanderfolgen. Ist der adressierte Speicherbaustein physikalisch nicht adressierbar (weil er evtl. nicht vorhanden ist), so wird in der globalen Variablen "Fehlernr", der aktuelle Fehler übergeben (Fehlernr = 0: fehlerfrei). Die aufrufende Routine kann diesen dann auswerten. Die Funktionen bauen auf der Bibliothek I2C.h auf.
Die nachfolgend genannten Funktionen werden durch eintreffende Telegramme auf ihren zugewiesenen MOs aktiviert. Die Parameter sind in den Telegrammen codiert:
4.2.2.13 Zeit.h: Aktualisierung der knoteninternen SoftwareUhrDie Routine DCFZeit wird von eintreffenden Zeittelegrammen (CAN-ID: 50) auf MO13 aktiviert. Die eingetroffenen Zeitinformationen (Uhrzeit, Datum und Wochentag) werden von der knoteninternen Softwareuhr übernommen (Voraussetzung dafür ist natürlich, daß das Hauptprogramm eine solche Softwareuhr bereitstellt). Der Aufbau eines Zeittelegramms sieht (am Beispiel für 3.4.2002 - 19:30:00, Wochentag: 3) so aus:
Aufbau Byte2: (Wochentag<<4 | Monat), d.h. die oberen 4 Bits beschreiben
den Wochentag, die unteren 4 beinhalten den Monat.
Wochentag: 1:Mo, 2:Di, 3:Mi, 4:Do, 5:Fr, 6:Sa, 7:So 4.2.2.14 ir.h: Dekodierung der eintreffenden IR-SignaleDie hier verwendeten Routinen sind größtenteils von Bray
übernommen und nur an wenigen Stellen modifiziert. Ausführliche Beschreibung des RC-5 Codes und dessen Aufbau unter: http://users.pandora.be/nenya/electronics/rc5/index.htm
4.2.2.15 PCF8591.h: Anbindung eines I2C AD/DA-WandlersDer PCF8591 Baustein (Beschreibung) besitzt 4 AD-Wandler zu je 8 Bit und einen DA-Wandler (8Bit). Bis zu 8 Bausteine dieses Typs können an einem I2C-Bus betrieben werden. Die Basisadresse lautet 0x48, zu dieser wird dann die SlaveNr hinzuaddiert (verodert). Achtung, auch andere Bausteine anderer Typen verwenden diese Basisadresse (z.B. LM75). So können in Summe nur max. 8 Slaves dieser Typen verwendet werden. Der PCF8591 darf nur mit 100kHz (oder weniger) Bustakt gefahren werden. (#define I2C_400kHz darf nicht gesetzt sein.) Die Bibliothek PCF8591.h stellt diese Funktionen zur Kommunikation mit dem PCF8591 zur Verfügung:
Auch diese Funktionen bauen auf der Bibliothek i2c.c auf. Auf zahlreiche Konstantendefinitionen in PCF8591.h kann dabei zurückgegriffen werden. Beispiel:
4.2.2.16 lm75.h: Anbindung eines I2C TemperaturSensorsLM75 Eigenschaften: (Beschreibung)
Die Bibliothek lm75.h stellt diese Funktionen zur Kommunikation mit dem LM75 zur Verfügung:
Die Funktionen zur standalone-Überwachung von Temperaturen und eigenständiges Schalten des O.C.-Ausganges wird (noch) nicht unterstützt.
Kommandos können sein:
Die Telegrammformate zur Kommunikation mit dem TemperaturSensor LM75 finden sich in Kapitel 6.12.
|