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
Mach doch mal die Gegenprobe ob sie überhaupt noch gesund ist an einem anderen Gerät. Daten ausgelesen?
Oder schaue, ob sie mit der Microchip Library funktioniert.
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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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
im Moment ist er gerade mal bei 250MByte und der Datablock könnte ja auch ganz hinten liegen dasnn dauert das hier noch ein paar Stunden ._.
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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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 ?
Kann ja eine Byte Adresse und nicht LBA sein, dann wären wir bei nach 260kbyte. Bei SD v1 wohl auch wahrscheinlich....
Marc V. schrieb: > Lass es gut sein, im Gegensatz zu dir und deinem Freund bin ich nicht > nachtragend... Welchem Freund?
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.
:
Bearbeitet durch User
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
Da du nicht weißt, welcher Verzeichniseintrag auf deine Datei zeigt, geht das nicht. Was du implementierst, ist kein FAT.
Der erste Cluster, den die Datei verwendet, steht direkt im Verzeichnis bei Offset 27-28. Direkt dahinter steht dann die Filegröße in Bytes. https://social.technet.microsoft.com/wiki/contents/articles/6771.the-fat-file-system.aspx ist lesenswert. Noch einfacher kann man es wirklich nicht schreiben. Die Bilder allein im Artikel sollten schon ausreichen.
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.
:
Bearbeitet durch User
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.
Gee schrieb: > Das ist alles kein Thema übertreibtmal bitte nicht so maßlos Wenn dem so ist, warum eierst du dann hier tagelang erfolglos herum?
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.