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
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?
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.
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)
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
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.
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.
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
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.
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
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.