PIC16F688 EEPROM speichert nicht nach ausschalten

Hallo Mario,


Du beruecksichtigst schon, dass die EEPROM-Daten in Bank 1 liegen?


> allerdings sind meine Daten nach den Ausschalten immer
> weg,

Wie stellst Du das genau fest?


Was sagt der Emulator....werden die Daten in den EEPROM-Bereich 
abgelegt? Was passiert nach Reset im Emulator, sind die EEPROM Daten 
dort vorhanden?




Gruss

Michael

Hallo Michael,
hier mal ein Stück Code, mit dem es bei mir immer funktioniert:

  EEADR = 0;      //Adresse im EEProm
  EEDAT = Akku.low8;    //Wert, der ins EEProm soll

  WREN = 1;      //EEProm WRite ENable
  EECON2 = 0x55;      //unlock write
  EECON2 = 0xAA;      //unlock write
  WR = 1;        //write
  while(WR==1);      //warten bis WR wieder weg ist
  WREN = 0;      //EEProm Write disable


          //Korrekturwert aus EEProm lesen
  EEADR = 0;               //EEProm Adresse 0
  RD = 1;                  //lesen
  Delay1ms(1);        //etwas warten
    Korrektur=EEDAT;         //Korrekturwert auslesen

hth
Frank

Es kann sein, dass dein Compiler deine NOPs wegoptimiert, und du so das 
Timing nicht einhältst, nur so als Idee.

Gruß
Jens

Es wäre möglich, dass der Compiler hier eine Bankumschaltung dazwischen 
einfügt.

  EECON2 = 0x55;      //unlock write
  EECON2 = 0xAA;      //unlock write

Dann funktioniert das unlock nicht mehr.

@holger: Die Frage ist, für welchen Compiler die Codes sind, es sieht 
nach PICC aus.

Der PICC braucht im Code keine Bankanweisungen, daran kann es eigentlich 
nicht liegen.

Da liegt so ein komisches .pdf im Ordner des installierten Compilers... 
dürfte sich "manual" nennen. ;)

->


#include <htc.h>
void eetest(void) {
unsigned char value = 1;
unsigned char address = 0;
// write value to EEPROM address
eeprom_write(address, value);
// read from EEPROM at address
value = eeprom_read(address);
}

These functions test and wait for any concurrent writes to EEPROM to 
conclude before performing the required operation. The eeprom_write() 
function will initiate the process of writing to EEPROM and this process 
will not have completed by the time that eeprom_write() returns. The new 
data written to EEPROM will become valid approximately four milliseconds 
later. In the above example, the new value will not yet be ready at the 
time when
eeprom_read() is called; however, because this function waits for any 
concurrent writes to complete before initiating the read, the correct 
value will be read. It may also be convenient to use the preprocessor 
symbol, _EEPROMSIZE, in conjunction with some of these access methods. 
This symbol defines the number of EEPROM bytes available for the 
selected chip.

Irgendwie kommt mir das komisch vor. Du Stellst deine ADC-Kofig ein, 
OSC, TRIS-Register und so weiter. Aber das erste, was du mit dem EEPROM 
machst, ist es zu beschreiben. Wenn du den PIC startest und RC3 ist auf 
low, schreibt er eine 0 ins EEPROM und danach ließt du die 0 wieder aus 
und die LED leutet folglich nicht.

Du musst nach der Konfig erstmal den Wert lesen, wenn der 1 ist, die LED 
anschalten und dann leutet diese auch. Dann darfst du danach nicht aber 
gleich wieder die EEPROM-Adresse mit der 0 überschreiben, wenn dein RC3 
auf 0 ist.

Also lesen, LED ggf. setzen und dann hätte ich ein Polling gemacht. Eine 
Taste setzt den Wert im EEPROM und eine andere Taste löscht den Wert. 
Dann sollte es eigentlich funktionieren


Mario schrieb:
> dass der PIC nach ausschalten die Daten auf dem EEPROM nicht speichert
> besteht leider immer noch

Ich weiß wie du das meinst, aber korrekt ist es, dass man wärend dem 
Durchlauf speichert, er die Daten aber auch ohne Strom halten kann. 
Speichern tut er nicht, wenn er aus is, das passiert vorher.



edit: Ganz abgesehen davon gehört ansich in jedes C-Programm für µCs 
eine Endlosschleife, meist nach der Konfiguration. Bei deinem Programm 
ist es im Moment so, dass, wenn deine Konfig abgeschlossen ist und du 
den Wert ins EEPROM schreibst und danach wieder liest, ist das Programm 
vorbei. ggf startet der PIC dann wieder neu, schreibt wieder die Konfig 
usw..

Mein Plan wäre so:

main(){
//Initialisierung
//EEPROM-Wert lesen, evtl LED an
while(1){
//RC3 gedrückt? Wenn ja, 1 ins EEPROM speichern
//RC4 gedrückt? Wenn ja, 0 ins EEPROM speichern
//EEPROM lesen, LED an- bzw. ausschalten
}
}

Ich kenn mir ehrlich gesagt nicht so mit dem Hi-Tech-Compiler aus, aber 
ich dachte immer, das der halt C übersetzt. Und in C muss man doch 
eigentlich Variablen inklusive Datentyp definieren, oder? Woher weiß der 
Compiler, dass EE_DATA eine Variable ist, und welchen Typ er besitzt, 
also char oder int z.B. .
Und woher weiß der Compiler, dass der bei "ROT = AN", die LED anschalten 
soll? RC0 ist ja als ROT definiert, aber woher weiß er, dass AN "1" 
bedeutet? Wie gesagt, vielleicht ist das da ja eine Eigenheit, aber 
kommt mir irgendwie komisch vor.

Mario schrieb:
> Ich befürchte eher, dass die Daten auf dem EEPROM aufgrund irgendwelcher
> Einstellungen nicht gespeichert werden/verloren gehen, nicht wegen des
> Quelltextes.

Ich denke eher es liegt am Aufbau vom Programm:

Michael Skropski schrieb:
> Aber das erste, was du mit dem EEPROM
> machst, ist es zu beschreiben. Wenn du den PIC startest und RC3 ist auf
> low, schreibt er eine 0 ins EEPROM und danach ließt du die 0 wieder aus
> und die LED leutet folglich nicht.
>
> Du musst nach der Konfig erstmal den Wert lesen, wenn der 1 ist, die LED
> anschalten und dann leutet diese auch. Dann darfst du danach nicht aber
> gleich wieder die EEPROM-Adresse mit der 0 überschreiben, wenn dein RC3
> auf 0 ist.
>
> Also lesen, LED ggf. setzen und dann hätte ich ein Polling gemacht. Eine
> Taste setzt den Wert im EEPROM und eine andere Taste löscht den Wert.
> Dann sollte es eigentlich funktionieren

Ob dein Ausgang die LED bei 0 oder 1 anschaltet ist ja egal. Fakt ist, 
du schreibst die EEPROM-Zelle, bevor du sie ausliest. Das ist auch nach 
dem Starten des PICs so. D.h. bevor du die Chance hast, den 
gespeicherten Wert auszulesen, überschreibst du ihn schon wieder.

Achso, jetzt versteh ich! Is ja logisch. Aber draufgekommen wär ich 
net...

Also das Programm geht dann natürlich auch!! Super, vielen Dank, war 
schon ganz kurz vorm verzweifeln!!