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
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
@ 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
>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.
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
@ 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
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
@ 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
@ 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
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
>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.
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
@ 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
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?
@ 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
@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
@ 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
@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
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.
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...
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.
>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.
> >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.
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
@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
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.
@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 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
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).
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
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.
1
// sdcard.c
2
staticunsignedcharSendCommand(SdCard*pSd)
3
{
4
// ....
5
// Wait for command to complete
6
while(!MCI_IsTxComplete(pCommand));// hier Endlosschleife
7
8
returnpCommand->status;
9
}
10
11
// mci.c
12
unsignedcharMCI_IsTxComplete(MciCmd*pCommand)
13
{
14
return(pCommand->status!=MCI_STATUS_PENDING);
15
}
Genau in dieser While-Schleife bleibt das Programm stecken.
1
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.
1
// mci.c
2
//...
3
// Otherwise stop at the end of the command
4
else{
5
mciIer=AT91C_MCI_CMDRDY|STATUS_ERRORS;
6
}
7
8
// Send the command
9
WRITE_MCI(pMciHw,MCI_MR,mciMr);
10
WRITE_MCI(pMciHw,MCI_ARGR,pCommand->arg);
11
WRITE_MCI(pMciHw,MCI_CMDR,pCommand->cmd);// CMDRDY bit sollte gelöscht werden
12
//...
13
WRITE_MCI(pMciHw,MCI_IER,mciIer);// interruptmaske wird gesetzt
14
//...
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
