Ich suche Leute die mir helfen das nachfolgend beschriebene Projekt
kostengünstig umzusetzen:
Man könnte es im wesentlichen einen kleinen, mobilen Datenrecorder
nennen, der Daten eines Sensors unverändert auf eine
(Wechsel-)Festplatte schreibt.
Der Sensor wird mit 40MHz getaktet und liefert kontinuierlich digitale
12Bit Daten. Durch verschieben der Bits/Bytes erhält man also einen
Datenstrom von 60MB/Sekunde. Einige ausgewählte IDE Festplatten sind in
der Lage deutlich mehr kontinuierlich und sicher bis zum letzten Sektor
zu schreiben. Ein RAM Buffer dürfte nicht erforderlich sein, denn neue
Festplatten haben genügend Cache. Außerdem kommen sie ohne defekte
Sektoren. Ein Filesystem ist daher auch nicht zwingend erforderlich.
Das Lesen und Auswerten der Daten ist ebenfalls nicht Teil des
Projektes, es erfolgt später auf einem PC.
Über ein Interface (z.B. RS232) werden wenige Befehle an den Sensor
sowie Record und Stop Befehle gesendet und z.B. Festplatte ist voll
zurückgegeben.
Übrigens, speichern auf RAM geht nicht, da es vorkommen kann das selbst
eine 100GB Platte ohne Unterbrechung beschrieben wird.
Es ist noch wesentlich mehr erforderlich aber wer sich zutraut das bis
jetzt beschriebene zu realisieren sollte sich bei mir unter
elvsto@gmx.de melden. Das Ganze soll auch nicht umsonst sein.
Der zweite Teil des Projektes besteht darin, die Sensordaten
gleichzeitig und unabhängig von der HDD Aufzeichnung, durch eine noch
zu definierende Echtzeitverarbeitung leicht verändert über ein
ebenfalls noch zu definierendes Interface auszugeben. Dies kann auf
einer separaten Platine geschehen und erfordert einen Buffer von
mindestens 4MB (besser.16MB).
Der Hardwareaufwand inkl. Platinen (ohne Sensor und HDD) sollte bei
einer späteren Kleinserie maximal 250,- Euro/Stk. betragen.
nur mal so ein paar fragen am rande
1. welches fs macht denn z.b. 100GB -files mit?
2. was ist an hardware da? 60MB/Sekunde sind nicht wirklich wenig!
3. ist denn alles durchgeplant? oder ist es zur zeit nur ein
hirngespinnst?
Hi
@KoF
Er braucht kein FS. Und für NTFS und Reiser sind 100GB kein Problem.
Bei ext2 kommts auf die Clustergröße an. Ach, was erzähl ich denn
hier:
http://en.wikipedia.org/wiki/Comparison_of_file_systems
@Reiner Stolz
Welche IDE-Platten schaffen denn 60MB/s? Und bitte nicht nur außen
sondern über die komplette Platte? Wenn ich mir das aktuelle c't
Plattenkarusell so anschau schafft keine! IDE-Platte im Mittel!
60MB/s.
Matthias
@ KoF,
1. wie ich bereits sagte, auf der Platte braucht kein fs zu sein. Die
Daten werden einfach Sektor für Sektor oder Block für Block
geschrieben, fast so simpel wie formatieren. Lesen geht genauso
einfach. Ein Dateisystem z.B. FAT32, ist sicherlich schöner, aber auch
aufwendiger. Dann könnte man z.B. Dateien mit fixer Länge schreiben und
als Namen z.B. vorlaufende Nummern.
2. + 3. Was ist an Hardware da? Nun, zunächst Sensor und Platte (eine,
die locker 75MB/Sek auch auf den inneren Sektoren verkraftet). Okay,
Scherz beiseite. Das ganze ist schon sehr durchdacht, bis hin zu allen
optischen und feinmechanischen Teilen. Und da sind eine Menge drin,
weil es doch heftig mehr ist als nur ein Datenrekorder (mehr will ich
noch nicht verraten). Inkl. Gehäuse wurde es sogar schon als
funktionierendes Muster präsentiert (allerdings mit einem am Kabel
hängenden PC). Es ist also kein Hirngespinst. Ich denke, ich habe
mehrere alternative Lösungen gefunden, welche Hardware hängt aber auch
davon ab, wer mitmacht und welche Hardware derjenige am besten
beherrscht.
@ Matthias,
ich habe lange gesucht und Plattenhersteller direkt angesprochen, mein
Ziel beschrieben und daraufhin ein "Vorab-Testmuster" der noch nicht
erhältlichen Hitachi Travelstar 7K100 bekommen. Das ist eine 2,5"
Notebookplatte und sie ist schneller als die meisten Serverplatten. Ich
konnte im Low Level Dauerbetrieb fast 75MB/schreiben
( http://biz.yahoo.com/bw/050511/115182.html?.v=1 )
@ Stift: Danke, sehr hilfreicher Kommentar...
Fakt ist, es gibt schon länger schnelle 3,5" Platten aber erst
demnächst richtig schnelle 2,5"er. Letztere konnte ich vorab testen
und mit meinem PC (und ollem DOS Tool) ist sie so schnell wie ich´s
geschrieben hab. Mein Problem ist also nicht die schnelle Platte,
sonder die Tatsache, das ich KEINEN PC benutzen will. Warum sonst würde
ich hier Hilfe suchen? Die Projektbeschreibung ist da ziemlich
eindeutig.
Hi Stift,
Du weisst aber schon das Du da einen leistungsfaehigen IDE-Host-
Controller implementieren must, weil mit PIO-Modes kommst Du da
nicht sehr weit? Und wenn man da etwas bestehendes recyceln will
kommt das mit hoher Warscheinlichkeit aus der Rechnerwelt und
verwendet bestimmt Busmaster-DMA, d.h. das Businterface muesste
einschneidend umgeschnitzt werden um die Daten direct und
selbststaendig zur Platte zu schreiben. Falls jemand als Hobby
sowas fertigbringt hat er meinen tiefsten Respekt. 75MB/s bedeuten
immerhin 27ns pro 16-Bit Wert ohne Protokoll.
Mal eine Frage, wie hast Du unter DOS 75MB/s Transferrate zur
Platte gemessen?
Gruss,
Jens
Hallo,
das geht sicherlich mit einem FPGA - aber das ist schon ein etwas
grösseres Projekt. Und die 250 sind mit Platte oder wie genau
kalkuliert. Ich denke auch das es ein etwas grösseres Projekt wird:
also 3-4 Monate Entw Zeit. Und wer trägt die ganzen Entw Kosten? Wie
gross ist der Topf dafür?
Martin
Hallo Martin,
Das geht nur mit einem schnellen FPGA, aber schon ein normaler
UDMA-faehiger IDE-Kontroller ist eine harte Nuss. Dieser hier
soll aber zusaetzlich das Protokoll beherschen, also z.B.
selbsstaendig Sektoren addressieren. Sonst macht sowas ja die
CPU. Und wenn ich mit meiner Vermutung bzgl. des Einsatzzweckes
richtig liege reicht einfach von vorne bis hinten vollspielen
irgendwann auch nicht mehr aus, da sollte auch schon schreiben
oder lesen ab bestimmten Stellen moeglich sein.
Ich will den Plan ja nicht schlechtreden, aber ich glaube nicht
das das etwas fuer den Amatuerbereich ist. Um sowas zu debuggen
braucht man einen etwas besseren Logikanalysator und bei
elekrischen Problemen auch ein gutes Scope.
Wie viel sollte die Sache gleich kosten?
Jens
Oder man greift gleich zu einem entsprechendend ausgewählten Controller
oder SoC (32 Bit mit GCC-Unterstützung,ATAPI-Controler, DMA on Chip und
idealerweise noch etwas frei programmierbare Glue Logic zum Bits
schieben).
Hat jemand zufällig einen Link wo das ATAPI-Protokoll auf Hardwareebene
genauer beschrieben ist?
Ich war verreist, daher erst jetzt meine Antworten:
1. zum Sensor: Ich arbeite mit unterschiedlichen Sensoren, manche
liefern analoge Signale, andere digitale. Ist aber egal, da ich immer
ein Sensorinterface mit (oder ohne AD Wandler) aufbaue das in jedem
Fall am Ausgang 12 digitale Ausgangsleitungen und einen Clock Eingang
welcher mit 40MHZ getataktet sein muss, hat. Der Sensor, bzw. die
Sensorplatine liefert also mit jedem Tackt ein digitales 12Bit Signal.
Der Tackt muß immer kontinuierlich sein.
2. welche Anwendung: Nun ja, wenn ich das verrate werdert ihr sicher
antworten das dies sowieso UNMÖGLICH sei, oder? Aber wie gesagt, auf PC
basis funktioniert es schon. Auch hier hatten viele gesagt, es sei
unmöglich, aber wir kamen damit auf die Titelseite mehrerer
Fachzeitschriften. Wer mehr wisse will, bitte nachfragen.
3. HDD Interface: Mir ist klar, PIA ist viel zu langsam. Ein paar
(P)ATA bzw. IDE Lösungen sind auf
http://www.opencores.org/projects.cgi/web/ata/overview
zu finden.
Es muss ja nicht bei einem einfachen FPGA bleiben. Sicher ist mehr
"Intelligenz" hilfreich, zumal später tatsächlich noch viel mehr
funktionen hinzukommen sollen.
Ich denke, daß gerade im Hinblick auf Erweiterbarkeit eine FPGA-Lösung
ideal ist. Der IDE-Core benötigt beispielsweise bei einem Xilinx FPGA
etwa 1000 Slices, was bei den aktuellen FPGA-Familien fast schon die
kleinste Größe ist.
Wählt man also einen deutlich größeren Typ hat man große Reservern, um
einfache Steuerungs- oder im großen Umfang DSP-Aufgaben zu erledigen.
Wenn die Steuerungsaufgaben überwiegen bietet es sich sogar an eine
Soft-CPU im FPGA zu integrieren oder man wählt einen Typ z.B. aus der
Virtex 2Pro Reihe, der schon einen IBM PowerPC enthält.
Da man sich so im wesentlichen auf einen Baustein beschränken kann,
sollte auch das Budget ausreichen.
Ja, Opencores ist (mir) bekannt. Nur kommt man da über 16 MB/s nicht
hinaus. Dafür brauchts UDMA4/5/6 was 66/100/133 MB/sec entspricht. Nur
da wird aus Gründen der Datensicherheit paketorientiert gearbeitet und
die Pakete haben crc-Prüfsummen. Das macht beim PC der Controller. Und
beim FPGA müßte man halt wissen wie (incl.das drumherum).
Und wenn PC-Basis geht, was spricht (ausser dem vermutlich höheren
Preis) gegen einen extrakleinen Industrie-PC.
Tom, Du hast recht, aber gegen die PC Lösung (wir haben schon ein
kleines, schnelles 17x17cm Industrie MiniITX Board mit Pentium M
benutzt) spricht erstens der Stromverbrauch und zweitens daß der PC-Bus
seine Grenzen erreicht hat. Da ich aber beabsichtige demnächst die
nächste (und übernächste) Sensorklasse zu benutzen, wird ein PC nicht
mehr mitkommen. Zur Erklärung: Derzeit benutze ich einen Sensor mit
einem 12Bit Ausgang, mein Ziel sind aber Sensoren mit mehreren 12Bit
Ausgängen (die größten derzeit lieferbarten haben 16(!)gleichzeitig
arbeitende Ausgänge. Das entspricht einer Datenmenge von
960Mbyte/Sekunde. Die geplante FPGA Lösung könnte sowohl für den
jetzigen Sensor als auch für zukünftige eingestzt werden, weil sie je
nach Anzahl der Sensorausgänge einfach multipliziert werden kann;
sozusagen eine Einheit mit je einer Festplatte für je einen
Sensorausgang.
Okay, da ich immer mehr emails und Anfragen bekomme um was für eine
Anwendung es sich handelt, zunächst zwei Dinge vorweg: Es wird nichts
gemessen und das Ganze ist wesentlich spannender aber auch
umfangreicher als nur das Aufzeichnen von irgendwelchen Messdaten.
Ich bin gerade dabei eine Webseite einzurichten mit detailierten Infos
zu dem Projekt. Link folgt in Kürze, dann wisst ihr mehr.
Die CRC-Generierung nicht. Nur müßte man wissen welches Polynom zur
Berechnung benutzt wird. Ob der Header mit in der Prüfsumme auftaucht,
wie eventuelle Fehler signalisiert werden etc. Wie schon geschrieben,
ich hab fleissig gegoggelt und nicht wirklich was gefunden.
Image-Sensoren liefern solche Datenmengen :-) passt auch zu den
erwähnten optischen und feinmechanischen Komponenten.
Bei der Kernforschung fallen meines Wissens ebenfalls ähnliche
Datenmengen an, Glaub aber nicht das es hierbei darum geht.
An VirtexII Pro hab ich auch gedacht. Dürfte aber preislich den Rahmen
etwas sprengen.
Die Logik-Gleichungen stammen aus einem "Working Draft zu ATA5" und
beziehen das Polynom schon mit ein.
Ich hab das pdf mal gezippt und hänge es in zwei Teilen an
Hallo,
das Ding ist für mich eine Nummmer zu groß. Natürlich würden mich
interessieren was der Initiation bauen will.
Ich habe auch im Netz gesucht nach entsprechenden Möglichkeiten. Als
Tipp habe ich diesen Mann.
http://www.gte.us.es/db/doc/web/users.php?lang=uk&id=17VHDL implementation of an IDE-ATA controller
Student's name: Ramón Martín Álvarez
Electronics Engineer. Date: 2001-11-01
FPGA implementation of a harddisc controller
Den Artikel hat ein Student von Ihm geschrieben, ansonsten scheint er
fit zu sein. Sicher hat er für dein Geld auch noch studentische
Reserven.
