HI, ich möchte eigentlich Holger Klabundes Fat System (http://www.holger-klabunde.de/) für meine Schaltung verwenden. Ein ATMEGA32L soll auf die SD-Karte per Hardware SPI schreiben und lesen. Da ich mit Holgers Programm bisher noch keine brauchbare Fehlermedlung bekommen habe, nutze ich nun Ulrich Radig´s FAT System. Über den USART bekomme ich dann folgende Meldungen: *********************************************** System OK Karte gefunden!! 0 26 0 32 5f 59 83 c8 be fb cf ff 92 40 40 d7 Directory Directory Ende FERTIG!! *********************************************** Wenn ich das richtig interpretiere, dann wird die Karte zwar erkannt, allerdings das Dateisystem nicht, bzw. wird das Root-Verzeichnis nicht gefunden oder ausgelesen. Nun ich habe die SD-Karte schon auf verschiedenste Weisen formatiert. Die letzte Variante war: Mit Knoppix meinen Wi***** Rechner gestartet. Dann per konsole mit "fdisk /dev/sda" zuerst eine leere Dos-Partitionstabelle erstellt, dann eine Partition mit einem FAT16 Dateiformat (Hex 6) und dann das ganze mit "w" geschrieben. Habe dann eine "mmx.txt" Datei erstellt in die ich nur den Text "Test" reingeschrieben habe. Was mache ich also falsch ? Ich schätze das es an meiner Formatierung weiterhin liegt. Bin für jede Hilfe dankbar.
Hi was hast für eine Karte? versuch mal die software von roland riegel, hab damit gute erfahrungen gemacht, ist hier in der code-sammlung, braucht aber momentan 15kB flash. da kann man aber noch etwas machen um 2-4 kB einzusparen, das war mir aber im moment nicht so wichtig da ich sie auf einen mega128 einsetze. gruß Andreas
Ich verwende eine Sandisk Mini SD Karte mit Adapter auf die normale SD-Karten-Grösse und einen Kartenleser von Reichelt. Ich bin mir ziemlich sicher, dass es nicht an der Software liegt, da es vorallem über Ulrich Radiks Software doch auch viele positive Feedbacks auch auf dieser Website gibt. Der Fehler, so glaube ich liegt an meiner Formatierung. Die Karte wird ja erkannt nur die Debug-Messages über die USART sind für mich zu schwer zu interpretieren. Ich weiss das die Hex Zahlen die Rückgabewerte der CSD-Abfrage sind, kann diese aber nicht interpretieren. Aussderdem gibt die fat_read_dir_ent ein 0xffff zurück.
So geschafft, ich hatte bei der letzten Formatierung vergessen eine "mmc.txt" wieder anzulegen. Nun hat er den Text "Test" im HT ausgegeben. Bleibt dann nach der Ausgabe dort stehen.
Die SD-karte sollte gehen wenn sie nicht größer 1GB ist. Ich hab meine MMC Karte unter windows formatiert. mit FAT16 (heist bei windows FAT) und es läuft. Könnte noch an die art der Partition liegen, hast du eine Primäre Partition angelegt? Schaue mal nach ob die Sektoren 512 Byte groß sind, sollte eigendlich so sein solange die karte kleiner gleich 1 GB ist. Hast du der karten einen namen gegeben? Wie hast du die Stromversorgung gemacht? eine so eine karte zieht spitzen bis 200mA. Die roland-riegel lib beruht auf ulrich radigs und die beispielanwendung sagt ganz genau woran sie scheitert. ob beim karte finden, Partition wählen, dateisystem öffnen oder hauptverzeichniss öffnen.
Holger Klabundes System funktioniert nun auch ;-) Zumindest erkennt er die Karte nun und gibt folgendes aus: *********************************** FirstDataSector 581 maxsect 1984000 FirstDirCluster 0 maxcluster 61959 Using FAT12 Using FAT16 Using FAT32 Using FAT Buffer MMC/SD Card FAST_SPI_WRITE FAST_SPI_READ FAST_FWRITE FAST_FREAD F_CPU 4194304 Start writing files 1 374.21s 5.3kB/s ********************************* Is nich schnell aber bei der Frequenz normal oder ? Werde auch auf einen ATMEGA32 und dann einem Takt von 16MHz wechseln
Hallo Matthias, ich bin auch gerade dabei Holgers Code zum laufen zu bekommen aber habe dabei ein paar Probleme. Der Code erkennt einfach das Dateisystem nicht. Könntest du vielleicht dein Programm mal hochladen, damit ich das vergleichen kann und somit möglicherweise meinen Fehler finde? Schonmal Danke im Voraus. Gruß, Marian
Dann liegt das an der Formatierung der Karte. Lade dir mal das Tool: "Hard Disk Low Level Format Tool" runter und formatier deine Karte komplett. Dann in Windows XP unter Datenträgerverwaltung neu formatieren auf Fat. Dann geht das. ;-)
Habe gemacht was du geschrieben hast und das Problem besteht immer noch. Muss ich bei der Formatierung eine bestimmte Zuordnungseinheit wählen oder kann ich das auf Standard lassen?
Ich benutze genau das Programm von Holger, deswegen würde es keinen Sinn machen, dass hochzuspielen sry
Gib mal an, was für einen Chip, welchen Takt, welche Versorgung und welche Spannunsgteiler du verwendest
Ich nutze folgendes: -Atmega32-L mit 7.3728MHz, d.h. SPI Takt von 57,6 KHz -Versorgung: LiPo-Akku 3.6 V , 1200mAh Ich verwende keine Spannungsteiler, da mein ganzes System durch 3.3V Spanungsregler begrenzt wird, d.h. die Pins der SD Karte sind direkt mit dem Atmega32 verbunden. Ich habe auch noch einen Sensor in der Schaltung, den ich Problemlos über SPI auslese.
ok hatte ich auch zuerst, dann könnte es an den FUSE Bits liegen. Wie sind die eingestellt ? Das Protokoll gibt dir wahrscheinlich "No Flash" zurück oder ? Ist die Pin Belegung der SD-Karte richtig ? siehe http://ulrichradig.de/ Wie lange ist deine Leitung zur Karte, eventuell benötigst du Pull-Ups ? An dem Prog liegt es jedenfalls nicht, das funkt, hab auch erst mehrere kleine Fehler herausfinden müssen bis es ging. Was für eine Karte nimmst du ? Du hast auch ganz sicher zuerst die Low Level Formatiernug gemacht ? Hat dann Windows die Karte erkannt und konntest du darauf zugreifen ? >Muss ich bei der Formatierung eine bestimmte Zuordnungseinheit wählen >oder kann ich das auf Standard lassen? ich habs mit Standard gemacht, dann ging es. Wird deine Karte erkannt ? MMCIdentify(); ?
@ Marian
Poste hier weiter, und nicht in "GCC" !
>Wird deine Karte erkannt ? MMCIdentify(); ?
Ja tut sie, aber scheinbar kommen falsche Werte aus dem CSD.
Zeigt nur 98MB statt 128MB an.
Dann wird auch der FAT Typ nicht erkannt.
SPI ist auf Minimum runtergeschraubt.
So weit zur Zusammenfassung.
Das hängt sicherlich irgendwie zusammen.
Aber was da jetzt faul ist ? Keine Ahnung.
Du benutzt einen LiPo Akku mit 3.6V und dann noch einen
Spannungsregler 3.3V. Selbst für einen LowDrop Regler
bleibt da nicht viel Marge. Hast du mal die Spannung
hinter dem 3.3V Regler gemessen ?
Ja sorry wegen dem Doppelpost aber in beiden wurde ich was gefragt und wollte halt nur nett antworten :). @Holger: Der Akku liefert voll geladen 4,2 Volt und das geht auch direkt an den Atmega. Nur die restliche Peripherie wird über den Spannungsregler versorgt welcher auch die 3,3 Volt am Ausgang hat. @Matthias: Die Fusebits sind "normal" eingestellt. Jtag aus, Brown out ist aus,Externe Quarz ist an. Willst du was spezielles dazu wissen? Ja, es gibt "no flash" zurück, da er in der Readsector Routine beim MBR Check abbricht, da dort der bootsector größer ist als maxsector. Tja wie lang die Leitung ist kann ich nicht genau sagen. Das ist alles auf einer Platine geätzt worden, schätzte so maximal 4 cm. Ich benutze eine 128 MB MMC von Kingston. Ja ich hab zuerst die LLF mit deinem Tool gemacht. Dann habe ich sie in der Datenträgerverwaltung so wie du gesagt hast formatiert. Kann ich davon ausgehen, wenn die Karte erkannt wird (auch wenn nicht ganz richtig), dass die Routinen so weit funktionieren oder kann es sein, das er irgendwo anders die Werte herbekommt, die ich sehe? Gruß, Marian
Marian wrote: > Der Akku liefert voll geladen 4,2 Volt und das geht auch direkt an den > Atmega. > Ich verwende keine Spannungsteiler, da mein ganzes System durch 3.3V > Spanungsregler begrenzt wird Was denn nun?
Hm war wohl etwas unglücklich ausgedrückt. Der Atmega (und nur der) liegt direkt am Akku, der Rest wird über die Spannungsregler versorgt.
Marian wrote: > Hm war wohl etwas unglücklich ausgedrückt. > > Der Atmega (und nur der) liegt direkt am Akku, der Rest wird über die > Spannungsregler versorgt. Und warum hast du dann keine Levelshifter (zB Spannungsteiler)?
Weil uns damals, als die Schaltung gebaut wurde, nicht bekannt war das das wichtig ist. Laut den SPI bzw. TTL Spezifikationen sind kleine Schwankungen auf den Leitungen ja ok. Also haben wir unsere Platine ohne gebaut. Auf dieser PLatine befinden sich auch noch 2 weitere Sensoren (Ein Beschleunigungssensor und ein Drucksensor) die über SPI korrekt ausgelesen werden. Deshalb wurde bei der Erweiterung mit dem SD Karten Slot auch nichts an den SPI Leitungen verändert. Ich habe ja auch schon den SourceCode 2.5 von Ulrich Radig verwendet, mit dem ich lesen und schreiben konnte, aber leider nicht mit voller zufriedenheit, da dieser Code das schreiben ja nicht voll unterstützt, weshalb ich nun zum Code von Holger gekommen bin.
>Kann ich davon ausgehen, wenn die Karte erkannt wird (auch wenn nicht >ganz richtig), dass die Routinen so weit funktionieren oder kann es Ja, du kannst. Mein Programm funktioniert bei mehreren SD/SDHC/MMC Karten. Die Kartengröße wird richtig berechnet. Sie wird nicht richtig berechnet wenn von der Karte falsche Werte kommen. >sein, das er irgendwo anders die Werte herbekommt, die ich sehe? >>Und warum hast du dann keine Levelshifter (zB Spannungsteiler)? Das wird genau das Problem sein. Latchup der 4.2V vom Atmega über die SD/MMC Datenleitungen in die 3.3V. Wer weiss ob die Karte noch OK ist ?
holger wrote: > Das wird genau das Problem sein. Latchup der 4.2V vom Atmega > über die SD/MMC Datenleitungen in die 3.3V. Wer weiss ob die > Karte noch OK ist ? Tja, würde ich nicht drauf wetten. Zumindest würde ich das erstmal sofort abklemmen... "Kleine Schwankungen" Wer erzählt denn so einen Mist im Bezug auf Levelshifting? *Kopfschüttel
In Windows kann ich sie noch beschreiben und lesen, also wird sie wohl noch heile sein.
Mal ne ganz andere Frage: Wieso wird der ATMega32L nicht auch aus den 3.3V versorgt ? Damit könnte man einige Probleme aus der Welt schaffen.
Wie hast du meine Routinen getestet ? In dein Programm eingefügt ? Vieleicht hast du einfach keine 1kB RAM mehr frei. Wenn du meine Routinen benutzen möchtest solltest du bei so wenig freiem RAM auf jeden Fall den FAT-Buffer abschalten. Auch alle Funktionen die du von meinem FAT nicht brauchst. avr-size meldet die erforderliche RAM Größe nicht ausführlich genug. Da fehlt z.B. der Stack Bedarf. Den muss man abschätzen.
Weil das ein portables Gerät ist und ich ansonsten keine Batterieanzeige für den Akku hätte. Wenn ich den Atmega an 3,3 Volt hänge, kann ich ja den Bereich von 4,2 bis 3,3 V leider nicht messen. Also haben wir den ADC etwas missbraucht und Aref an den Akku gelegt, so dass wir als Aref jetzt die Akkuspannung haben (damit die immer größer oder gleich groß der zu messenden Spannung ist). Dann haben wir an ADC0 die 3,3 Volt gelegt und quasi den ADC invertiert um somit den Batterieverbrauch zu ermitteln. Ich hoffe das war jetzt richtig nausgedrückt :).
Ich hab dein Programm ohne alles andere getestet. Ich habe error-Codes eingebaut, die ich mir über Bluetooth an meinen Laptop schicke, weshalb ich auch weiß, dass es beim MBR Check hängen bleibt. Das AVRstudio gibt einen RAM bedarf von 74,8% aus. Ich habe auch versucht alles abzuschalten was ich nicht benötige, wie z.B. Dateien erstellen oder löschen usw.
Kannst du denn wenigstens mal ausprobieren, den AVR (sowie den Rest) mit 3.3V zu versorgen? Es könnte ja durchaus sein, dass da teilweise einige Bits verrutschen (Sind denn die Ergebnisse immer gleich?), wenn du die SD ein gutes Stück ausserhalb der Spezifikation betreibst. Sind in den Datenleitungen denn wenigstens Widerstände? Die Akkuspannung hättest du übrigens auch messen können, ohne den AVR an die Betriebsspannung zu hängen. Mit einem sehr hochohmigen Spannungsteiler und (falls nötig) den unteren Widerstand an einem Port-Pin statt direkt an GND müsste sich die Spannung recht sparsam messen lassen. Ist der Stromverbrauch denn überhaupt ein grösseres Kriterium (Akkulaufzeit)? Dann solltest du nämlich die SD und alles andere Zeugs auch abschalten können. Das ist alles nicht unbedingt so sparsam.
>>Kannst du denn wenigstens mal ausprobieren, den AVR (sowie den Rest) mit 3.3V zu versorgen? Möglich ja aber etwas schwierig ,da alles auf einer Platine verbaut ist. Ich könnte den Akku abtrennen und ein Labornetzteil dran hängen. >>Es könnte ja durchaus sein, dass da teilweise einige Bits verrutschen Ich denke nicht das Bits verrutschen, da die Ergebnisse immer gleich sind und bei den anderen Sensoren auch keine Schwankungen auftreten. Wie oben schon erwähnt sind dort keine Widerstände? Kann mir mal bitte einer erklären warum diese Spannungsteiler bzw. Levelshifting so wichtig ist? Darüber habe ich mir noch nie so den Kopf gemacht, da die anderen Sensoren über SPI perfekt funktionieren. Ist eine SD Karte anfälliger für Störungen? >>Ist der Stromverbrauch denn überhaupt ein grösseres Kriterium (Akkulaufzeit)? Dann solltest du nämlich die SD und alles andere Zeugs auch abschalten können. Das ist alles nicht unbedingt so sparsam. Hm das man die Akkuspanung auch so messen kann wusste ich noch nicht. Ja die Akkulaufzeit ist sehr wichtig, weshalb ich auch das Bluetooth und den Rest immer abschalte sofern ich ihn nicht benötige. Im Moment will ich halt nur die SD Karte zum laufen bekommen, um meine Daten Online und "in freier Wildbahn" aufnehmen und abspeichern zu können.
Marian wrote: >>>Kannst du denn wenigstens mal ausprobieren, den AVR (sowie den Rest) mit > 3.3V zu versorgen? > > Möglich ja aber etwas schwierig ,da alles auf einer Platine verbaut ist. > Ich könnte den Akku abtrennen und ein Labornetzteil dran hängen. Dann solltest du aber den Spannungsregler rausnehmen und überbrücken, sonst hast du wegen dem Spannungsabfall des Reglers wiederum eine tiefere Spannung an der Karte (Und am Rest der Schaltung). >>>Es könnte ja durchaus sein, dass da teilweise einige > Bits verrutschen > > Ich denke nicht das Bits verrutschen, da die Ergebnisse immer gleich > sind und bei den anderen Sensoren auch keine Schwankungen auftreten. > Wie oben schon erwähnt sind dort keine Widerstände? Kann mir mal bitte > einer erklären warum diese Spannungsteiler bzw. Levelshifting so wichtig > ist? Darüber habe ich mir noch nie so den Kopf gemacht, da die anderen > Sensoren über SPI perfekt funktionieren. Ist eine SD Karte anfälliger > für Störungen? Ganz einfach: Wenn die SD-Karte mit 3.3V versorgt wird, der AVR aber (schlimmstenfalls) mit 4.2V, dann liegt an den Eingängen der Karte eine um 0.9V höhere Spannung als Vcc an. Das geht nicht gut... >>>Ist der Stromverbrauch denn überhaupt ein grösseres Kriterium > (Akkulaufzeit)? Dann solltest du nämlich die SD und alles andere Zeugs > auch abschalten können. Das ist alles nicht unbedingt so sparsam. > > Hm das man die Akkuspanung auch so messen kann wusste ich noch nicht. Ja > die Akkulaufzeit ist sehr wichtig, weshalb ich auch das Bluetooth und > den Rest immer abschalte sofern ich ihn nicht benötige. Im Moment will > ich halt nur die SD Karte zum laufen bekommen, um meine Daten Online und > "in freier Wildbahn" aufnehmen und abspeichern zu können. Dann ist ein Linearregler eigentlich fehl am Platz. Für sowas gibt es ganz kleine Schaltregler, da wird dann wenigstens auch keine Leistung verheizt (Oder nur sehr wenig). Ausserdem musst du auch beachten, dass auf der Versorgungsleitung für die Karte genügend grosse Kondensatoren sitzen. Die will beim Schreiben schonmal 100mA oder so. BTW: Welchen Thread denn jetzt?
Hallo, ich habe damals keine Level-Shifter benutzt da das Datenblatt des Atmegas zeigte, dass die Pins ungefähr Vcc-0.5V ausgeben. Bei einer durchschnittlichen Akkuspannung von 4V käme man somit auf 3.5V. Das ist nicht die feine Art, allerdings sollten 0.2V ein TTL-Signal nicht in dem Maße beeinflussen. Das ist alles schon ne Weile her und Marian hat nun eine fertig bestückte Platine. Einfach mal Umlöten sollte also nur als Notlösung dienen. Grüße, Daniel
Also seltsam ist das schon alles. Heute morgen habe ich nochmal ein wenig im Programm was geändert wie z.B. unnötige Errorcodes entfernt und den FAT-Buffer und andere Routine mal defined und wieder undefined und siehe da, jetzt geht es. Kann mir das einfach nicht erklären! Ich teste jetzt mal die Karte vollständig zu beschreiben, dauert ja ne Weile. Danach melde ich mich nochmal. Vielen Dank an alle die sich mit mir hier so lange rumgeschlagen haben! Gruß, Marian
Daniel (x2) wrote: > ich habe damals keine Level-Shifter benutzt da das Datenblatt des > Atmegas zeigte, dass die Pins ungefähr Vcc-0.5V ausgeben. Wo steht denn sowas? Die AVRs haben 2 Fets, die gegenläufig verschaltet sind am Port. Die Spannung, die bei einer 1 am Port anliegt, hängt vom Strom ab, der dort fließt. Wenn du allerdings ne Steuerleitung anschließt (Strom ziemlich klein) liegt die Spannung bei nahezu VCC.
>Wo steht denn sowas?
Wie erwähnt, ist das alles schon ziemlich lang her. Ich denke, es stand
im Datenblatt des Atmega32.
OK die 128 MB zu beschreiben habe ich mal unterbrochen, das dauert mir etwas zu lange :). Habe nun einfach etwas in die Datei hineingeschrieben und es funktioniert endlich. Wo der Fehler lag, weiß ich leider immer noch nicht. Nochmals danke an euch!
Daniel (x2) wrote: >>Wo steht denn sowas? > > Wie erwähnt, ist das alles schon ziemlich lang her. Ich denke, es stand > im Datenblatt des Atmega32. Du hast garnicht mal so unrecht. Im Mega16 Datenblatt steht: VOH (Output High Voltage) bei Vcc = 5V; IOH = -20mA ->4,2V Beachte aber, dass das bei 20mA Stromfluss ist. Deine Steuerleitung wird kaum dauerhaft 20mA ziehen. Ergo wird die Spannung am Portpin noch etwas höher sein, als 4,2V.
@Holger:
Eine Frage hätte ich noch. Auf deiner Homepage steht folgendes :
>Ein reines Lesesytem für FAT12/16/32 kommt mit ca. 5kB Code aus. Ein KLEINES
Schreib/Lesesystem mit ca. 10kB. Wenn man ALLE Funktionen benutzen möchte, kann es
in einem ATMega16 schon ziemlich eng werden. RAM Bedarf ohne FAT-Buffer ca. 0.7kB.
Mit FAT-Buffer 1.2kB
Bei mir sieht der RAM Bedarf leider nicht so aus. Ohne FATbuffer steht
bei mir 1099 Bytes und mit FATbuffer 1651 Bytes. Ich habe folgendes
defined:1 | // #undef defines below in "mydefs.h" if you don't need them
|
2 | // spare program memory by deciding if you want to read, write or both
|
3 | #define DOS_READ //define this if you want to read files
|
4 | #define DOS_WRITE //define this if you want to write files
|
5 | // spare program memory by deciding if we want to use FAT12, FAT16, FAT32.
|
6 | // don't touch if you don't know the FAT type of your drive !
|
7 | #define USE_FAT16 //define this if you want to use FAT16
|
Wieso wird bei mir mehr RAM benötigt als bei dir? Muss ich zusätzlich zu den undefines noch mehr auskommentieren? Gruß, Marian
>Beachte aber, dass das bei 20mA Stromfluss ist. Deine Steuerleitung wird >kaum dauerhaft 20mA ziehen. Meine Pins ziehen immer 20mA! :P:P:P Hehe, es scheint ja nun zu funktionieren - so schlecht kann die Schaltung also nicht gewesen sein. :)
Hey, bin auch gerade dabei an MMC/SD mit FAT zu werkeln. Lesen klappt schon gut und recht schnell. Jetzt will auch noch das schreiben implementieren. Dazu wollt ich mal fragen wie ich das am sinnvollsten angehe: 1) In der FAT einen freien Sektor suchen und die Adresse im Root Dir eintragen 2) den nächsten Sektor suchen und dessen Adresse im vorigen eintragen. 3) 512 Byte Daten an die adresse des vorigen schreiben 4) Loop über 2/3 bis das Schreiben beendet ist. Das wäre jetzt meine spontane Vorgehensweise. Voraussichtlich fallen ca 32kbit also 4kB Daten an (IMA APDCM bei 8kHz). Da ich vorher nicht weiß wie lange ich jeweils aufzeichne kann ich leider nicht vorher berechnen wieviele Cluster ich ungefähr brauche und da schon mal eine Clusterkette schreiben lassen.
Den Atmel auch an die 3,3V hängen und den Akku hochohmig über einen Spannungsteiler an einen A/D Port hängen. Zieht dann praktisch kein Strom und wenn du keine Spikes detektieren willst, dann geht das auch wunderbar. Größenordnung so um die 100k/100k, dann bist du bei 4,2V Akku bei 2,1V A/D. Zieht dann etwa 20µA, was ok ist denke ich, ggf. kannste die Were noch hochschrauben. Dann würde ich aber einen Kerko oder so noch dhinterhängen, wen der A/D seine paar µA zieht. Das geht bei mir ganz gut...
Ich habe nun auch versucht, eine SD-Karte anzusprechen. Erst gabs Probleme aufgrund verschliffener Signale durch den Spannungsteiler an den Signalen (vermutlich C´s in der Karte und parasitäre Kapazitäten durch den wilden Testaufbau). Hab dann den SPI-Takt herunter gedreht und nun gehts. Weil es am Anfang mit Ulrich Radigs Software nicht ging (aufgrund des oben beschriebenen Probleme) habe ich die Software von Roland Riegel getestet. Da die mir aber zu kompliziert ist, habe ich nach dem Finden des Fehlers wieder die von Ulrich Radig verwendet. Die geht auch soweit. Allerdings ist mir aufgefallen, daß das Programm die Daten bei der Übertragung "verfälscht". Wenn Daten von der Karte geholt und auf die Schnittstelle geschickt werden, dann passiert folgendes: Ist ein Zeichen 0x0D (LF) in der Datei auf der SD-Karte enthalten, dann wird über die Schnittstelle anschließend ein weiteres 0x0D bei der RS232-Übertragung zum PC eingeschoben. z.B. Daten auf Karte: 0x00 0x00 0x0D 0xFF 0xEE vom PC empfangen: 0x00 0x00 0x0D 0X0D 0xFF 0xEE Bei Text ist das nicht so kritisch, aber ich habe ein Bitmap übertragen, das danach etwas "verschoben" ausgesehen hat. Bin bisher nicht dahinter gekommen, wo das passiert. Hat jemand ne Erklärung dafür? Kommt das schon von der SD-Karte so oder gibts da in der Software eine Stelle, wo dieses 0x0D eingeschoben wird? Falls ja, was ist der Grund dafür?
hab das Problem mit den "eingeschobenen "0x0D" gelöst. Es wurde nicht nach einem 0x0D, sondern vor einem 0x0A (das erwähnte Beispiel entsprach nicht ganz der Realität - hab 0x00...0xff ausgegeben und geschaut, an welcher Stelle das Problem passiert). Habe nun einfach ne neue Funktion geschrieben, die den Bufferinhalt vn der SD-Karte 1:1 weiter gibt. Der Dateizugriff (Lesen) auf Daten vom Hauptpfad der SD-Karte funktioniert nun problemlos. Hab auch die Größe der gesendeten Datei auf die tatsächliche Dateigröße begrenzt. Kann man mit der Software von Ulrich Rading auch irgendwie auf Dateien auf Unterpfaden zugreifen?
Ein Beispielcode für Assembler -freunde: Beitrag "SD-Karte Initialisierung Read Write FAT ATmega8 (Assembler)" Bernhard
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.