Hi, hat sich schon mal jemand beschäftigt, was die platsparendste Kombination von SPI-, SD-Karten- und FAT16 lib für AVRs ist? anforderungen: Hardware-SPI, die SPI-Lib hat muss also fast nix machen, nur die Zugriffe ein klein wenig kapseln. muss auch nicht interuptbasiert sein. SD-Lib: SDHC nicht benötigt fat16: nur eine geöffnete Datei nötig, keine Unterverzeichisse (nur Rootverzeichnis), keine langen Dateinamen. Hintergrund ist der, dass ich momentan selbst dabei bin, eine micro-Fat-Implementierung zu bauen. folgende Einschränkungen: siehe oben Anforderungen + es muss eine Datei enthalten sein, die in ihrer gesamten Größe fortlaufende Cluster belegt (einfach nach Formatierung auf PC eine große Datei drauf packen). Nach dieser wird gesucht (endung FRE), und der zugeordnete speicher roh beschrieben. Nach Abschluss der Datei wird ein neuer Dateieintrag angelegt mit startcluster der großen datei. Deren Startcluster wird verschoben und in der FAT noch der Endcluster markiert. Der Trick ist, dass man beim eigentlichen Schreiben die SD-Karte quasi im raw-Modus beschreibt und außer beim init und beim Datei beenden überhaupt keinen Filesystem-Verwaltungsaufwand hat. Gleichzeitig hat man den Komfort, die Daten bequem am Computer auslesen zu können. Dumm ist halt nur, dass man die 512Byte puffer trotzdem braucht. Da habe ich bisher keine wirklich gute idee, das zu veringern, wenn man das ganze dann trotzdem ganz normal (ohne extra-Programme) am PC handlen will. Das funktioniert auch ganz gut (atmega8). Nur bin ich bei mit der Weile auch bei einer Größe angekommen, wo ich mir nicht sicher bin, ob ich immer noch besser bin, als die kleinste bisher bestehende lib. Bevor ich Ewigkeiten suche und auf gut Glück die Libs zusammen packe, wollte ich mal fragen, ob sich damit schon mal jemand beschäftigt hat. Die die ich bisher gesehen habe, hatte zumindest viel mehr Codezeilen. Das ganze basiert rein auf sd_init/sd_read_block/sd_write_block, es sollte also kein Problem sein, die darunterliegenden librarie gegen die kleinstmögliche Kombination auszutasuchen. PS: die Idee zu diesem Ansatz hatte ich schon mal in irgend einem anderen Thread erwähnt. den konnte ich leider nicht mehr finden. Sollte das ganze fertig sein und ich ein bisschen aufgeräumt haben, werde ich das ganze auch in die Codesammlung packen. (vorausgesetzt es gibt nicht sowieso was besseres kleineres) Gruß, Vlad
Hi Vlad Don't know if it fits all your requirements :-) But it gets a lot of mention on AvrFreaks Petit http://elm-chan.org/fsw/ff/00index_p.html FatFs http://elm-chan.org/fsw/ff/00index_e.html /Bingo
Hallo Vlad, grundsätzlich ist es eine gute Idee, nicht allen Windows-Schnick-Schnack auf dem AVR nachbauen zu wollen. Ich denke selbst schon in dieser Richtung nach. Deine Lösung ist mir aber zu beschränkt. Faktisch wird die SD-Card damit zu einer Art CD-RW, die man einmal beschreiben kann, dann aber wieder komplett löschen muss. Außerdem bleibt die Unsicherheit, ob alle PC-Betriebssysteme die .FRE Datei wirklich immer in der von dir angenommenen Weise anlegen. Ich vermute, man könnte auch ohne eine solche Krücke ein "einmal" beschreibbares Medium machen, ohne mehr Aufwand zu treiben. Man muss zu Beginn nur den ersten freien Cluster in der FAT suchen, wenn man ihn von der letzten Schreib-Operation nicht ohnehin schon kennt. Dann muss man den ersten freien Dateieintrag finden, wenn man ihn... (s.o). Dann schreibt man munter drauf los, merkt sich die Dateigröße (die braucht man ohnehin für den Verzeichniseintrag). Wird die Datei geschlossen, muss man nur noch die Dateigröße in den Verzeichniseintrag schreiben, ((Dateigröße-1)/Clustergröße) fortlaufende Werte in der FAT belegen - und noch und einen Ende-Eintrag in die FAT. Fertig! Die "-1" erschlägt dabei den Sonderfall, dass die Dateigröße exakt ein Vielfaches der Clustergröße ist. Das ist vielleicht sogar noch kleiner als deine Lösung, aber wie gesagt aus meiner Sicht zu unflexibel. Gruß, DetlevT
Ich verwende die Elm Chan version und das funktioniert super. Die kannst Du mit entsprechendem #define auch als small mit weniger Funktionen bauen Gruß Tom
Detlev T. schrieb: > Deine Lösung ist mir aber zu beschränkt. Faktisch wird die SD-Card damit > zu einer Art CD-RW, die man einmal beschreiben kann, dann aber wieder > komplett löschen muss. Einsatzgebiet sind kleine Datenlogger. Die müssen meiner Meinung nach nicht mehr können. > Außerdem bleibt die Unsicherheit, ob alle > PC-Betriebssysteme die .FRE Datei wirklich immer in der von dir > angenommenen Weise anlegen. Das ist der einzig sinnvolle Weg. Warum sollte man in einer komplett leeren FAT die Cluster wild verteilen, wo gerade dies der große Schwachpunkt von FAT ist? Um sicher zu gehen, könnte man natürlich trotzdem ein Programm schreiben, was diee Datei anlegt, in dem es im RAW-Modus auf den Datenträger zugreift. Das hat den Vorteil, dass es schneller geht, da man keine Dummy-Daten auf die Karte schreiben muss, sondern direkt die Fat und die Files anlegt. Detlev T. schrieb: > [...] > Das ist vielleicht sogar noch kleiner als deine Lösung, glaub ich nicht. Da die Clusterverkettung erst hergestellt werden müsste. Bei meiner Variante existiert die schon und es muss nur der richtige Eintrag mit 0xFFFF markiert werden. lediglich das Anpassen des FRE-Eintrages würde entfallen. Weiter Vorteil hingegen ist, dass auf dem Datenträger noch andere Daten(Programme) untergebracht werden können, wenn die FRE-Datei nicht den gesamten Platz einnimmt. Außerdem stehen im Falle eines Absturzes oder Fehlers die gespeicherten Daten nicht in irgend welchen verlorenen Clustern, sondern in der FRE-Datei und können von da gerettet werden.
Thomas Burkhart schrieb: > Ich verwende die Elm Chan version und das funktioniert super. Die kannst > Du mit entsprechendem #define auch als small mit weniger Funktionen > bauen was ich bei dem aufjeden fall mir anschauen wollte, ist die sache, wie er das ohne den großen puffer macht. die SD-Karte kann man doch nur Sektor-weise schreiben. Lesen ist ja kein Problem, aber schreiben, da man ja auch die Daten, die man nicht verändert neu schreiben -also vorher lesen und speichern- muss.
>Nur bin ich bei mit der Weile auch bei einer Größe angekommen, wo ich >mir nicht sicher bin, ob ich immer noch besser bin, als die kleinste >bisher bestehende lib. Wo steht der Zähler denn jetzt?
holger schrieb: > Wo steht der Zähler denn jetzt? nur das fat ~1k sd write/read/init (nicht von mir) ~500 //Author: CC Dharmani, Chennai (India) // www.dharmanitech.com
>> Wo steht der Zähler denn jetzt? >nur das fat ~1k >sd write/read/init (nicht von mir) ~500 Dann mach dir keine Sorgen. Du bist weit unter den anderen;)
Bist du sicher, dass du FAT überhaupt brauchst? Es ist unter Windows relativ einfach, die komplette SD-Karte wie ein File zu öffnen (Ich habs bei NTRawWrite abgeschrieben) - und unter Linux ist es bestimmt noch einfacher.
sebastians schrieb: > Bist du sicher, dass du FAT überhaupt brauchst? Ist halt einfach eine Frage des Komforts. So kann man die Karte in jeden Rechner stecken und die Daten auswerten. Außerdem sind sie so gegen versehentliches Überschreiben geschützt, fals jemand voreilig auf OK, klickt, wenn windows feststellt, dass der Datenträger unformatiert ist. > Es ist unter Windows relativ einfach, die komplette SD-Karte wie ein > File zu öffnen so teste ich das ganze. Ich habe für die SD-Lib win32API-Erssatzroutinen geschrieben
Hallo, also so eine MMC/SD Karte ist SPI hörig. Wenn du den großen Puffer sparen möchtest kannst du immer byteweise lesen und analysieren. Wenn du den SPI Clock anhältst, bleibt die Karte quasi "stehen". Es würde aber wohl Sinn machen 32 Byte zu puffern, damit man wenigstens einen Datei/Ordner Eintrag puffern kann... Ach ja, wenn die Karte so mitten drin angehalten wird braucht die natürlich mehr Strom Grüße Daniel
Daniel R. schrieb: > Hallo, > also so eine MMC/SD Karte ist SPI hörig. Wenn du den großen Puffer > sparen möchtest kannst du immer byteweise lesen und analysieren. Wenn du > den SPI Clock anhältst, bleibt die Karte quasi "stehen". Es würde aber > wohl Sinn machen 32 Byte zu puffern, damit man wenigstens einen > Datei/Ordner Eintrag puffern kann... > Ach ja, wenn die Karte so mitten drin angehalten wird braucht die > natürlich mehr Strom das ist mir klar, aber wenn man fat benutzt muss man auch mal einen sector laden, einzelne Bytes manipulieren und dann wieder speichert. Da man ja nicht gleichzeitig lesen und schreiben kann (oder geht das), muss man den sector natürlich zwischenpuffern. im Rawmodus wäre das natürlich egal, da könnte man ja auch festlegen, dass nur die ersten 256 Bytes jedes Setors beschrieben werden, oder so vorgehen, wie du es beschrieben hast.
Vlad Tepesch schrieb: > Das hat den Vorteil, dass es schneller geht, da man keine Dummy-Daten > auf die Karte schreiben muss, sondern direkt die Fat und die Files > anlegt. Muß man sowieso nicht. Unter Java kann man einfach eine "RandomAccess" Datei öffnen, und sich mit "seek" den benötigten Platz reservieren lassen (steht natürlich ggf müll drin aber das ist ja sonst nicht anders). Dieses Verfahren wird oft von Programmen genutzt die sequentiell Daten schreiben (z.B. Videoverarbeitung) um Fragmentierung zu verhindern, anstelle die Datei dynamisch zu vergrößern. Sowas gibt es bestimmt auch für die WinAPI/C/C++...
Vlad Tepesch schrieb: > Thomas Burkhart schrieb: >> Ich verwende die Elm Chan version und das funktioniert super. Die kannst >> Du mit entsprechendem #define auch als small mit weniger Funktionen >> bauen > > was ich bei dem aufjeden fall mir anschauen wollte, ist die sache, wie > er das ohne den großen puffer macht. > die SD-Karte kann man doch nur Sektor-weise schreiben. > Lesen ist ja kein Problem, aber schreiben, da man ja auch die Daten, die > man nicht verändert neu schreiben -also vorher lesen und speichern- > muss. Es gibt einige Einschränkungen, wodurch er wohl auf einen großen Puffer verzichten kann, siehe http://elm-chan.org/fsw/ff/pf/write.html bei "Description" => "The write function has some restrictions listed below"
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.