www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SD Karte warten lassen


Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich hab eine Frage zur Ansteuerung von SD-Karten:

Ich möchte die Verwedung eines 512B großen Puffers vermeiden, da ich nur 
nen mega8 habe und eigendlich ein double buffering machen möchte.

Meine Idee war folgende:
Da der µC der Karte ja den Takt vorgibt könnte man die Karte ja warten 
lassen und die Bytes nach und nach schicken.
Oder spricht da was dagegen?

Anwenungsfall ist ein GPS-Logger.
Die Daten purzeln da Byteweise in einen Empfangspuffer der UARt und in 
der Hauptschleife hole ich sie da raus und schicke sie an die SPI.

die idee war halt ein Sector-schreib-zyklus zu starten und dann 
byteweise reinschieben, immer wenn ein neues Datum anliegt.
sind die 512byte voll, schließt man den Sektor und öffnet den nächsten

(habe ein quasi-Raw-Format - fat 16 mit einer riesen dummydatei, die 
continuierlich über den gesammten Platz verteilt ist)

Spricht was gegen diesen Ansatz, oder sollte das funktionieren?
Die frage ist halt, bekommt die Karte das mit, dass zwischen den Bytes 
mehr Zeit vergeht. Gibts da timeouts, oder sind die wirklich komplett 
der spi-clock hörig?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Spricht was gegen diesen Ansatz, oder sollte das funktionieren?
>Die frage ist halt, bekommt die Karte das mit, dass zwischen den Bytes
>mehr Zeit vergeht. Gibts da timeouts, oder sind die wirklich komplett
>der spi-clock hörig?

Das müsste klappen. Bei meinen SD Karten Versuchen stört
z.B. ein Timer Interrupt nicht die Bohne. Sie sind
"spi-clock hörig" ;)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das geht, kann ich bestätigen.
Problem ist dann nur, das die Karte viel Strom zieht. Sollte man sich 
bei einem GPS Logger überlegen. Der wird ja wohl mit Batterie laufen.

Aber mega8 und 512 Byte Puffer schließen sich nicht aus. Geht wenn die 
Anwendung die darauf läuft nicht auch noch Unmengen statischen RAM 
braucht ohne Probleme. Problem wird da dann eher der Flash fürs Programm 
werden...

Grüße Daniel

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klingt interessant Vlad.
Hast du irgendwo Spec zur SD Card gefunden?
Soweit ich weiss gibt es keine offene, nur als reverse engeeread.
Drum bin ich erstaunt dass die SPI versteht.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
nö, also vom Programm bi nich erst bei der Hälfte, wobei das meiste 
schon drin ist (SD, uart, lcd, Benutzerinterface).
Was fehlt sind noch ein paar Routinen um den empfangenen String zu 
zerlegen um am display ein par infos auszugeben (Satelitenanzahl, 
Uhrzeit, ev. Position)

Ich hab lediglich noch ein paar kleinere Probleme mit der SD-Ansteuerung 
und wollt halt wissen ob es daran liegen kann, das man das doch nicht so 
machen sollte.

Tatsächlich hab ich momentan einen Multisectorwrite offen, den ich wie 
beschrieben behandle.
nach beenden des Logging (und schließen des multiblockwrite) scheitert 
jedoch ein restartem eines Nächsten loggingvorgangs.
Das scheint dafür zu sprechen, das etwas mit der deinitalisierung nicht 
stimmt.


Ich poste mal den von mir angepassen Sd-code, vielleicht hat jemand Bock 
mal rein zu scheuen. benutzt werden die SD_writeMultiBlockXXX funktionen
SD_writeMultiBlockStart, SD_writeMultiBlokByte, SD_writeMultiBlockFinish

Falls ihr euch wundert, warum die 4Post heist: ich hab noch ein wenig 
aufgeräumt (auskommentierter code)

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Markus
???

Da gibts doch genug quellen.
Deswegen sind die ja so beliebt, bei Bastler projekten. Deswegen und 
wegen dem an sich verhältnismäßig unkompliziertem SPI-Mode.

Nur wird in allen quellen, die ich bisher gesehen habe immer ein 512Byte 
Puffer verwendet, was ich gerne vermieden hätte.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber warum vermeiden? Ist doch zu Lasten vom Strom Verbrauch. Soll der 
Logger nicht mit Batterie betrieben werden?
Es besteht ja auch noch die Möglichkeit die 512 Bytes Dynamisch zu 
verwalten.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Wurschteln mit Mega8 und SD-Karte ist kontraproduktiv. Setze einen 
Mega168p auf die Lötpads, ist direkt pinkompatibel, hat mehr Speicher 
und mehr Funktionalität.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja wegen dem 168 bin nich auch schon ne weile am Überlegen. Aber Mega8 
hab ich noch zwei da. die 168 müsste ich erst bestellen. (die 8er kriegt 
man ja schon für 0,60€, die 168 kosten immhin noch 3,50 - zumindest sind 
das die Buchtpreise)

Ist der Stromverbrauch so unterschiedlich? was verbraucht denn so ne SD 
Karte?

Ich hätt angemommen im Vergleich zur GPS maus geht das im Rauschen 
unter.

Werd heut Abend noch mal ins Datasheet schauen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 168er krigst Du bei CSD-electronics für 2.75 bzw. 2.45 ab 10 Stück 
plus Versand.

>Ist der Stromverbrauch so unterschiedlich? was verbraucht denn so ne SD
>Karte?

Zwischen 30 und 100mA beim Zugriff, deselektiert entschieden weniger.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. schrieb:
> Die 168er krigst Du bei CSD-electronics für 2.75 bzw. 2.45 ab 10 Stück
> plus Versand.

genau: plus Versand.
Die von mir genannten Preise sind inclusive Versand bei 5 Stück.

>
>>Ist der Stromverbrauch so unterschiedlich? was verbraucht denn so ne SD
>>Karte?
>
> Zwischen 30 und 100mA beim Zugriff, deselektiert entschieden weniger.
Oh, mit soviel hätt ich nicht gerechnet.

Ich solltes wohl doch dann als Block auf einmal schreiben.

Ich bin mir fast sicher, dass ich das auch so in den Mega bekomme, 
allerdings muss ich dann wahrscheinlich die Bytes aufm Stack zählen, 
damit der nicht in den statischen speicher reinläuft.

Kriegt man beim avr-gcc irgendwo raus, wieviel stack jede Funktion 
braucht?
Oder kriegt der Compiler es sogar mit, wenn der Stack zu groß werden 
würde?

dynamische Speicherverwaltung gibts ja nicht, also sollte das alles 
vorhersagbar sein, wenns keine Rekursion gibt.


Edit:
der worst case ist ja der call der Interuptroutine mit dem größten 
Stackverbrauch in, in dem stackmäßig tiefstem Codezweig

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Versand bei CSD würde gerade mal 2.50EUR für einen 
Luftpolsterumschlag mit 5 oder 10 Controllern betragen. Außerdem finde 
ich es mehr als fraglich, weshalb Du für die paar Cent Spagat und 
Klimmzüge gleichzeitig machen willst. Da Du mit den Geräten nicht in 
Serie gehen willst, spielt der Kostenfaktor bei diesen Werten gleich gar 
keine Rolle. Aber Du kannst natürlich auch die Herausforderung annehmen, 
um dann später doch 'in den Sack zu hau´n'...

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht reizt mich ja auch nur der effiziente Umgang mit den 
vorhandenen Ressourcen.

Außerdem benutze ich immerhin schon mal nen Mega8 und keinen tiny13 ;-P

Aber im ernst: die Mega8 hab ich halt da. die anderen müsste ich 
bestellen, inklusive Wartezeit.

Un dann wär der Mega vom Programm fast leer, die Pins aber fast alle 
belegt.
Das ist doch unbefriedigend.

Und da ich mir sicher bin, dass es auch mit dem 8er auch geht, probier 
ichs erst mal da.
Aber schlimm verrenken werd ich mich nicht, wenns doch nicht geht, dann 
wechsel ich halt.
Die m168 Option hatte ich aber von Anfang an im Hinterkopf.

Da geht dann auch ne vernünftige fat16lib mit drauf.

Meine derzeite variante würde ich erst ganz zum Schluss erweitern, dass 
sie pro Logging eine eigene Datei anlegt. Hab da auch schon nen Plan für 
die Umsetzung im Hinterkopf, wie man das richtig Code und 
speicherschonend unter bestimmten Voraussetzungen hinbekommt

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber im ernst: die Mega8 hab ich halt da. die anderen müsste ich
>bestellen, inklusive Wartezeit.

Wenn Du vor 13.00 Uhr bestellst, hast Du sie morgen zum Mittag.

>Aber schlimm verrenken werd ich mich nicht, wenns doch nicht geht, dann
>wechsel ich halt.
>Die m168 Option hatte ich aber von Anfang an im Hinterkopf.

Andersrum wird ein Schuh draus: Auf einem größeren Controller wird 
entwickelt, wenn ein kleinerer reicht, wird herunterportiert.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also dynamische Speicherverwaltung gibt es bei C nicht geschenkt, aber 
mit calloc und malloc kann man das selber machen.

Ich bekommen eine ausgewachsene FAT 16/32 Lib auf nen mega8 und dann ist 
da noch reichlich Platz für eine Logging Software.

Ich hab hier eine MMC Karte die zieht um die 120mA wenn man die so im 
Schreibvorgang hängen lässt...

Das mit dem "ich mache eine große Datei auf der Karte" gefummel ist nix. 
Es gibt bei Conrad für 1,5 einen 3 Farad Goldcap (8x20mm). Als Notstrom 
um die FAT zu sichern reicht der völlig aus !

Nix für ungut...

Grüße Daniel

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Platte schrieb:
> Hallo,
>
> also dynamische Speicherverwaltung gibt es bei C nicht geschenkt, aber
> mit calloc und malloc kann man das selber machen.
>
soltle man auf µCs ohne MMU nicht benutzen - tue ich auch nicht

> Ich bekommen eine ausgewachsene FAT 16/32 Lib auf nen mega8 und dann ist
> da noch reichlich Platz für eine Logging Software.
beweise!
Die fat implementierungen die ich bisher gesehen habe füllen den zu 
mindestens 75%

>
> Das mit dem "ich mache eine große Datei auf der Karte" gefummel ist nix.

Doch es funktioniert sehr gut.
Man kann die Karte im raw-modus beschreiben und kommt trotzdem am PC an 
die Daten und hat sie vor versehendlichen Überschreiben geschützt.

die erweiterung, die ich im Hinterkopf habe, splitt die große Datei dann 
nach loggingende in den ersten bescriebenen Teil und einer neuen großen 
Restdatei. Alles was dafür nötig ist, ist ein weiterer 
Verzeichniseintrag, sowie die veränderung zweier Bytes in den FATs.


> Es gibt bei Conrad für 1,5 einen 3 Farad Goldcap (8x20mm). Als Notstrom
> um die FAT zu sichern reicht der völlig aus !
>
> Nix für ungut...
>
> Grüße Daniel

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich steuere bei meinem LED-cube die LEDs über schiftregister an, welche 
an meinem SPI-bus hangen. gleichzeitig hängt eine SD-card am selben 
SPI-bus. wenn ich nun daten von der SD lese, wird diese kommunikation 
immer wieder durch die aktualisierung der LEDs unterbrochen (ich habe es 
so gelösst, dass in dieser zeit auch kein takt die SD erreicht). und es 
funktioniert einwandfrei.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die fat implementierungen die ich bisher gesehen habe füllen den zu
>mindestens 75%

Was willst du denn für einen Logger bauen? soll der mit double Variablen 
auch die Position berechnen? Wofür benötigst du da noch so viel Platz 
für Code. 25% reichen doch völlig aus.

>Doch es funktioniert sehr gut.
>Man kann die Karte im raw-modus beschreiben und kommt trotzdem am PC an
>die Daten und hat sie vor versehendlichen Überschreiben geschützt.

>die erweiterung, die ich im Hinterkopf habe, splitt die große Datei dann
>nach loggingende in den ersten bescriebenen Teil und einer neuen großen
>Restdatei. Alles was dafür nötig ist, ist ein weiterer
>Verzeichniseintrag, sowie die veränderung zweier Bytes in den FATs.

Also ob man jetzt ne Datei anlegt und diese nach Loggingende normal 
schließt. Oder ob man erstmal eine Datei anlegt die die ganze Karte 
ausfüllt, dann am ende diese beschneidet und ne neue Datei anlegt die 
wieder die ganze Karte einnimmt, erscheint mir in keiner weise 
einfacher/bequemer oder sonst vorteilhafter.
Mann muss doch auch im "raw-modus" wissen ab wo man schreiben kann usw. 
man muss also die gleichen Sachen machen wie im nicht "raw-modus"...

Das es auch so wie von dir beschrieben funktioniert zweifel ich ja 
garnicht an nur ist das nicht mehr FAT...

Da könnte man sich direkt die Daten einfach so auf die Karte schreiben 
und dann auf PC Seite eine Software die das dann ausliest...

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Platte schrieb:
>>Die fat implementierungen die ich bisher gesehen habe füllen den zu
>>mindestens 75%
>
> Was willst du denn für einen Logger bauen? soll der mit double Variablen
> auch die Position berechnen? Wofür benötigst du da noch so viel Platz
> für Code. 25% reichen doch völlig aus.
userinterface (Strings, symbole, drehencoder, taster, Display), UART, 
SD,  -> alles schon drin 50%
parsen der NMEA daten für infos wie Satellitenanzahl, Uhrzeit und 
Position.
miniFAT erweiterung
-> kommt noch sollte aber lange nicht die reslichen 50% brauchen

>
>>Doch es funktioniert sehr gut.
>>Man kann die Karte im raw-modus beschreiben und kommt trotzdem am PC an
>>die Daten und hat sie vor versehendlichen Überschreiben geschützt.
>
>>die erweiterung, die ich im Hinterkopf habe, splitt die große Datei dann
>>nach loggingende in den ersten bescriebenen Teil und einer neuen großen
>>Restdatei. Alles was dafür nötig ist, ist ein weiterer
>>Verzeichniseintrag, sowie die veränderung zweier Bytes in den FATs.
>
> Also ob man jetzt ne Datei anlegt und diese nach Loggingende normal
> schließt. Oder ob man erstmal eine Datei anlegt die die ganze Karte
> ausfüllt, dann am ende diese beschneidet und ne neue Datei anlegt die
> wieder die ganze Karte einnimmt, erscheint mir in keiner weise
> einfacher/bequemer oder sonst vorteilhafter.
> Mann muss doch auch im "raw-modus" wissen ab wo man schreiben kann usw.
> man muss also die gleichen Sachen machen wie im nicht "raw-modus"...
Die Datei wird auf dem PC nach dem formatieren angelegt. Damit ist 
sichergestellt, dass da ein FAT drauf ist und wenn die KArte jemand in 
seinen SD-slot steckt, dass er die nicht aus Versehen formatiert.

Dann sucht man sich den letzten root-Verzeichniseintrag und fängt da an 
per raw modus reinzuschreiben.
nach ende des loggings. bennent man den letzten eintrag um, schreibt die 
größe rein und legt einen neuen mit der restlichen Größe an, der nach 
dem letzt beschriebenen Block beginnt.
In der FAT braucht man nur den Index des letzten Blocks der gerade 
geschriebenne Datei FFFF für Dateiende schreiben.

Das sollte ne ganze nummer einfacher und kleiner als eine 
standard-FAT-Implemetnierung sein, die nach freien Clustern suchen muss 
und die Kette der Blöcke erst aufbaut.

>
> Das es auch so wie von dir beschrieben funktioniert zweifel ich ja
> garnicht an nur ist das nicht mehr FAT...
Das Filesystem ist und bleibt FAT (mit der einschränkung auf das 
Wurzelverzeichnis)

>
> Da könnte man sich direkt die Daten einfach so auf die Karte schreiben
> und dann auf PC Seite eine Software die das dann ausliest...
das hat den Nachteil, dass man die Daten nicht mit jedem Programm 
auslesen kann und birgt zum anderen die Gefahr, dass durch einen 
unbedachten Klick, die SD-Karte formatiert wird.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na gut. Wenn man dann umbedingt alles in nen mega8 quetschen will :)
In der von dir beschriebenen Art und Weise sicherlich mit sehr wenig 
Code umsezbar...

Ich hab mal probiert, bei meiner FAT 16/32 Lib in minimal Konfiguration, 
komme ich auf 70% Auslastung von nem mega8. Da wird dann wohl 
tatsächlich nicht alles rein passen was du da noch so machst.

Grüße Daniel

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was braucht denn deine Lib, wenn man die fat32 teile weglässt?

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schwer zu sagen, das ist alles ziemlich verzahnt...nur FAT 16 oder 32 
geht nicht, ist auch eigentlich nicht geplant.
Soo wahnsinnig viel müsste man aber eigentlich auch nicht umbauen. Bis 
auf die Länge der FAT Einträge und das Root-Dir ist das ja alles 
gleich...

Hm, vielleicht bau ich das doch um, auf ein #define FAT_TYPE wo man 
zwischen FAT 16 und 16/32 switchen kann.

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.