mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik kleinste SPI-SD+Fat Lib für AVR


Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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;)

Autor: sebastians (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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++...

Autor: M. G. (looking)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.