Hallo allerseits, ich wollte eigentlich wissen, ob es möglich ist ein Disketten-Laufwerk mit einem AVR anzusprechen. Sinn: Ich suche ein nicht flüchtiges Medium zum Speichern einiger Daten im wenige kB-Bereich bis in den MB-Bereich. Eine Alternative wäre natürlich eine Festplatte, wobei mir das dann doch etwas zu hart vorkommt, für die paar Daten. Ich bin deshalb auf die Floppy gekommen, weil ich die Daten gerne via PC auslesen würde/damit speichern würde. Was ist da günstiger, wenn PC und Platine weit auseinander liegen, als eine Diskette kurz rüberzutragen? Es ist klar, dass ich eine Art Dateisystem erstellen/verwalten/verwenden muss. (Wenn mir dazu jemand eine Idee/nähere, gute INfos hat, bin ich auch ganz Ohr, insbesondere im Bereich Linux: minix und ext2 oder eben FAT, oder?)Dazu muss ich aber ein fertiges Laufwerk irgendwo organisieren und dann entsprechend ansprechen (egal, welches Dateisystem). Wie kann ich das machen? MfG und Danke im Voraus Christian
Diskettenlaufwerke sind zwar sehr einfach anzusteuern. Man hat direkten Zugriff auf die Laufwerksmechanik. So sind z.B. folgemde Pins vorhanden: - Motor an - Kopfmotor Schritt - Kopfmotor Richtung - Index Pulse etc. Allerdings ist das Timing beim Lesen/ Schreiben exakt einzuhalten, was mit einen MC nicht so ganz einfach sein wird. Ich empfehlen zum Datenaustausch mit dem PC eine SD-Speicherkarte. Ist per SPI Hardwaretechnisch sehr einfach anzubinden und ausserdem gibt es massenhaft Beispielcode dazu.
Hi, Ich denke das wird sehr aufwendig werden, da du, wenn du keinen Floppycontroller verwenden willst, deine Daten im Takt an das Floppy senden musst. Floppys haben keinen eigenen Puffer, die Daten werden vom Controller synchron zu der Rotation der Floppy geschrieben. Wenn du darüber eine Studienarbeit machen willst, ist das ok. Einen alten Floppycontroller für ISA-Bus vom AVR anzusteuern dürfte da noch einfacher sein. (Aber woher nehmen) Nimm lieber eine SD-Karte für 7 Eu kriegst du 128MB das sind eine menge Floppys. Nebenbei: Floppys waren vor 20 Jahren schon nicht der Hit. Dirk
OK, ich glaube, das mit den Floppies kan ich vergessen. Dann bleibt nur die Frage: soll ich besser auf ein FAT oder ein anderes System ausweichen? FAT gibt's halt Code-Schnipsel, aber die brauchen fast einen externen RAM. Gibt's da anspruchslosere Alernativen? Wenn ich ein RAM einsetzen wollte, wie müsste ich das eigentlich machen (mega8)? Ich hab das schon ein paar mal gelesen, wusste aber nie, wie man das macht. Hardware? Software (gcc)? MfG und Danke soweit mal Christian
Ich empfehle auch eine kleine SD-Karte. Sie ist kompakt, nicht mechanisch, braucht wenig Platz und Strom und ist sehr billig. Ansteuerung ist auch nicht schwierig, gibt genug Ressourcen im Netz. Darauf ein FAT-Dateisystem implementieren und man kann sie ohne Probleme mit dem PC lesen.
Du musst nicht unbedingt ein FAT-Filesystem unterstuetzen. Du kannst auch in ein FAT-Filesystem eine Datei auf dem PC ablegen und dann deren Anfang in deinem Microcontroller suchen und dort einfach deine Daten reinschreiben. Allerdings solltest du beim erstellen der DAtei darauf achten das die Karte leer oder nicht fragmentiert ist. Grundaetzlich liesse sich ein FAT-Filesystem auch auf einem Microcontroller machen. Du brauchst aber dann mindestens 512Byte Ram fuer den Schreib/Lesepuffer und noch mal so 50-100Byte fuer Verwaltungsaufgaben. Das waere zwar relativ langsam und ineffizient, wuerde aber den meisten Anspruechen genuegen da man normalweise am Microcontrolluer nur immer eine Datei offen haben will und wohl auch nur immer Daten anhaengt. Die Verwendung von FAT-Code anderer Leute ist nicht nur langweilig und uncool, der ist meist auch fuer groessere Controller geschrieben. Wenn man genug Ram hat empfiehlt es sich naemlich schon zumindest Teile von FAT und Direktory im Ram zu halten, das willst du aber nicht mit einem Mega8. Olaf
Hi, ist zwar ein bischen an der ursprünglichen Frgestellung vorbeigeschossen, aber es intgeressiert mich doch brennend: Was ist der Unterschied zwischen SD-Speicherkarten und MMC-Karten?!? Schließlich sind die in Bauform und wahrscheinlich auch Kontaktierung identisch, bloß dass MMCs wohl älter (evtl. auch kleiner und v.a. langsamer) sind. hintergrund der Frage ist, dass ich noch MMCs daheim rumfliegen habe (aus ner alten Digicam) und die Idee mit der Anbindung an einen µP recht interessant klingt. Gruß Fred
> Was ist der Unterschied zwischen SD-Speicherkarten und > MMC-Karten?!? MMC ist der Vorgänger der SD-Karte. Die SD-Karte kann auch mit bis zu 4 Bit parallel angesprochen werden, die MMC nur seriell. > hintergrund der Frage ist, dass ich noch MMCs daheim rumfliegen > habe (aus ner alten Digicam) und die Idee mit der Anbindung an > einen µP recht interessant klingt. Kannst du getrost machen. Die meisten wählen den SPI-Modus zum Ansprechen der Karte, und der ist bei SD und MMC gleich.
Die SD-Karte kennt noch zusaetliche Modi um den Datenzugriff zu beschraenken. Es ist daher von grossen Interesse aus der Sicht der Industrie das sich dies durchsetzt. Du koenntest dann z.B keine Sektorkopie einer Karte mehr machen. Benutzt man diese Modis aber nicht sind die Karten aber gleich. Es gibt auch schon MMC mit deutlich mehr Kontakten die dann wohl auch schneller sind. Wobei man sich aber fragt was der Unsinn soll. Hat man wieder alles schoen parallel haette man auch bei CF bleiben koennen. Es gibt aber noch einen mechanischen Unterschied, SD-Karten sind etwas dicker. Es gibt durchaus auch Geraete die nur einen MMC-Slot haben. Da bekommt man eine SD-Karte nur mit dem Hammer rein und ganz schlecht wieder raus. :-) Olaf
> Wobei man sich aber fragt was der Unsinn soll. Hat man wieder > alles schoen parallel haette man auch bei CF bleiben koennen. Nein. Erstens haben CF noch viel mehr Leitungen, zweitens gibt es keinen Zwang, die SD-Karten parallel zu betreiben. Sie können immer auch seriell benutzt werden, wenn man keine hohen Transferraten braucht. > Es gibt durchaus auch Geraete die nur einen MMC-Slot haben. Da > bekommt man eine SD-Karte nur mit dem Hammer rein und ganz > schlecht wieder raus. :-) Ich habe auch ein Gerät, das nur MMC untertützt. Eine SDCARD hat trotzdem reingepaßt, aber nicht funktioniert. Daß nur MMC untertützt wird, habe ich erst dadurch erfahren.
Hallo nochmal, wo bekomm ich dann entweder Infos, wie man das macht, oder entstrechende Code-Schnipsel her? Ich bevorzuge nicht die Idee mit der vorzeitig hergestellten Datei, da der µC mindestens mit 2 Dateien rumhantieren muss und dann aber auch weitere erstellen können soll. Eine andere Frage tuut sich mir auf (s.o.) wie kann ich ein externes RAM an den Mega8 anschließen? Geht das überhaupt? Wenn ja: Wie realisiere ich Soft- und Hardwaremäßig das? UNd noch eine Kleinigkeit: Das SPI ist doch die PIN-Kombination MOSI, MISO, Clk und SS, oder? Nun möchte ich mehrere Chips an einen Bus zusammenhängen. Einer soll als zentrale Steuereinheit dienen, einer soll als Speicherverwaltungs-Chip dienen, ein paar andere für die Eingabe/die Informationsaufnahme zuständig. Da da z.T. sehr kleine Controller benötigt werden (mir reicht bei einigen Aufgaben wirklich ein tiny o.ä), würde ich gerne die Chips über einen Hardware-Bus zusammenschalten. Meine Überlegungen waren, dass ein UART/TWI nicht von allen Chips (v.a. den kleinen) unterstützt werden. Kann ich hier das SPI einsetzen? Prinzipiell ja schon, muss nur dafür sorgen, dass es zu keinen Kollisionen kommt. Kann ich das mit de Bus auc machen, wenn ich einen Chip an eine SD anschließen will? MfG Christian
"Du musst nicht unbedingt ein FAT-Filesystem unterstuetzen. Du kannst auch in ein FAT-Filesystem eine Datei auf dem PC ablegen und dann deren Anfang in deinem Microcontroller suchen und dort einfach deine Daten reinschreiben." Ja, das wäre auch exakt mein Ansatz. Eine nicht fragmentierte Datei mit der maximalen Größe anlegen, am Anfang ein Magic (z.B. 16 Byte) reinschreiben und dann den MC einfach dieses Magic suchen lassen und dahinter seine Daten schreiben lassen. Irgendwelche FAT zu implementieren ist dann völlig unötig. Solange die Datei unfragmentiert ist, geht dann auch ein UNIX, NTFS, UDF oder was es sonst noch gibt. Der MC muß dann nur ein Endekennzeichen setzen, damit dann der PC weiß, bis wohin die Datei wirklich Daten enthält, bzw. damit auch der MC weiß, wo er den nächsten Datensatz anhängen muß. Peter
Aber das geht immer von einer Datei aus! Wenn ich jetzt aber mehrere brauche, die angelegt werden müssen??? MfG Christian
Hallo nochmal, wollte nur schnell ein kurzes "Danke" loswerden. Gruß Fred
» http://elm-chan.org/fsw/ff/00index_e.html Das ist aber ein Code für "große" Chips. Da reicht mir wahrscheinlich der RAM nicht. Wie kann ich das umgehen? (Wie RAM extern hinzufügen?) Wie kann ich die SD-Karte über den 4-Bit-Bus anzapfen, damit der SPI frei bleibt? MfG und Danke soweit mal Christian
> Wie kann ich die SD-Karte über den 4-Bit-Bus anzapfen, damit > der SPI frei bleibt? Ich hab drei ueberraschende Neuigkeiten fuer dich: 1. SPI ist kein Bus sondern nur ein syncrones serielles Interface. 2. Man kann meherre Geraete an einem SPI betreiben wenn du jedem seine eigene CS Leitung verpasst. Das kann manchmal mit Muehe verbunden sein weil SPI eben kein BUS ist, die Devices also unterschiedliche Vorstellungen von der Clockpolaritaet haben. Man muesste dann bei jedem umschalten richtig initialisieren. 3. Wenn es garnicht anders geht kann man SPI auch in Software programmieren. olaf
> Wenn ich ein RAM einsetzen wollte, wie müsste ich das eigentlich > machen > (mega8)? > (Wie RAM extern hinzufügen?) Ganz einfach: Schau Dir an, wieviele Pins statischer RAM hat, dann schau Dir an, wieviele Pins Dein Mega8 noch frei hat, dann überlege, ob Du diese Frage nochmal stellst. Selbst wenn Du statt des Mega8 den Mega168 benutzt, wäre eine PC-kompatible FAT mangels RAM nicht realisierbar. Du wirst also einen größeren Controller mit mehr SRAM benutzen müssen oder Du musst auf die PC-Kompatiblität verzichten. Dazwischen gibt es noch die Möglichkeit, einen Controller mit Speicherinterface (8515-kompatibles Pinout oder Mega128) zu benutzen und daran externes SRAM anzuschließen. Das erfordert allerdings eine recht komplexe Platine. Hinweise dazu bieten die Datasheets der betreffenden AVRs (8515, Mega128, ...) Bisher bin ich mit dem (wenigen) SRAM der AVRs immer ausgekommen, meist war noch ein großer Teil ungenutzt. Aber das FAT-System ist nunmal so bescheuert, dass man dafür viel RAM benötigt. Ich habe es deshalb bisher gemieden. PC-Kompatiblität ist nicht alles... > Wie kann ich die SD-Karte über den 4-Bit-Bus anzapfen, Vermutlich gar nicht. Denn in den öffentlich zugänglichen Datenblättern der SD-Cards fehlen nämlich die Informationen, die für den Zugriff im "SD Memory Card"-Mode von Bedeutung sind. Um diese Informationen zu bekommen, musst Du wohl (zahlendes) Mitglied in der "SD-Group" werden. Die SD-Card ist nunmal zum Verteilen von Multimedia-Daten konzipiert worden, wobei die Gängelung des Benutzers (Rechtebeschneidung) im Vordergrund steht. Wenn Du sie für andere Zwecke "missbrauchen" willst, dann musst Du mit den Einschränkungen leben. ...
> Aber das FAT-System ist nunmal so bescheuert, dass > man dafür viel RAM benötigt. Ich habe es deshalb > bisher gemieden. PC-Kompatiblität ist nicht alles... Das stimmt nicht. Man braucht zwingend einen 512Byte grossen Puffer um die MMC/SD Karte beschreiben zu koennen. Ansonsten koennte man sich aber Stueck fuer Stueck durch das Dateisystem arbeiten. Man liesst einfach am Anfang mal den Bootsektor ein und merkt sich dann nur in welchem Sektor die beiden FATs und das Direktory steht. Dann legt man sein File im Direktory an. Sobald man nun einen Sektor mit Daten voll hat, schreibt man ihn in sein File und schaut dann erstmal in der FAT nach wo der naechste hinsoll. Man muss sich ja nur diese Sektornummer merken. Dann kann man seinen Buffer wieder fuer Daten verwenden. Ausserdem passt man nach dem Schreiben der Daten noch schnell die FATs und das Direktory an. Auf diese Weise wuerde man mit etwa 550Byte auskommen. Waere also mit einem R8C oder dem veralteten Mega8 <BG> machbar. Klar, es waere hoellisch umstaendlich und schnarchlahm, aber fuer ein paar Messdaten wuerde es ausreichen. Aber natuerlich sowas kann man noch nicht von jemand anderem kopieren sondern man muesste es sich selber schreiben. :-] Olaf
> Man braucht zwingend einen 512Byte grossen Puffer .. Eben, und das ist in meinen Augen (für AVR-Verhältnisse) "viel RAM". Ansonsten gebe ich Dir recht. > Zum Thema FAT16 gibt es auch einen Beitrag in der Codesammlung. Sicher, aber dort wird man vermutlich auch nicht mit weniger RAM auskommen, oder? Mal ganz abgesehen davon, dass in der Codesammlung inzwischen soviel Müll steht, dass es kaum noch möglich ist, "die Spreu vom Weizen" zu unterscheiden. Ansonsten empfehle ich Christian, erstmal die Datenblätter der evaluierten Komponenten zu beschaffen, zu lesen und versuchen zu verstehen. ...
>Sicher, aber dort wird man vermutlich auch nicht mit weniger RAM >auskommen, oder? Dass man 512 Bytes braucht liegt in der Sektorengrösse begründet (soweit ich das System bis jetzt verstanden habe). >Mal ganz abgesehen davon, dass in der Codesammlung inzwischen soviel >Müll steht, dass es kaum noch möglich ist, "die Spreu vom Weizen" zu >unterscheiden. Das kann man relativ leicht an der Überschrift erkennen...da sollte/müsste trotzdem mal ausgemistet werden ...(Alle Beiträge, die ohne Anhang gestartet werden, grundsätzlich löschen - denn Code gehört in den Anhang.)
Wieso schreibt der MC die Dateien nicht einfach hinterienander auf die Speicherkarte? Am Anfang dann noch eine kleine Tablle wo drinsteht wo welche Datei anfaengt und aufhoert. Also ein einfachst-Dateisystem. Wenn du nur zwei Dateien hast und die Speicherkarte gross genug ist, dann koenntest du die erste Datei z.B. vom Anfang bis zur Haelfte und die zweite Datei von der Haelfte bis zum Ende der Speicherkarte haben. Die Dateien koennten dann noch ohne Probleme wachsen. Auf dem PC muss dann nur ein kleines Programm geschrieben werden, welches die Speicherkarte leist und die Dateien extrahiert.
> Dass man 512 Bytes braucht liegt in der Sektorengrösse > begründet (soweit ich das System bis jetzt verstanden habe). Das ist richtig. Und es laesst sich auch nicht aendern wenn man Daten schreiben will. Beim lesen kann man den Buffer auch kleiner machen. Ich weiss aber nicht ob das jede Karte unterstuezt. Aber wenn man einen Microcontroller mit 1kB Ram hat dann ist das moeglich. Ich hab jedenfalls eine Datenlogger Applikation mit R8C problemlos laufen. Das geht sogar mit im Hintergrund laufendem Debugger. (der braucht auch noch etwas Ram) Olaf
>Auf dem PC muss dann nur ein kleines Programm geschrieben werden, >welches die Speicherkarte leist und die Dateien extrahiert. Da dürfte es einfacher sein, dem µC den FAT zu verpassen. Sonst könnte man es vielleicht noch so machen, dass man die SDC/MMC als reinen Speicher für den Logger benutzt und die Daten dann per PC über den Controller abfragt (die Karte quasi direkt anlöten).
>Da dürfte es einfacher sein, dem µC den FAT zu verpassen.
Da wiederspreche ich aber!
Ich hatte von Jahren soetwas aehnliches mit einer CF-Karte gemacht.
Der MC sammelte Sensordaten und schrieb diese auf die CF-Karte.
Im Sektor 1 stand die Endposition der Datei in Sektoren. Ab Sektor 2
dann die Datei.
Unter Linux hat dann ein simples Shell-Script die Datei extrahiert.
>Unter Linux
Das kann natürlich sein (bin von der "herkömmlichen"
KlickibuntiFenster-Betriebssystem-Variante ausgegangen)
Ich beschreibe die SD-Card vom PC aus blockweise unter DOS (QBASIC-Programm) und nutze dazu meinen Eigenbau-ISP-Programmer und ein Adapter von ISP auf SD-Card. Der AVR braucht die Daten allerdings nur zum Lesen. Ein komplettes Dateisystem war bisher noch nicht nötig, also habe ich mir noch keine ernsthaften Gedanken darüber gemacht. Die Beschreibung des FAT-Systems hat mich auch erstmal davon abgehalten, dieses System zu implementieren. ...
>unter DOS (QBASIC-Programm)
Wer ausser dir macht das noch? (Nicht persönlich nehmen!)
Standard ist/soll in diesm Fall IMHO eine FAT16-formatierte SD-Karte,
die man mit Hilfe der µC-Schaltung beschreibt und im PC mit Hilfe eines
handelsüblichen "Cardreaders" (gibt's die in zwischen als
100in1-Cardreader?) ausliest.
Dass man unter Linux oder DOS sowas machen kann, kann ich mir
(inzwischen) vorstellen. Jemand, der sowas macht, sollte dann IMHO aber
auch keine Probleme haben, dieses System auf einen µC zu übertragen.
Unter Linux hat dann ein simples Shell-Script die Datei extrahiert.... auch unter windows!!! wurde es ganz einfach durchgeführt.
> Wer ausser dir macht das noch? (Nicht persönlich nehmen!) Vermutlich niemand. Aber ich hatte keine Lust, mich auf dem AT90S8535L (den Mega8535 gab's noch nicht) mit FAT zu verzetteln. Und da ich damals auch keine Möglichkeit fand, per Cardreader die SD-Card sektorweise anzusprechen, habe ich es eben so gelöst. ;-) ...
Also zumindest unter Win98 muss man Karten auch Sektorweise ansprechen koennen weil ich zum debuggen immer debug im DOS-Fenster benutzt habe und das konnte einzelne Sektoren lesen. Aber es hindert einen ja auch niemand daran eine Karte auf dem PC zu formatieren, dort ein File abzulegen und dann zu schauen in welchem Sektor beginnt das File. Man kann dann die Karte genauso Sektorweise beschreiben, aber unter beliebigen Betriebssystemen auf Filesystemebene darauf zugreifen. Olaf
Wenn wir gerade von Floppies sprechen: Sind das jetzt Schrittmotoren? Könnte man die sinnvoll als Motoren für einen kleineren Roboter verwenden? Und noch etwas zum Thema: Zu erwähnen wäre für SD-Cards die Library von Ulrich Radig, www.ulrichradig.de. (Sofern es nicht schon erwähnt wurde.)
Hallo nochmal, also es geht mir weniger um die Richtung PC --> SD --> µC, sondern eher anderst herum. Es soll möglich sein, ein (großes) Programm auf dem PC zu schreiben, das dann Compuiliert wird (nicht mit avr-gcc, sondern in eine selbst erstellte, vermutlich "leserliche" Sprache nach dem Motto "m1r40" für "Motor 1 rechtsdrehend mit 40%" oder so.). So kann man verschiedene Programme aufbauen und diese auch in einem eigenen Verzeichnis ablegen. (Zu so einem Programm gehören mehrere Dateien. => Verzeichnis zur Struktur). Nun soll der User dem AVR mitteilen (Tasten, LCD, ...), welches Programm auszuführen ist. Der AVR hat dann alle Befehle in der Datei abzuarbeiten. Idealterweise sollte er dann noch die Möglichkeit haben, die Abläufe etwas genauer zu dokuentieren (=> Datei schreiben un Unterverzeichnis) nach dem Motto "Motor drehte mit xxy Upm". Ich denke, mit einem einfachst-System komme ich da nicht besonders weit. Das wäre, denke ich ein rießiger Aufwand. Da ich nicht viel über das FAT weiß, würde mich mal interessieren, wie das eigentlich aufebaut ist. Wo bekomme ich die Info her? Wie ich schon oben erwähnt habe, will ich ja notfalls der SD einen eigenen µC verpassen. Was ist ein 8515? Ein "alter" Chip? Weil von denen hab ich noch ein paar hier rumfahren (AT98C2051 und AT89C55 (der kann doch viel ext. RAM ranhängen, oder?)) Allerdings weiß ich nicht, wie ich die Dinger richtig programmieren kann. Weiß jemand da eine Möglichkeit unter Linux mit C zu compilieren? Gibt es da freie Programmer zum Selbstbau (notfalls kann ich den auch selber machen.)? Eine andere Möglichkeit wäre natürlich, da ich Linux verwende, ein Linux-Dateisytem zu implementieren. Ich denke da an Minix, weil das ein sehr altes (klein, wenig speicherhungrig) Dateisystem ist. Aber auch hier weiß ich nicht, wie es aufgebaut ist. MfG Christian
Nimm einfach FAT. Wie die aufgebaut ist braucht dich nicht zu interessieren, es gibt fertige Bibliotheken die auch auf einen Mega8 noch passen.
Das beantwortet aber einen großen Teil meiner Fragen nicht: Zum Thema wie funktioniert FAT und zu den "alten" Chips mit ext. RAM und Programmierung. MfG Christian
FAT ist ein Filesystem (auch altdeutsch "Dateisystem" genannt). Das
hat nichts mit RAM und alten Chips zu tun.
Bei einem Dateinsystem werden auf einem bestimten Teil des
Speichermediums (File Allocation Table = FAT) Informationen zum
Lagerort, der Grösse und dem Namen der Daten gespeichert.
Das kann man im RAM natürlich auch machen (RAMdisk).
>Compuiliert
etc.
Klingt nach Fischertechnik Computing, Lego Mindstorm o.dergl.
Wenn du auf dem PC ein Programm nach deinen Vorgaben (Syntax und was da
noch so zugehört) erstellst, dann brauchst du auf dem Controller einen
"Interpreter", der deine Programmiersprache dann versteht und umsetzt
(PHP arbeitet so).
Es kommt darauf an, was du machen willst (ich habe mir dein Post nicht
komplett durchgelesen), manchmal gibt es schon eine fertige Lösung, die
man einfach noch nicht gefunden hat (jemand anders aber)...
> Was ist ein 8515? Ein "alter" Chip? Eigentlich nicht, der Mega8515 ist neuer als der Mega8. Es handelt sich um zwei pinkompatible AVRs, einmal den (veralteten) AT90S8515, zum anderen dessen Nachfolger ATMega8515. Beide haben das Feature "Speicherinterface", sind also zum Anschluss von externem SRAM vorbereitet. Für speicherhungrige Anwendungen könnte man das SRAM damit auf 32kB oder mehr aufstocken. Nähere Informationen stehen im Datasheet des AT90S8515 oder ATMega8515. > Da ich nicht viel über das FAT weiß, würde mich mal interessieren, > wie > das eigentlich aufebaut ist. Wo bekomme ich die Info her? Weiter oben http://www.mikrocontroller.net/forum/read-1-406853.html#407023 gab es den Link auf: http://elm-chan.org/fsw/ff/00index_e.html und dort ganz untern unter 'Ressources' findet man weiterführende Links, z.B. auch: http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx Weiterhin findet Google: http://www.google.de/search?num=100&hl=de&ie=ISO-8859-1&newwindow=1&q=specification+FAT+filetype%3Apdf&meta=lr%3Dlang_de%7Clang_en Es sollte also nicht unmöglich sein, Informationen zu finden. > Das beantwortet aber einen großen Teil meiner Fragen nicht: Zum > Thema > wie funktioniert FAT und zu den "alten" Chips mit ext. RAM und > Programmierung. Von alten Chips ist keine Rede, nur von AVRs mit integriertem Speicherinterface zum Anschluss eines externen SRAMs. > manchmal gibt es schon eine fertige Lösung, .. Das ist aber nicht Jedermanns Sache. Manchmal ist eigener schlechterer Code unter'm Strich besser als zusammengefundener besserer, aber unverstandener Code. Das ist eben Ansichtsache. Der Eine macht, der Andere klaut. ;-) ...
Also 1.) zum Thema FAT denke ich, kann ich erst mal was lesen. Das wir wohl etwas Zeit brauchen. Wenn ich da Fragen hab, meld ich mich! 2.) Bzgl. anderem Core: Was ist da das Problem? Das Ding 89C55 hat deutlich mehr Flash. Für eine kleine Rutine langt's allemal. Ich hab da einen Comiler namens sdcc. Funktioniert der gut (Erfahrungen?)? Gibt's einen geschickten Programmer? 3.) Das mit Interpreter & Co. war mir von vorne herein klar. Es geht hier konkret darum, einen Kreuztisch mit Spindel zu steuern. Und da sollen halt verschiedene Programme drauf laufen. (s.o.) Das wird eh ein großer Batzen; ich weiß och nicht, wie viele Chips ich brauchen werde, aber mahr als 5 werden's wohl werden. Da kann dann einer ruhig eine interpretationsaufgabe übernehmen. Eine andere Frage: Wenn man den 8515er nicht mit 64k RAM sondern - sagen wir mal - mit 32k Flash und 32k RAM ausstattet, kann der dann auch vom Flash runter arbeiten? Welche Adressen gelten dann für was? Wie kann ich in den ext. Flash springen und den ext. RAM verwenden (avr-gcc)? MfG Christian
...wer sagt eigentlich das mann alle Bytes eines Sektors nutzen muss? bei den heutigen Preisen für MMC/SD-Kareten ist es doch kein Problem z.B. nur 64Bytes eines Sektors im RAM zu halten und den Rest beim schreiben mit $00 der $FF zu füllen.
@Christian: Es ist ein Unterschied, ob du Flash (eine Art ROM) als Baustein benutzt, oder eine Flash-Card (SD/MMC/CF...). Der Baustein liefert dir bei anlegen einer bestimmten Adresse den Inhalt einer Speicherstelle. Eine Flash-Card arbeitet seriell. Da wird die Ansteuerung etwas umständlicher, geht aber auch. Der 89C55 ist ein ganz wunderbarer Controller (hab nie etwas anderes behaupten wollen). Im Prinzip kannst du ihn mit 64KB RAM ausrüsten und die FLASH-Card dann über eine andere Schnittstelle (SPI) ansprechen. Mit 64K sollte es dann auch keine Probleme bzgl. FAT geben. Die FLASH-Card lässt sich halt nicht nicht so einfach in ein Mikrocontroller-System integrieren. Egal welches Speicherinterface der Controller mitbringt (wobei eine Hardware-SPI die Sache AFAIK schon etwas erleichtert).
> http://elm-chan.org/fsw/ff/00index_e.html Ich wollte diesen Link nochmal hervorheben. Macht einen ordentlichen Eindruck und scheint besser als das, was ich eigentlich hernehmen wollte: http://www.sparkfun.com/commerce/product_info.php?products_id=657 (Siehe Download "Firmware") Zu der Speicherdiskussion: Es gibt zwei Möglichkeiten, so ein Projekt durchzuziehen: - Entweder man will schnell zu einem Ergebnis kommen, und nimmt vorgefertigte Libraries wie die von Andreas genannte. Dann braucht man halt einen größeren Prozessor, der entsprechend mehr kostet. - Oder man will etwas lernen und versucht, das gleiche Ziel mit wenig Speicher zu erreichen. Beides kann Spaß machen - ich hab mich für ersteres entschieden. Baue auch gerade eine Art Datenlogger, und da ich mit Speicher etc. keinen Ärger haben wollte, hab ich den größten MSP genommen, den ich finden konnte (1611=10K SRAM (oder nur 5? k.A.))... Christian
Ach ja, damit keine Mißverständnisse entstehen, ich bin ein anderer Christian als der Fragende...
» @Christian: » Es ist ein Unterschied, ob du Flash (eine Art ROM) als Baustein » benutzt, oder eine Flash-Card (SD/MMC/CF...). » Der Baustein liefert dir bei anlegen einer bestimmten Adresse den » Inhalt einer Speicherstelle. Eine Flash-Card arbeitet seriell. Da wird » die Ansteuerung etwas umständlicher, geht aber auch. » » Der 89C55 ist ein ganz wunderbarer Controller (hab nie etwas anderes » behaupten wollen). » Im Prinzip kannst du ihn mit 64KB RAM ausrüsten und die FLASH-Card dann » über eine andere Schnittstelle (SPI) ansprechen. » Mit 64K sollte es dann auch keine Probleme bzgl. FAT geben. » Die FLASH-Card lässt sich halt nicht nicht so einfach in ein » Mikrocontroller-System integrieren. Egal welches Speicherinterface der » Controller mitbringt (wobei eine Hardware-SPI die Sache AFAIK schon etwas erleichtert). Mein Frage hatte mehrere Intensionen: 1. Kann ich einen 8051 (oder was auch immer) einfach an ein AVR-System anschließen? Wenn ja, wie kann ich möglichst leicht programmieren (eigene Software, s. Punkt 3)? 2. Kann ich die Sachen mit dem SD-Chip einen 8051er erledigen lassen (ext. Speicher) und diesen via Soft-SPI o. ä. ansprechen? 3. Kann ich, um ein eigenes, sehr großes Programm (viele Text-Tabellen imm Flash für LCD-Ausgabe und stark verschachtelt) den Flash und den RAM erweitern? Wenn ja, wie wird das a) mit der Speicherverwaltung gemacht (RAM-Lücke?)? b) mit einem C-Compiler richtig angesprochen, dass die Variablen in den RAM ausgelagert werden? Wie die Teile für internes und externes Flash erzeugen? (avr-gcc wegen 8515 und irgendwas für die 8051er!) Ist es möglich, dem Compiler zu sagen, was extern und was intern sein soll? MfG Christian
Da ich momentan sehe, dass das zu weit vom eigentlichen Thema weggeht, schreibe ich das in separate Beiträge ins Forum. Danke Christian
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.