Hallo, ich steuere eine 32MB-CF-Karte mit einem PIC an. Sektoren lesen uns schreiben geht einwandfrei. Jetzt bin ich dabei, ein Dateisystem zu implementieren. Hierzu habe ich die Karte mit FAT16 formatiert und um zu testen eine kleine Textdatei draufkopiert (test.txt). Diesen Eintrag möchte ich in der Dateizuordnungstabelle (FAT) wieder finden. Aber an welchen Position steht diese? Soweit ich weiß ist diese relativ abgelegt und wird folgender Maße ermittelt: Aus dem MBR (Master BOOT RECORD) nimmt man 2 byte von der Position 0x01C6. Hier also 0x654D (MBR s.u.). Dies soll dann die Anfangsadresse des VBR sein (VOLUME BOOT RECORD) in Sektoren sein. Im VBR nimmt man dann an Position 0x0E wieder einen 2 byte Wert raus. Das soll dann die Anzahl der reservierten Sektoren sein. Diese zwei 2-byte-Werte müssen dann addiert werden, und man erhält die Anfangsadresse der Dateizuordnungstabelle. Quelle: 2 Byte-Wert lesen von Sektor 0, Position 1C6h, das ist Master Boot Record 1. Partitionseintrag (1BEh) 1C6h-1BEh=8 an dieser Stelle in dem Partitionseintrag ist ein Wert abgespeichert, der der Abstand zwischen MBR-Sektor und dem ersten Sektor der Partition in Sektoren angibt. Diese 2 Byte-Wert in AL übertragen, AL enthält jetzt Anfangadresse des Volume Boot Records. 2 Byte-Wert lesen von Sektor =Anfangadresse des Volume Boot Records, Position Eh. Das ist Anzahl der reservierten Sektoren. Anfangadresse des Volume Boot Records addieren mit Anzahl der reservierten Sektoren und Ergebnis in Variable "FAT" speichern. Das ist nämlich Anfangsadresse der FAT- Tabelle. Aber ich finde ja nicht einmal zum VBR mit dieser Methode!! Kennt sich jemand damit aus? Was mache ich falsch oder stimmt diese Quelle überhaupt? Die Dateizuordnungstabelle steht glaube ich bei mir an Position 0x03D000, da ich hier mit dem HEX-Editor den string test.txt wieder finde. Aber wie berechne ich das richtig? Hier ist der MBR: EB 3C 90 4D 53 44 4F 53 35 2E 30 00 02 01 02 00 02 00 02 60 F4 F8 F3 00 3F 00 FF 00 20 00 00 00 00 00 00 00 00 00 29 5A D5 72 9C 4E 4F 20 4E 41 4D 45 20 20 20 20 46 41 54 31 36 20 20 20 33 C9 8E D1 BC F0 7B 8E D9 B8 00 20 8E C0 FC BD 00 7C 38 4E 24 7D 24 8B C1 99 E8 3C 01 72 1C 83 EB 3A 66 A1 1C 7C 26 66 3B 07 26 8A 57 FC 75 06 80 CA 02 88 56 02 80 C3 10 73 EB 33 C9 8A 46 10 98 F7 66 16 03 46 1C 13 56 1E 03 46 0E 13 D1 8B 76 11 60 89 46 FC 89 56 FE B8 20 00 F7 E6 8B 5E 0B 03 C3 48 F7 F3 01 46 FC 11 4E FE 61 BF 00 00 E8 E6 00 72 39 26 38 2D 74 17 60 B1 0B BE A1 7D F3 A6 61 74 32 4E 74 09 83 C7 20 3B FB 72 E6 EB DC A0 FB 7D B4 7D 8B F0 AC 98 40 74 0C 48 74 13 B4 0E BB 07 00 CD 10 EB EF A0 FD 7D EB E6 A0 FC 7D EB E1 CD 16 CD 19 26 8B 55 1A 52 B0 01 BB 00 00 E8 3B 00 72 E8 5B 8A 56 24 BE 0B 7C 8B FC C7 46 F0 3D 7D C7 46 F4 29 7D 8C D9 89 4E F2 89 4E F6 C6 06 96 7D CB EA 03 00 00 20 0F B6 C8 66 8B 46 F8 66 03 46 1C 66 8B D0 66 C1 EA 10 EB 5E 0F B6 C8 4A 4A 8A 46 0D 32 E4 F7 E2 03 46 FC 13 56 FE EB 4A 52 50 06 53 6A 01 6A 10 91 8B 46 18 96 92 33 D2 F7 F6 91 F7 F6 42 87 CA F7 76 1A 8A F2 8A E8 C0 CC 02 0A CC B8 01 02 80 7E 02 0E 75 04 B4 42 8B F4 8A 56 24 CD 13 61 61 72 0B 40 75 01 42 03 5E 0B 49 75 06 F8 C3 41 BB 00 00 60 66 6A 00 EB B0 4E 54 4C 44 52 20 20 20 20 20 20 0D 0A 44 61 74 65 6E 74 72 84 67 65 72 20 65 6E 74 66 65 72 6E 65 6E FF 0D 0A 4D 65 64 69 65 6E 66 65 68 6C 65 72 FF 0D 0A 4E 65 75 73 74 61 72 74 3A 20 54 61 73 74 65 20 64 72 81 63 6B 65 6E 0D 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 AC C4 D3 55 AA Nebenbei: Bei 32 MB: Sektorgröße ist immer 512 byte, hier 4 Sektoren pro Cluster = 2KB Clustergröße. Alex
Moment mal, es gibt eine FAT und es gibt DIR-Einträge! Wo Du den ersten Cluster einer Datei findest, steht im DIR-Eintrag. Wo die folgenden Cluster sind, steht in der FAT. Es ist eine verkettete Liste. Die ersten beiden FAT-Einträge geben den Media-Typ und Größe an. Dann kommt der Eintrag für den 2. Datencluster (Erster Cluster der ersten Datei): Das ist die Nummer des nächsten Clusters (also wenn unzerstückelt 3) usw. Wenn es der letzte Cluster ist, steht FFFF oder FFFE drin. Die FAT steht zweimal auf der Platte, Inhalt sollte gleich sein, sonst stimmt was nicht (CHKDSK brint Fehler). Wenn Du die guten alten DOS-Norton-Utilities hast, kannst Du mit NU das genau nachvollziehen.
Hi Bei mir funzt das Sektorlesen auch, allerdings scheinen bei mir alle Sektoren um 32 Sektoren verschoben, das heißt ich will eine mp3 die laut WinHEX in sektor 528 anfängt an meinen mp3 decoder senden und muss damit das passt sektor 560 angeben...??? Irgendwie komisch oder?? Die register der flash karte beschreibe ich eigentlich alle korrekt. Woran kann das liegen?? Werde sobald das bei mir mit den Sektoren passt auch mit FAT anfangen MFG Jörn
Hallo Profi, gut zu wissen, das die Position der Datei im DIR-Eintrag steht. Dennoch benötige ich demnach die Position von FAT und DIR um eine Datei auslesen zu können. Wie finde ich nun diese beiden Tabellen. Ich würde das ganze gern allgemeingültig programmieren, dass es auch mit anderen Karten funktioniert. Hallo Jörn, schon lange nicht mehr gesprochen!! Das du 32dez mehr auf deinen Adressen hast scheint normal zu sein. Das ist halt ein Offset! Ich habe dies mit 16, 32 und 256 MB ausprobiert. Das schein immer so zu sein. z.B. beim auslesen der Sektrorgröße über das Identifycomand ist auch ein offset von 64dez drauf. Ich weiß zwar auch nicht was das soll, aber ist halt so. Gruß Alex
Hi, Oh dann bin ich ja beruhigt, hab schon gedacht ich mache was falsch ;-) Dann werd ich die 32 standartmäßig in meiner sektor lesen funktion draufrechnen, dann kann ich wenigstens mit sector 0 anfangen ist dann nicht so verwirrend.. MFG Jörn
mir hat diese seite weitergeholfen http://home.teleport.com/~brainy/fat16.htm zusätzlich natürlich noch die beschreibung von microsoft gabs glaub oich auch irgendwo auf der seite
Hi ape, die Seite ist echt gut, aber ich komme immernoch nicht zu meiner FAT bzw. Root Directory. Die Vorgehensweise scheint zu stimmen: Im MBR beginnt der erste Partionseintrag bei der Position 1BEh. Dann zähle ich noch 8 drauf und bin bei 1C6h. Hier steht ein Word, welches die Anzahl von Sektoren zwischen dem MBR und dem ersten Sektor in der Partion angibt. Dieser erste Sektor ist der FAT16 BOOT RECORD. Im MBR (siehe erster Forumseintrag) steht bei 1C6h der Wert 654Dh (lowbyte bei 1C6H und highbyte bei 1C7H). Dieser Wert multipliziert mit Bytes pro Sektor (512 dezimal = 200h): 654Dh * 200h = CA9A00h. Mit dieser Position befinde ich mich schon im Datenbereich. Das kann doch nicht sein!! Ist vielleicht ein Offset auf dem Word bei 1C6h im MBR oder wie lässt sich das erklären? Weißt du hier Rat??? Gruß Alex
Hi,
scheint so als würde Dir beim Einlesen der Sektoren ein Fehler
unterlaufen, denn der Sektor im ersten Forumsbeitrag ist nicht der MBR,
sondern bereits der Bootsektor ("EB 3C 90" ist die jump instruction).
WinHex zeigt diese ersten Sektoren nicht an.
mhmm also irgendwas kann da noch nicht stimmen, der boot record sollte recht weit vorne stehen bin mir nicht mehr ganz sicher was für einen wert da hatte ich glaube 32 oder sowas, und warum multiplizierst du den wert mit den bytes pro sektor? funktioniert dein datenlesen einwandfrei? ich habe das ganze mit einer mmc implementiert hat schon alles funktioniert aber mittlerweile lese ich nur noch müll von der karte, hab noch nicht näher untersucht woran es liegt die karte geht jedenfalls im pc noch, aber der avr löiest nur noch datenschrott von ihr.
Ich lese den 1. Sektor der Karte. An der Stelle 1BEh + 08h steht die Sektornummer des 1. Sektors der 1. Parition. Dann diesen Sektor lesen. Dort steht jetzt an Stelle 00Dh die Anzahl der reservierten Sektoren, dies zu dem 1. Sektors der 1. Parition addieren und man hat den 1. Sektor der 1. FAT. Jetzt multipliziert man die Werte an Stelle 010h (Anzahl der FATs) und 016h (Anzahl der Sektoren pro FAT) und addiert 1. Sektor der 1. FAT dazu, als Ergebnis hat man dann der 1. Sektor des Root-Verzeichnisses. Interessant ist noch der 1. Sektor des Datenbereiches, den erhält man indem man den Wert aus Stelle 011h (Anzahl der Verzeichniseinträge in der Root) liest mit 32 multipliziert durch den Wert an Stelle 00Bh (Bytes pro Sektor) teilt und nochmal den 1. Sektor des Root-Verzeichnisses addiert. Jetzt hat man den Begin aller 3 wichtigen Bereiche. Liest man jetzt den 1. Sektor des Root-Verzeichnisses das Wort an der Stelle 01Ah bekommt man den Anfangscluster der 1. Datei. Man subbtrahiert 2 (wegen den ersten 2 Stellen in der FAT), multipliziert mit Sektoren pro Cluster (steht im 1. Sektors der 1. Parition and Stelle 00Bh) und addiert 1. Sektor des Datenbereiches. Damit kann man jetzt beginnen den Inhalt der Datei zu lesen, und zwar genau die Anzahl der Sektoren pro Cluster. Um den nächsten Cluster der Datei zu bekommen, teilt man die letzte Clusternummer durch 2 (2 Bytes pro FAT-Eintrag) und liest den Wert aus der FAT. Schon hat man den 2. Cluster der Datei und kann den Inhalt der Datei wieder der Sektoren pro Cluster lesen. Die Länge der Datei steht im Dir-Eintrag ab Stelle 01Ch. So, das war's erstmal.
Hallo Leute, vielen Dank für euer Beiträge. Ich hab jetzt alle wichtigen Bereiche gefunden. Mein Fehler war, dass ich nicht wusste, dass WinHex erst ab dem BootSektor anzeigt, den ich dann für den MBR hielt. Jetzt erklärt sich auch mein Offset von 32dez bei der Adressierung der CF-Karte. Weiß vielleicht jemand noch, warum in der FAT die ersten 4 bytes immer F8 FF FF FF sind? Profi hat was von Media-Typ und Größe geschrieben. Was ist der Media-Typ und welche Größe ist gemeint? Gruß Alex
F8 FF und FF FF signalisieren immer das Ende einer Cluster-Chain warum sie Am Anfang der FAT stehen weiß ich auch nich aber es ist normal :)
ich hab gerad mal nachgeschalgen: das erste byte der fat ist der media descriptor (ein überbelibsel aus alten zeiten) und der rest ist standardmässig mit 0xff aufgefüllt - bis zum beginn der fat einträge (byte 5 müsste das sein) der code 0xf8 steht schlicht und ergreifend für festplatte, 0xf0 ist für die gute alte diskette und andere code kann ich dir nicht sagen, da mein buch hier von 1988 ist :)
Hallo Leute, im Bootsector steht unter der Adresse 11h "Maximum Root Directory". Also die maximalen Einträge im DIR-Verzeichnis. Hier stehen 512 drin. Das kann doch aber nicht sein, dass man nur 512 Dateien abspeichern kann. Wird dann noch eine weitere Tabelle angelegt oder muss dann ein neues Verzeichnis erstellt werden? Alex
das hauptverzeichniss ist eine statische datenstruktur, wird einmal beim formatieren angelegt und kann danach nicht mehr verändert werden
Hallo, das steht auch alles im Hardware White Paper von Microsoft. Such mal nach "fatgen103.pdf"
Hi, passt vielleicht nicht ganz zum thema, aber mein mp3 player funzt jet :-). Allerdings nur mit einer frisch formatierten karte, da ich aus dem root directory nur den start und endsector pro datei auslese... MFG Jörn
Hi, einen Dateinamen im Dir-Verzeichnis zu finden und den Anfangscluster der Datei auszulesen ist soweit kein Problem. Alle weiteren Cluster der Datei stehen in der FAT. Wie bekomme ich aber die Verbindung zwischen meinem Anfangscluster und den weiterern Clustern der Datei? Muss man hierzu die Anzahl der gültigen Dateien im Dir-Verzeichnis zählen und dann diese mit der Anzahl der "End Of Files" in der FAT in Verbindung bringen? Das stell ich mit etwas umständlich vor, wie geht das? Alex
Du siehst in der FAT nach. Als Index benutzt Du den Anfangscluster. In dem so gefundenen FAT-Eintrag steht 'ne Nummer - das ist die Nummer des Folgeclusters. In dessen Eintrag steht wiederum die Folgenummer - das ganze wird solange fortgesetzt, bis im Eintrag des letzten zur Datei gehörenden Clusters ein EOF steht. Beispiel: Datei startet an Cluster 7 FAT 07 - 08 08 - 09 09 - 10 10 - EOF Das ist eine Clusterkette 7-8-9-10 So können auch Lücken in der Datei realisiert werden (was Fragmentierung genannt wird): 07 - 08 08 - 12 09 - 11 10 - EOF 11 - EOF 12 - 13 13 - EOF Hier haben wir drei Clusterketten, 7-8-12-13, 9-11 und 10, was drei unterschiedlich großen Dateien entspricht. Alles klar?
Hi Rufus, danke für die Auskunft. Ich wusste nicht, dass ich den Anfangscluster so einfach als index in der FAT verwenden kann. Sehe ich das richtig, dass der Wert, den ich über den Anfangscluster finde, wiederum ein INDEX der FAT ist, an dem der nächste cluster zu finden ist? Somit wäre nämlich die FAT eine einfachverkettete Liste, was dann auch Sinn macht. Gruß Alex
Du siehst das richtig - genau so funktioniert die FAT. FAT12 auszuwerten macht keinen Spaß - das wirst Du auch schon 'rausgefunden haben. FAT16 oder FAT32 sind da viel angenehmer, die kann man nötigenfalls auch von Hand im Hexdump lesen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.