mikrocontroller.net

Forum: Projekte & Code Kann jemand ein selbstgebautes FS brauchen ?


Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: sebba (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Wolfram Quehl (quehl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joachim Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: TheMason (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ps. das ganze ist mit dev-c++ geschrieben (hatte gerade kein vs express 
zur hand)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Frank N. (betafrank)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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? ;-))

Autor: Hans Wilhelm (hans-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: liftmonteuer Winne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: liftmonteuer Winne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :-)

Autor: liftmonteuer Winne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
;-)

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das Thema eigentlich noch interessant?

Jörg

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso sollte es nicht?

Also ich meine, was willst du uns sagen?

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ?

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also an dem "clone-code" (bzw. die isp-routinen) wäre ich auch noch 
interessiert :-)

hört sich ja echt cool an :-)

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Paris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich wollte mal fragen ob jemand sowas brauchen kann.

Eigentlich nicht, trotzdem vielen Dank für das Angebot.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ...

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Roland D. (eigengott)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.