Forum: Mikrocontroller und Digitale Elektronik EEPROM 25LC1024 an ATmega8


von Stefan W. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Forum,

für eine private Anwendung möchte ich einen AVR Controller (ATmega8) mit 
einem seriellen EEPROM (Microchip 25LC1024) über SPI verbinden. Um dies 
zu realisieren habe ich die jeweiligen Datenblätter studiert und die 
"Geräte" verdrahtet. Dann habe ich mich ebenfalls nach Studium der 
Datenblätter und diverser Forenbeiträge an die Entwicklung des Programms 
gemacht. Der Code wurde in C geschrieben und mit AVR Studio 5 
kompiliert. Ziel des Programms ist es ein Byte (hier Zahl 15) an eine 
feste Adresse im EEPROM zu schreiben und dieses dann wieder auszulesen. 
Als Kontrolle ob dieser Vorgang geklappt hat, wird das ausgelesende Byte 
über RS232 an meinen PC gesendet. Der Teil der RS232 Kommunikation 
funktioniert einwandfrei. Probleme gibt es mit der Kommunikation mit dem 
EEPROM. Ich benutze dazu das Hardware SPI des ATmega 8. Dabei habe ich 
die Anschlüsse des EEPROMs folgendermaßen mit denen des AVRs verbunden:

ATmega8:  25LC1024:
PB5 (SCK) -> SCK
PB4 (MISO) -> SO
PB3 (MOSI) -> SI
PB2 (SS) -> CS

Weiterhin sind beim EEPROM VCC, HOLD und WP an +5V und VSS an GND 
gelegt.
Die Länge der Verbindungen beträgt max. 2cm.

Als Clockfrequenz habe ich den internen RC-Oszillator des Controllers 
mit 1MHz verwendet.

Als Auslesewert erhalte ich immer 255 zurück, auch dann wenn ich statt 
eines Datenbytes das Statusregister auslesen möchte.

Im Anhang befindet sich mein Source Code und das Datenblatt des EEPROMs.

Vielleicht findet jemand, der schon Erfahrung mit diesen Speichern hat, 
sofort einen Fehler im Programmcode.

Für Tipps und Ratschäge wäre ich sehr dankbar.

Beste Grüße

Stefan W.

: Verschoben durch Moderator
von Klaus (Gast)


Lesenswert?

Stefan W. schrieb:
> Für Tipps und Ratschäge wäre ich sehr dankbar.

Mein Tipp: Lesen lernen.

Insbesondere die Überschrift für dieses Unterforum:
> Wie findet ihr diese Website, was würdet ihr verbessern?

von Michael H. (michael_h45)


Angehängte Dateien:

Lesenswert?

Du lässt zwischen den einzelnen zu sendenden Bytes die CS-Leitung nicht 
durchgehend aktiv.
Siehe Anhang: du musst 5 Bytes senden, währenddessen die CS-Leitung 
dauernd low ist.

P.S.: falsches Unterforum.

von Stefan W. (Gast)


Lesenswert?

Klaus schrieb:
> Mein Tipp: Lesen lernen.

Das ist mein erster Thread in diesem Forum. Ich bitte daher um 
Nachsicht. Beim nächsten Mal werde ich darauf achten.

(Mod: Thread nach µC & Elektr. verschoben)

von Stefan W. (Gast)


Lesenswert?

Michael H. schrieb:
> Du lässt zwischen den einzelnen zu sendenden Bytes die CS-Leitung nicht
> durchgehend aktiv.

Die Funktion ByteWriteSPI setzt doch am Anfang CS auf Low und sendet 
dann die 5 Datebytes mit Hilfe von WriteSPI(). Diese Funktion verändert 
doch nichts am CS, oder sehe ich das falsch. CS wird aoch erst nach 
Abschluss der Datenübertragung wieder auf High gezogen.

Oder meintest du etwas anderes?

Gruß

Stefan

von grml (Gast)


Lesenswert?

Stefan W. schrieb:
> Für Tipps und Ratschäge wäre ich sehr dankbar.

grml... das ist sicher nicht der originale code.
das, was da im anhang ist, ist nämlich nicht kompilierbar.

von Michael H. (michael_h45)


Lesenswert?

Stefan W. schrieb:
> Oder meintest du etwas anderes?
Nein, du hast schon Recht. Da hab ich mich auf die schnelle verschaut.
1
ByteWriteSPI(H_Add,L_Add,test);   //Variable test an Test Adresse schreiben
2
...
3
  out = ByteReadSPI(H_Add,L_Add);  //Byte an Test Adresse auslesen
Wo ist das mittlere Adress-Byte?

Ist das wirklich der code, den du benutzt? Da müsste es Warnings und 
Errors beim Compilieren hageln. Denn außerdem ist eeprom.h nicht in 
deiner AVR_SPI_EEPROM.c eingebunden.

von Stefan W. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Michael,

ja das war leider eine alte Version des Codes. Ich habe die neue in den 
Anhang gelegt (Projekt gesamt). Entschuldigung für die Umstände.

Gruß Stefan

von Michael H. (michael_h45)


Lesenswert?

Das schaut schon besser aus.

Aber compiliert das bei dir ohne Warnings?

Deine eeprom.h musst du (für ANSI-C zumindest) anders schreiben.
1
unsigned char ReadSPI(void);
2
void WriteSPI(unsigned char);
3
unsigned char ReadStatus(void);
4
void WriteEnable(void);
5
void WriteDisable(void);
6
void SPIWIPPolling(void);
7
void ByteWriteSPI(unsigned char, unsigned char, unsigned char, unsigned char);
8
unsigned char ByteReadSPI(unsigned char, unsigned char, unsigned char);
Habs bei mir gerade mit einem 25LC1024 und dieser eeprom.h getestet und 
da funktionierts.

von Stefan W. (Gast)


Lesenswert?

Hallo Michael,

ja komischerweise kompiliert das Projekt bei ohne Warnngs. (Nur der 
Hinweis, das die Compiler Optimierung derzeit deaktiviert ist).

Ich werde deine Änderungen für das h-File morgen früh ändern und es dann 
nochmal probieren.

Benutzt du auch den internen AVR Takt und die selbe Verdrahtung?

Wenn mein Code bei dir nach der Änderung so läuft, wäre das ja 
wunderbar.

Gruß

Stefan

von Stefan W. (Gast)


Lesenswert?

Hallo Michael,

das geänderte h-File war die Lösung. Nochmals vielen Dank für deine 
Hilfe.

Noch eine abschließende Frage:

Aus dem Datenblatt des Speichers habe ich entnommen, dass ein 
"Page-Write" automatisch generiert wird, sobald bei einem 
Byte-Schreibvorgang mehr als ein Datenbyte gesendet wird. Das bedeutet 
also, wenn ich sicher sein will, dass die gesendeten Bytes auf jedenfall 
fest weggepeichert sind, muss ich nur beim letzten Schreibzugriff ein 
Dummy Byte hinzufügen und die aktuelle Page wird geschrieben, egal ob 
die Pagegröße noch nicht erreicht wurde.

Ist das soweit richtig, oder mache ich da vielleicht einen Denkfehler?


Gruß

Stefan W.

von Michael H. (michael_h45)


Lesenswert?

Stefan W. schrieb:
> das geänderte h-File war die Lösung. Nochmals vielen Dank für deine
> Hilfe.
Gerne. Allerdings finde ich es schon sehr komisch, dass dein Compiler 
trotz -Wall und -std=gnu99 da keine Warnungen bring.
Macht er das auch nicht bei Aufruf von "make clean" und dann "make all"?


Stefan W. schrieb:
> Aus dem Datenblatt des Speichers habe ich entnommen, dass ein
> "Page-Write" automatisch generiert wird, sobald bei einem
> Byte-Schreibvorgang mehr als ein Datenbyte gesendet wird. Das bedeutet
> also, wenn ich sicher sein will, dass die gesendeten Bytes auf jedenfall
> fest weggepeichert sind, muss ich nur beim letzten Schreibzugriff ein
> Dummy Byte hinzufügen und die aktuelle Page wird geschrieben, egal ob
> die Pagegröße noch nicht erreicht wurde.
Der Schreibvorgang erfolgt immer Page-weise. Das heißt, dass jede 
angefangene Page immer komplett geschrieben wird.
Darum kümmert sich der Speicher aber intern selbst, da brauchst du 
nichts extra einzubauen.

von Stefan W. (Gast)


Lesenswert?

Hallo Michael,

danke für deine Antwort.

Bezüglich des Compilers:
Nein leider lässt sich der Compiler auch dann nicht zu einer Warnung 
überreden. Es funktioniert jedoch auf einem anderen Computer, weshalb 
ich vermute, dass die Installation von AVR Studio auf dieser Maschine 
fehlerhaft ist. Deshalb werde ich die Software hier einmal neu 
installieren.

Freundliche Grüße

Stefan W.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.