Hallo Leute, weis jemand ob es Datasheets zu COMPACT FLASH-Card gibt. Ich möchte die Informationen aus dieser Karte auslesen. Wie ich die PIN belegung machen soll habe ich natürlich keine Ahnung! Gruss Stefan
Die CF karten ahben ein IDE interface. -> parallele Datenübertragung. Da gabs mal so eine Adapterplatine von Elektor.
Hier steht eigentlich alles drin, was man braucht. Ich habs aber irgendwie nicht zum Laufen gekriegt. Gruß
@Stefan: brauchst du nur die Daten dieser einen Karte? Auf dem PC und hast du sonnst bastelmäßig nichts weiter vor? Dann ist ein Cardreader oder so ein IDE-CF Adapter wie Richard es schreibt genau das richtige für dich. Willst du jedoch per µC oder so die Daten auslesen (z.b. für einen MP3 Player) dann ist ein Datenblatt gar nichtmal so schlecht. Auf der Seite von Kai ( http://elektronik.kai-uwe-schmidt.de ) findest du z.b. en MP3 Player Projekt und alle Datenblätter dazu: http://elektronik.kai-uwe-schmidt.de/projekte/mp3/portable/datasheet.zip Viel Spaß und frohe Weihnachten, Netbandit
Hi Leute, auch ich versuche (mit einem PIC16F877) auf eine CF-Karte zuzugreifen und habe ein ähnliches Problem wie es Daniel in diesem Forum unter http://www.mikrocontroller.net/forum/read-1-161430.html beschrieben hat. Grundlage meiner Arbeit ist ebenfalls der oben erwähnte Artikel im PDF-Format. Die Frage in welchem der 3 in der CF-Spezifikation angegebenen Modi (PC Card Memory Mode, PC Card I/O Mode, True IDE Mode) die Karte nun läuft habe ich auch noch nicht restlos geklärt, ich denke aber sie läuft im PC Card I/O-Mode, wenn das Auslesen über den /OE-Pin (Pin 9 der CF-Karte) erfolgt. Den PC Card Memory Mode schließe ich aus. Leider habe ich in der CF-Spezifikation keine eindeutigen Hinweise gefunden (oder nicht verstanden). Das Seltsame bei mir ist, dass ich zunächst zwei Sektoren, nämlich den Master Boot Record (Sektor 0 der Karte) und den Bootsektor (Sektor 32 laut Partitionstabelle, entnommen dem 4-Byte-Wert ab Offset 454 im Master Boot Record) problemlos von meiner 128MB Sandisk CF-Karte lesen kann. Auf die gleiche Art und Weise möchte ich einen weiteren Sektor lesen und bekomme dann plötzlich lauter gleiche Zeichen (0x58, hierbei handelt es sich verarschenderweise um ein großes X). Das Verhalten ist stabil, egal wie oft oder wie lange ich die Stromzufuhr unterbreche und somit einen Reset meines µCs ausführe. Zeit- und Warteschleifen im Code vor und nach dem Absetzen des ATA-Kommandos "Read Sector" 0x20 bringen nix. Mit meinem USB-Kartenleser (so ein ganz billiger für 9,99EUR) und dem Tool "WinHex" kann ich die Karte ordnungsgemäß lesen, daraus schließe ich auch, dass sie noch funktioniert. Ich hatte bereits zu Anfang meiner Experimente ein ähnliches Problem bereits beim ersten Lesen eines Sektors wie auch bei "identify Drive" 0xEC, damals halfen relativ extreme Wartezeiten. Durch Umstellen des Codes und Auswerten des RDY/-BSY-Signals (Pin 37) war das Problem zunächst verschwunden. Das könnte ich vor dem 3. "Read-Sector"-Aufruf noch überprüfen, habe ich noch nicht getan. Vielleicht liegt's aber auch daran, dass ich beim 2. Aufruf nicht alle 512 Bytes über den /OE-Strobe abhole, da ich sie nicht benötige. Am /OE-Strobe swelbst liegt's nicht, denn wenn ich den 3. "Read-Sector"-Aufruf nicht absetze, bekomme ich astrein die übrigen Bytes des zuvor gelesenen Sektors. Da ich aber trotzdem 512 Bytes lese, im CF-Buffer aber nur noch (in diesem Fall) 464 Bytes drin sind, bekomme ich 48 ungültige Bytes, die alle den Wert 0x55 haben (großes U). Ich werde diese beiden Varianten noch testen und melde mich dann nochmal.
Jetzt habe ich beide Varianten getestet, leider hat es nichts gebracht. Nun muss ich wohl mit dem Oszi ran. Prinzipiell funktioniert's ja bei den ersten beiden "Read-Sector"-Aufrufen. Erst beim dritten Mal streikt der Aufbau. Von daher habe ich auch Zweifel, ob ich mit dem Scope was finde... viele Grüße der Schlizbäda
Moinmoin! Immerhin bist du schon weiter gekommen als ich. Wenn Du nach dem Artikel arbeitest, bin ich mir zu 99.99% sicher, daß Du im PC Card Memory Mode arbeitest. Wie lang sind bei Dir extreme Wartezeiten? Mit welcher Sprache programmierst Du? Ich hab bis jetzt das ganze aufgrund mangelnder Kooperation Seitens der CF-Karte beiseite gelegt, aber vielleicht kommen bei dieser Diskussion noch einige gute Tipps zusammen. Grüße
strike.... ich habe den Fehler gefunden! Wenn man es weiß ist es logisch: Nachdem man das Kommando "Read Sector" abgesetzt hat, indem man zunächst den Wert 0x20 an die Datenleitungen D7:0 der CF-Karte anlegt und anschließend den Wert 0x07 (binär 111, ATA COMMAND REGISTER) an die Adressleitungen A2:0 anlegt, muß man vor dem Stroben über /OE natürlich den Wert 0x00 an A2:0 anlegen. Dies ist die Adresse des ATA DATA REGISTERs. Hier lag der Fehler bei mir. Das Auslesen des ständig gleichen Zeichens ist logisch, da der Inhalt des ATA STATUS REGISTERs ausgelesen wurde, dessen Wert sich erst beim nächsten Kommando-Zugriff auf die Karte ändert. "Extreme Wartezeiten" sind für mich Schleifen ab 50ms Dauer, das sind für einen µC "Ewigkeiten", aber das braucht's ja jetzt nicht mehr... In welchem Mode ich letztlich arbeite ist mir wurscht, die Hauptsache ist es funktioniert. @Daniel: Ich glaube, dass auch Du diesen Punkt übersehen hat. Ich programmiere das Ding in PIC-Assembler (MPLAB IDE v7.00) und verwende den PIC-Brenner5 von sprut. Mein armer PIC hat gestern und heute wohl zwischen 50 und 100 Programmierzyklen über sich ergehen lassen müssen
strike.... ich habe den Fehler gefunden! Wenn man es weiß ist es logisch: Nachdem man das Kommando "Read Sector" abgesetzt hat, indem man zunächst den Wert 0x20 an die Datenleitungen D7:0 der CF-Karte anlegt und anschließend den Wert 0x07 (binär 111, ATA COMMAND REGISTER) an die Adressleitungen A2:0 anlegt, muß man vor dem Stroben über /OE natürlich den Wert 0x00 an A2:0 anlegen. Dies ist die Adresse des ATA DATA REGISTERs. Hier lag der Fehler bei mir. Das Auslesen des ständig gleichen Zeichens ist logisch, da der Inhalt des ATA STATUS REGISTERs ausgelesen wurde, dessen Wert sich erst beim nächsten Kommando-Zugriff auf die Karte ändert. @Daniel: Ich glaube, dass auch Du diesen Punkt übersehen hat. Ich programmiere das Ding in PIC-Assembler (MPLAB IDE v7.00) und verwende den PIC-Brenner5 von sprut. Mein armer PIC hat gestern und heute wohl zwischen 50 und 100 Programmierzyklen über sich ergehen lassen müssen. "Extreme Wartezeiten" sind für mich Schleifen ab 50ms Dauer, das sind für einen µC "Ewigkeiten", aber das braucht's ja jetzt nicht mehr... In welchem Mode ich letztlich arbeite ist mir wurscht, die Hauptsache ist es funktioniert. schlizbäda
Moinmoin! Ich hab nochmal in meinen Code geguckt und festgestellt, daß ich nicht vergessen hab, das richtige Register zu adressieren. Muß der Fehler doch woanders liegen. Gruß
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.