Benutzer:Atuschen - Versionsgeschichte

Atuschen: /* Mein Ethersex-Setup: */

2010-02-07T09:46:15Z

‎Mein Ethersex-Setup:

Atuschen: /* Mein Ethersex-Setup: */

2010-02-07T09:39:44Z

‎Mein Ethersex-Setup:

Atuschen: /* Mein Ethersex-Setup: */

2010-02-07T09:39:16Z

‎Mein Ethersex-Setup:

Atuschen: /* Geplante Erweiterungen: */

2010-02-07T09:36:28Z

‎Geplante Erweiterungen:

Atuschen: /* Mein Ethersex-Setup: */

2010-02-07T09:29:03Z

‎Mein Ethersex-Setup:

Atuschen: /* Mein Ethersex-Setup: */

2010-02-07T09:04:37Z

‎Mein Ethersex-Setup:

Atuschen: /* Geplante Erweiterungen: */

2010-02-06T23:33:22Z

‎Geplante Erweiterungen:

Atuschen am 6. Februar 2010 um 23:31 Uhr

2010-02-06T23:31:06Z

Atuschen: /* Geplante Erweiterungen: */

2010-02-06T21:37:52Z

‎Geplante Erweiterungen:

Atuschen: /* Geplante Erweiterungen: */

2010-02-06T21:21:31Z

‎Geplante Erweiterungen:

← Nächstältere Version		Version vom 7. Februar 2010, 09:46 Uhr
Zeile 29:		Zeile 29:

	[[Bild:Atuschen-Ethersex-Setup1.JPG‎\|640px]]		[[Bild:Atuschen-Ethersex-Setup1.JPG‎\|640px]]
		+
		+	Ich habe den HD44780-Treiber entsprechend angepasst, so dass die Ausgabe über den PCF8574 läuft. Die Hintergrundbeleuchtung vom LCD ist schaltbar, ebenso eine zusätzliche LED (den R/W-Pin vom LCD benutze ich nicht). Den zweiten PCF8574 für die Taster frage ich zur Zeit periodisch in der appsample.c ab, möchte aber später den Interrupt-Ausgang des PCF nutzen.

	=== Geplante Erweiterungen: ===		=== Geplante Erweiterungen: ===

@@ Zeile 24: / Zeile 24: @@
   - 8 Taster über PCF8574 am I2C-Bus
   - 24C256 32KB EEPROM am I2C-Bus
-    alternativ 24C65 EEPROM
+    alternativ 24C65 8KB EEPROM
 Alles zur Zeit im fliegenden Aufbau auf mehreren Lochrasterplatinen:

@@ Zeile 24: / Zeile 24: @@
   - 8 Taster über PCF8574 am I2C-Bus
   - 24C256 32KB EEPROM am I2C-Bus
 Alles zur Zeit im fliegenden Aufbau auf mehreren Lochrasterplatinen:

@@ Zeile 30: / Zeile 30: @@
 === Geplante Erweiterungen: ===
   - RFM12 (868 MHz) oder FS20 Sender/Empfänger
   - Heizkörper-Thermostate (Funk/868 MHz)

@@ Zeile 25: / Zeile 25: @@
   - 24C256 32KB EEPROM am I2C-Bus
-Alles zur Zeit im fliegenden Aufbau auf mehreren Lochrasterplatinen.
+Alles zur Zeit im fliegenden Aufbau auf mehreren Lochrasterplatinen:
 === Geplante Erweiterungen: ===

@@ Zeile 20: / Zeile 20: @@
   - 4x 2272 Funkschalter
   - 3x Pollin UP-Funkdimmer
-  - Pollin K8IO Relaiskarte über PCF8574 am I2C-Bus
+  - Pollin K8IO Relaiskarte über PCF8574A am I2C-Bus
   - 2x20 LCD über PCF8574 am I2C-Bus
   - 24C256 32KB EEPROM am I2C-Bus

← Nächstältere Version		Version vom 6. Februar 2010, 23:33 Uhr
Zeile 55:		Zeile 55:
	Ein Problem dabei könnte der (relativ) langsamge Zugriff auf den externen EEPROM sein. Also würde ich zu jeder Minute pro Stunde in der ein Befehl vorhanden ist paralell ein Eintrag im RAM speichern. Ich meine je 1 Bit für jede Minute. Der Controller fragt jede Minute im RAM ab ob das entsprechende Bit gesetzt ist, wenn ja liest er die passende (fixe) Adresse im EEPROM, vergleicht danach Stunde, Monat, Tag, Wochentag und falls diese übereinstimmen springt er die Adresse mit dem auszuführenden Befehl an.		Ein Problem dabei könnte der (relativ) langsamge Zugriff auf den externen EEPROM sein. Also würde ich zu jeder Minute pro Stunde in der ein Befehl vorhanden ist paralell ein Eintrag im RAM speichern. Ich meine je 1 Bit für jede Minute. Der Controller fragt jede Minute im RAM ab ob das entsprechende Bit gesetzt ist, wenn ja liest er die passende (fixe) Adresse im EEPROM, vergleicht danach Stunde, Monat, Tag, Wochentag und falls diese übereinstimmen springt er die Adresse mit dem auszuführenden Befehl an.
	Damit würde man nur 60 bit (pro Minute 1) = 8 byte RAM benötigen. Außerdem würden nur dann EEPROM-Zugriffe erfolgen, wenn tatsächlich zur aktuellen Minute Befehle vorliegen würden.		Damit würde man nur 60 bit (pro Minute 1) = 8 byte RAM benötigen. Außerdem würden nur dann EEPROM-Zugriffe erfolgen, wenn tatsächlich zur aktuellen Minute Befehle vorliegen würden.
		+	Zur Initialisierung müsste das EEPROM beim booten 1x komplett gelesen werden, damit die entsprechenden Bits im RAM gesetzt werden.

@@ Zeile 53: / Zeile 53: @@
 Dafür ist mir der RAM im ATMega zu knapp. Also müssen die Schaltbefehle in einen externen nichtflüchtigen Speicher verlagert werden, den ich im laufenden Betrieb ändern kann. Prädestiniert dafür wäre der 4Kbit High-Endurance-Block eines 24C65 I2C-EEPROMS, welcher laut Datenblatt ca. 10 Mio Schreibzyklen verträgt. Da dieser Block nur 512 Byte groß ist, müssten die auszuführenden Befehle (welche sich nur selten ändern) in einem anderen Bereich gespeichert werden. Nur die Schaltzeiten/Tage müßten im High-Endurance-Block stehen. 3-4 byte reichen zur Codierung der Schaltzeiten aus, wodurch sich mindestens 128 Schaltzeitpunkte speichern lassen. Das wäre mehr als ausreichend für meine Zwecke.
-Ein Problem dabei könnte der (relativ) langsamge Zugriff auf den externen EEPROM sein. Also würde ich zu jeder Minute pro Stunde in der ein Befehl vorhanden ist paralell ein Eintrag im RAM speichern. Ich meine nur die Minute selbst. Der Controller fragt jede Minute im RAM ab ob ein entsprechender Eintrag vorhanden ist, wenn ja liest er die passende (fixe) Adresse im EEPROM, vergleicht Stunde, Monat, Tag, Wochentag und falls diese übereinstimmen springt er die Adresse mit dem auszuführenden Befehl an.
+Ein Problem dabei könnte der (relativ) langsamge Zugriff auf den externen EEPROM sein. Also würde ich zu jeder Minute pro Stunde in der ein Befehl vorhanden ist paralell ein Eintrag im RAM speichern. Ich meine je 1 Bit für jede Minute. Der Controller fragt jede Minute im RAM ab ob das entsprechende Bit gesetzt ist, wenn ja liest er die passende (fixe) Adresse im EEPROM, vergleicht danach Stunde, Monat, Tag, Wochentag und falls diese übereinstimmen springt er die Adresse mit dem auszuführenden Befehl an.
-Damit würde man nur 60 bit (pro Minute 1) = 8 byte RAM benötigen.
+Damit würde man nur 60 bit (pro Minute 1) = 8 byte RAM benötigen. Außerdem würden nur dann EEPROM-Zugriffe erfolgen, wenn tatsächlich zur aktuellen Minute Befehle vorliegen würden.

← Nächstältere Version		Version vom 6. Februar 2010, 21:37 Uhr
Zeile 52:		Zeile 52:
	Auch die Lösung mit dem dynamischen Cron ist mir nicht ganz recht, da ich im Idealfall mindestens 2x7 Schaltzeiten benötige (1 Woche Spät, 1 Woche Frühschicht im Wechsel + Wochenende).		Auch die Lösung mit dem dynamischen Cron ist mir nicht ganz recht, da ich im Idealfall mindestens 2x7 Schaltzeiten benötige (1 Woche Spät, 1 Woche Frühschicht im Wechsel + Wochenende).
	Dafür ist mir der RAM im ATMega zu knapp. Also müssen die Schaltbefehle in einen externen nichtflüchtigen Speicher verlagert werden, den ich im laufenden Betrieb ändern kann. Prädestiniert dafür wäre der 4Kbit High-Endurance-Block eines 24C65 I2C-EEPROMS, welcher laut Datenblatt ca. 10 Mio Schreibzyklen verträgt. Da dieser Block nur 512 Byte groß ist, müssten die auszuführenden Befehle (welche sich nur selten ändern) in einem anderen Bereich gespeichert werden. Nur die Schaltzeiten/Tage müßten im High-Endurance-Block stehen. 3-4 byte reichen zur Codierung der Schaltzeiten aus, wodurch sich mindestens 128 Schaltzeitpunkte speichern lassen. Das wäre mehr als ausreichend für meine Zwecke.		Dafür ist mir der RAM im ATMega zu knapp. Also müssen die Schaltbefehle in einen externen nichtflüchtigen Speicher verlagert werden, den ich im laufenden Betrieb ändern kann. Prädestiniert dafür wäre der 4Kbit High-Endurance-Block eines 24C65 I2C-EEPROMS, welcher laut Datenblatt ca. 10 Mio Schreibzyklen verträgt. Da dieser Block nur 512 Byte groß ist, müssten die auszuführenden Befehle (welche sich nur selten ändern) in einem anderen Bereich gespeichert werden. Nur die Schaltzeiten/Tage müßten im High-Endurance-Block stehen. 3-4 byte reichen zur Codierung der Schaltzeiten aus, wodurch sich mindestens 128 Schaltzeitpunkte speichern lassen. Das wäre mehr als ausreichend für meine Zwecke.
		+
		+	Ein Problem dabei könnte der (relativ) langsamge Zugriff auf den externen EEPROM sein. Also würde ich zu jeder Minute pro Stunde in der ein Befehl vorhanden ist paralell ein Eintrag im RAM speichern. Ich meine nur die Minute selbst. Der Controller fragt jede Minute im RAM ab ob ein entsprechender Eintrag vorhanden ist, wenn ja liest er die passende (fixe) Adresse im EEPROM, vergleicht Stunde, Monat, Tag, Wochentag und falls diese übereinstimmen springt er die Adresse mit dem auszuführenden Befehl an.
		+	Damit würde man nur 60 bit (pro Minute 1) = 8 byte RAM benötigen.

@@ Zeile 51: / Zeile 51: @@
 Nicht akzeptabel ist für mich, wegen jeder Änderung den Controller neu flashen zu müssen (begrenzte Flash-Zyklen, bei Verwendung des Bootloaders ist ein laufender Rechner notwendig).
 Auch die Lösung mit dem dynamischen Cron ist mir nicht ganz recht, da ich im Idealfall mindestens 2x7 Schaltzeiten benötige (1 Woche Spät, 1 Woche Frühschicht im Wechsel + Wochenende).
-Dafür ist mir der RAM im ATMega zu knapp. Also müssen die Schaltbefehle in einen externen nichtflüchtigen Speicher verlagert werden, den ich im laufenden Betrieb ändern kann. Prädestiniert dafür wäre der 4Kbit High-Endurance-Block eines 24C65 I2C-EEPROMS, welcher laut Datenblatt ca. 10 Mio Schreibzyklen verträgt. Da dieser Block nur 512 Byte groß ist, müssten die auszuführenden Befehle (welche sich nur selten ändern) in einem anderen Bereich gespeichert werden. Nur die Schaltzeiten/Tage müßten im High-Endurance-Block stehen.
+Dafür ist mir der RAM im ATMega zu knapp. Also müssen die Schaltbefehle in einen externen nichtflüchtigen Speicher verlagert werden, den ich im laufenden Betrieb ändern kann. Prädestiniert dafür wäre der 4Kbit High-Endurance-Block eines 24C65 I2C-EEPROMS, welcher laut Datenblatt ca. 10 Mio Schreibzyklen verträgt. Da dieser Block nur 512 Byte groß ist, müssten die auszuführenden Befehle (welche sich nur selten ändern) in einem anderen Bereich gespeichert werden. Nur die Schaltzeiten/Tage müßten im High-Endurance-Block stehen. 3-4 byte reichen zur Codierung der Schaltzeiten aus, wodurch sich mindestens 128 Schaltzeitpunkte speichern lassen. Das wäre mehr als ausreichend für meine Zwecke.