Hallo zusammen, möchte gerne auf einer SD-Karte ein Fat16/32 dateisystem aufziehen. War schon auf Ulrich Radigs seite. Benutze leider einen PIC16F877a Controller. Hat jemand da schon was fertiges, mir kommts vor allem auf die Schreibfunktion an und nicht aufs lesen. Danke im vorraus Gruss Uli
Hi, das hier: http://elm-chan.org/fsw/ff/00index_e.html ist eigentlich gar nicht schlecht, nur mit der Schreibfunktion hab ich so meine Probleme (gehabt). Irgendwo ist da ein Sektor-Offset falsch... Hab an irgendeiner Stelle im Quellcode "+32" eingefügt, seitdem geht es, hab das aber leider nicht hier und kann dementsprechend nicht nachschauen, wo das war. Wollte das nochmal genauer untersuchen, aber mir fehlt die Zeit... Gruß, Christian
>Hab an irgendeiner Stelle im Quellcode "+32" eingefügt, seitdem geht es, >hab das aber leider nicht hier und kann dementsprechend nicht >nachschauen, wo das war. >Wollte das nochmal genauer untersuchen, aber mir fehlt die Zeit... klingt als wenn du eine SD mit Partitionssektor hast, diese aber vorher als Superfloppy angesprochen hast
Hi Wolfram,
ist schon ein paar Tage her, das ich das gemacht habe, und ich habe
leider von FAT nicht so wahnsinnig viel Ahnung. Auf jeden Fall habe ich
mit einigen unterschiedlichen Einstellungen bei Partitionierung und
Formatierung herumgespielt, alles hat nichts genutzt. Soweit ich mich
erinnern kann:
- mkdosfs /dev/sda (d.h. den ganzen Datenträger ohne Partionstabelle
formatiert)
-> mounten war nicht möglich
- mkdosfs /dev/sda1
-> Datenträger ließ sich normal ansprechen etc., aber mittels
Controller darauf schreiben ging nicht
(D.h. die Dateien wurden schon angelegt und waren auch sichtbar,
jedoch haben sie nicht den geschriebenen Text sondern nur Leerzeichen
angezeigt. Mit "hexdump /dev/sda(1)" habe ich dann herausgefunden, daß
die Daten schon geschrieben wurden, nur halt mit falschen Offset... Seit
ich dann die genannte "Korrektur" durchgeführt habe, funktioniert es
eigentlich ganz ok...)
Die FAT-Implementierung von elmchan.org bietet jedenfalls keine
Einstellmöglichkeiten für derlei Sachen, demnach sollte das eigentlich
automatisch erkannt werden. Ich hab den Code zwar mal überflogen, um den
jedoch vollends zu verstehen, müßte ich mich etwas mehr mit dem
FAT-Dateisystem an sich beschäftigen, was ich z.Zt. nicht möchte.
Naja, immerhin funktionierts.
Gruß,
Christian
Hi! deine 32 sind die $20 von Adresse $1C6/1C7 im Sektor0. Da müssen aber nicht immer $20 drinnstehen. Du musst also einfach ein Dateisystem verstehen, wenn du es richtig verarbeiten willst. Wie willst du sonst Fehler finden. Schaue dir bitte den Dateianhang an unter: Beitrag "Re: MMC/SD Adresse" Da steht alles Wichtige für Fat16 drinn. Wenn du dich dann noch bischen mit Fat beschäftigst bekommst du das auch gebacken. Viel Erfolg, Uwe
Hallo, danke für eure Tips. Habe mir die gennanten Websites mal angeschaut. Die Mehrheit der Sachen ist leider für avr Controller geschrieben. Habe im Forum von Microchip jedoch folgenden Beitrag gefunden: http://forum.microchip.com/tm.aspx?m=199006&mpage=1 Laut der Aussage dort brauche ich mit meinem PIC16F877a gar nicht erst anzufangen das FAT-System für eine SD Karte zu implementieren da der PIC zu wenig RAM besitzt und man mindestens 1.5 Kbyte benötigt (mindestblock ist 512 Byte.)Der PIC16F877 hat laut Datenblatt 386 Byte RAM und 256 Byte EEPROM, also zu wenig. Leider stehen mir nur die PIC Controller zur Verfügung und ich habe auch nur ein Brenngerät für PIC16 und nicht für die neueren PIC18. Weiss da jemand eine Lösung oder bin ich komplett am A......? Danke für Antworten Gruss Uli
Und Du kannst auch wirklich kein Geld ausgeben um das Ziel zu erreichen? Weil vor allem weil man bei den AVRs ja auch relativ günstig zu einem programmierbaren Chip kommt. (Mega8, STK200 kompatibler Programmieradapter (oder eben paralleles Kabel), AVR GCC) Gruss, Sebastian
@ Sebastian Eckert Die Seite kannte ich auch schon. Da wird aber nur eine Routine zum lesen der SD Karte mit dem PIC16 beschrieben. So wie ich das verstanden habe brauche ich beim lesen nicht unbedingt den 512 byte speicher, die Sache wird halt nur langsamer. Anders beim schreiben: Zitat: Hier sieht es jetzt völlig anders aus ! Wenn die SD beschrieben werden soll muß immer ein kompletter Sektor geschrieben werden. Es ist möglicherweise auch hier egal wie lange es von Byte zu Byte dauert bis der komplette Sektor beschrieben wurde. Für einen Datensektor gibt es bis hier noch keine Probleme wenn die Daten Byte für Byte sofort zur SD gesendet werden. Die Probleme fangen an wenn man die FAT aktualisieren muß. Man muß immer einen kompletten Sektor ins RAM lesen um den Verzeichniseintrag oder die FAT zu aktualisieren und dann auf die SD zurückschreiben. Das geht nicht anders. Ein Sektor ist 512 Bytes groß. Man braucht auch noch einiges für die Verwaltung der Daten. Sagen wir mal 50 Bytes. FAT zu schreiben braucht also mindestens 562 Bytes. Eher mehr. Zu Externem RAM: Hmm, habe keine Ahnung davon aber es scheint die Sache wohl noch mehr zu komplizieren. Vielleicht sollte ich doch schauen auf einen besseren PIC18 umzusteigen. Gruss Uli
Ja, das stimmt wohl, leider. Externer RAM benötigt entweder, parallel angesteuert, eine ganze Menge Portpins, die man sicher für andere Zwecke besser gebrauchen könnte, oder bringt, seriell angesteuert, recht viel programmiertechnischen Overhead mit sich. Es gab mal RAMs mit I2C, wenn ich mich richtig erinnere, wahrscheinlich von Philips. Ist aber lange her, ob es die noch gibt, ist fraglich. Wenn Geschwindigkeit eine Rolle spielt, hilft wohl doch nur ein größerer Controller mit internem RAM, oder einer, der, im Gegensatz zu den üblichen PICs, ein Interface für externen statischen RAM hat (8051er, AT90S8515... aber wahrscheinlich gibt es das bei den "großen" PICs auch.)
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.