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?
>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" ;)
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
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.
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)
@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.
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.
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.
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.
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.
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
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'...
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
>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.
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
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
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.
>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...
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.
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
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.
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.