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
>- ich muss mit 1000 Hz samplen
Hast du da ne Null weggelassen ? Das wären sonst nur
schlappe 64 Byte/ms.
Hallo holger richtig, eine 0 vergessen. Ich meinte natürlich 10000Hz -> alle 100µs 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 | static unsigned char SendCommand(SdCard *pSd) |
3 | {
|
4 | // ....
|
5 | // Wait for command to complete
|
6 | while (!MCI_IsTxComplete(pCommand)); // hier Endlosschleife |
7 | |
8 | return pCommand->status; |
9 | }
|
10 | |
11 | // mci.c
|
12 | unsigned char MCI_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
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.