SD-Lib Daniel R.: seltsamer Fehler auf AVR32

Ups, ich habe euch meine Änderungen statt dem Orginal-Code gepostet, der 
muss heißen:

...
usart_write_line(&AVR32_USART3,"1 ");

vsector=&fat.sector[14];
fat.fatSec=*(unsigned short*)vsector;

usart_write_line(&AVR32_USART3,"2 ");
vsector=&fat.sector[17];
rootEntCnt=*(unsigned short*)vsector;

usart_write_line(&AVR32_USART3,"3 ");
vsector=&fat.sector[22];
fatSz16=*(unsigned short*)vsector;

usart_write_line(&AVR32_USART3,"4 ");
...

Du hast nichts verstanden...
Die Daten sind nicht vertauscht, der Prozessr bleibt stehen!

>>Der AVR32 ist ein BIG ENDIAN Prozessor
Der AP-Prozessor ist ein  BIG ENDIAN, UC3A-Core ist ein Little-Endian!
Andernfalls würde der Schnippsel hier:

char d[2] = {0x01, 0xFF};
void* R = &d[0];
char mess[20];
U16 T = *((U16*)R);
sprintf(&mess, "T: %d",T);
usart_write_line(&AVR32_USART3,mess);

kein 511, sondern ein 65281 aufs Terminal zaubern.

Wenn du schon keine Ahnung hast, solltest du wenigstens das hier 
beachten:
http://www.mikrocontroller.net/articles/Netiquett

>> <mitleid state="on">
>> Da hast du etwas Größeres vor dir
>> Viel Spass
>> </mitleid>

Das keine Hilfe, das ist reiner Hohn!
Bevor du bei anderen von Frechheit sprichst, ließ mal, was du 
geschrieben hast.

>>Zumindest in einem der von Atmel angebotenen Softwarepackete für AVR32
>>ist FAT-Code inkl. "Treibern" für Speicherkarten drin
>>(atmel.com->AVR32->Software-Package o.ä.). War sogar beim letzten Mal
>>drüberschauen (länger her) für FreeRTOS vorbereitet.

Ja, die kenne ich. Ich fand die von Daniel R. übersichtlicher, deshalb 
wolte ich sie probieren.

>>- ChaN's FAT-code (google: chan ) kann per Makro auf "Byte-by-byte
>>access" konfiguriert werden. Damit sollte es keine Probleme mit
>>endianess oder aligments geben. Zumindest einen Test wert.
Du meinst damit die "große" FAT-Lib von Chan?
Die versuche ich gerade umzuschreiben, indem ich den Beispiel-AVR-Code 
anpassen. Hoffentlich sitze ich da nicht dem Endian-Pferd auf.
Das ARM-Beispiel nutzt leider nicht SPI, sonst würde ich mich daran 
orientieren. Auf der anderen Seite: Wenn Thomas sagt, dass die Atmel-Lib 
bei ihm gut funktioniert, dann werde ich mich auch lieber daran halten.

>>Ich hab dann in den sauren Apfen gebissen und mich durch die
>>FAT-Routinen des Framework gekämpft. Hab es damit dann auch zum laufen
>>bekommen.
Könntest du mir deine conf_access.h als Orientierung zur Verfügung 
stellen? Das Beispiel von Atmel behandelt statt einer SD-Karte einen 
at45dbx-Flash, was man wohl in conf_access.h umstellen kann(?). Wäre 
sehr nett von dir.

>>In der Procyon-lib ist das lauffähig für den Atmel enthalten.
Ich habe das mal gegoogelt und eine ältere Version für die 8-Bitter 
gefunden. Gibt es die auch für die 32-Bitter?

>> Das ARM-Beispiel nutzt leider nicht SPI, sonst würde ich mich daran
>> orientieren.

Auf der WinARM-Seite von M. Thomas gibt's was für ARM & SPI.
Einmal für SAM7: 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html

für Cortex M3 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#stm32_memcard

mfg

...sollte auch nicht unerwähnt bleiben: 
http://embdev.net/articles/ARM_MP3/AAC_Player

mfg

Hey,

Danke für die Libs. Ich weiß nicht, was ich falsch mache, aber bei mir 
nutzt er den falschen NCPS-Pin. Ich habe in der Board.h auf meine eigene 
Board-Datei verwiesen. In der steht folgendes:

#define SD_MMC_CARD_DETECT_PIN      AVR32_PIN_PB13
#define SD_MMC_WRITE_PROTECT_PIN    AVR32_PIN_PB14
#define SD_MMC_SPI                  (&AVR32_SPI1)
#define SD_MMC_SPI_NPCS             1 //AVR32_SPI1_NPCS_1_0_PIN
#define SD_MMC_SPI_SCK_PIN          AVR32_SPI1_SCK_0_0_PIN
#define SD_MMC_SPI_SCK_FUNCTION     AVR32_SPI1_SCK_0_0_FUNCTION
#define SD_MMC_SPI_MISO_PIN         AVR32_SPI1_MISO_0_0_PIN
#define SD_MMC_SPI_MISO_FUNCTION    AVR32_SPI1_MISO_0_0_FUNCTION
#define SD_MMC_SPI_MOSI_PIN         AVR32_SPI1_MOSI_0_0_PIN
#define SD_MMC_SPI_MOSI_FUNCTION    AVR32_SPI1_MOSI_0_0_FUNCTION
#define SD_MMC_SPI_NPCS_PIN         AVR32_SPI1_NPCS_1_0_PIN
#define SD_MMC_SPI_NPCS_FUNCTION    AVR32_SPI1_NPCS_1_0_FUNCTION

trotzdem löscht er den 2 oder 3 NCPS-Pin (kann ich nicht unterscheiden, 
sehe es aber am am Oszi). Ich erhalte auch keine Warnung ala 
"SD_MMC_SPI_NPCS redefined".
Im Prinzip besteht mein Programm im Moment nur aus

while(1)
{
  nav_reset();
  nav_drive_set(0);
  nav_partition_mount();

  nav_file_create("Start.txt");
  file_open("Start.txt");
  file_close();
  gpio_tgl_gpio_pin(AVR32_PIN_PB21);
};

Die Initialisierung des SPI geschieht in einer eigenen, vorher 
aufgerufenen Funktion.
Die aber kann nicht so falsch sein, denn für die andere Komponente an 
dem (selben) SPI-Bus klapp das bestens.


...
int  SD_spi_opt = 0 << AVR32_SPI_CSR1_CPOL_OFFSET| //Inaktiver Takt Low;
        1 << AVR32_SPI_CSR1_NCPHA_OFFSET | // Aktive Flanke ist 1
        0  << AVR32_SPI_CSR1_CSNAAT_OFFSET |
       1 << AVR32_SPI_CSR1_CSAAT_OFFSET | // Deselektiere Baustein 
nicht!
        0 << AVR32_SPI_CSR1_BITS_OFFSET | //  8Bit Modus
        200 << AVR32_SPI_CSR1_SCBR_OFFSET | //langsamer Takt: PBA/200
        10 << AVR32_SPI_CSR1_DLYBS_OFFSET | // 11zyklen, nach fall von 
Cs
        10 << AVR32_SPI_CSR1_DLYBCT_OFFSET;

AVR32_SPI1.csr1 = SD_spi_opt;
...

Wenn jemand eine Idee hat, warum der den falschen CS-Pin löscht, bitte 
schreiben.

So, Problem ist behoben, die FAT-Lib läuft! Allerdings arbeitet sie 
nicht mit SDHC-Karten, was komisch ist, weil die Routinen vorhanden 
sind...
Kennt jemand das Problem?

Ansonsten bedanke ich mich für die Hilfestellungen und die Dateien!