COMPACT FLASH-Card

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

sorry,

irgendwie hab ich das Ding jetzt 2mal abgeschickt


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ß