Hallo Leute, ich habe mir vor ca. 3 Wochen ein kleines Filesystem geschrieben (im moment nur Entwicklungsphase auf dem PC) und möchte bzw werde das für uC's portieren (erstmal AVR mit DataFlash, SD-Karte oder internes uC Flash). Ich wollte mal fragen ob jemand sowas brauchen kann. Das Teil kann Dateien erstellen/lesen/schreiben/löschen und Ordner erstellen. Die Datei-Namen sind bis zu 16 Zeichen lang. Anders als FAT16/32 hat jeder Sektor einen Header der sagt was es mit diesem Sektor auf sich hat (Directory, Datei, System usw...) Da das ganze eben kein FAT16/32 ist ist es natürlich nicht PC kompatibel. Es soll aber ein Programm geben mit dem man (im Falle von SD-Karten) Dateien von einer SD-Karte lesen/schreiben kann. Quasi als Schnittstelle zum Dateisystem. Ich frage deshalb, da ich nicht weiß ob jemand mit einem zu-nichts-kompatiblen Dateisystem anfangen kann, oder ob ich mir die mühe spare soll das hier reinzustellen. Gruß Rene
Eigentlich sollten keine Fragen in der Codesammlung auftauchen... Was Deinen auf Deinen Betreff ja zutrifft. Zum Aufwand Sourcen hier einzustellen - das dürfte an einer Hand in Minuten abzuzählen sein. Mach doch einfach mal, evtl. hat jemand eine Idee das noch weiterzuentwickeln/Vorschläge/Verbesserungen.
also grundsätzlich frag ich mich welche vorteile ich davon hätte.... also mir is schon klar dass FAT16/32 nich das allertollste ist, aber im Flash bau ich mir halt n kleines struct und sobalds größer wird (SDCard oder so) macht FAT16 ja schon sinn (gerade WEIL es kompatibel zum rest der welt ist) da ich jetzt mal unterstelle dass du nich doof bist, wirst du wohl nen grund haben, die nichtgerade kleine Menge Zeit (wenns denn gut ist) für die entwicklung zu opfern! Also erzähl mir doch mal was dein Dateisystem tolles kann und in welchem Umfeld es sinnvoll ist! Gruß, sebba
@frank schande auf meinem haupt :-) der hintergedanke dabei das hier reinzustellen war erstmal zu sehen ob jemand interesse hat und wenn nicht kann man es ja immer noch in der versenkung verschwinden lassen. :-) hoffe der hintergedanke führt nicht zu haue :-) mit der doku das stimmt schon, aber ich möchte auch noch weitere sachen anbieten (z.b. PC-Programm zum beschreiben von SD-Karten mit einem solchen Dateisystem) daher wollte ich erstmal mögliches interesse abwarten. @sebba auf die idee bin ich zum einen aus ein wenig langeweile gekommen, zum anderen weil ich mir schon zu c64 zeiten überlegt habe ein eigenes kleines dateissystem zu basteln. das ist eigentlich auch der hauptgrund : selber mal sowas machen. weitere hintergedanken/hintergründe : - das ewige in-der-fat-tabelle-nachgucken-müssen ist zeit- und/oder speicher aufwendig - das dateisystem sollte möglichst wenig platz verschwenden (also nicht noch hunderte von zusätzlichen sektoren nur für die verkettung von sektoren zu benötigen) - das dateisystem sollte bei geringerem ressourcenverbrauch (erstmal nur auf der medien-seite) auch schneller sein. daher habe ich mich entschieden jedem sektor einen header zu verpassen. das benötigt zwar bei großen datenträgern evtl. genausoviel (wenn nicht sogar mehr) "verschwendete" sektoren, aber dafür wird es dann auch schneller. in dem header steht drin wo der nächste sektor zu finden ist. dadurch muß ich nicht erst in einer fat tabelle suchen sondern kann direkt weiterlesen. (ok das birgt andere probleme aber ist erstmal egal). weiterhin bietet das mehr sicherheit, denn wenn die fat-tabelle kaputt ist kann die zuordnung nicht mehr hergestellt werden (ok bei fat wird das problem durch redundanz gelöst) als ideen (die noch zu realisieren sind bzw. sich damit realisieren lassen) wären : - ein datenlogger für modellflugzeuge - hier möchte/werde ich ein AT45DB161 DataFlash einsetzen in dem das Dateisystem implementiert ist um Flüge einzeln zu speichern. - in verbindung mit ulrich radigs webserver größere inhalte speichern/schneller laden können - eine art jingle-mp3-player - auf sd-karte werden mehrere mp3's gespeichert und können recht schnell wiedergegeben werden - für meine fpga-grafikkarte mehrere zeichensätze zu speichern und bei bedarf laden. - für einen basic-interpreter/eine intermediate language basierend auf avr/arm ein schnelles dateisystem zu haben das sind ein paar ideen die man genausogut mit einem fat32/16 realisieren kann, aber wie gesagt steht für mich eher im vordergrund sowas mal selbst gemacht zu haben. hoffe das klingt jetzt alles nicht zu abgehoben :-)) gruß rene
mir erscheint dabei wesentlich, daß beim Schreiben nicht immer dieselben Sektoren geschrieben werden. Beim FAT wird immer derselbe FATsektor geschrieben und daher der Flash schneller abgenutzt. Die 2. FAT Datei im PC ist zu nichts nütze. Wenn eine FAT kaputt geht, ist bei mir auch immer die 2. FAT kaputt gewesen. Angeblich soll es ja Flashspeicher geben, die es selbst machen, die Daten immer woanders hinzuspeichern. Das wird im PC FAT wohl trotzdem nicht der Fall sein, insofern könnte Dein Ansatz eine Lösung sein. Aber nur um etwas Neues inkompatibles zu schaffen, ist das wohl nicht so sinnvoll. Es sollte schon eine Verbesserung drin sein und beim Flash geht das auch nicht schneller, wenn man die Daten statt in der FAT im Sektor speichert. Das wäre nur bei der Festplatte der Fall. Da jedoch erheblich. mfg
Sinnvoll ist sowas meiner Meinung nach nur auf Speichermedien, die sich random lesen und auch schreiben lassen. Also Dataflash, "große" serielle EEPROMS und evtl. das interne Flash. Vielleicht könnte man sich ja auf eine Art "Standard" einigen und dann einen seriellen oder USB-Reader bauen. Für die nächste Generation von meinem BASIC Computer habe ich etwas ähnliches schon entwickelt (oder bin besser noch dabei). Gruß Jörg
prima ! wenn ich zu deinem basic-computer (mir schwebt sowas ähnliches vor) was beisteuern kann würd mich das freuen. werde heute mittag mal was dazu schreiben. gruß rene
Die Nachteile von FAT16&Co sind ja bekannt. Allerdings sehe ich hier im Moment keine Vorteile, die ein eigenes FS bieten soll. Man kann sich natürlich je nach Anwendung ein speziell zugeschnittenes FS basteln, aber läuft dabei Gefahr, dieses bei Verwendung in einer anderen Anwendung wieder ändern zu müssen. Zum Beispiel die "Verkettung von Sektoren mittels Header im Sektor": Um den nächsten freien Sektor auf dem Medium zu finden, müssten theoretisch alle Sektorketten durchlaufen werden. Bei FAT muss "nur" die FAT nach einer freien Stelle durchsucht werden. Also maximal 64K Einträge bei FAT16. Bei einer Sektorverkettung und 2GB Speicher wären es schon 4 Millionen Einträge! Selbiges gilt für das Löschen einer Datei. Ein FAT-Cluster enthält bis zu 64 Sektoren. Somit ist das Durchlaufen der Clusterkette 64x schneller als das Durchlaufen der Sektorkette. Auch wenn man dabei auf das Nachschauen in der FAT verzichten kann. FAT hat entscheidende Nachteile, wenn es um das Verwalten sehr vieler und sehr kleiner Dateien handelt. Ist eine Datei kleiner als ein Cluster, wird der übrige Platz vergeudet. Wenn ich aber Anwendungen, wie Datenlogger oder MP3-Player lese, gehe ich von großen Dateien aus. Und dafür ist eine Clusterkette besser als eine Sektorkette. Da der Verlust an unbenutzten Sektoren geringer ist. Zur "Abnutzung des Speichermediums" will ich noch anmerken: Die hier genannten Beispiele MP3, Zeichensätze, Webserver sind fast alles Anwendungen, die keine oder wenige Schreiboperationen benötigen. Was soll da abgenutzt werden? Mir selbst ist noch nie eine CF oder SD-Karte durch Abnutzung gestorben, weder im Fotoapparat, noch in Steuerungssystemen (welche ich herstelle). Einzig die Anwendung "Datenlogger" könnte ein Problem sein. Aber selbst hier kann man sich dadurch behelfen, indem man für jede Messwertaufzeichnung automatisch ein neues File generiert und die alten auf dem Speicher lässt, bis dieser fast voll ist. Ist kein Platz mehr frei, wird das älteste File neu überschrieben, wobei als Dateinamen eine ständig fortlaufende Nummerierung gilt. Bevor ich hier konkret etwas starten würde, wäre es erstmal interessant, eine wirkliche Gegenüberstellung beider Systeme zu sehen. Joachim
>Sinnvoll ist sowas meiner Meinung nach nur auf Speichermedien, die sich >random lesen und auch schreiben lassen. Also Dataflash, "große" serielle >EEPROMS und evtl. das interne Flash. das (verbleibende) interne flash als FS zu nutzen kam mir auch schon in den sinn. vor allem da die low-level anbindung an mein fs lediglich init_device, read_sector, write_sector als schnittstelle benötigt. somit wäre es möglich eeprom, internes flash, dataflash und sd-karte lediglich über unterschiedliche treiber einzubinden was dann im vergleich zum windows-system ebenfalls laufwerke ermöglicht. ich möchte dabei aber noch einen schritt weiter gehen und (ähnlich linux) auch byte-stream geräte in den dateibaum einbinden um z.b. dateien direkt an ein byte-geräte (rs232 oder ein text-ausgabegerät) zu schicken. aber das ist noch zukunftsmusik. ich denke das mein fs gegenüber fat16 schon einige vorteile bietet. allerdings (und das ist denke ich das hauptproblem für eine breitere akzeptanz) ist es halt nicht kompatibel, wobei man dazusagen muß das ein paar tools auf dem pc die sache sicherlich vereinfachen (z.b. über den eintrag "senden an" im kontext-menü). an dieses tools werde ich arbeiten sobald das fs einigermassen steht. die performance dürfte (auf uCs) etwas besser sein wenn es um lineares lesen oder schreiben geht. einen freien sektor zu suchen dauert zwar zeit aber da kann man sicherlich einige optimierungen machen die die sache wieder beschleunigen. ich werde den quellcode (so wie er ist) mal fertig machen und hier reinstellen. allerdings weise ich direkt darauf hin das es noch nicht fertig ist und momentan nur in einem pc programm läuft. falls interesse besteht werde ich es weiterpflegen. gruß rene
noch etwas zum dateisystem : intern wird jede datei und jedes directory mit einer dateinummer und einem index (pro sektor) versehen um bei einem crash bzw. defekten sektoren zumindest tlw. die daten wiederherstellen zu können. die dateinummern werden in ein separaten sektoren abgelegt. dabei wird für jede datei ein bit angelegt. werden nun 10 dateien angelegt so muß dieser sektor 10mal geschrieben und gelesen werden. das ist etwas unschön, kann man aber auch evtl. weglassen. hatte dabei im hinterkopf das man bei einem crash bzw. defekt der sektoren nicht alle daten verloren gehen (wie es bei fat16 der fall sein kann wenn die fat-sektoren beschädigt sind) gegenüberstellung fat16/32 - ofs (mein dateisystem) : ressourcenverbrauch : fat16 - organisation in clustern - verkettung in speziellen sektoren ofs - organisation in sektoren - verkettung im header der sektoren fat16 - kleine dateien benötigen immer einen cluster ofs - kleine dateien benötigen wenigstens einen sektor geschwindigkeit : fat16 - man muß zwischendurch immer in der fat nachschauen welcher sektor als nächstes drankommt (wenn die fat nucht tlw. im ram gehalten wird) ofs - man kann schnell sequentiell lesen/schreiben da die verkettung im header des sektors passiert. innerhalb der datei zu springen kann dagegen lange dauern da ich zur zeit nur eine einfach verkettete liste implementiert habe (rücksprünge können SEHR lange dauern) sicherheit : fat16 - ist die fat tabelle im eimer ist das dateisystem im eimer ofs - durch verkettung sind nur teile (bzw einzelne dateien) kaputt. wenn die datei-nummern-sektoren kaputt sind können diese rekonstruiert werden. (durch die in jedem sektor vorhandene dateinummer)
Ich will mal nur ganz kurz meins beschreiben. Es ist halt ein bisschen auf die Bedürfnisse meiner Projekte zugeschnitten und gerade in Punkto Speicherplatzeffizienz nicht gerade das Gelbe vom Ei (6,25% verwaltungsaufwand) und auch die Größe der Dateien ist auf 254 Blöcke begrenzt. - Das Medium ist in 0,5K-Blöcke eingeteilt, bei 16 Bit Blocknummern lassen sich so theoretisch 32MB ansprechen. - jeder Block enthält 480 Bytes Nutzdaten und 32 Bytes Information. - es gibt keine Verzeichnisse sondern nur Dateien. Die Dateinamen sind 24 Bytes lang, wovon ich 12 Bytes als Gruppe und 12 Bytes als Name nutze. - Der Infoteil enthält Dateinamen, Blocknummer innerhalb der Datei (wird auch zur Belegterkennung genutzt), Nummer des nächsten Blockes und einen 32 Bit Schreibzähler, der bei jedem geschriebenen Block um 1 erhöht wird. Als Funktionen gibt es momentan nur "Block schreiben", "Ersten Block lesen", "Nächsten Block lesen" und "Datei löschen". Ist die Datei nicht vorhanden, wird eine neue erzeugt, ansonsten der Block hinten angehängt. Es können gleichzeitig mehrere Dateien zum Lesen und zum Schreiben "geöffnet" sein, das braucht jeweils 27 Bytes je Datei und einmal 8 Bytes im RAM. Das Filesystem braucht aber unbedingt random Lese- und Schreibzugriff, was bei EEPROM und Dataflash ja gegeben ist. Gruß Jörg
@joerg dein fs ist meinem gar nicht so unähnlich, nur das ich generell 32-bit nummern verwende (für sektoren, dateinummern und indizes). mein header benötigt 16 byte und meine dateinamen können 16 zeichen lang sein. die anzahl der maximal "geöffneten" dateien ist über ein define konfigurierbar und benötigt pro "handle" ebenfalls 27 byte (netter zufall :-)). allerdings benötige ich immer noch 1 handle zusätzlich für den aktuellen pfad. ich stell das heute abend mal rein. gruß rene
hier mal der aktuelle entwicklungs-stand meines ofs (own file system - ok etwas platt .. aber mir viel nichts besseres ein). das dingen ist noch weit von einem mikrocontroller entfernt, da ich (wahnsinnigerweise) sektoren als lokale variablen definiert habe (überall da wo ich es brauche). ich werde das demnächst umbauen damit nur noch ein sektor vorgehalten werden muß. fehlerbehandlung ist noch nicht eingebaut, sowie div. andere sachen (z.b. positionierung innerhalb der datei, korrektes schreiben (im moment werden daten nur hinten angehängt). schaut mal rein wenn ihr zeit und lust habt .... gruß rene
ps. das ganze ist mit dev-c++ geschrieben (hatte gerade kein vs express zur hand)
Sowas habe ich schonmal gebaut: Beitrag "Custom made file system: "uFS"" bzw. http://klinkerstein.m-faq.de/index.php?content=Micro-File-System
stimmmt ... deinen artikel zum uFS hatte ich damals gelesen. aber ich denke es ist unabhängig von deiner entwicklung :-) (obwohl ich nicht ausschließen will das in den tiefen meines unterbewusstseins etwas davon hängengeblieben ist :-))) hast du dein fs im dauereinsatz ? vllt. kann man sich da ja zusammentun (du, jörg und ich) und mal eine essenz daraus bilden die erweiterbar ist. ich denke da an die idee von jörg das interne flash eines controllers als evtl. "boot"- bzw. system-"laufwerk" zu nehmen und die eigentlichen daten in einem dataflash oder auf mmc/cf karte oder gar hdd zu speichern. vielleicht wird ja ein picoLinux draus :-) gruß rene
für ein "picolinux" brächte man einen controller der code im ram ausführen kann... der ansatz mit 2 listen hat schon was für sich.. ich würds nur auf doppelt-verlinke listen erweitern und die wortbreiten dem speichermedium anpassen... auf einem 24c32 hätte wäre sowas z.b schon ganz brauchbar: int8 typ (file/payload) int8 next-entry int8 prev-entry int8 first-payload-sektor bzw wenns bereits payload ist dann sind hier schon daten char[8] name damit bräuchte jede file 12 bytes und 20 bytes wären payload..payload sektoren hätten 29bytes user daten.. typ könnte man sich eigentlich auch sparen.. also 30 wären drinnen von 32... wenn man z.b jede stunde temp, luftdruck, windstärke, windrichtung und ka was loggen wollte, dann könnte man 128 stunden alle 5 werte als floats in extra files legen... interessants wärs schon... übrigends um das ganze am pc verändern zu können könnte man das dem pinguin mit fuse beibringen ;) 73
>für ein "picolinux" brächte man einen controller der code im ram >ausführen kann... nicht zwangsläufig :-) achtung jetzt wirds abgedroschen :-)) ich stelle mir vor das man eine virtuelle machine/intermediate language implementiert die byte für byte aus dem aktuellen sektor (der im ram gehalten wird) ausliest und die operationen direkt ausführt. interner speicher wird nur für zwischenergebnisse oder einen rpn-stack benötigt. der restliche speicher bleibt für variablen oder anwendungsdaten frei. (wir reden hier über min. 2k ram). evtl. könnte man noch ein spi-ram (gibts sowas eigentlich und wenn ja wie teuer und woher, kann sowas gut gebrauchen) anschließen. das ganze system wird dann zwar langsam aber dafür sehr flexibel. habe mir schon einige ideen zusammengesponnen (mal sehen obs was wird). die idee mit der doppelt verketteten liste werde ich mir mal überlegen. möchte nur ungern mehr als 16 byte (bei meiner derzeitigen realisierung) für den header verbraten, obwohl das eigentlich auch egal ist da das zweierpotenz-kriterium eh für die tonne ist, und solange nicht zuviel header-overhead vorhanden ist gehts sicherlich. kleiner hinweis : ich bin nicht pinguin-tauglich (bzw. unerfahren) und weiß leider nicht was fuse ist. ist das eine möglichkeit eigene dateisysteme als linux devices zu implementieren oder was ist das ? gruß rene
@Simon K, Anfang des Jahres hast Du geschrieben: "Läuft auch jetzt auf dem AVR ... Die AVR Version adde ich später." Wann ist denn endlich später? ;-))
von http://fuse.sourceforge.net/ Filesystem in Userspace With FUSE it is possible to implement a fully functional filesystem in a userspace program. also was ganz nettes :) doppelt verkettet macht eigentlich nur sinn bei größtern listen.. bei dem 24c32 machts wirklich keinen sinn.. die 128-pages kannst auch sogar nur mit 1nem byte header vergewaltigen... header für file: 1bit unterscheidung obs frei ist 7bit auf die erste payload-page 8bit pointer auf nächste file einige byte name die payload page hat nur 1bit für das belegt und 7bit auf die nächste page.. du musst allerdings sicherstelln, dass auf page 0 auch wirklich der anfang der 1. datei ist :) das mit der virtuellen maschine hab ich mir auch schon überlegt... bin aber zum schluss gekommen, dass man am besten einen existierenden controller einfach nachbaut und dann existierende compiler/... verwenden kann... anderer ansatz ist einfach einen bytecode-interpretere zu basteln für z.b embedded-java, lua oder ähnliches... 73
Ich hab mir mal den Sourcecode angeschaut und werde aber doch mein eigenes Konzept weiterverfolgen. Hängt auch damit zusammen, dass ich eigentlich fast nur in ASM progge... Virtuelle Maschinen sind schon eine Überlegung wert, da man nicht mehr an einen Controllertyp oder an eine Architektur gebunden ist. Auch wenn das vielleicht jetzt etwas weltfremd klingt, in ca. 3-4 Jahren möchte ich an einem selbstentwickelten Computer Texte schreiben, Mails lesen etc. Mein BASIC-Computer soll nur der Anfang sein. Gruß Jörg
@hans erstmal danke für den link. werd ich mir bei gelegenheit mal anschauen. >doppelt verkettet macht eigentlich nur sinn bei größtern listen.. bei >dem 24c32 machts wirklich keinen sinn.. das fs ist in erster linie auch nicht unbedingt für eeprom konzipiert, sondern eher für blockorientierte medien (cf/sd/hdd/flash). eeprom ist sicherlich auch möglich, aber dann müssten weitere anpassungen (nicht generell 32 bit-zeiger/zahlen sondern nur 8 bit beispielsweise). ich schau mal ob ich sowas noch implementiere (evtl. über compilerschalter die datentypen anpasse) das mit ner eigenen virtuellen maschine/byte-code-interpreter hat sicherlich den nachteil das man auf fast nichts fertiges zurückgreifen kann. allerdings sind die gängigen virtuellen maschinen auch nicht unbedingt für mikrocontroller konzipiert (da auch hier fast immer eine größere menge ram im system (also direkt vom uC adressierbar) vorausgesetzt wird). aber ich denke ich werde mir da auch was eigenes basteln. @jörg schade das das fs nichts für dich ist. aber so abgedroschen bzw. weltfremd klingt das nicht mit einem selbstentwickelten system zu arbeiten. wenn man das als beknackt ansehen würde, wäre es auch bescheuert sich eine eigene cpu aus ttl-logik zusammenzubauen. hat aber trotzdem jemand gemacht und ich finde das eine starke leistung (vor allem weil da ein komplettes system drauf läuft das sich wie ein normaler computer [wenn auch an c64 anmutend :-))] handhaben lässt) die "und-was-soll-das-ganze-jetzt"-frage kann man sich im hobbybereich eh schenken, da es i.d.r. doch um den eigenen ehrgeiz geht und da finde ich es bemerkenswert sowas wie deinen basic-avr oder die mycpu oder andere dinge umzusetzen. mal ganz abgesehen davon schweben mir ähnliche dinge vor. nur das ich wahrscheinlich mehr externe hardware einsetzen möchte. z.b. mit meinem fpga-board eine grafik-karte die einfache zeichenoperationen hardware-mässig ausführen kann (stichwort eigenes windows :-))). gruß rene
Schau dir mal das FS des 8-Bit-Atari an. Dort war der Sektor 128 bzw. 256 Byte lang. Die ersten 3 Sektoren sind immer 128 Byte lang. In Ihnen befindet sich neben dem Bootfile vor allem ein Kennbyte die Sektorgröße der übrigen Sektoren und deren Zahl betreffend. Im Sektor 168 befindet sich eine Sektorbelegungstabbelle der sektor 169 und 7 folgende sind dem Hauptdirectorie vorbehalten. Im einzelnen Datensektor sind je nach DOS die letzten 3-4 Byte der Sektorverlinkung und Filezuordnung vorbehalten. Wobei das expliziet letzte Byte die tatsächliche Zahl der zum File gehörenden Bytes darstellt. Dies ist speziell für den letzten sektor eines Files von interesse, aber auch beim zusammenlinken von Files. So konnten zusammengestzte Files aus meheren einzelnen files erstellt werden ohne alle sektoren neu zu schreiben. Lediglich die Sektorverlinkung wurde geändert. Im Tracemode konnten man so den Files unabhängig von der Sektorenfolge und ohne Zugriff auf eine Fat folgen. Sinnvoll könnte auch das Verzeichnen der vorhergehenden Sektoren sein speziell zur Datenrettung sein. MfG Winne
@winnie also eine andere sektor-größe als 512 byte zu definieren ist nicht das thema, aber gerade bei verwendung von flash speicher (egal ob uC-flash oder sd/cf) ist die blockgröße i.d.r. immer 512 byte, und wenn man eh einen sektor a 512 byte zwischenspeichern muß (da man ja immer nur seitenweise löschen kann, es sei denn man hat einen controller mit internem speicher) macht es wenig sinn eine kleinere page-size zu verwenden, da man dann mehrere pages laden und wieder schreiben muß wenn man daten verändern möchte.
Die Sektorgröße ist mir doch egal ich wollte nur ein Beispiel für ein FAT-loses Dateisystem bieten. kleine sektoren sind eh nur bei speichermagel auf dem medium sinnvoll. atari hate 128-360KB je Disk. Im übrigen sind die ATARI-Filsysteme gut dokumentiert , übersichtlich und können eine gute Anregung sein. Die Ssystemdaten an de Sektoranfang zu stellen, scheint mir jedoch sinnvoller als bei ATARI, besonders bei verschieden Formaten ließen sich Sektoren auf ihr Format testen ohne die exakte Größe su kennen. Viel Spass also bei Deinem Projekt. Ein sinnvolles Projekt ist es allemal, besonders wenn es man nicht jedermann zu leicht machen will, an die Daten zu gelangen. Dann jedoch würde ich gleich noch die Bits ein wenig scrambeln. Das macht dann einen Ideen-Klau noch unatraktiver."Bei mir würde es den Ehrgeiz löcken." MfG Winne
war ja auch nicht bös gemeint. :-) fat ist ja auch (gott sei dank) nicht das einzige fs das es gibt. als anregung sicherlich nicht schlecht, aber mein fs ist mittlerweile schon recht weit gediegen (zumindest auf dem pc) und ich denke ich werde an diesem ansatz festhalten. trotzdem danke für deine ausführungen. habe übrigens schon zu c64'er zeiten einen ansatz für ein eigenes fs gehabt. habe da aber nicht mehr weitergemacht. da gabs dann auch so kuriositäten das das directory bei spur 18, sektor 0 (oder wars 1 ?!) angefangen hat. die idee mit einem system-bereich lässt sich übrigens bei mir recht leicht implementieren. evtl nutze ich das als boot bereich (falls ich mal eine virtuelle maschine programmiert bekomme ...) danke noch fürs lob :-)
>als anregung ist dein hinweis mit dem atari-fs sicherlich nicht schlecht, aber
mein fs ist mittlerweile
meinte ich eigentlich .... fat ist sicherlich keine gute anregung :-)
Kleine Anmerkung Der Hintergrund das Direktory im mittleren Track zu platzieren war der, die maximale Zugriffzeit auf diesen Bereich möglichst gering zu halten. so brauchte der Kopf maximal 20 Spuren überqueren um ans "Dir" zu kommen ;-)
stimmt ... da war was ... und die 254 byte nutzdaten kamen glaube ich dadurch zustande das die restlichen 2 byte für den nächsten zusammenhängenden sektor verwendet wurden ...
Auch wenn hier im Thread nicht mehr viel los ist, will ich noch ein paar Sachen anmerken. Und zwar deswegen, weil ich gestern das gesamte Konzept wieder übern Haufen geworfen habe. 1. Bei den Atmel Dataflash (bei mir der AT45DB081B) muß jede Page eines Sektors innerhalb von 10000 Schreibzyklen geschrieben werden. Dazu gibt es mehrere Möglichkeiten. Der von Atmel favorisierte Zähler im Controller ist spätestens dann Mist, wenn zwischendrin die Spannung abgeschaltet oder der Flashbaustein als "Modul" gewechselt wird. Also bleibt folgendes übrig: a) Schreibzugriffe auf jeder Page zählen und z.B. bei 8192 Schreibzyklen im Sektor alle Pages auffrischen. Das dauert aber ca. 10 Sekunden. b) Ein Page-Refresh nach jedem Schreibzugriff. Ein Zählerbyte in jeder Page (ab Byte 256). Dazu muss aber die Page gefunden werden, die lt. ihrem Zähler als nächste mit dem Rewrite dran wäre. 2. Ich hatte leider überlesen, dass Atmel das mehrfache Überschreiben einer Page ohne zwischendrin zu löschen nicht empfiehlt. Es hätte halt vieles vereinfacht... 3. Gleichmässig über den gesamten Bereich verteilte Schreibzyklen und schnelle Zugriffszeiten scheinen sich diametral gegenüberzustehen. Mein bisheriges Konzept sah vor, bei jedem Schreibzugriff die freie Page mit dem niedrigsten Schreibzähler aller freien Pages zu finden. Das macht das Ganze aber relativ träge, so dass ich nur noch eine "ungefähr gleichmässige" Verteilung der Schreibzugriffe anstrebe. Naja, mal sehen was für Ideen die nächste Woche bringt, Gruß Jörg
Wieso sollte es nicht? Also ich meine, was willst du uns sagen?
@joerg erstmal danke für deine ausführungen zum thema at45dbxx ... schade das man ohne diesen refresh nicht auskommt ... hätte wirklich einiges einfacher gemacht. ich überlege wie man evtl. trotzdem noch nutzen aus einem solchen fs ziehen kann. eine idee wäre : man bettet es in ein bestehendes fat-system ein. sprich : man nimmt eine frisch formatierte sd-karte, packt ein leeres file mit der größe des abzubildenden fs darauf (evtl. noch prüfen ob linear (!) durchgängig ...) und bestimmt beim startup des uCs den startpunkt der "partition". hat den vorteil das man dann pc seitig in das fs reingucken kann :-) und trotzdem den datenträger noch nutzen kann :-) wär das brauchbar ?
Die Frage habe ich deswegen gestellt, weil ich wissen wollte inwieweit Ansätze jenseits von FAT überhaupt von Interesse sind. Das mit dem Refresh habe ich mittlerweise folgendermassen gelöst: - im nicht für die Daten genutzen Bereich der Pages (Bytes 256-263) liegen zusätzliche Informationen. Da man beim Dataflash auch einzelne Bytes lesen kann, ist das Ganze letztendlich doch nicht ganz so schwierig. - Ein Byte dient als Refresh-Zähler und wird beim "Formatieren" auf 0x00 gesetzt. - Nach jedem Schreiben einer Page wird die nächste zu refreshende Page bestimmt, dazu wird zuerst das Zählerbyte der ersten Page mit dem der letzten verglichen. Sind beide gleich, dann wird die erste Page refresht und dabei der Zähler um 1 erhöht. - Sind die Zähler ungleich, wird die erste Page gesucht, die den gleichen Zählerstand wie die letzte Page hat. Dazu kann man alle Zähler durchtesten oder ähnlich wie bei der sukzessiven Aproximation vorgehen. Letzteres, weil es ja nur einen Zähler- wechsel innerhalb der gesamten Pages gibt. Die gefundene Page wird refresht und dabei der Zähler um 1 erhöht. Weiterhin gibt es in den oberen Bytes noch einen Schreibzähler, der die gesamten Schreibzugriffe zählt, und einen Overwrite-Zähler. Letzterer wird beim Freigeben der Page wieder auf Null gesetzt. Wird eine Page einer Datei sehr oft geschrieben, dann wird nach einer festlegbaren Anzahl von Schreibvorgängen eine freie Page mit niedrigerem Schreibzähler gesucht. Wird so eine Page gefunden, werden die alte Page freigegeben, die Daten in die neue Page geschrieben und die Headerpage aktualisiert. Achso, jedes File besteht aus einer Headerpage, die sich nur an einer durch 16 teilbaren Position befinden kann und Datenpages. In der Headerpage stehen die Positionen der Datenpages, bei einer Pagegröße von 256 Bytes sind dadurch die Dateien auf 32KBytes begrenzt, was aber für die meisten Mikrocontrolleranwendungen (zumindest für meine) ausreicht. Dateityp und Dateiname stehen selbst am Anfang der Datei, danach kommen erst die Daten. Für SD-Karten etc. ist das Ganze wahrscheinlich wenig sinnvoll, aber dafür ist es ja auch nicht gedacht. Um die Daten in den PC zu bekommen nutze ich die serielle Schnittstelle des MC, denkbar ist aber auch ein USB-Reader mit einem kleinen Controller. Für die nächste Version von meinem BASIC-Controller (für den ich das Dateisystem emtwickelt habe) strebe ich weitestgehende Unabhängigkeit vom PC an, was bis dahin gehen soll, dass sich das System über SPI clonen kann. Gruß Jörg
>weil ich wissen wollte inwieweit >Ansätze jenseits von FAT überhaupt von Interesse sind. deswegen habe ich ja auch eingangs diese frage gestellt :-)) aber ich glaube ich werde das mit dem "embedded-fs-in-fat" wohl mal angehen (wenn mein rechner es wieder tut ....) fat auf dem uc zu realisieren ist sicherlich sinnvoll, aber auch ressourcenfressend (alleine der aufwand um directories korrekt (also mit langen dateinamen) zu lesen, geschweige denn dateien schreiben...) und von daher denke ich könnte dieses fs trotzdem noch interessant sein. zumal es dann nicht komplett inkompatibel ist. >dass sich das System über SPI clonen kann. das hört sich ja mal geil an. willst du mehr darüber verraten ? wäre interessant .. willst du eine leere hardware (also avr) komplett per isp (spi) von einem master-system aus programmieren, oder bezieht sich das "nur" auf die basic-programme ? bin gespannt ... gruß rene
Wenn schon, dann komplett incl. Fuses. Der Code dafür ist auch schon fertig, bricht allerdings ab da kein Controller am anderen Ende ist. An sich braucht es nur ein Kabel, bei dem SKC direkt verbunden, MISO und MOSI gekreuzt sind, und das (beim BASIC-Computer mittlerweise auf dem ISP-Stecker liegende) SS mit dem reset des Targets verbunden ist. Zuerst werden beim Program enable das Echo (0x53) getestet und dann noch die ID-Bytes mit denen vom Mega644 verglichen. Dann folgt Erase und Kopieren des gesamten Flash. Zum Schluss werden die Fuses gebrannt. Gruß Jörg
also an dem "clone-code" (bzw. die isp-routinen) wäre ich auch noch interessiert :-) hört sich ja echt cool an :-)
Hmmm, so mal nur aus reinem Interesse: Wäre es eigentlich möglich, auf einem Mikrocontroller das Linux ext2 oder ext3-System zu verwenden, um Dateien auf einer Festplatte oder einem beliebigen anderen Medium zu speichern? Oder würde sich der Aufwand selbst auf einem 32 Bit ARM-Board nicht lohnen? Wobei ich natürlich sagen muss, dass das selbergebastelte FS hier nicht überl ist. Aber nachteilig ist halt schon seine Kompatiblität zu andern Systemen, die sich in Grenzen hält ;)
Bei Festplatte oder Speicherkarte ist das FS eigentlich egal, FAT ist halt dabei der "kleinste gemeinsame Nenner". Die Hauptbeschränkung bei EEPROM und Flash ist die begrenzte Anzahl von Schreibzyklen je Page. Und beim Dataflash kommt noch das "Refreshen" dazu. Dafür kann man aber sehr einfach einzelne Bytes lesen. Die Daten gleichmäßig über den Speicher zu verteilen, ist an sich kein größeres Problem, das in annehmbarar Zeit zu tun ist aber schon weitaus weniger trivial. So hat z.B. meine erste Version bei 70% Füllgrad und zufällig gesetzten Schreibzählern plötzlich über 10 Sekunden gebraucht um eine 4KB Datei anzulegen. Bei der nächsten Datei ging es dann wieder wesentlich schneller. Es wird wohl noch einige Zeit ins Land gehen, bis ich brauchbaren Code veröffentlichen kann... Gruß Jörg
>Ich wollte mal fragen ob jemand sowas brauchen kann.
Eigentlich nicht, trotzdem vielen Dank für das Angebot.
mal wieder ein kleines update (für die die es interessiert). ich werde den ansatz mit dem eingebetteten ofs auf einer fat-formatierten sd karte verfolgen. das läuft so : man nimmt eine mit fat16 formatierte sd-karte und packt PC-seitig eine leere image-datei drauf. es wird dann gecheckt ob auch alle cluster sequentiell geschrieben worden sind. dann wird dieses image "formatiert" (alle sektoren werden mit 0xff gefüllt, und die header der ersten beiden sektoren werden geschrieben) dann kann man pc seitig dateien in das/von dem ofs-image schreiben und lesen. uc-seitig wird dann einfach nur diese image-datei gesucht und der start-sektor des ofs-images ermittelt. dann (sollen) lassen sich dateien ebenfalls schreiben und lesen momentaner stand ist : pc-seitiger check und formatieren des ofs-images. uc-seitig bin ich gerade dabei das ofs zu implementieren. gruß rene
Ich hab mir jetzt nicht jeden Beitrag hier durchgelesen, aber ehrlich gesagt sehe ich überhaupt keinen Sinn darin, das so zu realisieren. Du brauchst doch auf dem Mikrocontroller eine FAT16 Implementierung für das finden des Imagefiles und außerdem noch dein eigenes Dateisystem. Warum schreibst du das Dateisystem nicht direkt auf die Karte ohne FAT dazwischen? Wenn ich dich richtig verstehe, hast du vor auf die Karte unter Windows zuzugreifen. Ich denke mal über eine eigenes Programm, wo du die Image-Datei auf der FAT16-Karte öffnest und darin rummanipulierst. Es ist aber garnicht nötig eine solche Image-Datei auf einem FAT16 Dateisystem anzulegen, da du die SD-Karte auch als RAW öffnen kannst und so auf jeden Sektor zugreifen kannst - ohne unterliegendem FAT16 Dateisystem. Ich hab es nämlich genau so auch gemacht bei meinem Dateisystem. Mit Visual C++ 6.0 ein kleines Konsolenprogramm geschrieben, wo ich mir anschauen kann was auf der SD-Karte in meinem Filesystem enthalten ist. Idealerweise benutzt das Programm die gleichen Libs, die auf meinem AVR benutzt wurden.
hallo simon, >Du brauchst doch auf dem Mikrocontroller eine FAT16 Implementierung für >das finden des Imagefiles. das sind aber nur 2-3 funktionen. ich will ja nicht fat16 komplett imeplementieren. ich brauche ja nur den start-sektor meines images und den habe ich nach lesen von 2-3 sektoren ermittelt. der hintergrund das ganze eingebettet zu machen liegt darin das man die sd-karte dann trotzdem unter windows noch weiternutzen kann (wäre beim reinen ofs ja nicht so ohne weiteres möglich). und man kann sich unter windows auch leichter die images einfach sichern. >da du die SD-Karte auch als RAW öffnen kannst und >so auf jeden Sektor zugreifen kannst - ohne unterliegendem FAT16 >Dateisystem das raw-öffnen mache ich zur zeit nur damit ich unter windows prüfen kann ob das image auch komplett linear durchgängig ist. um die sektoren zu manipulieren nutze ich z.z nur ganz normale datei-operationen. kann aber auch mit raw-funktionen gemacht werden. >Idealerweise benutzt das Programm die gleichen Libs, die auf meinem AVR >benutzt wurden. das habe auch ich so vor :-) der einzige untgerschied besteht darin wie ich die sektoren anspreche, und dafür gibts dann eigene funktionen. somit lasse ich mir die möglichkeit offen mein fs später komplett auf der karte (also ohne fat) zu legen. wie gesagt die sache mit dem fs unter fat hat nur den grund das die karte noch normal nutzbar sein soll. erleichtert die fehlersuche.
> wie gesagt die sache mit dem fs unter fat hat nur den grund das die > karte noch normal nutzbar sein soll. erleichtert die fehlersuche. Versteh ich nicht. Was heißt "normal"? Die Karte ist doch genauso gut ohne FAT noch "benutzbar" als mit FAT. Ich mein, wo ist der Vorteil gegenüber den ganzen Nachteilen?
>Die Karte ist doch genauso gut >ohne FAT noch "benutzbar" als mit FAT aber doch nicht wenn ich die karte komplett auf mein fs umstelle. dann kann ich fat ja nicht mehr nutzen. (jedenfalls nicht vom explorer aus) mit dem eingebetteten fs kann ich noch dateien von windows auf die karte kopieren (unter fat) und trotzdem mein eigenes fs nutzen (über die pc-tools). quasi als "partition" >gegenüber den ganzen Nachteilen welchen denn allen ? ich seh nur einen kleinen : ich muß ein paar funktionen haben um im fat-fs etwas zu ermitteln (den root-dir-sektor und den sektor meines images)
TheMason wrote: >>Die Karte ist doch genauso gut >>ohne FAT noch "benutzbar" als mit FAT > > aber doch nicht wenn ich die karte komplett auf mein fs umstelle. dann > kann ich fat ja nicht mehr nutzen. (jedenfalls nicht vom explorer aus) > mit dem eingebetteten fs kann ich noch dateien von windows auf die karte > kopieren (unter fat) und trotzdem mein eigenes fs nutzen (über die > pc-tools). quasi als "partition" Aber dann darfst du die Größe von der "Partition" nachher nicht mehr verändern, da sonst das Image nicht mehr linear auf der Karte liegt. Ich dachte, dass das Image so groß gemacht wird, wie die SD-Karte selbst. Dass du noch andere Sachen (als deine FS-Partition) darauf kopieren wolltest wusste ich nicht.
>Aber dann darfst du die Größe von der "Partition" nachher nicht mehr >verändern, da sonst das Image nicht mehr linear auf der Karte liegt. das ist richtig. wäre ein nachteil. allerdings legt man im ersten sektor ja die größe des fs fest. und im nachhinein wird die sicherlich nicht geändert. >Ich dachte, dass das Image so groß gemacht wird, wie die SD-Karte >selbst. das kann man sicherlich machen. wäre dann geschmackssache. für erste tests werde ich sicherlich kleinere images 10-60mb verwenden, und später mal schauen wie die performance mit einem kompletten image (also ca. größe der sd-karte) >Dass du noch andere Sachen (als deine FS-Partition) darauf kopieren >wolltest wusste ich nicht. die idee ist mir gekommen weil hier im thread jeder 3. sagt : was soll ich mit sowas inkompatiblen ?! und es stimmt ja eigentlich auch. also kam mir die idee einfach eine vorher erstellte datei als "partition" zu nutzen. so kann man die karte von windows aus weiter-nutzen (wenn man das image nicht so groß macht wie die sd-karte) und gleichzeitig unter einem mikrocontroller das ofs nutzen (und kann dies von windows aus lesen/schreiben). vielleicht das durch diesen ansatz das fs "publikumstauglicher" ist. warten wirs mal ab ...
Hallo, nachdem der Thread jetzt doch etwas ins technische abgerutscht ist (soll keine Wertung sein), möchte ich ihn gern noch einmal aufgreifen. Ich empfinde ein "nicht der Regel entsprechendes Filesystem" in einigen Fällen als sehr hilfreich; sofern es sich -nach entsprechenden Vorbereitungen- auch von PC aus beschreiben lässt. So könnte ich mir z.B. vorstellen, Firmware-Updates ober sonstige relevante Daten auf einer SD-Karte an Kunden zu verschicken, so dass die Daten dort nicht beliebig replizieren werden können... Also aus aktuellem Anlass würde mich der Stand dieses Projektes interessieren. Gibt es da mittlerweile etwas vorzeigbares ? Gruß, Stefan
Joachim Müller wrote: > Zum Beispiel die "Verkettung von Sektoren mittels Header im Sektor": > Um den nächsten freien Sektor auf dem Medium zu finden, müssten > theoretisch alle Sektorketten durchlaufen werden. Nicht, wenn man die freien Sektoren anfangs in eine grosse Datei packt, die wie alle anderen Dateien mit verketteten Sektoren arbeitet. Da hat man sofort einen freien Sektor (und den Pointer zum nächsten), man muss dann nur die Pointer entsprechend schieben. D.h. beim Schreiben wird diese spezielle Leer-Datei immer kleiner, beim Löschen entsprechend wieder größer. Das fragmentiert natürlich wie Sau, aber da hier keine beweglichen Teile im Spiel sind, ist das wurscht.
Stefan wrote: > So könnte ich mir > z.B. vorstellen, Firmware-Updates ober sonstige relevante Daten auf > einer SD-Karte an Kunden zu verschicken, so dass die Daten dort nicht > beliebig replizieren werden können... Naja, ein eigenes FS nur zu verwenden weil es undurchsichtiger ist als ein Standard-FS? Das kanns doch nicht sein. Sicherheit gewinnt man dadurch nicht. Wenn man einen Kopierschutz für Updates auf SD-Karte will der auch wirklich funktioniert kann man die Datei z.B. mit der Seriennummer der SD-Karte signieren.
@stefan hatte gerade erst gesehen das wieder jemand auf den thread geantwortet hat. also ich habe schon angefangen die api etwas zusammenzuraffen um das fs auf einem avr und auf einem pc laufen zu lassen. bin aber noch mit dran. komme allerdings im moment nicht oft dazu daran weiterzuarbeiten da ich vorrangig an meinem synthesizer arbeite und auch noch ein umzug ansteht. werde aber immer peu a peu daran weitermachen und ab und zu den stand posten. das ziel ist es (wie oben schon angedeutet) das eigene fs in einer fat16 datei (die nach dem formatieren der sd-karte einfach darauf kopiert wird) zu beherbergen. so kann man einfacher vom pc darauf aus zugreifen, und man muß nicht die ganze sd-karte "opfern". außerdem kann man so (pc-seitig) backups der ofs-"partition" machen und auch wieder einfach zurückspielen. avr-seitig werde ich dann mehrere levels implementieren (read-only, read-write-no-dirs, full support) so meine vorstellung.
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.