Ich habe eine 2Gb SD karte und bekomme sie einfach nicht initialisiert..
belesen habe ich mich schon wie der Teufel..
Also die Karte hängt bei mir an einem Leistungsstarken 16Bit PIC..
SPI Mode ist 0, SPI Clock ist 1,2MHz, PIC und Karte laufen mit 3,3V.
Initialisiert wird die Karte etwa mit 200kHz dazu sende ich 150 Clockst,
die SS und MISO Leitung ist währenddessen high. Danach schalte ich SS
auf low warte ein paar 100 µs und sende den CMD0 mit 1,2MHz 40 0 0 0 0
56.. danach nochmall FF als Dummy und will danach eigentlich ne 01 als
Antwort von der Karte haben.. Die Karte antwortet allerdings immer mit
FF ...
Ein 10k Pull UP hängt am MISO...
Was mache ich denn falsch? Muss der CMD0 denn auch noch mit <400kHz
gesendet werden?? Das geht leider nicht der PIC ist wie erwähnt mit
70MIPS ziehmlich fix und mit allen Post und Pre Scalern komme ich im SPI
Clock nur auf 1,2MHz herunter. Achja der SPI läuft natürlich im 8 Bit
Modus
ich bin mir auch nicht ganz sicher ob ich beim senden zwischen den Bytes
ne kurze Wartezeit reinmachen muss.. habe aber schon beide Varianten
Probiert.. nix
oszi40 schrieb:> Mach doch mal die Gegenprobe ob sie überhaupt noch gesund ist an> einem> anderen Gerät. Daten ausgelesen?
Sie funktioniert im Rechner..
Habe jetzt mehrfach gelesen das die Karte 'ständig' geclockt werden muss
weil sie keinen eigenen clock für ihren Prozessor besitzt.. werde das
morgen mal probieren. Das ergibt iwi auch sinn da man ja noch vor der
Initialisierung die 74+ Clocks schicken muss
Gee schrieb:> auf low warte ein paar 100 µs und sende den CMD0 mit 1,2MHz 40 0 0 0 0> 56..
Na fast. CMD0 muss noch mit <=400 kHz gesendet werden, Du bist ja noch
im SD Mode. Die Checksumme für CMD0 ist außerdem 0x95, ohne die nimmt er
das Kommand gar nicht an.
Jim M. schrieb:> Gee schrieb:>> auf low warte ein paar 100 µs und sende den CMD0 mit 1,2MHz 40 0 0 0 0>> 56..>> Na fast. CMD0 muss noch mit <=400 kHz gesendet werden, Du bist ja noch> im SD Mode. Die Checksumme für CMD0 ist außerdem 0x95, ohne die nimmt er> das Kommand gar nicht an.
stimmt ist auch 95.. mache jetzt die gesamte init mit 200kHz geht
trotzdem nix..
Was komisch ist ich habe heute früh noch eine alte SD Karte mit 16MB
eingesteckt die hat er sofort erkannt.. mit dem alten Programm wo cmd0
noch mit 1,2MHz gesendet wurde.. allerdings hat das nur 3 mal geklappt
und seit dem auch hier nix mehr.. Karte funktioniert noch am Rechner..
> Habe jetzt mehrfach gelesen das die Karte 'ständig' geclockt werden muss> weil sie keinen eigenen clock für ihren Prozessor besitzt..
Die hat schon einen eigenen Clock, das ist also falsch. Das SD Interface
im SD sowie SPI mode sind aber vom CLK Flankengetriggert und der CLK
kommt eben immer vom Host. Damit kann die Karte keine Daten senden wenn
vom Host kein CLK kommt. Wenn man aber keine Daten erwartet braucht man
auch nicht zu clocken.
Weiter gehts mit FAT16... ich möchte die Startblock Adresse einer Datei
im Root Verzeichniss finden. Den Datei Name finde ich im Root Directory
in dem ich Sämtliche Blöcke vom PIC durchsuchen lasse.. diese befindet
sich aber relativ weit hinten auf der 2GB Karte so das mir der
Suchvorgang zu lange dauert.. Wie finde ich schneller die richtige
Adresse heraus?
Und stimmt es das die ersten beiden Bytes im Datenblock der Datei die
Adresse zum nächsten Datenblock beinhaltet oder habe ich das Falsch
verstanden? Ich mochte nach dem ich die Datei gelesen habe sie wieder
beschreiben, allerdings muss ich da ja Prinzipbedingt immer den
Kompletten Block von 512Bytes schreiben und überschreibe dann ja somit
auch die ersten beiden Bytes die die Startadresse zum nächsten Block
enthält die müsste ich ja dann wieder so unverändert übernehmen richtig?
Gee schrieb:> Wie finde ich schneller die richtige Adresse heraus?
Mit einem Cache. Wenn du nicht genug RAM dafür hast, hast du Pech.
Gee schrieb:> Und stimmt es das die ersten beiden Bytes im Datenblock der Datei die> Adresse zum nächsten Datenblock beinhaltet oder habe ich das Falsch> verstanden?
Der Datenbereich enthält Daten, keine Metadaten.
Die Verlinkungen der Cluster zueinander stehen in der FAT.
S. R. schrieb:> Gee schrieb:>> Wie finde ich schneller die richtige Adresse heraus?>> Mit einem Cache. Wenn du nicht genug RAM dafür hast, hast du Pech.
Das stimmt natürlich nicht.
FAT Adresse (Startcluster) kann man man auslesen, auch die Anzahl
der FATs und deren Größe.
(FAT Adresse + FAT Größe * Anzahl der FATs) ergibt Startadresse der
Rootdirectory.
Startsector der Rootdirectory + SecPerRootDir ergibt Startadresse
für Datasectors. Alle weiteren Directorys (falls vorhanden) befinden
sich in Datasectors.
Der Vorgang selbst ist allerdings ein bisschen komplizierter als es
sich liest.
Du wirst einiges mehr lesen (und verstehen) müssen, um überhaupt
so weit zu kommen...
Marc V. schrieb:>>> Wie finde ich schneller die richtige Adresse heraus?>> Mit einem Cache. Wenn du nicht genug RAM dafür hast, hast du Pech.> Das stimmt natürlich nicht.
Du hast natürlich die Weisheit mit Löffeln gefressen.
Wenn es zu lange dauert, einen Eintrag in der FAT zu finden - weil man
dazu einiges von der SD-Karte lesen muss - dann kann man einen Cache
implementieren, um diese Suchvorgänge abzukürzen, ergo die Suche zu
beschleunigen.
S. R. schrieb:> Du hast natürlich die Weisheit mit Löffeln gefressen.
Nein, aber du und dein Freund glauben, dass das bei Euch der
Fall ist...
> dann kann man einen Cache> implementieren, um diese Suchvorgänge abzukürzen, ergo die Suche zu> beschleunigen.
LOL.
Hast du überhaupt den Schimmer einer Ahnung von der Größe einer
FAT16 Tabelle ?
Bei 2GB SD-Card ?
Oder was passiert wenn bei einer halbvollen SD-Card eine kleine
Datei am Anfang mit einer grossen Datei überschrieben wird ?
Offensichtlich nicht...
Wundert mich aber bei dir und deinem Freund überhaupt nicht.
Hauptsache, wenn ich "Hü" sage, Ihr beide schreit sofort "Hott", ob
argumentiert oder nicht, ist absolut egal.
> Wenn es zu lange dauert, einen Eintrag in der FAT zu finden - weil man> dazu einiges von der SD-Karte lesen muss - dann kann man einen Cache
Man muss dazu bestimmt nicht einiges lesen um den Eintrag zu finden,
das wird ganz einfach berechnet (beim lesen).
Man muss nur wissen wie.
Soviel zu deiner Weisheit...
Moin .. also die Root Table finde ich mitlerweile Problemlos.. Habe seit
Stunden aber Probleme die richtige Adresse der ersten Datenblocks zu
finden..
Die Steht ja eigentlich bei Offset 1A in der Root Table nach dem
Dateinamen.. dort lese ich den Wert "2" aus.. Das erscheint mir zu
gering..
Desshalb finde ich den Anfang nicht.
Ich lasse den PIC gerade die ganze SD Karte nach der Zeichenfolge AAA
durchsuchen (das steht in meinem text File auf der Karte) und lasse mir
anschließend die Adresse anzeigen.
Leider dauert der Suchvorgang sehr lange.. SPI steht auf 3,5MHz aktuell
Gee schrieb:> Die Steht ja eigentlich bei Offset 1A in der Root Table nach dem> Dateinamen.. dort lese ich den Wert "2" aus.. Das erscheint mir zu> gering..
Und was steht in Offset 0x1B ?
Wenn FC dein Startcluster (2) ist:
StartSector ist dann (FC-2) * SectorsPerCluster + HiddenSectors +
FirstDataSector.
Gee schrieb:> Die Steht ja eigentlich bei Offset 1A in der Root Table nach dem> Dateinamen.. dort lese ich den Wert "2" aus.. Das erscheint mir zu> gering..
Vielleicht solltest du dir den Aufbau eines FAT File Systems mal näher
ansehen. Elm Chan hat da sehr gute Vorlagen geliefert.
Man findet die Daten recht schnell - wenn man systematisch vorgeht.
Der MBR sagt dir, wo deine Partition liegt. Lesevorgang 1
Den Aufbau der Partition und die Lage des Root Verzeichnisses findest im
Bootsektor. Lesevorgang 2
Das Rootverzeichnis kann etwas größer sein. Da musst du einige Sektoren
lesen, bis du deinen Filenamen hast. Bei 512 Einträgen sind das 32
Sektoren.
Der Verzeichniseintrag enthält dann den Startcluster für die Daten. Und
in der FAT steht, ob und wenn ja wo es weitergeht. Macht für eine kurze
Datei 36 Lesevorgänge. Keine Raketentechnik.
Marc V. schrieb:> Wundert mich aber bei dir und deinem Freund[wem?] überhaupt nicht.> Hauptsache, wenn ich "Hü" sage, Ihr beide schreit sofort "Hott", ob> argumentiert oder nicht, ist absolut egal.
Du hast angefangen zu argumentieren, und zwar erst gegen einen Strohmann
und dann ad hominem. Das ist keine Diskussionskultur, sondern dummes
Rumgezoffe.
In einer verketteten Liste (und die FAT ist nunmal nichts anderes) sind
Suchen immer linear und daran änderst du auch nichts. Willst du es
schneller haben, musst du (Teil-)Ergebnisse cachen, was aber erst ab der
zweiten Suche hilft. Das fängt schon damit an, dass du zwei Sektoren (2x
512 Byte) im Speicher hältst, um nicht ständig die FAT neu lesen zu
müssen.
Ich habe nicht geschrieben, dass er sich die gesamte FAT (oder sogar die
gesamte SD-Karte) in den RAM ziehen soll. Ich habe auch nichts zu
Fragmentierung geschrieben. Oder überhaupt irgendwas, weswegen du mich
gerade anpisst, denn woran du dich störst, schreibst du ja nicht. Was
soll das?
S. R. schrieb:> In einer verketteten Liste (und die FAT ist nunmal nichts anderes) sind> Suchen immer linear und daran änderst du auch nichts.
Will ich auch nicht.
Ein bisschen Arithmetik:
Bei 2GB Card mit FAT16 formatiert ist FAT Tabelle 128KB oder 256
Sectors. Clustersize muss 32KB betragen.
Ein Sector in FAT hält 256 Clusters, das sind 256*32KB = 8MB.
Wieviele Dateien grösser als 8MB (die für einen uC interessant sind),
befinden sich auf der Karte ?
Einen Sektor lesen (mit SPI) dauert ungefähr 2ms.
Einen ganzen Sektor prüfen (ob die Einträge die Sektorengrenze
überschreiten) dauert höchstens 50-100us. Wenn ich Filesize aus
der Directory benutze, dauert es noch weniger und ich weiss ob ich
noch einen Sector einlesen muss.
Warum soll ich dann 2 Sectors einlesen und am Start 2ms und
512 Bytes verlieren ?
> Oder überhaupt irgendwas, weswegen du mich> gerade anpisst, denn woran du dich störst, schreibst du ja nicht. Was> soll das?S. R. schrieb:> Du hast natürlich die Weisheit mit Löffeln gefressen.
mir ist beim Suchvorgang ein kleiner Fehler unterlaufen ich habe nach
AAA gesucht in wirklichkeit stand 1234 in der Datei.. er findet sie
jetzt quasi sofort.. Dadurch konnte ich nun die Adresse des Data
Clusters ermitteln sie beträgt HEX 00 04 10 00 ich komme aber im Moment
noch nicht Rechnerisch auf die genaue Adresse.. irgendwas mache ich noch
falsch bei der Berechnung..
Im Notfall könnte ich den Dateianfang auch mit einer Signatur Versehen
und somit habe ich auch ganz schnell deie Start Cluster ADR gefunden und
kann mit dem File arbeiten.. ist zwar ne russische Methode aber
funktionieren tuts.. Ne saubere Lösung wäre mir natürlich trotzdem
lieber
Muss das Ende der Datei noch irgtendwie markiert werden? Glaube ich habe
da was von 0xFF 0xFF gelesen
Marc V. schrieb:> Ein Sector in FAT hält 256 Clusters, das sind 256*32KB = 8MB.
Das heißt, wenn du eine 8 MB große Datei linear liest oder schreibst,
musst du diesen Sektor bis zu 256 mal von der SD-Karte lesen.
Marc V. schrieb:> Warum soll ich dann 2 Sectors einlesen und am Start 2ms und> 512 Bytes verlieren ?
Weil du nicht zwei FAT-Sektoren einlesen sollst, sondern den jeweils
aktiven FAT-Sektor plus den jeweils aktiven Datensektor. Ist das so
schwer oder willst du nicht verstehen?
Gee schrieb:> Muss das Ende der Datei noch irgtendwie markiert werden? Glaube ich habe> da was von 0xFF 0xFF gelesen
Jede Datei hat eine Größe, die steht im Inhaltsverzeichnis neben dem
Dateinamen. Mehr Bytes als da angegeben sind in der Datei nicht drin
(sie belegt aber trotzdem den kompletten letzten Cluster).
"Dateigröße modulo Clustergröße" ergibt also die Anzahl der gültigen
Bytes im letzten Cluster.
In der FAT - nicht in den Daten! - ist der letzte Cluster markiert, weil
er naturgemäß keinen Nachfolger hat.
S. R. schrieb:> Marc V. schrieb:>> Ein Sector in FAT hält 256 Clusters, das sind 256*32KB = 8MB.>> Das heißt, wenn du eine 8 MB große Datei linear liest oder schreibst,> musst du diesen Sektor bis zu 256 mal von der SD-Karte lesen.
Selbstverständlich nicht.
S. R. schrieb:> Marc V. schrieb:>> Warum soll ich dann 2 Sectors einlesen und am Start 2ms und>> 512 Bytes verlieren ?>> Weil du nicht zwei FAT-Sektoren einlesen sollst, sondern den jeweils> aktiven FAT-Sektor plus den jeweils aktiven Datensektor. Ist das so> schwer oder willst du nicht verstehen?
Nein, das ist weder schwer noch ist es das, was du behauptet hast:
S. R. schrieb:> Wenn es zu lange dauert, einen Eintrag in der FAT zu finden - weil man> dazu einiges von der SD-Karte lesen muss - dann kann man einen Cache> implementieren, um diese Suchvorgänge abzukürzen, ergo die Suche zu> beschleunigen.
P.S.
Lass es gut sein, im Gegensatz zu dir und deinem Freund bin ich nicht
nachtragend...
Gee schrieb:> jetzt quasi sofort.. Dadurch konnte ich nun die Adresse des Data> Clusters ermitteln sie beträgt HEX 00 04 10 00 ich komme aber im Moment
Das kann auf keinen Fall die Adresse eines Clusters sein.
Sektoradresse vielleicht, aber warum diese Datei erst nach 130MB
anfangen sollte und wie du sie trotzdem "quasi sofort" findest, ist mir
immer noch unklar.
Sind da noch andere Dateien auf der Card ?
Marc V. schrieb:> Das kann auf keinen Fall die Adresse eines Clusters sein.
Sektoradresse vielleicht, aber warum diese Datei erst nach 130MB
anfangen sollte und wie du sie trotzdem "quasi sofort" findest, ist mir
immer noch unklar.
Sind da noch andere Dateien auf der Card ?
Stimmt ich meinte die Adresse.. HEX 00 04 10 00 (DEZ 266.240)
sind gerade mal 260kB ;) Das geht natürlich sehr fix
Was mir sehr helfen Würde ist die genaue Formel zur Berechnung Der
Adrese des Startclusters meiener Datei und ich will wissen welche Zellen
aus der MBR ich dazu brauche. Alla [Anzahl der FATs] (zu finden unter
Offset xx) + x + x * x usw... ;) ohne unnötigen Schnick Schnack bitte :)
Das geht nicht, weil eine Datei keinen festen Platz auf der SD-Karte
hat.
Wenn du kein FAT implementieren willst, dann
(a) nimm eine fertige Bibliothek, oder
(b) lass FAT weg.
Hast du den Wikipedia Artikel gelesen und verstanden? Da sind schöne
Tabellen drin und Hinweise auf weiterführende Literatur.
Auch hier
http://elm-chan.org/fsw/ff/00index_e.html
findest du viele Infos und Beispiele.
S. R. schrieb:> Das geht nicht, weil eine Datei keinen festen Platz auf der SD-Karte> hat.>> Wenn du kein FAT implementieren willst, dann> (a) nimm eine fertige Bibliothek, oder> (b) lass FAT weg.
Desshalb rede ich von einer Formel zur Berechnung..
a: ist nicht mein Stil
b: ich brauche FAT
Georg G. schrieb:> Hast du den Wikipedia Artikel gelesen und verstanden? Da sind schöne> Tabellen drin und Hinweise auf weiterführende Literatur.>> Auch hier> http://elm-chan.org/fsw/ff/00index_e.html> findest du viele Infos und Beispiele.
Kenne die ganzen Artikel und habe die Formeln auch angewandt nur leider
komme ich imemr auf das falsche Ergebniss desshalb wäre es schön wenn es
jmd mit deinen eigenen Worten mal wieder geben könnte das ich es besser
verstehe
Vielleicht hätte ich am Anfang sagen sollen das es mir nur darum geht
die Adresse des ersten Daten Sektors meiner Datei zu ermitteln. Die
restlichen Fat Funktionen brauche ich nicht
ich würde die Berechnung der Adresse folgendermaßen angehen:
MBR OFFSETs:
0x10 = number of FATs (1 Byte)
0x11 = RD_ENTRIES (2 Bytes)
0x16 = size of FAT (2 Bytes)
RD OFFSETs:
1A = Starting cluster number for file (2 Bytes)
Root DIR Block Nummer= (size of FAT)x(number of FATs) + 1
(RD_ENTRIES x 32) / 512 = [Anzahl der Blöcke die das RD Groß ist]
[Anzahl der Blöcke die das RD Groß ist] + (Root DIR Block Nummer] -2= X
(X+[Starting cluster number for file]) x 512= Adresse des ersten
Datenblocks
Stimmt das so?
Gee schrieb:> S. R. schrieb:>> Das geht nicht, weil eine Datei keinen festen Platz auf der SD-Karte>> hat.>>>> Wenn du kein FAT implementieren willst, dann>> (a) nimm eine fertige Bibliothek, oder>> (b) lass FAT weg.>> Desshalb rede ich von einer Formel zur Berechnung..> a: ist nicht mein Stil> b: ich brauche FAT
Dann wirst Du Dich das nächste halbe Jahr damit beschäftigen müssen:
- Wie sieht eine Paritionstabelle aus? Ja, SD Karten haben eine.
- Wie sieht der erste FAT Sektor aus?
- Wo steht er? (S.o. Partitionstabelle).
- Was ist der Unterschied zwischen FAT16 und FAT32?
- Wie groß ist ein Cluster?
- Wie sieht ein Verzeichniseintrag aus?
usw. usf...
Die Initialisierung der SD Karte war die einfache Übung. FAT zu
implementieren ist kompliziert, da nimmt man besser was fertiges.
Gee schrieb:> Stimmt das so?
Nö. Partitionstabelle fehlt - die zeigt Windoof Dir übrigens nicht ohne
Admin Rechte an, das kann nicht jeder Hex Editor! Außerdem muss man mit
"reservierten Sektoren" im Boot Sektor rechnen, also Offset ab 0xE mit
einem Wert > 1.
Mal abgesehen davon ist die Formatierung, mit der SD-Karten kommen, oft
nicht die gleiche, wie wenn man in Windows einfach auf "Formatieren"
drückt.
Einfach hinzugehen und zu sagen "ab Sektor N finde ich die erste Datei
des Dateisystems" ist jedenfalls vieles, aber kein FAT. Scheint der TO
aber zu wollen.
Gee schrieb:> (X+[Starting cluster number for file]) x 512= Adresse des ersten> Datenblocks>> Stimmt das so?
Nein.
Und ohne dich ein bisschen zu bemühen, wird es auch nie stimmen.
Es wurde dir schon mehrmals angedeutet, dass SD-Card nicht gleich
SD-Card ist, Formatierung nicht gleich Formatierung ist...
Das einzige was bei deiner Card feststeht (weil 2GB und FAT16) ist,
dass Clustergrösse 32KB beträgt und FAT Tabelle 128KB gross ist.
Alles andere kann total verschieden sein.
Anbei dump von einer SD-CARD mit Debug Ausgabe.
Ich hab dir sowohl MBR als auch VBR ausgegeben.
Und Directory mit Long und Short Namen.
Wenn du das (einigermassen) verstanden hast, kannst du versuchen
herauszufinden wie die entsprechenden Adressen berechnet worden
sind und wo sich der erste Datasector befinden sollte.
Das ist alles kein Thema übertreibtmal bitte nicht so maßlos.. Mein
Programm ist jetzt schon dazu in der Lage mein File in der Root Dir zu
finden. Getestet mit: Der ursprünglichen Formatierung, mit der Win
Formatierung sowohl schnell als auch komplett, sowie mit dem Programm SD
Formatter.. ich finde den Eintrag immer.. ist alles kein Hexenwerk und
die Berechnung ist nunmal fest definiert und bei FAT generell gleich
sonst würde das alles nicht Funktionieren ;)
Gee schrieb:> Das ist alles kein Thema übertreibtmal bitte nicht so maßlos.. Mein> Programm ist jetzt schon dazu in der Lage mein File in der Root Dir zu> finden. Getestet mit: Der ursprünglichen Formatierung, mit der Win
LOL.
Aber nicht mit deinen Berechnungen. Vielleicht mit ein Sektor nach
dem anderen einlesen.
Und wo ist dein Problem wenn dein Programm schon alles kann ?
Ich bin raus.
See ya.
Richtig ich suche im gesamten Root dir einfach nach meinem Datei Namen
das dauert nur Sekunden Bruchteile und anhand dessen kann ich alle
weiteren Daten ermitteln die ich brauche. Voilà ..
Gee schrieb:> ist alles kein Hexenwerk und> die Berechnung ist nunmal fest definiert und bei FAT generell gleich> sonst würde das alles nicht Funktionieren ;)
Ich wünsche dir, dass dein Programm irgendwann mal nicht funktioniert,
und zwar dann, wenn du es wirklich brauchst und nicht die Zeit hast, es
zu reparieren.
Aber ohne Totalschaden, bin ja kein Unmensch.
