Archiv verlassen und diese Seite im Standarddesign anzeigen : Festplatte an Mikrocontroller (IDE & NTFS)
Hat zwar nix mit Robotern zu tun,
aber vielleicht hat ja trotzdem Jemand Ahnung davon...
Der Titel sagt eigentlich schon alles:
Ich will eine normale IDE Festplatte (beliebiger Grösse) an einen Mikrocontroller hängen.
Dafür wollte ich eigentlich 2 µCs nehmen, also so:
Platte -> µC1 -> µC2 => wohin auch immer
Dabei wäre µC1 für die eigentliche Ansteuerung der Platte zuständig (würde also quasi den IDE-Bus bereitstellen)
und µC2 für das Dateisystem (also NTFS)
Was ich also in erster Linie mal brauche sind die Spezifikationen vom IDE-Bus
also sowohl Hardware als auch Protokoll.
Und dann brauche ich natürlich möglichst viele Informationen zum NTFS Dateisystem
(oder notfalls FAT32, aber NTFS wär besser)
letztendlich soll es dann so aussehen, daß ich µC2 den Befehl gebe eine Datei zu erstellen,
und der wiederum schickt dann eine entsprechende Kommandosequenz zu µC1.
also von aussen will ich einfach mal die grundlegendsten Funktionen haben um Daten auf der Platte zu speichern bzw. zu lesen.
(Dateien/Verzeichnisse erstellen/löschen/umbenennen, Platte formatieren, evtl. partitionieren)
Verbinden werde ich die µCs wohl mit einem parallelen Datenbus (mit allen ports die noch übrig sind)
und einem seriellen (I²C) für die Befehle.
Das ganze System soll auf grösstmögliche Geschwindigkeit ausgelegt sein.
Ich brauche eine Übertragungsrate von 15 MByte/s oder mehr (schön wäre natürlich volle IDE Geschwindigkeit bei UDMA2, also 33MB/s)
deshalb will ich das auch unbedingt auf 2 Mikrocontroller verteilen, selbst wenn einer vielleicht reichen würde (was ich mir allerdings nicht vorstellen kann)
Ich hoffe ihr könnt mir da weiterhelfen http://unrealed.myexp.de/forum/style_emoticons/default/smile.gif
PS: PC-104 oder ähnliche Systeme wollte ich eigentlich nicht verwenden
Hi
Ich kann dir leider nicht helfen. Wollte dir aber sagen, dass du NTFS mit größter Wahrscheinlichkeit nicht hinbekommen wirst. Wenn du zur Zeit etwas die Entwicklungen in der Linux Szene verfolgst, wirst du meirken, dass man eigentlich nur von einem NTFS Laufwerk lesen kann. Das Schreiben funktioniert nur teilweiße. Warum das Ganze??
Es liegt wie so vieles an Microsoft, die die Spezifikationen von NTFS nicht freigeben und somit sie durch Reverse Engeneering beschafft werden müssen.
Trotzdem viel Glück mit deinem Projekt
MfG
hmm, das ist natürlich schlecht...
aber ein vergleichbares System würds notfalls auch tun
Schau mal bei den MP3 Player Projekten. Die haben sowohl die IDE Specs als auch die Implementation der Filesystemen. Außerdem noch Erweiterungen wie 'lange Dateinamen'.
Als Alternative zu NTFS (was zu kompliziert ist und bei uC Projekten auch nicht benötigt wird) gibt es FAT (FAT, FAT8, FAT12, FAT16, FAT32).
15MB/s ?? Was willst du denn machen? Und welche Controller willst du einsetzen? AVRs schaffen das naürlich nicht.
Grüße
Flite
was ich machen will?
eine Netzwerkfestplatte.
Das ist das Ziel das ich mir gesteckt habe.
d.h. ich stecke die Platine hinten an eine Festplatte, verbinde das Teil mit dem Switch...
und habe dann vom LAN aus Zugriff darauf als wäre es einfach nur ein freigegebenes Verzeichnis auf irgendeinem Rechner.
bei 100MBit LAN bräuchte ich also 12.5MB/s Übertragungsrate, dafür würde dann auch der PIO Modus reichen (ca. 16MB/s).
Aber schöner wäre natürlich 1000MBit LAN, denn da könnte man die maximal 33MB/s bei UDMA2 voll ausnutzen.
Aber das muss nicht sein, ich bin auch mit 100MBit zufrieden.
FAT32 würde ich nur ungern verwenden, da es NTFS nunmal weit unterlegen ist.
Bei der Sache brauch ich schon was anständiges.
edit: das heisst natürlich nicht, daß es zwingend NTFS sein muss, aber was Vergleichbares
Welche Controller ich verwenden will weiss ich noch nicht...
ist mir im Prinzip auch sch**** egal, solange sie schnell genug sind.
Hm... Also ich hab zwar nicht die Riesenahnung, aber ich fürchte, dass die uCs da ein wenig zu langsam für sind!
notfalls nehm ich halt zwei MB91302A von Fujitsu...
das ist ein 32Bit Controller mit einer maximalen Taktfrequenz von 68 MHz.
das sollte doch reichen oder?
edit:
ich könnte ja auch statt µC1 einen fertigen ATA-Controller verwenden...
nur leider sind alle die ich bisher gefunden habe "PCI-to-ATA" (also speziell um über den PCI-Bus zusätzliche Festplatten anschliessen zu können),
und eignen sich daher wohl kaum für Mikrocontrollerprojekte.
aber praktisch wär's schon, wenn es da welche gäbe die quasi "Rohdaten" liefern, denn dann bräuchte ich mir um den Teil schonmal keine Sorgen mehr machen.
Hallo Felix
ich habe früher bei 2 sehr bekannten Us Halbleiterfirmen gearbeitet. Ich meine deine Aufgabenstellung rechtfertigt sich nur als "hobby-Aktion". Wenn du es aber machen möchtest würde ich einen Festplatten-Controller IC nehmen. Die Halbleiterhersteller haben in ihren Applikationsnoten normalerweise alles was man so braucht, also Schaltung und eine Menge info zur Software. Bin leider schon länger nicht mehr dabei, bin daher über die gegenwärtigen Produkte hierfür nicht informiert. Google mal.
Ein Fesplattencontroller ist ja extra für die Aufgabe designed und übernimmt also den Großteil, ein universeller uC ist keine geeignete Auswahl. genauso würde ich übrigens auch bei deiner Schaltung betreff I/F zum Netz verfahren.
Ok - wenn du eine LAN Platte basteln willst, sind die 15MB/s schon richtig gewählt.
Ich habe noch nie mit sowas gearbeitet. Kann dir leider nicht weiterhelfen.
Grüße Flite
Hallo Hellmut,
googlen nach "Festplattencontroller" oder "hard disc controller" liefert mir alles mögliche, aber leider keinen einzigen Hersteller.
wer produziert denn solche Teile?
was den LAN-Teil angeht, dafür wollte ich eh keinen Mikrocontroller nehmen, sondern einen W3100A von WIZnet.
Bei dem Ding ist ja praktisch alles was man braucht schon mit drin (die wichtigsten Protokolle etc.)
d.h. im Idealfall sähe die Geschichte dann wohl so aus:
Festplatte -> Festplattencontroller -> µC -> W3100A -> LAN
wobei der µC dann für das Dateisystem zuständig wäre
daß das nur eine "Hobby-Aktion" ist, is klar,
ich will die Dinger nich vermarkten oder so (oder vielleicht doch!? hmm...)
es wäre ja viel einfacher und bequemer nen kleinen alten Rechner mit Platten vollzustopfen und die dann im Netz freizugeben.
aber die Mikrocontrollervariante hat halt enorme Vorteile:
- lautlos (vom Plattengeräusch mal abgesehen)
- stromsparend
- mobil (nimmt man statt dem USB-Stick halt die LAN-Platte mit)
@Flite
jo, den Wert habe ich nicht ohne Grund gewählt ;)
12.5MB/s würden zwar auch reichen, aber ein bischen Reserve schadet ja nie
Hi Felix G,
Schau mal hier, da gibts auch schon ein fertiges Layout, da du evtl. anpassen kannst.
http://home.cybervillage.de/heesch/ide.htm
Gruss sensor
noch was....
du könntest ja auch einen ALTERA nehmen und in VHDL Proggen. Hardwarenaher gehts fast nimmer. Sind auch recht schnell. Genaueres weis ich allerdings nicht.
Gruss sensor
Hessibaby
20.10.2004, 09:07
Hi Felix,
mal ganz davon abgesehen das es beliebig viele fertige NAS-Kontroller gibt würde ich den Lösungsansatz an deiner Stelle entweder an einem USB/IDE- oder einem Parallel/IDE-Konverter suchen da diese das Handling der Platte und die Verwaltung des Filesystems (meistens FAT32) übernehmen. Einen µC mit einem PHY an der einen und USB/Parallel an der anderen Seite mit einem TCP/IP-Stack zu programmieren stellt schon eine sicherlich interessante aber auch sehr anspruchsvolle Aufgabe dar ( Zeitaufwand mit einem ATMEL ca. 150 - 200 Stunden ). Die Implementierung eines Filesystems ist selbst für absolute Profis eine Wahnsinnsaufgabe. Die Erstellung von NTFS hat über 400 Mannjahre gedauert.
Der einzige Lösungsansatz wäre die Disassemblierung von z.B. FreeDOS oder die Analyse von PTS-DOS um sich das Diskhandling anzusehen. Wenn Du möchtest kann ich Dir meine PTS-DOS Developer CD gerne zur Verfügung stellen. Allerdings stelle ich mir das Umassemblieren von X86 Code auf ATMEL ziemlich heftig vor.
Die oben erwähnten NAS-Kontroller haben üblicherweise einen X86 kompatiblen CPU-Core und setzen auf embedded-Linux bzw. embedded-NTServer auf.
Über die erforderliche Rechenleistung zur Erzielung des von Dir angedachten Datendurchsatzes möchte ich an dieser Stelle nicht philosophieren sondern nur anmerken das z.B. der früher in PC´s eingesetzte ISA-/EISA-Bus mit seinen 8/16MHz cycle zu langsam für 100Mb Ethernet war.
Gruß Hartmut
Hallo Felix
Ich denke das der Link von sensor der gangbare Weg ist. Wer schön über den Fortgang deiner Entwicklung auf dem laufenden gehalten zu werden.
@Sensor
erstmal danke für den Link...
was Altera betrifft, meinst du ein CPLD oder ein FPGA?
ich schätze mal ein CPLD reicht für nen IDE-Bus oder?
@Hartmut
NAS...
ich war wirklich geschockt als ich nach NAS controller gegoogelt habe,
und feststellen musste, daß es das was ich bauen möchte schon fertig auf einem kleinen Stück Silizium gibt.
Die haben mir meine Idee geklaut http://unrealed.myexp.de/forum/style_emoticons/default/gc.gif
Aber da bin ich jetzt erst recht stur, und mache das ohne so ein Ding http://unrealed.myexp.de/forum/style_emoticons/default/p.gif
Was das Dateisystem betrifft...
mag sein, daß die Entwicklung von NTFS so lange gedauert hat,
aber ich will ja kein neues Dateisystem entwickeln sondern nur ein bestehendes implementieren.
Das dauert sicherlich auch seine Zeit, aber es ist schaffbar.
aber mal was anderes...
wäre es sehr viel schwerer einen PCI-Bus zu bauen anstatt einem IDE-Bus?
denn wenn nicht könnte ich auch einfach einen PCI Bus machen, und dann ein paar MB RAM und nen ATA-Controller dran hängen.
dann könnte ich die Platte z.B. auch im UDMA-Modus verwenden.
und wenn ich mich nicht irre heisst das ja nur, daß der ATA-Controller die Daten direkt von der Festplatte ins RAM schreibt.
das wäre praktisch, denn dann bräuchte ich mit meinem Dateisystem-µC nurnoch aufs RAM zugreifen.
@Hellmut
klar, wenn die Vorbereitungen (Literatur anschaffen etc.) abgeschlossen sind, und ich das tatsächlich versuche,
werde ich euch natürlich auch auf dem Laufenden halten (und mit Fragen löchern http://unrealed.myexp.de/forum/style_emoticons/default/zwinker.gif)
Hi,
>was Altera betrifft, meinst du ein CPLD oder ein FPGA?
Ich kenne eigentlich nur den FPGA, allerdings bin ich da nicht der crack :(, hab fast noch nie was damit gemacht. VHDL ist nicht mein ding :-), obwohl es inzwischen schöne Grafische Prog. möglichkeiten gibt. Seh's halt bei den Kollegen...
Gruss sensor
Hessibaby
22.10.2004, 14:51
Hi Felix,
einen PCI-Bus zu implementieren erachte ich als nicht notwendig denn auch ohne diesen kannst Du ja ne PCI-Netzwerkkarte und einen PCI-ATA-Controller benutzen. Du muß halt auf die Spannungen achten da die PCI-Bus Komponenten seit einigen Jahren üblicherweise mit 3V3 und nicht mehr mit 5V0 arbeiten. Und bei z.B. einem ATMEGA hast Du genügend Ports um beide Seiten bedienen zu können.
Gruß Hartmut
Hallo Hartmut,
meinst du ich soll den ATA-Controller direkt mit dem Ethernet-Controller verbinden, und den µC nur zum "steuern" der beiden Komponenten verwenden?
geht das denn überhaupt?
und wo soll ich dann das Dateisystem unterbringen?
ich mein...
prinzipiell muss ja zwischen ATA-Controller und Ethernet-Controller noch mein Mikrocontroller mit dem Dateisystem.
(eigentlich müsste sogar noch ein weiterer µC mit rein für die Netzwerkprotokolle etc.)
oder meinst du was ganz anderes und ich hab das nur falsch verstanden?
Was mir als einfachstes dazu einfällt, wäre einen kleinen ARM-7-TDMI zu nehmen, da gibts auch schöne mit integriertem Netzwerk-Controller und auf denen läuft auch uC-Linux, was bedeutet, dass du damit "nur" noch die Anbindung einer Festplatte realisieren musst, wobei es das glaub ich sogar auch schon gibt... Dann kannst du später einfach der FTP oder HTTP auf den Controller zugreifen.
Sowas ähnliches basteln wir im Embedded-Systems-Labor bei uns an der FH und das geht wirklich bequem...
Das schöne an dem Samsung-Chip ist, dass man direkt SD-Ram anschließen kann und sich keine Gedanken um den Refresh machen muss...
unter http://eiti.fh-pforzheim.de/labore/embsys/embsys.htm findest du noch ein paar Details zu dem ARM und zur Programierung.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.