Zugriff auf SD-Karte mit Atmega168

[Flo W. (Gast)]

Hallo!

möchte Daten von einem Atmega168 auf eine SD schreiben. Hatte zuerst 
mein Programm auf einem Atmega8 laufen, da hat alles funktioniert. Ich 
verwende für die SD-Karte und für FAT16 den Code von Ulrich Radig (siehe 
Anhang). Mein Programm hängt sich beim Initialisieren der SD-Karte auf, 
d. h. der Controller wird ständig "resetet". Es steht in meinem 
Hauptprogramm Folgendes:

  if((mmc_init() != 0) || (InitFat16() != 0)) {
    lcd_write("keine SD-Karte");
  }

In mmc.h fehlte bei "#if defined" ein Eintrag für den Atmega168, daher 
habe ich den Abschnitt vom Atmega8 kopiert (siehe Kommentar im Code), da 
bei beiden ja die gleiche Pinbelegung ist.

Verhalten sich der Atmega8 und der Atmega168 bei SPI evtl. 
unterschiedlich? Hat jemand eine Idee wo ich noch etwas anpassen müsste?

Vielen Dank.
Flo

[SNR (Gast)]

Reset deutet oft auf Stack overflow hin...

[Flo W. (Gast)]

Komisch, dass es halt beim Atmega8 nicht passiert. Wie könnte es denn 
bei dieser Initialisierung zum Overflow kommen?

[Flo W. (Gast)]

Hat jemand eine Idee woran es noch liegen könnte? Ich weiss einfach 
nicht wo ich nach dem Fehler suchen soll...

Habe einen Pullup-Widerstand an /CS und DO angeschlossen... ich vermute 
den Fehler aber eher in der Software, da es ja mit dem Atmega8 läuft!

[AVR-Fan (Gast)]

Prüfe mal nach ob die Interrrupt-Vektoren
die gleichen sind!

Prüfe ebenso die Registeradressen.

Könnte auch daran liegen.

[Flo W. (Gast)]

Interrupts brauche ich doch für die SD-Karte nicht...? Welche 
Registeradressen meinst du?

Ich konnte dem Problem etwas näher kommen und zwar funktioniert 
mmc_init() ohne Probleme. Der Absturz erfolgt bei InitFat16(). Dort bei 
SDC_GetSector, was in mmc.h als mmc_read_sector bezeichnet wird (Name 
per #define ersetzt). mmc_read_sector läuft bis zum Funktionsaufruf von 
mmc_read_block. Dort scheint es Probleme zu geben. Habe das mit Hilfe 
einer LED erkennen können, die ich an bestimmten stellen im Programm 
angemacht habe. Wobei mmc_read_block auch bis zum Ende durchläuft...? 
Kann es hier evtl. wo einen Stackoverflow geben? Hat jemand eine Idee, 
wie ich weiter vorgehen könnte?

[Joe (Gast)]

Sind die Speicherbereiche bei Atmega 8 und ... 168 gleich ?

[Flo W. (Gast)]

Also die Größen der Speicher sind bei beiden gleich. Der SRAM wird 
jedoch unterschiedlich addressiert! Könnte es evtl. dadurch Probleme mit 
dem Stack geben?

[Flo W. (Gast)]

Ich konnte inzwischen herausfinden, dass der Fehler wirklich an einem 
Stackoverflow lag, da nur noch 71 Bytes im SRAM frei waren. Ich habe das 
Programm etwas verkleinert und es hat funktioniert! Jetzt weiss ich nur 
nicht, wieviel Platz ich für den Stack reservieren muss... kann man die 
Größe des Stacks wahrend des Programmablaufs abfragen z. B. mit 
sizeof()? Die Zahl könnte ich dann auf einem LCD ausgeben...

[Sascha W. (sascha-w)]

Flo W. schrieb:
> kann man die
> Größe des Stacks wahrend des Programmablaufs abfragen z. B. mit
> sizeof()? Die Zahl könnte ich dann auf einem LCD ausgeben...
Die einzig sinnvolle Auswertung die auch einigemaßen stimmen könnte 
währe innerhalb eines Timerinterupts den Stackpointer zu lesen und den 
niedrigsten Wert zu speichern. Je häufiger der INT aufgerufen wird desto 
genauer wird der Wert.

Sascha

[Flo W. (Gast)]

Danke. Habe es mit "mem-check" gemacht 
(http://www.rn-wissen.de/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc). 
Das hat gut funktioniert und ich weiss wieviel SRAM noch frei ist.