Atmega 328p uint16_t auf EEPROM per SPI geht nicht

[Andy (Gast)]

Hallo zusammen,

bin noch ziemlich neu in der Microcontrollerwelt und möchte ein EEPROM 
(25LC640A) mit einem uint16_t Wert beschreiben und wieder auslesen.

Ich benutzt ein Atmega 328p und das ganze soll über SPI ablaufen. 
Sprache wäre C.

Was bereits funktioniert:

SPI_init klappt...

Kann auch ohne Probleme eine uint8_t Wert auf ein beliebige Adresse 
schreiben und wieder auslesen...

Was nicht funktioniert:

Jedoch sobald ich uin16_t versuche kommt auf dem LCD nur Käse raus. Bin 
schon ziemlich am verzweifeln woran das liegen könnte. Hoffe ihr habt 
eine Idee. Wahrscheinlich ist es nur ein Anfänger oder Verständnis 
Fehler.

Hier mein Code fürs schreiben und lesen:

/* einfache Funktion, um via SPI zu lesen und zu schreiben */
unsigned char spi_transfer(unsigned char data)
{
    SPDR = (unsigned char) data;              //SPI Data Register transmit
    while (!(SPSR & (1<<SPIF)));              //SPI Status Register, SPI Interrupt Flag wait for transmission complete
    return SPDR;                              //SPI Data Register return received data 
}

///////////////////////////////////////
// uint_16_t auf eeprom schreiben
/////////////////////////////////////////

// Adresse in die geschrieben werden soll
uint16_t adresse = 0;
// Daten die geschrieben werden sollen
uint16_t data_schreiben = 1234;

//CS auf low
spi_cs(0);
// Schreibvorgang einleiten
spi_transfer(WREN);
// CS auf high
spi_cs(1);
//wartezeit CS
_delay_us(1);
//CS auf low
spi_cs(0);

// Adresse fürs schreiben in MSB und LSB
//Schreibmodus aktivieren
spi_transfer(WRITE);
// Schreibadresse für MSB
spi_transfer((unsigned char) adresse>>8);
// Schreibadresse für LSB
spi_transfer((unsigned char) adresse);

        //transmit data MSB
        spi_transfer((unsigned char) data_schreiben>>8);
        //transmit data LSB
        spi_transfer((unsigned char) data_schreiben);

// schreibvorgang übermitteln
spi_cs(1);
// 5 ms Wartezeit für Schreibvorgang
_delay_ms(5);
// CS auf low
spi_cs(0);
// Schreibmodus verlassen
spi_transfer(WRDI);
// CS auf high
spi_cs(1);
// Wartezeit CS
_delay_us(1);

//schreiben ist ab hier abgeschlossen
////////////////////////////////////////////////////
/// EEPROM lesen
//////////////////////////////////////////////////

// Adresse aus der gelesen werden soll
uint16_t adresse = 0;
uint16_t data_auslesen = 0;


/** read msb + lsb**/
// CS auf low
spi_cs(0);
// In Lesemodus wechseln
spi_transfer(READ);
// Schreibadresse für MSB
spi_transfer((unsigned char) adresse>>8);
// Schreibadresse für LSB
spi_transfer((unsigned char) adresse);
// Eine Null wird als Dummy benutzt und der Wert des EEPROMs ausgelesen.
// Der wird wird der Variablen Ausgelesener_Wert_EEPROM überschrieben.

 //read data LSB by dummy transmission
data_auslesen = data_auslesen + (spi_transfer(0)<<8); 
//read data MSB by dummy transmission
data_auslesen = data_auslesen + spi_transfer(0);

Danke schon einmal.

[Apollo M. (Firma: @home) (majortom)]

Andy schrieb:
> Kann auch ohne Probleme eine uint8_t Wert auf ein beliebige Adresse
> schreiben und wieder auslesen...

... glaube ich nicht, da du nicht das page-weise Write beachtet hast.

Andy schrieb:
> einem uint16_t Wert beschreiben und wieder auslesen

... du must den Datentyp selber unterstützen, also hier 2x read/write 
byte und das int korrekt darauf abbilden via z.B. union Definition.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andy schrieb:
> Hoffe ihr habt eine Idee.

//CS auf low
spi_cs(0);

// Adresse fürs schreiben in MSB und LSB
//Schreibmodus aktivieren
spi_transfer(WRITE);
// Schreibadresse für MSB
spi_transfer((unsigned char) adresse>>8);
// Schreibadresse für LSB
spi_transfer((unsigned char) adresse);

        //transmit data MSB
        spi_transfer((unsigned char) data_schreiben>>8);
        //transmit data LSB
        spi_transfer((unsigned char) data_schreiben);

// schreibvorgang übermitteln
spi_cs(1);

Kann dein EEPROM diese Kommandofolge?
Ist das Kommando WRITE für mehr als 1 Byte geeignet?

> Hier mein Code fürs schreiben und lesen
Da bitte künftig selber die [c] Tags drumrum machen, wie über jeder 
Eingabebox bei "Wichtige Regeln - erst lesen, dann posten!" beschrieben.

[Andy (Gast)]

Ok ohne die Page zu beachten, könnte in meinem Fall bei unbedachter Wahl 
der Adresse ein überlauf entstehen. oder?

Aber wie bildet ich das ab mit 2 mal read / write? Muss ich vorher die 
unint16_t in 2 x 8 teilen? und dann erst übertragen und lesen und wieder 
zusammen setzen?

Wenn ja dann wie?

Danke im schon einmal.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andy schrieb:
> Ok ohne die Page zu beachten, könnte in meinem Fall bei unbedachter Wahl
> der Adresse ein überlauf entstehen. oder?
Ja. Ist beim code hier aber nicht der Fall. Denn du schreibst ja nur 2 
Byte am Anfang von Page 0.

> Aber wie bildet ich das ab mit 2 mal read / write? Muss ich vorher die
> unint16_t in 2 x 8 teilen? und dann erst übertragen und lesen und wieder
> zusammen setzen?
Tust du ja eh' schon, müsste also gehen.

Andy schrieb:
> Kann auch ohne Probleme eine uint8_t Wert auf ein beliebige Adresse
> schreiben und wieder auslesen...
>
> Was nicht funktioniert:
> Jedoch sobald ich uin16_t versuche kommt auf dem LCD nur Käse raus.
Im Code oben ist kein LCD involviert.
Und was kommt heraus, wenn du das 16-Bit Wort so schreibst, wie oben 
dargestellt, dann aber ein Byte von Adresse 0 liest und das als char 
darstellst, und danach das Byte von Adresse 1 liest und als char 
darstellst?

Oder was passiert, wenn du diese beiden Bytes nacheinander einzeln 
schreibst und dann als 16-Bit-Wort ausliest?

[jo mei (Gast)]

Wenn ich meinen Universal-EEPROM-Code so anschaue dann muss das
Schreiben auf ein solches serielles EEPROM etwas differenzierter
geschehen.

- STATUS lesen
- Wenn Block Protection Bits gesetzt sind, diese löschen
- Wenn nicht dann ohne Löschen weiter

Dann erst Write Enable setzen, dann Daten schreiben.

Die Block Protection Bits muss man wohl nicht immer neu
löschen, möglicherweise würde durch dauerndes Löschen
diese eine Zelle (Register) langsam vorzeitig
verschlissen werden.

Aber mit gesetzten Block Protection Bits wird man das
EEPROM nicht beschreiben können .....

[Andy (Gast)]

Danke erstmal für eure Antworten!

Ich lese am Anfang das Statusregister aus, um zu schauen ob die 
Anschlüsse alle funktionieren. Das geht also. Was du weiter mit den 
"Block Proctection Bits" meinst weiß ich leider nicht. (-> Verweis auf 
Anfänger)

>Im Code oben ist kein LCD involviert.

Den Part hab ich nicht mit veröffentlich, da ich nicht wollte, dass der 
Code zulange wird den ich hier poste.

>Und was kommt heraus, wenn du das 16-Bit Wort so schreibst, wie oben dargestellt, 
dann aber ein Byte von Adresse 0 liest und das als char darstellst, und danach das 
Byte von Adresse 1 liest und als char  darstellst

ok hab folgendes probiert:

Hab den Wert "1234" als uint16_t auf Adresse (0) geschrieben. Danach 
über meine funktionierende spi_read_uint8_t () Funktion ausgelesen. 
Kommt 210 auf dem LCD raus. Da ja 1234 Dezimal = 0000 0100 1101 0010 
Binär sind und das LSB hier ja genau 210 ist sollte das passen. Der Wert 
wird in Adresse (1) angezeigt

Jedoch steht in Adresse (0) beim auslesen der Wert 0 auf dem LCD.

Beschreibe ich eine uint8_t nochmals auf Adresse (0) mit einem 
beliebigen Wert z.B.: 99 wird dieser auch korrekt ausgelesen.
Dieser müsste ja jetzt auf dem EEPROM dauerhaft gespeichert werden.

Benutzte ich jetzt nochmals meinen wirte uint16_t Code zeigt mir das LCD 
wieder die 210 in Adresse (1) und 0 in Adresse (0) angezeigt.

Sollte aber eigentlich eine 4 rauskommen, da der vordere Teil der 
geteilten 16 Bits ja 0000 0100 = 4 sein sollte.

[jo mei (Gast)]

Andy schrieb:
> Was du weiter mit den
> "Block Proctection Bits" meinst weiß ich leider nicht.

RTFM!

Einfach mal Datenblatt lesen. Wenn du das nicht willst dann
mach irgendwas anderes. Aber nicht EEPROM programmieren.

[Andy (Gast)]

Ich weiß was eine Page Protection ist. Jedoch versteh ich nicht was das 
hiermit zu tun hat. (das mein ich mit Anfänger)

Aber Page Protection ist nicht an. Sonst würde das beschreiben mit einem 
uint8_t Wert auf Adresse (0) oder (1) nicht funktionieren.

Oder stehe ich gerade auf dem Schlauch.

Und Ja ich hab das Datenblatt gelesen. Sonst wüsste ich ja nicht wie ich 
CS high oder low setzen sollte etc.

[Andy (Gast)]

Ssooo danke erstmal an Lothar!

Hast mich auf die richtige Spur gebracht. Konnte den Fehler immer mehr 
eingrenzen. Hat jetzt geklappt.

Lag wirklich am schreiben und nicht an der lese Funktion.

Warum auch immer geht die Bit-Manipulation nicht in der Zeile:
   >     spi_transfer((unsigned char) data_schreiben>>8);

hab somit vorher die "Data" Werte in MSB und LSB aufteilen müssen.
Am Ende alles in eine Funktion / Libarry ausgelagert.

uint16_t spi_eeprom_lesen_uint16_t (uint16_t adresse)
{

uint16_t data_auslesen = 0;

if (adresse < 8192)
    {

// CS auf low
spi_cs(0);
// In Lesemodus wechseln
spi_transfer(READ);
// Schreibadresse für MSB
spi_transfer((unsigned char) adresse>>8);
// Schreibadresse für LSB
spi_transfer((unsigned char) adresse);
// Eine Null wird als Dummy benutzt und der Wert des EEPROMs ausgelesen.
// Der wird der Variablen Ausgelesener_Wert_EEPROM überschrieben.

 //read data LSB by dummy transmission
data_auslesen = data_auslesen + (spi_transfer(0)<<8);
//read data MSB by dummy transmission
data_auslesen = data_auslesen + spi_transfer(0);


//Um 2 mal hinter einander auszulesen muss cs auf high gesetzt werden
    // CS auf high
    spi_cs(1);
    // Wartezeit CS
    _delay_us(1);
    }

    // Der Rückgabewert data_auslesen wird aus der Funktion ausgegeben.
    return data_auslesen;

// auslesen EEPROM abgeschlossen

}

danke nochmal für die Hilfe!

[Andy (Gast)]

ups sorry meine Fehler...

Falsche Funktion wollte die write posten. Naja vielleicht helfen der 
Nachwelt somit beide.

Hier nochmal die Schreibfunktion:

// einen uint16_t Wert als Daten auf das EEPROM schreiben
void spi_eeprom_schreiben_uint16_t (uint16_t adresse, uint16_t daten)
{

    if (adresse < 8192)
    {

    // uint_16_t auf eeprom schreiben

// Data wird in MSB und LSB aufgteilt
// Das MSB von Data
uint8_t msb = daten >> 8;
// Das LSB von Data
uint8_t lsb = daten & 0xFF;

//CS auf low
spi_cs(0);
// Schreibvorgang einleiten
spi_transfer(WREN);
// CS auf high
spi_cs(1);
//wartezeit CS
_delay_us(1);
//CS auf low
spi_cs(0);

// Adresse fürs schreiben in MSB und LSB
//Schreibmodus aktivieren
spi_transfer(WRITE);
// Schreibadresse für MSB
spi_transfer((unsigned char) adresse>>8);
// Schreibadresse für LSB
spi_transfer((unsigned char) adresse);

        //transmit data MSB
        spi_transfer((unsigned char) msb);
         //transmit data LSB
        spi_transfer((unsigned char) lsb);

// schreibvorgang übermitteln
spi_cs(1);
// 5 ms Wartezeit für Schreibvorgang
_delay_ms(5);
// CS auf low
spi_cs(0);
// Schreibmodus verlassen
spi_transfer(WRDI);
// CS auf high
spi_cs(1);
// Wartezeit CS
_delay_us(1);
}
//schreiben ist ab hier abgeschlossen
}

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andy schrieb:
> Ssooo danke erstmal an Lothar!
Keine Ursache.

> Hast mich auf die richtige Spur gebracht.
Wenn immmer möglich sollte man bei der Fehlersuche das "Teile und 
Herrsche" Prinzip anwenden und versuchen, das "große Problem" in 
einzelne "kleine Probleme" zu zerlegen.

> Konnte den Fehler immer mehr eingrenzen.
Aber du hast ihn noch nicht gefunden, sondern einen windigen 
"Workaround" gebastelt. Denn der eigentliche Fehler liegt da:
> Warum auch immer geht die Bit-Manipulation nicht in der Zeile:

spi_transfer((unsigned char) data_schreiben>>8);

Das würde ich an deiner Stelle genauer anschauen. Du lernst dabei fürs 
Leben  ;-)

> geht die Bit-Manipulation nicht
Klar, denn der Compiler beachtet keine Whitespaces bzw. die 
Textformatierung. Wenn du mit dem Leerzeichen im Code:

(unsigned char) data_schreiben>>8

auch gern das gehabt hättest:

(unsigned char) (data_schreiben>>8)

also: zuerst wird geschoben und dann abgeschnitten,
sieht der Compiler trotzdem das:

((unsigned char)data_schreiben) >> 8

Merkst du was?
Hier werden zuerst die 8 "oberen" Bits von data_schreiben 
abgeschnitten und dann die unteren 8 Bits rausgeschoben.
Übrig bleibt 0.

Und dass genau der selbe Code dort "funktioniert" hat:

spi_transfer((unsigned char) adresse>>8);

liegt einfach daran, dass du bisher nur in den unteren 256 Bytes des 
EEPROMs herumwerkelst und die "oberen Bits" sowieso 0 sind.

Also mach mal das, dann geht es auch mit dem Code ganz oben:

spi_transfer((unsigned char)(adresse>>8));
...
spi_transfer((unsigned char)(data_schreiben>>8));

Stichwort dazu: Priorität von Operanden und Casts.

[Andy (Gast)]

Haaa.... Darauf wäre ich nie gekommen. Im Nachhinein logisch. Vielen 
Dank nochmal!