Hallo, ich will eine SD-Karte mit einem uC ansprechen, der über 128 Byte RAM verfügt. Zunächst will ich sie mal "nur Ansprechen", später sollen Sachen aus ihrem FAT16 System gelesen werden können. Ich programmiere in Assembler und 16-Bit breit, meint ihr das geht noch mit 128 Byte RAM? µLuxx
Hi! Ich würde sagen - gehen tut es, aber mit FAT16 bist du vermutlich sehr schlecht beraten... Für Schreiboperationen brauchst du eigentlich zwingend 512 Byte Ram, da du nur Blockweise auf die SD Karte schreibne kannst. Beim Lesen gilt das gleiche, aber du kannst ja einfach alle anderen Bytes verwerfen... Dadurch wird das ganze zwar sehr langsam, aber der Zugriff wird möglich. Du liest halt einzelne Blöcke mehrfach komplett aus und verarbeitest jeweils nur einen Teil der Daten. Dazu müsstest du allerdings vorhandene SD Libraries umbauen oder gleich deine eigene schreiben (ist ja dank SPI nicht sonderlich aufwändig). Matthias
Geht schon, aber schnell wird das nicht. Vor allem beim Schreiben wird es schwer, denn dann braucht man 512Bytes um einen Sektor zu puffern.
ja stimmt, ich hätte noch erwähnen müssen, dass ich NUR LESEN will, nicht schreiben...Und ich hatte vor, meine eigene Routine zu schreiben, mir gings um die machbarkeit...
wenn du den hohen zeitverlust rechnen tust für das wegwerfen de restlichen bytes und der zerstückelei, dann kannste ja gleich i2c-eeprom64kbyte nehmen.
ich will die sd karte experimentehalber erst mal auf nem kleinen uC ansprechen, später werde ich dann ein richtiges vieh mit riesen RAM haben, dann hab ich diese probleme nicht mehr, ich will halt "nur mit dem kleinen etwas üben..."
Du brauchst so ein riesen Vieh garnicht. Aber 1kByte RAM sollte man sich schon gönnen, wenn man FAT voll ausnutzen möchte. Also mega8 oder ähnliches und dem FAT12-32 lesen und schreiben steht nichts im Weg.
>ich will halt "nur mit dem kleinen etwas üben..."
Das wird keine Übung, sondern ein Krampf.
Nimm wenigstens einen ATMega8.
Hallo, weil es mir beim Lesen hier gerade auffiel: es wurde von mehrmals lesen und wegwerfen gesprochen, warum? Die Karte wartet doch, bis es weiter geht, man kann also sowohl nach dem Lesen der ersten Bytes auswerten und dann weiterlesen als auch stückweise einen Sektor schreiben und zwischendurch die Daten zusammensuchen. Alles jetzt natürlich unter der Vorraussetzung, daß es die Logik des Vorganges zuläßt. Ich habe auch mit 256Byte Buffer und einer MMC-Karte Daten vom Parallelport eines PC geholt, Sektor schreiben bestellt, die ersten 256 Byte geholt und geschrieben und dann die nächsten 256 Byte holen und schreiben. Dann nächsten Sektor usw. Beim Lesen genauso, Sektor bestellen, 256 Byte von der Karte holen und zu einem Parallelport-Drucker schicken, dann die nächsten 256 Byte usw. Kann man auch in noch kleineren Portionen machen, kommt nur darauf an, ob man eben mit den Daten im kleinen Buffer eas sinnvolles machen kann. Gru0 aus Berlin Michael
Hi! Bist du dir sicher? Wie bringe ich denn die Karte dazu, keine weiteren Daten zum µC zu senden? Sobald ich ein Byte im Empfangspuffer des µC habe und das nächste ankommt, wird es doch sogar automatisch verworfen, wenn ich das alte bis dahin nicht ausgelesen habe. Oder habe ich da einen Denkfehler? Theoretisch hab ich auch schon drüber nachgedacht: Einfach das CLK Signal "still halten", solange man keine Daten will. Allerdings ist für mich das SPI im µC sehr neu, weshalb ich nicht weiß, ob das möglich ist. Aus dem Datenblatt geht nichts dergleichen hervor. Deshalb geh ich davon aus, dass immer nur komplette Blöcke empfangen werden können? Aus dem Protokollblatt über SD/MMC Karten, welches man bei Ulrich Radig auf der HP findet geht hervor, dass man die BlockSize der Karten umschalten kann, das aber wohl sozusagen fast keine (garkeine?) Karten unterstützen... Meintest du vielleicht dieses Feature? Falls es auf einfache Weise möglich sein sollte, die Blöcke in kleinen Schritten mit nahezu beliebiger Wartezeit zwischendurch zu lesen, so wäre ich ebenfalls stark an der Lösung interessiert. Ich programmiere gerade eine "Pokeruhr" mit Soundausgabe von SD. Dabei habe ich derzeit nen 600 Byte Ringpuffer für den Ton, welchen ich immer erst befülle, wenn 512 Byte frei sind (eben weil ich derzeit nur mit den Funktionen von Ulrich Radig 512 Byte am Stück lesen kann). Dadurch verschwende ich natürlich Speicher, da mir eigentlich auch ein 256 Byte Buffer vollkommen ausreichen würde (und die 512 Byte bringen mir eigentlich garnichts, da ich eben nur im Mainloop prüfe, ob der Puffer neu befüllt werden kann -> der "eigentliche" Puffer ist nur 600-512 = 88 Byte groß. Könnte ich z.B. in 64 Byte blöcken lesen, hätte ich mit kleinerem Puffer + minimal erhöhtem Leseoverhead immernoch eine größere Überbrückungszeit als momentan. Matthias
>Theoretisch hab ich auch schon drüber nachgedacht: >Einfach das CLK Signal "still halten", solange man keine Daten will. Genau so kannst du das machen. Kein Clock, keine Daten. Den kompletten Sektor inklusive CRC musst du auf jeden Fall abholen, aber nicht unbedingt verarbeiten. Unbenötigte Bytes einfach raustakten reicht auch.
Matthias Larisch wrote: > Bist du dir sicher? Wie bringe ich denn die Karte dazu, keine weiteren > Daten zum µC zu senden? Sobald ich ein Byte im Empfangspuffer des µC > habe und das nächste ankommt, wird es doch sogar automatisch verworfen, > wenn ich das alte bis dahin nicht ausgelesen habe. Oder habe ich da > einen Denkfehler? Theoretisch hab ich auch schon drüber nachgedacht: > Einfach das CLK Signal "still halten", solange man keine Daten will. > Allerdings ist für mich das SPI im µC sehr neu, weshalb ich nicht weiß, > ob das möglich ist. Aus dem Datenblatt geht nichts dergleichen hervor. > Deshalb geh ich davon aus, dass immer nur komplette Blöcke empfangen > werden können? Die Karten senden überhaupt nicht von alleine. Man muss eine Clock Erzeugen (Meistens indem man "Dummy Bytes" sendet). Und wenn man einfach nach 256 Byte erstmal aufhört Dummy Bytes zu senden und später weitermacht, geht das ohne Probleme. Vorausgesetzt das Chip-Select der Karte bleibt die ganze Zeit auf LOW.
Ich bin ja auch dämlich... Habe den Sourcecode zu schnell überflogen & verwendet, vielen Dank euch, das werde ich demnächst mal implementieren :-) In Ulrichs Code wird einfach ein 0xFF gesendet zum empfangen. Im übrigen finde ich, sind SD Karten ein sehr optimales Speichermedium. Ich wüsste jetzt eigentlich keine Anwendung mehr, wo man irgendwelche EEProms oder Flashspeicher nutzen sollte, wenn man mehr als 64 KByte oder so braucht. Denn 16MB SD Karten hat ja jeder denke ich rumfliegen, wirklich langsam sind die auch nicht... Matthias
Matthias Larisch wrote: > Ulrichs Code wird einfach ein 0xFF gesendet zum empfangen. Das müssten dann die Dummy-Bytes sein. Ist übrigens egal was du hier sendest Wenn du 0x00 nimmst, kannst du noch Strom sparen (vorausgesetzt du benutzt einen Spannungsteiler als Pegelwandler. Bzw. du benutzt überhaupt einen Pegelwandler) > Im > übrigen finde ich, sind SD Karten ein sehr optimales Speichermedium. Ich > wüsste jetzt eigentlich keine Anwendung mehr, wo man irgendwelche > EEProms oder Flashspeicher nutzen sollte, wenn man mehr als 64 KByte > oder so braucht. Denn 16MB SD Karten hat ja jeder denke ich rumfliegen, > wirklich langsam sind die auch nicht... Seh ich genauso.
@ µluxx Besorg dir einen Atmega8 von Reichelt, der kostet da 1.70 Euro. Mit dem kannst du so ziemlich alles machen und es gibt genug Code mit dem in Beispielen. Was für einen µC hast du momentan zum testen?
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.