Hallo, ich beschäftige mich - rein gedanklich - mit folgendem Problem: Eine Mikrocontroller-Schaltung soll die Möglichkeit haben, Konfigurationen bzw. "Programme" von SD-Karte einzulesen. Diese "Programme" kann der Benutzer mittels Software am PC erstellen und auf die SD-Karte speichern. Aber der Controllerprogrammierer ist faul, und will kein FAT-Gedöhns am Controller programmieren. Wie macht man das nun am besten? Meine Ideen: 1.) Natürlich könnte die PC-Software einfach Rohdaten auf die Karte schreiben, also komplett ohne Dateisystem, dann hätte man das Problem erst gar nicht. Allerdings muß man von einem dummen Benutzer ausgehen, und wenn der dann die Karte in den PC schiebt, dann bekommt er die Meldung, daß die Karte unformatiert ist, und natürlich formatiert er sie dann, ergo sind dann die Konfogurationen auf der Karte weg und der Benutzer wundert sich. 2.) Die Karte darf nur mit der PC-Software beschrieben/geändert werden, und diese PC-Software brennt praktisch ein Image auf die Karte, bei dem sichergestellt wird, daß Fragmentierung auf dem Datenträger gar nicht vorkommen kann. Dateien bzw. "Programme" dürfen maximal einen Cluster groß sein, somit entfällt ebenfalls das Hin-Und-Her-gespringe. Der Controller erkennt die "Programme" mittels Magic Number (von der PC-Software generiert) und braucht somit ebenfalls keine FAT-Implementierung. Beides macht mich nicht richtig glücklich. Gibt's irgend eine gute und einfache Lösung, die ich übersehen habe und die DAU-tauglich ist? Danke, NOR
Kleine FAT Partition anlegen damit Windows glücklich ist und in einem fest definierten Bereich hinter dieser Partition austoben? Ist aber auch alles irgendwie "hacky"
Oliver Lehmann schrieb: > Kleine FAT Partition anlegen damit Windows glücklich ist und in einem > fest definierten Bereich hinter dieser Partition austoben? Cool, danke, das ist eine echt gute Idee, auf die ich wahrscheinlich selbst nie gekommen wäre. > Ist aber auch alles irgendwie "hacky" Tjo, aber funktioniert und ist gut und günstig. Vielen Dank nochmal! NOR
Oliver Lehmann schrieb: > Kleine FAT Partition anlegen damit Windows glücklich ist und in einem > fest definierten Bereich hinter dieser Partition austoben? > > Ist aber auch alles irgendwie "hacky" Da kann man ja dann sogar noch eine kleine Anleitung, oder Config für das pc-programm drauf packen....
>> Kleine FAT Partition anlegen damit Windows glücklich ist und in einem >> fest definierten Bereich hinter dieser Partition austoben? > >Cool, danke, das ist eine echt gute Idee, auf die ich wahrscheinlich >selbst nie gekommen wäre. > >> Ist aber auch alles irgendwie "hacky" > >Tjo, aber funktioniert und ist gut und günstig. Und maximal umständlich. Naja, was solls wirst schon selber sehen.
@ Norbert M. (nor-iega) >Aber der Controllerprogrammierer ist faul, und will kein FAT-Gedöhns am >Controller programmieren. Das ist nicht faul, sondern normal. Wer will schon immer wieder das Rad neu erfinden? Nutze eine fertige FAT Bibliothek. http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten#Bibliotheken_zur_Ansteuerung >1.) Natürlich könnte die PC-Software einfach Rohdaten auf die Karte >schreiben, also komplett ohne Dateisystem, Hätte ich vor einigen Monaten auch noch drüber nachgedacht. Heute denk ich da keine Sekunde mehr dran. Die bestehenden Bibiotheken sind so gut und einfach in der Anwendung, da wäre es dumm, sie nicht zu nutzen! >Beides macht mich nicht richtig glücklich. Gibt's irgend eine gute und >einfache Lösung, die ich übersehen habe und die DAU-tauglich ist? Ja, siehe oben. Ich habe vor einigen Monaten das FATFs von ELM ChaN zum 1. Mal genutzt, das lief auf Anhieb sehr gut! Kann ich wärmstens empfehlen! Du wirst nie wieder ohne FAT leben wollen!!
Falk Brunner schrieb: >> Aber der Controllerprogrammierer ist faul, und will kein FAT-Gedöhns am >> Controller programmieren. > Das ist nicht faul, sondern normal. Wer will schon immer wieder das Rad > neu erfinden? Nutze eine fertige FAT Bibliothek. Wie gesagt, es ist ja nur ein gedankliches Problem. Vielleicht gibt's für den Controller ja keine fertige FAT-Bibliothek. >> 1.) Natürlich könnte die PC-Software einfach Rohdaten auf die Karte >> schreiben, also komplett ohne Dateisystem, > Hätte ich vor einigen Monaten auch noch drüber nachgedacht. Wäre sowiso die schlechteste Möglichkeit, weil der Benutzer dann ja wie gesagt die Karte mit an Sicherheit grenzender Wahrscheinlichkeit "kaputtformatiert". Daniel R. schrieb: > Oliver Lehmann schrieb: >> Kleine FAT Partition anlegen damit Windows glücklich ist und in einem >> fest definierten Bereich hinter dieser Partition austoben? > Da kann man ja dann sogar noch eine kleine Anleitung, oder Config für > das pc-programm drauf packen.... Jo, Stimmt, eine kleine Textdatei drauf, wo drin steht, wie alles funktioniert. Die Idee ist super, danke! holger schrieb: >>Tjo, aber funktioniert und ist gut und günstig. > Und maximal umständlich. Wie gesagt, ich bin gerne bereit, mich von "besseren" Lösungen überzeugen zu lassen. Sonst hätte ich ja nicht gefragt :-) > Naja, was solls wirst schon selber sehen. Da es sich um ein rein gedankliches Problem handelt werde ich gar nix sehen. Ich bin erst ganz am Anfang meiner Elektronikkarriere, da würde ich nichtmal versuchen sowas zu bauen. Ich frage nur, weil mich die Thematik an sich interessiert, auch wenn es zu komplex für meinen Kenntnisstand wäre, das selbst machen zu wollen.
Norbert M. schrieb: > Aber der Controllerprogrammierer ist faul, und will kein FAT-Gedöhns am > Controller programmieren. Mein Gott, FAT (mit der Beschränkung: nur lesen und nur aus dem Wurzelverzeichnis) ist doch absolut trivial. Insbesondere, wenn die zu lesende Datei dann auch noch kleiner als ein Cluster ist.
Welcher Controller ist es ? Und faul sein macht meist erfinderisch :-P Aber weil Du ja keine Suchmaschine bedienen kannst: http://elm-chan.org/fsw/ff/00index_e.html
Mit Linux kann man solche Block-Devices einfach als Datei öffnen. Ganz ohne FAT, Partitionen, Tables oder sonstwas.
Das kann man unter Windows auch, sofern der entsprechende Benutzer über die erforderlichen Berechtigungen verfügt. Es ist aber Pfusch, da die SD-Karten-Spezifikation klar das zu verwendende Dateisystem vorschreibt. Und der Aufriss, mit 'nem µC eine Datei aus dem Root-Verzeichnis einer mit FAT16 formatierten Karte zu lesen, der ist nur geringfügig größer als das Lesen ohne Dateisystem -- dafür ist aber auf der PC-Seite keinerlei spezielles Programm, keine Administratorrechte und keine sonstige Verwirrung erforderlich.
Um auf einem 2k Tiny mal 20 Bytes Konfig. zu speichern, mißachte ich da lieber mal die "Vorschriften", als den Flash mit einem FAT-Driver vollzustopfen. Vielleicht komm ich ja trotzdem in den Himmel. :)
Ein 2K Tiny speichert 20 Bytes Konfig im EEPROM ;-)
c-hater schrieb: > Norbert M. schrieb: > Mein Gott, FAT (mit der Beschränkung: nur lesen und nur aus dem > Wurzelverzeichnis) ist doch absolut trivial. Insbesondere, wenn die zu > lesende Datei dann auch noch kleiner als ein Cluster ist. Eben, genau das habe ich ja geschrieben: >> 2.) Die Karte darf nur mit der PC-Software beschrieben/geändert werden, >> [...] Dateien bzw. "Programme" dürfen maximal einen Cluster groß sein... ------------------------------------------------------------------- cppler schrieb: > Welcher Controller ist es ? Vorzugsweise einer, für den es keine fertige FAT-Library gibt. > Aber weil Du ja keine Suchmaschine bedienen kannst: > http://elm-chan.org/fsw/ff/00index_e.html Daß es für verschiedene Controller Bibliotheken gibt weiß ich sehr wohl. Darum ging's doch gar nicht! Nimm einfach an, daß es ein exotischer Controller ist, für den es keine Bibliothek gibt. ------------------------------------------------------------------- batman schrieb: > Mit Linux kann man solche Block-Devices einfach als Datei öffnen. > Ganz ohne FAT, Partitionen, Tables oder sonstwas. Klar, wenn man kein Dateisystem verwendet, dann hat man natürlich auch keine Probleme mit dem Dateisystem. Das war das, was ich unter Option 1.) vorgeschlagen hatte, nämlich: >> 1.) [...] Rohdaten [...] schreiben, also komplett ohne Dateisystem... Wird hier eigentlich manchmal gelesen was gefragt wird, oder wird einfach nur irgendwas als Antwort geschrieben? ------------------------------------------------------------------- Rufus Τ. Firefly schrieb: > Es ist aber Pfusch, da die SD-Karten-Spezifikation klar das zu > verwendende Dateisystem vorschreibt. Wirklich? Das wusste ich nicht, danke für den Hinweis. Das gedankliche Kernproblem ist eigentlich die Übertragung von irgendwelchen "Konfigurationsdaten" durch den Benutzer von seinem PC auf die Schaltung mit dem Controller. Das ginge natürlich auch mit einem USB-Stick, aber dann käme zur FAT-Problematik noch das ganze USB-Gedöhns dazu. In einer idealen Welt hätten die "dummen" Endbenutzer einen generischen EEPROM-Programmer im PC und der Benutzer müsste nur das PROM in die Schaltung knallen (und es gäbe PROMS, die man nicht falsch rum einsetzen kann und wo man nicht wie bei DIP die Beinchen verbiegen kann - und ja, PLCC ist mir bekannt). SD hat eben den Vorteil, daß man da einfach von der Controllerseite her lesen kann, und daß jeder Benutzer ein Schreib-Lesegerät dafür hat. Sonst könnte man ja gleich eine (proprietäre) Chipkarte nehmen, dann hätte man das Problem mit "versehentlichem kaputtformatieren" bzw. mit einem Dateisystem im Allgemeinen nicht. Nur bräuchte der Benutzer dafür wieder ein spezielles Gerät und dazu kommt die Treiberproblematik, wenn das Betrübssystem des Benutzers nicht vorgegeben werden kann/soll. > Und der Aufriss, mit 'nem µC eine Datei aus dem Root-Verzeichnis einer > mit FAT16 formatierten Karte zu lesen, der ist nur geringfügig größer > als das Lesen ohne Dateisystem Ja, aber nur, wenn die Dateien kleiner als die Clustergröße sind. > dafür ist aber auf der PC-Seite keinerlei spezielles Programm, keine > Administratorrechte und keine sonstige Verwirrung erforderlich. Die PC-Seite macht mir sowiso weniger sorgen, die stelle ich mal als gegeben hin, zumindest was gebräuchliche Medien wie SD-Karten o.Ä. betrifft, da wird der "dumme" Benutzer ja wohl draufschreiben können. ------------------------------------------------------------------- @ALL: Wie gesagt, das Problem ist eher gedanklicher Natur, es geht darum, wie eine möglichst große Zahl von möglichst dummen Benutzern Daten vom PC über ein Speichermedium an eine Schaltung mit Controller übertragen kann, ohne etwas kaputt zu machen. Insbesondere erübrigt sich daher folgendes: - Die Frage nach dem konkreten Controller - Die Frage nach dem Betriebssystem des Benutzers - Der Hinweis, daß es Bibliotheken für Dateisysteme gibt Der Tipp von Oliver Lehmann (ollil) im ersten Reply mit "der kleinen Pro-Forma-FAT-Partition zur Beruhigung des OS's" und der Speicherung der eigentlichen Daten im Off-Filesystem-Bereich war bis dato der Beste. Falls jemand noch zweckdienliche Gedanken besisteuern kann würde ich mich sehr freuen.
Ein fauler Programmierer, der sich zwar den Einsatz einer fertigen FAT-Lib erspart aber dafür lieber ein spezielles PC-Programm schreibt? Hmm. Was stimmt an diesem Bild nicht? > Natur, es geht darum, wie eine möglichst große Zahl von > möglichst dummen Benutzern In dem Fall gibt es nur eine Lösung: den faulen Programmierer feuern und sich jemanden suchen, der sich bewusst ist, was es heisst einen Vorgang DAU-tauglich zu machen.
Norbert M. schrieb: > Der Tipp von Oliver Lehmann (ollil) im ersten Reply mit "der kleinen > Pro-Forma-FAT-Partition zur Beruhigung des OS's" und der Speicherung der > eigentlichen Daten im Off-Filesystem-Bereich war bis dato der Beste. Nein. Der Benutzer könnte ja auf die Idee kommen, den ganzen Platz der Speicherkarte nutzen zu wollen und dazu entweder die bestehende Partition zu vergrößern oder eine zweite anzulegen. Uuuund... rumms. Oder was anderes: Der Benutzer könnte zu Sicherheit ein Backup dieser Karte anlegen wollen. Er sichert, was er sieht, also den Inhalt des Filesystems der Partition. Also genau das Entscheidende nicht... Dazu kommt noch, daß zum Bearbeiten dieser Einstellungen außerhalb des FS am PC wiederum Admin/root-rechte nötig wären. Also Kurzfassung: Eine extrem blödsinnige Idee. Die wäre für eine private Bastellösung sicher akzeptabel, aber nicht, um sie von Laien benutzen zu lassen.
Von wegen 2k Tiny: erst mal schauen, ob nicht die 4k/8k Version billiger ist, z.B. weil sie in größeren Stückzahlen verkauft wird. Könnte ja aber auch ein schöner Kopierschutz sein, denn dabei ist es ja wichtig, daß man den rechtmäßigen Benutzer maximal nervt und dem Hacker kein ernsthaftes Problem vorsetzt.
c-hater schrieb: >> Der Tipp von Oliver Lehmann (ollil) im ersten Reply mit "der kleinen >> Pro-Forma-FAT-Partition zur Beruhigung des OS's" und der Speicherung der >> eigentlichen Daten im Off-Filesystem-Bereich war bis dato der Beste. > > Nein. Der Benutzer könnte ja auf die Idee kommen, den ganzen Platz der > Speicherkarte nutzen zu wollen und dazu entweder die bestehende > Partition zu vergrößern oder eine zweite anzulegen. Uuuund... rumms. Nicht nur das. Windows lässt es überhaupt nicht zu, am Partitionsschema von SD-Karten o.ä. etwas zu ändern, und die SD-Karten-Spezifikation, die das Dateisystem vorschreibt, übrigens auch nicht. Davon abgesehen erfordert die Präparation einer SD-Karte auf diese Art und Weise erst recht Spezialwissen und -Programme seitens des Nutzers. Norbert M. schrieb: > es geht > darum, wie eine möglichst große Zahl von möglichst dummen Benutzern > Daten vom PC über ein Speichermedium an eine Schaltung mit Controller > übertragen kann, ohne etwas kaputt zu machen. Und da ist "SD-Karte so nutzen, wie vorgesehen" die naheliegendste und zuverlässigste Variante. Ja, dann kann ein Tiny halt nicht als Controller verwendet werden, ja, dann muss auf dem Controller halt zumindest rudimentäre FAT-Lese-Unterstützung implementiert werden. Aber das geht in kürzerer Zeit als diese Diskussion hier schon läuft, da es zig fertige Lösungen gibt, die man ohne Probleme an jeden auch noch so exotischen Controller anpassen kann (sofern der in C programmierbar ist und ausreichend Arbeitsspeicher hat). Gerade unter der Prämisse, daß "eine möglichst große Zahl von möglichst dummen Benutzern" damit zurecht kommen soll, scheidet jeder andere Ansatz aus. Wird ein spezielles Programm benötigt, schränkt das die Anzahl der Benutzer ein, denn die verwenden möglicherweise auch was anderes als Windows. Werden andere, spezielle Klimmzüge benötigt (Anderes Partitionsschema o.ä.), scheiden noch mehr Benutzer aus, weil das a) nicht ohne weiteres möglich ist und b) eine fehlerträchtige Prozedur ist und c) die SD-Karten-Spezifikation verletzt. Wird eine so präparierte SD-Karte z.B. in eine Digitalkamera eingelegt, kann es sein, daß diese damit gar nicht glücklich wird, weil sie eine spezifikationskonforme Karte erwartet.
http://elm-chan.org/fsw/ff/00index_p.html Wenn es möglichst einfach, möglichst anwenderfreundlich sein soll, MUSS es 100% standardisiert und weit verbreitet sein. Also SD-Karte mit FAT. Punkt. Je nach Anwendung kann man die FAT Bibliothek verkleinern. Siehe oben. Für eine selbstgestrickte, nicht standardkonforme Lösung braucht man 10mal mehr Zeit und das Ergebnis ist deutlich schlechter.
> Vielleicht gibt's für den Controller ja keine fertige FAT-Bibliothek.
Die avrfat32 Library lässt sich in wenigen Minuten auf beliebige
Controller (mit oder ohne hardware-SPI Interface) anpassen.
Voraussetzung ist nur die Programmeirsprache C.
Wobei das für mich auch kein Hindernis wäre. Der Code enthält keinerlei
Tricks, ist daher ohne Probleme in andere Sprachen übersetzbar.
Norbert M. schrieb: > Falls jemand noch zweckdienliche Gedanken besisteuern kann würde ich > mich sehr freuen. Und falls du hier nicht so einen unverschämten Ton anschlagen würdest, würden sich alle anderen mehr freuen. Ich sag dir mal meine Meinzng dazu: 1. Überhaupt so ein Gedankenspiel anzufangen, mit lediglich theoretisierenden realitätsfernen Randbedingungen, ist albern. 2. Die Idee mit der SD-Karte ist als solche blöd. Entweder man versaut durch irgendwelche Tricks die gegebene Formatierung oder man muß den Programmierer feuern und den Chip wechseln - und das für eine Handvoll Daten, deren Umfang das Benutzen einer SD-Karte überhaupt nicht rechtfertigt. 3. Da du zwar einen unendlich doofen PC-Benutzer annimmst, aber nicht dazu sagst, auf welche Weise dieser die Daten überhaupt in die richtige Form und an die richtige Stelle bekommt, ist das gesamte Unterfangen Unsinn. 4. Unter der Annahme, daß ein Benutzer auf dem PC ein spezielles Programm benötigt, was für ihn die Daten aufbereitet (da er ja selber es nicht kann) und obendrein für eine SD-Karte ohnehin ein Lesegerät an den PC zu stecken ist, wäre es sinnvoller, die Datenübertragung per serieller Verbindung herzustellen, entweder klassisch oder per USB. In letzterem Falle müßte entweder das Zielsystem eine solche aufweisen, was generell als gegeben angesehen werden muß, da es ja dafür fertige Chips gibt oder es müßte dazu (analog zum SD-Kartenleser) ein Schnittstellenwandler benutzt werden den es ebenfalls fertig gibt. Der Rest wäre lediglich die Abstimmung zwischen PC-Programm und µC bezüglich solcher Dinge wie Handshake und Details des Übertragungsformates. So. Genug herumtheoretisiert. W.S.
Rufus Τ. Firefly schrieb: > Nicht nur das. Windows lässt es überhaupt nicht zu, am Partitionsschema > von SD-Karten o.ä. etwas zu ändern Doch, na klar. Mit Admin-Rechten kannst du machen, was du willst. (Wenn du es kannst) > Davon abgesehen erfordert die Präparation einer SD-Karte auf diese Art > und Weise erst recht Spezialwissen und -Programme seitens des Nutzers. Das auf jeden Fall. > Ja, dann kann ein Tiny halt nicht als Controller verwendet werden Ach was. Mit den weiter oben bereits genannten Beschränkungen (read-only und nur aus dem Rootverzeichnis und nur Dateien mit einer Maximallänge von einem Cluster) paßt der Code locker in deutlich unter 1/2k Flash und braucht knapp 30 Bytes RAM. Man braucht Blöcke nämlich nicht unbedingt vollständig im RAM zu puffern, man kann sie auch als Stream lesen und nur das Rausfischen, was einen von den gelesenen Daten wirklich interessiert. Interessant wird es dann, wenn man sich auf diese Weise zu seinem Nutz-Cluster durchgehangelt und dessen Header erfolgreich verifiziert hat. Der Payload muß dann ja irgendwo hingelesen werden. Ich nehme bei den Tinys Flash als Ziel. Buffer für eine Flash-Page ist ja immerhin da. Dann noch schnell den Rest des Quellblocks "lesen", SD-Card abkoppeln und die gelesenen Daten flashen. Voila: 128 Bytes Konfigdaten sind im Tiny2313 gelandet. > Gerade unter der Prämisse, daß "eine möglichst große Zahl von möglichst > dummen Benutzern" damit zurecht kommen soll, scheidet /jeder andere/ > Ansatz aus. Das sehe ich absolut genauso.
W.S. schrieb: > Norbert M. schrieb: >> Falls jemand noch zweckdienliche Gedanken besisteuern kann würde ich >> mich sehr freuen. > Und falls du hier nicht so einen unverschämten Ton anschlagen würdest, > würden sich alle anderen mehr freuen. Hmm, es tut mir aufrichtig leid, falls mein Begehren unverschämt rübergekommen sein sollte. Das war sicherlich nicht meine Intuition, ehrlich nicht! Ich will nur wissen, wie man eine Datenübertragung über ein möglichst weit verbreitetes Medium machen kann, mehr nicht. > Ich sag dir mal meine Meinzng dazu: > 1. Überhaupt so ein Gedankenspiel anzufangen, mit lediglich > theoretisierenden realitätsfernen Randbedingungen, ist albern. Gut, das magst Du vielleicht so sehen, ich finde die Frage legitim. > 2. Die Idee mit der SD-Karte ist als solche blöd. Wie gesagt, SD hat eben den Vorteil, daß dafür fast alle Benutzer ein Schreib-Lesegerät haben. Klar, eine Chipkarte wäre sicher besser, aber erstens brauchts dazu ein eigenes Gerät das nicht jeder hat, und dann kommt ja noch die Treiberproblematik dazu. SD funktioniert wohl auf jedem Betriebssystem. > Entweder man versaut durch irgendwelche Tricks die gegebene > Formatierung oder man muß den Programmierer feuern und den Chip > wechseln - und das für eine Handvoll Daten, deren Umfang das Benutzen > einer SD-Karte überhaupt nicht rechtfertigt. Wie gesagt, nenn' mir ein brauchbareres Medium. Ich bin ganz Ohr! Wenn USB-Stick oder SD-Karte schon scheiße sind, was denn dann? Auf CD brennen ist noch dümmer, da gibt's genau die selben Probleme und noch dazu bräuchte die Schaltung dann noch ein CD-Laufwerk. Lochstreifen? > 3. Da du zwar einen unendlich doofen PC-Benutzer annimmst, aber nicht > dazu sagst, auf welche Weise dieser die Daten überhaupt in die richtige > Form und an die richtige Stelle bekommt, ist das gesamte Unterfangen > Unsinn. Der Benutzer soll am PC einfach ein Programm aufrufen, wo er vorgefertigte Konfigurationen laden kann, und da gibt's dann von mir aus einen Punkt "Exportiere Konfiguration auf Karte" und das Programm macht das dann. Wie gesagt, die PC-Seite ist ja kein Problem, in meinem Gedankenuniversum. > 4. Unter der Annahme, daß ein Benutzer auf dem PC ein spezielles > Programm benötigt, was für ihn die Daten aufbereitet (da er ja selber es > nicht kann) und obendrein für eine SD-Karte ohnehin ein Lesegerät an > den PC zu stecken ist, wäre es sinnvoller, die Datenübertragung per > serieller Verbindung herzustellen, entweder klassisch oder per USB. Blöd nur, wenn das "Gerät" (also die Schaltung mit dem Microcontroller) zum Beispiel in der Gartenlaube steht und der Benutzer keinen Schlepp-Computer hat. Ansonsten könnte man ja gleich ein Interface bauen, das das die Gerätschaft vom PC aus ansteuert. > In letzterem Falle müßte entweder das Zielsystem eine solche aufweisen, > was generell als gegeben angesehen werden muß, da es ja dafür fertige > Chips gibt oder es müßte dazu (analog zum SD-Kartenleser) ein > Schnittstellenwandler benutzt werden den es ebenfalls fertig gibt. Na klar könnte man in dem Falle einen Silabs 2xxx oder einen FTDI Fxxx einbauen, wenn man da ein Kabel legen könnte. > Der Rest wäre lediglich die Abstimmung zwischen PC-Programm und µC > bezüglich solcher Dinge wie Handshake und Details des > Übertragungsformates. So. Genug herumtheoretisiert. Genau, hätte, wäre, wenn... Das Gerät steht an Ort X, der Computer an Ort Y. Wie bekommt nun der DAU die Daten von Y nach X, ohne großartig was kaputt machen zu können? IMO bist Du vom Ton her mindestens genau so unverschämt wie ich ;-p Wie gesagt, es war sicherlich nicht meine Absicht, patzig zu wirken. Aber ich habe doch eine genau denfinierte Frage gestellt, für die ich eine halbwegs praktikable Lösung suche. Nicht mehr und nicht weniger. Mit bestem Gruße, schönes Wochenende wünsche ich.
Norbert M. schrieb: > Der Benutzer soll am PC einfach ein Programm aufrufen, wo er > vorgefertigte Konfigurationen laden kann, und da gibt's dann von mir aus > einen Punkt "Exportiere Konfiguration auf Karte" und das Programm macht > das dann. Wie gesagt, die PC-Seite ist ja kein Problem, in meinem > Gedankenuniversum. Dann mach das doch einfach so. Warum hast Du hier noch mal um Rat gefragt?
Rufus Τ. Firefly schrieb: > Norbert M. schrieb: >> Der Benutzer soll am PC einfach ein Programm aufrufen, wo er >> vorgefertigte Konfigurationen laden kann, und da gibt's dann von mir aus >> einen Punkt "Exportiere Konfiguration auf Karte" und das Programm macht >> das dann. Wie gesagt, die PC-Seite ist ja kein Problem, in meinem >> Gedankenuniversum. > > Dann mach das doch einfach so. Warum hast Du hier noch mal um Rat > gefragt? Hast Du das Ausgangsposting gelesen? Dort habe ich zwei gangbare möglichkeiten vorgestellt, die mir in den Sinn gekommen sind, nämlich >>> 1. Nur Rohdaten schreiben >>> 2. FAT-Image brennen und Daten kleiner als Clustergröße sein lassen. Gefragt habe ich, weil: >>> Beides macht mich nicht richtig glücklich. Gibt's irgend eine gute und >>> einfache Lösung, die ich übersehen habe und die DAU-tauglich ist? Rede ich chinesisch? Mir ist klar, daß Du Moderator bist, aber auch Moderatoren können mal einen schlechten Tag haben. Warum versteht mich fast keiner hier (ausser Olli, dem hier nochmal herzlichst gedankt sein soll)? Anyway, da ja nix brauchbares kommt kann man den Thread hier ja der Versenkung zuführen, ich werde mich eben anderweitig informieren müssen. LG, NOR
> nämlich >> ... Gibt's irgend eine gute und einfache Lösung, die ich übersehen >> habe und die DAU-tauglich ist? die gute und einfache Lösung, die DAU tauglich ist, ist es, dass der DAU mit dem Werkzeug mit dem er auch sonst zurecht kommt (Windows-Explorer) die Konfigurationsdatei aus einem Verzeichnis auf dem alle Konfigurationen sind, auf die SD-Karte kopiert. Alles andere erfordert Mehrarbeit. Wie war das nochmal mit dem faulen Programmierer? Spezialprogramme tendieren regelmässig dazu, runtergelöscht zu werden, vom Virenscanner blockiert zu werden, nicht auffindbar zu sein bzw abzustürzen. Wenn du ein Spezialprogramm zur Erstellung der Konfiguration hast, schön. Wenn mir dieses Programm die Konfiguration auch gleich noch auf die Karte kopiern kann, super. Aber wenn ich die nur und ausschliesslich mit dem Spezialprogramm auf die Karte kriege, dann ist mein nächster Gang der in die Systemsteuerung, Unterpunkt "Programme und Funktionen"
Karl Heinz Buchegger schrieb: > Alles andere erfordert Mehrarbeit. Wie war das nochmal mit dem faulen > Programmierer? Hmm, gut, ich erkenne an, daß eine Lösung mit FAT wohl das Beste wäre. Wenn ich 'mal so weit bin, daß ich mich mit diesem digitalen Elektronikzeugs soweit auskenne, daß ich so ein Projekt machen kann, dann werde ich mir wohl mal wirklich überlegen müssen, wie viel Aufwand es wohl ist, sich einen FAT-Leser zusammenzubasteln. Bis dahin dürfen aber gerne noch ein paar Jahre vergehen :-p > Spezialprogramme tendieren regelmässig dazu, runtergelöscht zu werden, > vom Virenscanner blockiert zu werden, nicht auffindbar zu sein bzw > abzustürzen. Naja, ein Spezialprogramm braucht der Benutzer ja sowiso, wenn er mein Gerät nutzen woll, bzw. wenn er dessen Konfiguration ändern will. Beim PC ist es eben so, daß man das ganze zu.B. mit Python plattformunabhängig schreiben kann. > Wenn du ein Spezialprogramm zur Erstellung der Konfiguration hast, > schön. Wenn mir dieses Programm die Konfiguration auch gleich noch auf > die Karte kopiern kann, super. Jo, sehe ich auch so :-) > Aber wenn ich die nur und ausschliesslich mit dem Spezialprogramm auf > die Karte kriege, dann ist mein nächster Gang der in die > Systemsteuerung, Unterpunkt "Programme und Funktionen" Soll er's eben löschen, dann kann er eben $_Gerät auch nicht mehr nutzen xD Anyway, ich hab's verstanden, ich sollte mir dieses FAT-Zeugs mal gebnauer ansehen. Blöd nur, daß da auch wieder nix mit niemandem kompatibel ist, da gibt's FAT12, FAT16, FAT32 + VFAT. Danke jedenfalls allen, die sich an diesem Thread beteiligt haben. Ich wollte wirklich nicht unverschämt oder patzig rüberkommen, falls es so sein sollte dann bitte ich nochmal ausdrücklich um Entschuldigung. NOR http://www.derwandel.at/
@Norbert M. (nor-iega) >gebnauer ansehen. Blöd nur, daß da auch wieder nix mit niemandem >kompatibel ist, da gibt's FAT12, FAT16, FAT32 + VFAT. Alles halb so wild, das passt schon. FAT12 findest du real kaum noch, das wurde nur auf Disketten genutzt. FAT16 ist für kleine USB-Sticks bis 2GB, FAT32 für alles was größer ist. Fertig. Gute FAT-Bibliotheken wie von ELM CHAN können alles verarbeiten.
Falk Brunner schrieb: > FAT32 für alles was größer ist. Fertig. Leider nicht ganz; jenseits der 32 GB schreibt die SD-Karten-Spezifikation exFAT vor. Allerdings dürfte der Kundenkreis, der so große Karten verwendet, zur Zeit noch recht überschaubar sein.
Eine 16 GB SD-Karte (kleiner gibt's ja kaum günstig zu kaufen) für ein paar Bytes Konfigurationsdaten ist Verschwendung. Außerdem funktionieren manche Karten weniger gut. Fertiger USB-Seriell-Wandler im Gerät: - USB hat jeder und mit vernünftigem Wandler braucht man keinen Treiber - PC-Programm ist simpel - UART ist simpel Nachteil: Man muss das Gerät zu einem PC tragen oder einen PC zum Gerät. Aber bei Notebooks ist das kein Problem...
Svenska schrieb: > - USB hat jeder und mit vernünftigem Wandler braucht man keinen Treiber Ach? Welches Windows liefert denn bitte diese Treiber mit? Eine generelle CDC-Unterstützung gibt es zwar, aber die braucht unter Windows eine *.inf-Datei.
> Eine generelle CDC-Unterstützung gibt es zwar, aber die braucht unter > Windows eine *.inf-Datei. Naja, im Wiki steht "Kein Treiber erforderlich, nur .INF-Datei". :-) Alternativ nimmt man einen Wandler, der sich als USB-HID meldet - gibt's auch... ich wollte nur mal die Diskussion von "ich muss eine SD-Karte so kaputt wie möglich einbinden, um es in meinem Universum möglichst einfach zu halten" weg treiben.
ein Weg, sich es einfach zu machen ist: 1) Karte formatieren 2) Datei anlegen, die die gesamte Größe der Karte benutzt Damit sind alle (nicht von der FAT belegten) Cluster der Karte in aufsteigender Reihenfolge der Datei zugewiesen. Der PC ist zufrieden, er hat ein Formatiertes Medium mit einer Datei. Der µC ist zufrieden, er hat nur sehr wenig Aufwand, den Datei-Anfang zu finden. und zu lesen oder zu schreiben.
Vlad Tepesch schrieb: > ein Weg, sich es einfach zu machen ist: > 1) Karte formatieren > 2) Datei anlegen, die die gesamte Größe der Karte benutzt > > Damit sind alle (nicht von der FAT belegten) Cluster der Karte in > aufsteigender Reihenfolge der Datei zugewiesen. > Der PC ist zufrieden, er hat ein Formatiertes Medium mit einer Datei. > Der µC ist zufrieden, er hat nur sehr wenig Aufwand, den Datei-Anfang zu > finden. und zu lesen oder zu schreiben. Das ist auch nur eine Variante dessen, was Winzigweich schon vor 30 Jahren gemacht hat, um sein MS-DOS gebootet zu bekommen. Also wennschon, dann bitteschön so, wie es MS damals gemacht hat. Die Idee, eine unfragmentierte Datei zu erzeugen ist grundsätzlich die gleiche. Aber statt den ganzen Platz auf dem Medium zu verschwenden, wird die Datei nur so groß wie nötig gemacht und mit Attributen versehen, die sie für normaldumme User einfach unsichtbar macht. Und als Ergänzung zum ungenügenden M$-Ansatz von damals: Um die Möchtegern-Hacker erst garnicht auf dumme Gedanken zu bringen, erzeugt man noch eine schöne Honigtopf-Datei mit einem in Teilen unübersehbar konstanten Header und dem Output eines (nicht zu guten) Zufallsgenerators für den Rest. Das beschäftigt die dann bis in's hohe Rentenalter. Erst dann kommt der eine oder andere vielleicht auf die Idee, mal zu schauen, ob da vielleicht noch was anderes in der Partition rumlungert... Natürlich prüft der Client das Vorhandensein der Honigtopf-Datei und die File-Attribute der echten Config-Datei und des Honigtopfes und verweigert die Arbeit, wenn da was nicht den Erwartungen entspricht... So einfach kann "absolute Sicherheit" erreicht werden. ;o) Und die Diskussion über den Inhalt des Honigtopfes füllt Internet-Foren, beschert deren Betreibern Werbeeinnahmen, beschäftigt die Stattsanwaltschaft und die Justiz, ist also gesamtwirtschaftlich bald so unverzichtbar, daß die Sache systemrelevant wird, also von Geheimdiensten mit allen Mitteln geschützt und notfalls mit den Steuergroschen der Arbeitnehmer gerettet wird. Oops, ach nee, sowas klappt ja nur bei Banken und Versicherungen...
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.