ARM7 MicroSD Timinganalyse

[Nobbie (Gast)]

Hallo,

ich bin gerade dabei ein Projekt mit einem ARM7 und einer MicroSD zu 
planen.
Es sollen alle 100µs Messdaten erfasst und auf der MicroSD gespeichert 
werden. Für die Timinganalyse habe ich mir jetzt mal die 
UserGuides(Stand 2005) von der MicroSD angeschaut und finde dort Zahlen 
wie "Block Read Access Time 10...100ms" und "Block Write Access Time 
40...250ms". Diese Zahlen demotivieren mich ein bißchen.

Deshalb hier mal die Frage in die Runde: Hat jemand von euch bezüglich 
MicroSD und Timing schon mal ein paar Analysen gemacht?

Mein Problem ist, dass die MicroSD über SPI angeschlossen ist und ich 
für die Datenspeicherung(64Byte) maximal 60µs zur Verfügung habe.
Nun könnte man natürlich mehrere Blöcke a 64Byte zu einem 512Byte Block 
sammeln und dann schreiben. Das bringt dann aber das Timing der 
Peripherie durcheinander, da diese zum Teil auch über SPI angeschlossen 
ist und alle 100µs gesamplet werden.

Für nützlichen Input wäre ich dankbar.
Gruss Nobbie

[Mathi (Gast)]

Das ist ja eine Sache der Sache der SD-Karte. Habe gerade gegoogled und 
einige Zugriffszeiten von verschiedenen MicroSDs gefunden. Allerdings 
nur Read-Zeiten. Hab das nur kurz überflogen, aber vielleicht nützt der 
Link ja: http://forums.maxconsole.net/archive/index.php/t-47828.html

[Falk B. (falk)]

@ Nobbie (Gast)

>Es sollen alle 100µs Messdaten erfasst und auf der MicroSD gespeichert

Schön, das macht man aber sicher NICHT für jeden Messwert einzeln.

>Mein Problem ist, dass die MicroSD über SPI angeschlossen ist und ich
>für die Datenspeicherung(64Byte) maximal 60µs zur Verfügung habe.
>Nun könnte man natürlich mehrere Blöcke a 64Byte zu einem 512Byte Block
>sammeln und dann schreiben. Das bringt dann aber das Timing der

Das wirst du sowieso müssen.

>Peripherie durcheinander, da diese zum Teil auch über SPI angeschlossen
>ist und alle 100µs gesamplet werden.

Dann hast du ein Problem. Möglicherweie brauchst du zwei SPI Ports, 
einen vielleicht mit Soft-SPI angeschlossen. Oder du speicherst sehr 
viele Daten im RAM, und am Ende der Messung erst auf SD-Karte. Wie lange 
willst du denn messen?

MFG
Falk

[holger (Gast)]

>und ich für die Datenspeicherung(64Byte) maximal 60µs zur Verfügung habe

Das sind ca. 1MB/s.

Ich demotiviere dich gleich mal noch ein wenig mehr:

MMC/SD sind im SPI Modus nicht besonders schnell.
Das schnellste was ich auf einem LPC2138 bei 15MHz
SPI Speed beim schreiben erreicht habe war 580kB/s.
Das aber auch nur mit meiner schnellsten Karte.
Die meisten meiner Karten liegen so zwischen 150-300kB/s.
Eine Mini-SD schaffte gar nur 30kB/s.
Gut, da war noch ein FAT Dateisystem beteiligt.
Aber es war ein Testprogramm mit bereits gefülltem
Schreibpuffer. Also optimale Bedingungen.
Im realen Einsatz muss man die Werte vermutlich
deutlich nach unten korrigieren.

[Nobbie (Gast)]

Hallo,

erst mal danke für die Antworten.

Tatsache ist:
- ich habe nur einen SPI Port.
- insgesamt gibt es 3 Resourcen, die über Chipselect aktiviert werden.
  (1x MicroSD Karte und 2x Sensorik)
- weitere Ports stehen nicht mehr zur Verfügung
- ich muss mit 1000 Hz samplen
- ich habe ein FAT16 Formatierung auf der MicroSD

Ich habe auch schon überlegt, die 64Byte Blöcke immer zu einem 512Byte 
Block zu sammeln und erst dann zu schreiben. Problem ist dann aber, dass 
sich der SPI Schreibvorgang mit dem Samplen der Sensorik über SPI 
überschneidet.

Die Messzeit beträgt mindestens 30 Sekunden. Gehen wir mal von einer 
aufgerundeten Datenmenge vom 1MB/sek aus, haben wir 30MB Daten. Die 
speichert man nicht mehr im RAM.

Ich denke, ich werde mal entsprechende Benchmarks fahren um dies zu 
testen.

So, der Sontag ist versaut ;-(

Gruss Nobbie

[holger (Gast)]

>- ich muss mit 1000 Hz samplen

Hast du da ne Null weggelassen ? Das wären sonst nur
schlappe 64 Byte/ms.

[Nobbie (Gast)]

Hallo holger

richtig, eine 0 vergessen.
Ich meinte natürlich 10000Hz -> alle 100µs

Gruss Nobbie

[Falk B. (falk)]

@ Nobbie (Gast)

>- insgesamt gibt es 3 Resourcen, die über Chipselect aktiviert werden.
>  (1x MicroSD Karte und 2x Sensorik)
>- weitere Ports stehen nicht mehr zur Verfügung
>- ich muss mit 1000 Hz samplen

War nicht vorhin von 100us die Rede?
Wieviel Kanäle in welcher Auflösung sollen denn gesampled werden?

>- ich habe ein FAT16 Formatierung auf der MicroSD

>Ich habe auch schon überlegt, die 64Byte Blöcke immer zu einem 512Byte
>Block zu sammeln und erst dann zu schreiben. Problem ist dann aber, dass
>sich der SPI Schreibvorgang mit dem Samplen der Sensorik über SPI
>überschneidet.

Dann braucht man eine Art FIFO. Ein kleiner uC oder CPLD der 
koninuierlich die Sensoren sampelt und in den FIFO schreibt und dein 
ARM, der blockweise die Daten auf SD-Karte schreibt.

>Die Messzeit beträgt mindestens 30 Sekunden. Gehen wir mal von einer
>aufgerundeten Datenmenge vom 1MB/sek aus, haben wir 30MB Daten. Die
>speichert man nicht mehr im RAM.

Sagt mal, ist heute PISA Tag?

Wenn wir von den erstgenannten 100us ausgegehen, sind das 10kHz. Wenn 
pro Sample 1 Byte gespeichert werden soll, sind das 10kB/s. Macht in 30s 
gerade mal 300kB. Wenn nun mehr Bytes pro Sample gebraucht werden eben 
mehr.

>Ich denke, ich werde mal entsprechende Benchmarks fahren um dies zu
>testen.

Neee, erstmal nachdenken.

MFG
Falk

[Nobbie (Gast)]

Hallo Falk,

erst mal danke für dein Kompliment.

Da du sicherlich schon meinen Post gelesen hast, der 4Minuten vor deinem 
veröffentlicht wurde, ist sicherlich schon ein Teil deiner "PISA 
angelehnten" Äußerung beantwortet.

Hättest du meine ersten Post:

>Mein Problem ist, dass die MicroSD über SPI angeschlossen ist und ich
>für die Datenspeicherung(64Byte) maximal 60µs zur Verfügung habe.

richtig gelesen(und geschlußfolgert), wäre dir klar, dass ein Sample aus 
64Byte besteht. Deshalb werde ich auf deine Aussage:
"... 1Byte pro Sample..."
nicht weiter eingehen. Nur soviel: "Wer im Glashaus sitzt, sollte nicht 
mit Steine schmeißen."

Freue mich auf deine aggressive Antwort ;-)

Gruss Nobbie

[Jens (Gast)]

@ Nobbie:

>Tatsache ist:
>- ich habe nur einen SPI Port.
>- insgesamt gibt es 3 Resourcen, die über Chipselect aktiviert werden.
>  (1x MicroSD Karte und 2x Sensorik)
>- weitere Ports stehen nicht mehr zur Verfügung
>- ich muss mit 1000 Hz samplen
>- ich habe ein FAT16 Formatierung auf der MicroSD

>Ich habe auch schon überlegt, die 64Byte Blöcke immer zu einem 512Byte
>Block zu sammeln und erst dann zu schreiben. Problem ist dann aber, dass
>sich der SPI Schreibvorgang mit dem Samplen der Sensorik über SPI
>überschneidet.
Wer sagt denn das das Interface der SD-Karte genau so schnell Bytes
entgegennimmt um am Ende auf die reale Datenrate der Karte zu kommen?
Ich habe es zwar noch nicht probiert, aber meine Vermutung wäre
folgende:
Das Interface der Karte ist schneller, d.h. Du kannst die Daten für
einen Block dort relativ schnell hineinschreiben. Danach ist die
Karte allerdings erstmal eine Weile mit sich selbst beschäftigt
um die gepufferten Daten ins Flash zu schreiben.

>Die Messzeit beträgt mindestens 30 Sekunden. Gehen wir mal von einer
>aufgerundeten Datenmenge vom 1MB/sek aus, haben wir 30MB Daten. Die
>speichert man nicht mehr im RAM.
Zu den wirklich erreichbaren Datenraten kann ich nicht viel sagen,
aber bei diesen Mengen steht dann schon die Frage ob eine
suboptimal (SPI) angebundene SD-Karte noch das richtige Medium ist.

Jens

[Falk B. (falk)]

@ Nobbie (Gast)

>Da du sicherlich schon meinen Post gelesen hast, der 4Minuten vor deinem
>veröffentlicht wurde,

Die hab ich erst hinterher gesehen, weil ich da gerade mein Posting (und 
andere) verfasst habe.

>richtig gelesen(und geschlußfolgert), wäre dir klar, dass ein Sample aus
>64Byte besteht.

Solche "Schlussfolgerungen" sind selten brauchbar. Warum schreibst du 
das nciht einfach so?

>Freue mich auf deine aggressive Antwort ;-)

Nix aggressiv. Aber kernig! ;-)

Naja, macht halt 640kB/s, immerhin "nur" 64% der deklarierten 1MB/s. Ist 
ne Menge Holz und wie holger bereits sagte praktisch nicht per SPI in 
eine SD-Karte schreibbbar. Und wie ich bereits sagte, du brauchst einen 
FIFO.

MFG
Falk

[Nobbie (Gast)]

Hallo,

@all
Noch mal Danke für eure Antworten.

Gruss
Nobbie

[Karl Z. (griffin27)]

Hallo,

ich habe Ähnliches vor:

DAQ-Board:
16 Kanäle simultan gesampelt
14 Bit Auflösung
Bis zu 250kS/s pro Kanal (--> 8MB/s gesamt)

Gespeichert wird auf SD-Karte mit ARM7, 4-Bit Datenbus zur SD, 
DMA-Controller im ARM für das Wegschaufeln der Daten in 512B Blöcken.

Ich habe durch diesen Thread das Gefühl bekommen, als ob das nicht 
möglich wäre...

Der PC bringt doch auch ca. 10MB/s auf die SD-Karte, oder nicht?
Die theoretische maximale Übertragungsgeschwindigkeit des SD-Interfaces 
ist laut Spezifikation 4Bit * 25MHz Takt = 12,5MB/s.

lg, Karl

[holger (Gast)]

>Der PC bringt doch auch ca. 10MB/s auf die SD-Karte, oder nicht?
>Die theoretische maximale Übertragungsgeschwindigkeit des SD-Interfaces
>ist laut Spezifikation 4Bit * 25MHz Takt = 12,5MB/s.

Träum weiter. Keine meiner Karten bringt am PC 10MB/s.
Einige trödeln mit 1MB/s rum. Die maximale Geschwindigkeit
des Interfaces sagt GAR NICHTS über die Speicherzeiten
des Mediums aus. Es nutzt dir gar nichts einen Block mit 25MHz
in die Karte zu husten, wenn die danach mehrere Millisekunden
BUSY ist.

[Karl Z. (griffin27)]

Mhh, dann waren es doch eher 10Mbit/s ???
Schade, schade... werd mich mal nach schnellen SD-Karten umschauen.
Im Fotographiebereich muss es doch auch Lösungen geben. Schließlich 
machen so manche Spiegelreflex Kameras 3 Bilder/s und das mit je 6MB -> 
18MB/s...

lg, Karl

[Falk B. (falk)]

@ Karl Zeilhofer (griffin27)

>Im Fotographiebereich muss es doch auch Lösungen geben. Schließlich
>machen so manche Spiegelreflex Kameras 3 Bilder/s und das mit je 6MB ->
>18MB/s...

Die haben a) alle CompactFlash (die Schnittstelle ist 16! Bit breit) und 
b) nehmen die dann GUTE Karten, die schon einige MByte/s schaffen. 
Ausserdem GENAU hinschauen, solche Bildfolgen schaffen die meisten 
Kameras nur kurze Zeit, bis der RAM voll ist . . .


MFG
Falk

[Karl Z. (griffin27)]

Was sagt ihr zu diesem Link?
http://www.umtslink.at/index.php?pageid=sd_karte
Die Sprechen von bis zu 20MB/s!!!

Mir ist klar, dass es große Unterschiede bezüglich der Geschwindigkeiten 
gibt. Aber wenn ich eine gute und schnelle SD-Karte habe, dürfte meinem 
Vorhaben nichts im Wege stehen, oder?

[Falk B. (falk)]

@ Karl Zeilhofer (griffin27)

>Was sagt ihr zu diesem Link?
>http://www.umtslink.at/index.php?pageid=sd_karte
>Die Sprechen von bis zu 20MB/s!!!

Jaja, die liebe Werbung. Hat schon so manchen verblendet.

FINDE erstmal ein Karte, die WIRKLICH an deinem PC über längere zeit 
10MB/s schafft. DANN kannst du darüber nachdenken, das mit deinem ARM 
hinzukriegen. Ordentlich RAM als FIFO wären aber auch da nicht 
falsch.

MFG
Falk

[Jens (Gast)]

@all:

Wie weiter oben schon geschrieben wurde, für derartige
Anforderungen sind SD-Karten schlicht ungeeignet. Es ist
nahezu unmöglich von den Herstellern Daten über die
Transferraten der Karten zu erhalten und von dem oben
genannten theoretischen Maximum geht ja auch noch einiges
für den Protokolloverhead drauf. Zu guter letzt nehmen
gute SD-Controller der Host-CPU einiges an Arbeit ab
(CRC, DMA in den Speicher). Da ist mit universeller
Hardware (z.B. Mikrocontroller) kein Blumentopf zu
gewinnen.
So wie es aussieht besteht durchaus Bedarf nach einem
schnellen nichtflüchtigen Speicher, nur bezweifle ich
das 'normaler' Flash da geeignet ist. Wie wäre eine
IDE-Schnittstelle?

Jens

[Falk B. (falk)]

@ Jens (Gast)

>(CRC, DMA in den Speicher). Da ist mit universeller
>Hardware (z.B. Mikrocontroller) kein Blumentopf zu
>gewinnen.

Warum? Der uc ist schnell genug (ARM&Co), nur die Karte braucht "zu 
lange".

>das 'normaler' Flash da geeignet ist. Wie wäre eine
>IDE-Schnittstelle?

Gibts schon lange, nennt sich CompactFlash.

MFg
Falk

[Jens (Gast)]

@Falk:

>>(CRC, DMA in den Speicher). Da ist mit universeller
>>Hardware (z.B. Mikrocontroller) kein Blumentopf zu
>>gewinnen.

>Warum? Der uc ist schnell genug (ARM&Co), nur die Karte braucht "zu
>lange".

Da lasse ich mich gerne eines besseren belehren. Da laut meinem
Wissen kein (für den Amateur zu erwerbender) ARM den Parallelmode
in Hardware macht läuft es auf manuelles Port-Toggeln hinaus.
Wenn jemand damit hinreichend hohe Datenraten erreicht würde mich
das durchaus auch interessieren.

>>das 'normaler' Flash da geeignet ist. Wie wäre eine
>>IDE-Schnittstelle?

>Gibts schon lange, nennt sich CompactFlash.

Richtig, die sind schonmal schneller als SD und Konsorten. Gegenüber
richtigen Platten ist das Flash aber trotzdem noch um Größenordnungen
langsamer. Es wäre Interessant zu wissen ob ein Mikrocontroller mit
einer Platte nochmal zulegen kann.

Wennn ich Zeit hätte....

Jens

[Erik (Gast)]

Platten sind nur schneller wenn du grosse Blöcke (mehrere MB) auf einmal 
schreibst und diese auch möglichst "hinter einander" liegen.

Bei 512 B Blöcken, einer fragmentierten Platte und einem Filesystem 
hängt eine CF eine Platte absolut ab!

Bei der CF geht das Schreiben eines Blockes eigentlich immer gleich 
lang. Bei der Platte muss zuerst die Träge Mechanik den passenden Sektor 
aufsuchen. Kann bis zu ein paar Millisekunden dauern.
Bei kleinen und oder verteilten Blöcken sinkt die Datenrate somit enorm 
ab, du brauchst einen riesigen Puffer!

Gute CF im DMA Modus bei hoher Blockgrösse schaffen wirklich 10 MB/s. 
Habe es selber schon viel Mal erlebt.

Mache regelmässig Backup auf eine "Sandisk extreme CF". Beim Schreiben 
sehe ich die Rate mit dem Programm SuperCopier. Sie schwankt zwar, bei 
Grossen Dateien ist sie jedoch durchschn. sogar etwas höher.

[Wolfgang Mües (Gast)]

Ich habe schon einiges im Bereich SPI und microSD gemacht. Die neuen 
Karten (1 GByte und mehr) sind schon sehr fix.

Aber die Geschwindigkeit, auf die es WIRKLICH ankommt, ist nicht die 
Datentransferrate auf dem SPI, sondern die Schreibgeschwindigkeit des 
Controllers auf der Karte.

Wenn Du hier optimieren willst, dann solltest Du wissen, dass die im 
Moment eingesetzten NAND-Flashes alle eine Pagegröße von 2048 Bytes 
haben. D.h. wenn Du weniger schreibst, dann muss der Controller eine 
Page holen, einen Block (=512 Bytes) austauschen und alles an neuer 
Stelle wegschreiben.

D.h. auf das Protokoll runtergebrochen möchtest Du "write multiple 
sectors" mit mindestens 4 x 512 Bytes machen.

64 KBytes/Sec sollten so zu schaffen sein. Aber den SPI mit 2 anderen 
Devices teilen kannst Du wahrscheinlich vergessen...

[Karl Z. (griffin27)]

Jetzt muss ich da mal aufklären:
Der ARM7 von ATMEL, AT91SAM7A3, hat ein SD-Card Interface mit 4-Bit 
Modus in Hardware gegossen, und dazu dann auch noch einen 19-Kanal DMA 
Controller, der mir die Daten vom RAM auf die Karte schaufelt. Hab ich 
ja schon geschrieben!

Ergo: Es kommt nur mehr auf die Geschwindigkeit des, wie schon von 
jemandem angesprochen, des Flash-Controllers in der SD-Card an.
Deswegen gibt es auch verschieden schnelle SD-Karten zu unterschiedlich 
hohen Preisen.

Ich möchte einen Kunden von Amazon zitieren:
"Zwar bin ich nicht davon ausgegangen die volle Leistung zu erhalten 
aber wenn die Karte noch nicht mal annähernd die 9MB/s bzw. 10 MB/s 
meiner Ultra II schafft, beim schreiben ist sie fast doppelt so 
langsam."
http://www.amazon.de/PRETEC-Secure-Digital-Ultra-Speed/dp/B000BC8Y1Y/ref=sr_1_1?ie=UTF8&s=gateway&qid=1202242671&sr=8-1

Schreiben mit 10MB/s und Lesen mit 20MB/s ist bereits durchaus drin.
Der Daten- und CPU-Overhead sollte sich bei 512B-Blocktransfer in 
minimalen Grenzen halten.

Jetzt weiß ich wirklich nicht mehr, was mich und mein Projekt aufhält.

[holger (Gast)]

>Jetzt weiß ich wirklich nicht mehr, was mich und mein Projekt aufhält.

Die Realität vieleicht ? Bleibt die Frage ob du mit dem ARM7 deine
Daten auch mit 10MB/s einsammeln kannst.

[Rufus Τ. F. (rufus)]

> >Im Fotographiebereich muss es doch auch Lösungen geben. Schließlich
> >machen so manche Spiegelreflex Kameras 3 Bilder/s und das mit je 6MB ->
> >18MB/s...
>
> Die haben a) alle CompactFlash (die Schnittstelle ist 16! Bit breit) ...

Pedanterie:

Die DSLR-Modelle von Samsung und Pentax setzen seit geraumer Zeit 
ausschließlich SD-Karten ein. Auch das aktuelle Einsteigermodell der 
Firma Canon (EOS450) verwendet SD-Karten.

Auf einer Noname-2GB-Karte ("hama") kann meine DSLR (K10D) 
kontinuierlich 3 Bilder pro Sekunde speichern - wenn diese 
JPG-komprimiert sind und die etwa 3 MByte Größe nicht deutlich 
überschreiten, also keine zu komplexen Bildinhalte aufweisen.

Bei Verwendung einer "schnellen" SD-Karte von Sandisk sähen die 
Rahmenbedingungen sicherlich anders aus, aber 3 RAW-Aufnahmen pro 
Sekunde sind auch dann nicht drin.

Ganz so irrwitzig langsam sind SD-Karten also nicht.

[Karl Z. (griffin27)]

Danke, Rufus.

@holger: Die Daten müsste ich schon so schnell einsammeln können.
Bei einer Taktrate von 50MHz bleiben mir für jedes Sample 12,5 Takte 
Zeit, um es Parallel vom ADC abzuholen und in den RAM zu legen. Ich 
denke, das müsste sich ausgehen. Dazwischen muss ich eben alle 512B dem 
DMA-Controller sagen, dass es los geht, und irgendwie einen Takt von 
250kHz auf einen Pin bringen.

Es wird zwar alles ziemlich knapp, aber bin trotzdem optimistisch.

lg, Karl

[Jens (Gast)]

@Karl:

Wieder etwas gelernt, ich wußte nicht das es Atmel ARM's mit
SD-Interface gibt. Es wäre toll wenn Du mal davon berichtest
wenn die Sache läuft.

@Erik:

Das mit dem wahlfreien Schreiben ist natürlich richtig. Ich
habe aber angenommen das die vielen Megabytes RAM auf den
Platten nicht nur zum Puffern von Lesezufgriffen dienen.

Jens

[Volker -. (volker-01)]

Der LPC 2368 hat auch ein MCI-Interface (Mediacard & SD-Card-Intercface) 
sowie einen 4 Kanal-DMA-Controller, welcher auch die Daten vom/zum 
MCI/RAM schafft.

[gerhard (Gast)]

@jens
>Wieder etwas gelernt, ich wußte nicht das es Atmel ARM's mit
>SD-Interface gibt. Es wäre toll wenn Du mal davon berichtest
>wenn die Sache läuft.
alle at91 mit mci (mulitmedia card interface) unterstützen sd
z.Zt sind dies
AT91SAM7SA3
alle AT91SAM9

gruss
gerhard

[Karl Z. (griffin27)]

Karl Zeilhofer wrote:
> Die theoretische maximale Übertragungsgeschwindigkeit des SD-Interfaces
> ist laut Spezifikation 4Bit * 25MHz Takt = 12,5MB/s.
>
> lg, Karl

Korrektur:
Laut neuer SD-Card Spezification (V2.00) sind diese mit bis zu 50MHz zu 
Takten!! --> 25MB/s Maximum!!! Theoretisch jedenfalls. Praktisch geht 
beim lesen auch nicht mehr viel ab. Schreiben ist noch relativ langsam 
mit bis zu 9MB/s.

Ich bin nun dabei, eine kleine API für den AT91SAM7A3 für SD-Befehle zu 
schreiben. Hat vielleicht jemand sowas schon fertig???
Ist doch recht viel Arbeit. Das hab ich etwas unterschätzt.

lg, Karl

[Martin T. (mthomas) (Moderator)]

Karl Zeilhofer wrote:
>...
> Ich bin nun dabei, eine kleine API für den AT91SAM7A3 für SD-Befehle zu
> schreiben. Hat vielleicht jemand sowas schon fertig???
> Ist doch recht viel Arbeit. Das hab ich etwas unterschätzt.

Sodenn sich die MCI Hardware in AT91SAM9 und AT91SAM7A3 nicht zu arg 
unterscheiden, könnten die Beispielprojekte für die SAM9 auf 
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4227 nützliche 
Hinweise geben (z.B. "basic-sdcard" im Packet für AT91SAM9260).

[Karl Z. (griffin27)]

Ich musste gerade mit Entsetzten feststellen, dass der AT91SAM7A3 von 
Atmel sehr schlecht unterstützt wird. Trotz des SD-Interfaces, ist keine 
Bibliothek oder sowas dafür dabei.
Mal schaun, ob ich den Treiber für den ARM9 auf meinem Board zum laufen 
bekomme.

Wenn nicht, mach ich an meiner API weiter. Jetzt fehlt eigentlich nicht 
mehr soooo viel.

greets, Karl

[Karl Z. (griffin27)]

So, nachdem ich mich in den Treiber von Atmel reingelesen habe bin ich 
zu dem Schluss gekommen, dass bei mir die Interrupt Behandlung nicht 
recht funktionieren will.

Ich hoffe jetzt auf jemandem, der schon mal den MCI-Treiber auf einem 
ARM7 oder ARM9 implementiert hat.

Das MCI konnte erfolgreich initialisiert werden.
Aber es scheitert bei der Initialisierung der SD-Card, genauer gesagt 
beim erfolgreichen Senden von Befehlen. Der erste "Power-On" Befehl wird 
weggeschickt, und dann wird darauf gewartet, dass der Befehl fertig ist.

// sdcard.c
static unsigned char SendCommand(SdCard *pSd)
{
// ....
    // Wait for command to complete
  while (!MCI_IsTxComplete(pCommand)); // hier Endlosschleife

  return pCommand->status;
}

// mci.c
unsigned char MCI_IsTxComplete(MciCmd *pCommand)
{
  return (pCommand->status != MCI_STATUS_PENDING);
}

Genau in dieser While-Schleife bleibt das Programm stecken.

pCommand->status

 ist auf 0x01 gesetzt, und sollte in einer Interrupt Service Routine, 
die nie aufgerufen wird, auf 0x00 gesetzt werden.

Wie sieht es eigentlich aus mit Interrupts beim Debuggen mit JATG?
Ich arbeite mit Crossworks.

// mci.c
//...
    // Otherwise stop at the end of the command
    else {
        mciIer = AT91C_MCI_CMDRDY | STATUS_ERRORS;
    }

    // Send the command
    WRITE_MCI(pMciHw, MCI_MR, mciMr);
    WRITE_MCI(pMciHw, MCI_ARGR, pCommand->arg);
    WRITE_MCI(pMciHw, MCI_CMDR, pCommand->cmd); // CMDRDY bit sollte gelöscht werden
//...
    WRITE_MCI(pMciHw, MCI_IER, mciIer); // interruptmaske wird gesetzt
//...

Bei weiterer Beobachtung ist mir auf gefallen, dass das CMDRDY-Bit im 
Status Register gar nicht gelöscht wird, sobald in das Command Reg 
geschrieben wird, so wie es im User Manual zum uC steht.
D.h., es kann gar kein Interrupt ausgelöst werden, weil das bit immer 
gesetzt ist, und es keine "positive Flanke" gibt, auf die der Interrupt 
Controller reagieren könnte.

Die anderen Register des MCIs sind jedoch richtig, und funktionieren 
auch.

Was kann ich jetzt noch machen?
Notlösung wäre, das Bit zu pollen....

Bitte um Hilfe