PIC und Speicherzustand

Hallo! Anfängerfrage: Ich habe erfolgreich jetzt mein Proggi für das umschalten zwischen zwei Lampen (A+B) mit einem PIC16F8.. realisiert. Beim Einschalten der Steuerspannung brennt Lampe A, bei kurzem Tastendruck dann Lampe B. wenn ich die Steuerpannung ab und wider einschalte brennt natürlich wieder Lampe A. Ok. Frage: wie kann ich das programmieren, dass der letzte Schaltungszustand so wie "abgespeichert" wird, und beim wieder anlegen der Steuerspannung geladen wird?

Gruß Lennart

Reply to
Lennart Widhalm
Loading thread data ...

Lennart Widhalm schrieb:

Man nutze das eingebaute EEPROM.

Gruß Dieter

Reply to
Dieter Wiedmann
  • Lennart Widhalm [2006-04-29 19:31]:

Du brauchst irgendeinen persistenten Speicher. Hat dein PIC ein EEPROM? Da könnte man das drin ablegen.

Reply to
Lars Noschinski

"Lars Noschinski" schrieb im Newsbeitrag news: snipped-for-privacy@lars.home.noschinski.de...

Da müsste dann noch berücksichtigt werden, dass das EEPROM nur eine begrenzte Zahl von Schreibzyklen zulässt.

Eventuell ist es günstiger, den PIC in einen Sleep-Modus zu versetzen, oder so langsam zu takten, dass der Stromverbrauch so gering wird, dass eine ausreichend lange Pufferung mit einem kleinen Akku erreicht wird. Den Zustand kannst du dann einfach in einem Register speichern.

Gruß

Stefan

Reply to
Stefan Brroering

Danke mal für die Tip's, hat jemand einen WWW.Link, wie so etwas "programmtechnisch" erklärt wird? Lennart

Reply to
Lennart Widhalm

Lennart Widhalm schrieb:

formatting link
da gibts sogar Application Notes, sogar ganz viele.

Gruß Dieter

Reply to
Dieter Wiedmann

Sollten die spezifizierte Schreibzyklen nicht ausreichen, dann kann auch jedesmal ein anderes EEPROM-Byte zur Speicherung des aktuellen Zustandes benutzt werden.

MfG Martin

Reply to
Martin Konopka

Oder man nehme ein PCF8570 256 Byte i2c RAM, das man entweder per Goldcap oder Lithiumzelle puffert.

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

Frank-Christian Kruegel schrub:

Mann, wieso muss man eigentlich heutzutage immer derart mit Kanonen auf Spatzen schießen... 256 Byte, um ein einziges Bit zu speichern... OK, man will ja erweiterbar bleiben...

SCNR

Ansgar

--
Mails an die angegebene Adresse erreichen mich - oder auch nicht! Gültige  
Adresse gibt's bei Bedarf!
Mails to the given address may or may not reach me - valid return address  
will be given when required!
Reply to
Ansgar Strickerschmidt

Am Tue, 2 May 2006 06:36:34 UTC schrieb "Martin Konopka" :

Und wie/wo merkst Du Dir, welche EEPROM-Zelle grade dran ist? Das funktionert nur, wenn es (mindestens) einen Wert gibt. der nie abgespeichert wird. Den kann man dann in die gerade nicht benutzten EEPROM-Zellen schreiben.

Ich hab leider den Anfang dieser Diskussion verpasst, vielleicht gibt's diese(n) Wert(e) ja ...

Ade

Reinhard

--
Dipl-Ing. Reinhard Forster        Software-Entwicklung         
Mikroprozessor-Anwendungen        D-89075 Ulm
Reply to
Reinhard Forster

"Stefan Brroering" :

... die typischerweise in der Größenordung von 1 bis 10 Mio liegt. Wenn der Schalter an 200 Arbeitstagen im Jahr jeweils 1000 mal betätigt wird, reicht das für 5 Jahre.

Oder das Ein/Ausschalten über den Prozessor steuern, so daß vor dem Ausschalten noch housekeeping-Routinen laufen können. Dann muß nur einmal beim Ausschalten gespeichert werden, statt bei jedem Zustandswechsel. Noch eine Variante besteht darin, die Zahl der Schreibvorgänge zu beschränken, indem ein Zustandswechel nur dann im EEprom gespeichert wird, wenn der Zustand eine Weile angedauert hat. Ob das akzeptabel ist, hängt allerdings davon ab, was genau geschaltet wird.

--
Wir danken für die Beachtung aller Sicherheitsbestimmungen
Reply to
Wolfgang Strobl

Hallo Reinhard,

Dein Argument verstehe ich leider nicht.

Mit folgender Strategie kannst Du z.B. 7 Bit in einem Byte speichern:

1) Jungfräuliches EEPROM komplett nullen. 2) Beim ersten Speicherdurchlauf jeweils Bit 7 auf "1" setzen, die Bits 0...6 sind Nutzdaten. Es wird immer das Byte mit der niedrigsten Adresse beschrieben, dessen Bit 7 "0" ist. 3) Ist im kompletten Speicher das Bit 7 auf "1" gesetzt, dann ab der ersten Speicheradresse beim überschreiben das Bit 7 auf "0" setzen. 4) Der Vorgang wiederholt immer wieder mit abwechselnd gesetztem Bit 7 auf "1" oder "0".

Das zuletzt geschriebene Byte ist immer das mit der höchsten Adresse von dem Signalwechsel bei Bit 7. Gibt es im gesamten Speicher keinen Signalwechsel bei Bit 7, so ist das Byte mit der höchsten Adresse das zuletzt geschriebene.

Diese Strategie läßt sich je nach Art des Speichers und der Nutzdaten beliebig abwandeln.

Viel Spaß damit, Martin

Reply to
Martin Konopka

Am Mon, 8 May 2006 06:42:53 UTC schrieb "Martin Konopka" :

Hallo Martin!

Ist genau das Verfahren, das ich gemeint habe: alle Werte < 128 sind ungültig. So lange nur sieben Bits pro Byte gespeichert werden ist das kein Problem.

Eine andere Möglichkeit wäre, vor dem Schreiben die erste EEPROM-Zelle mit Inhalt = 0xff zu suchen und den neuen Wert da rein zu schreiben. beim Auslesen wird die letzte EEPROM-Zelle mit Inhalt != 0xff gesucht. Wenn keine freie Zelle mehr gefunden wird, muss das ganze EEPROM wieder gelöscht werden.

Das funktioniert aber nur, wenn der Wert 0xff niemals als zu speicherndes Datum vorkommt.

Ade

Reinhard

--
Dipl-Ing. Reinhard Forster        Software-Entwicklung         
Mikroprozessor-Anwendungen        D-89075 Ulm
Reply to
Reinhard Forster

Hallo Reinhard,

ganz ohne einen eindeutigen Hinweis (der leider auch Speicherplatz benötigt) auf das aktuelle Byte geht es natürlich nicht. Die beste Lösung richtet sich nach den Eigenschaften der zu speichernden Information. Lösungsmöglichkeiten gibt es jedenfalls genug.

MfG Martin

Reply to
Martin Konopka

Am Mon, 8 May 2006 09:24:57 UTC schrieb "Martin Konopka" :

Hallo Martin!

Dann sind wir uns ja einig.

Ich hab halt mal gesehen, dass jemand zur Schonung der EEPROM-Zellen die Werte jedesmal auf andere Adressen schreiben wollte - und dann in der ersten EEPROM-Zelle (Adresse 0) bei jedem (!) Schreibvorgang einen Offset eingetragen hätte ...

Ade

Reinhard

--
Dipl-Ing. Reinhard Forster        Software-Entwicklung         
Mikroprozessor-Anwendungen        D-89075 Ulm
Reply to
Reinhard Forster

Umpfff!

Solche Ideen sind sehr gut, solange sie vom Wettbewerber eingesetzt werden und man hoffentlich nie etwas mit diesem Produkt zu tun bekommt.

MfG Martin

Reply to
Martin Konopka

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.