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 )
Papperlapap... WENN DU IM lOW-LEVEL BEREITS SCHREIBEN KANNST, WO IST DEN DAS PROBLEM ? ICH GLAUBE DU REDEST BLÖDSINN.
@ 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.
Also nochmal: Bitte keine Angst davor, das die Festplatte zu langsam sein könnte. Ich garantiere, das ich Platten habe, die schnell genug sind.
Wie sieht der das Interface zum Sensor aus? Die Daten kommen doch nicht über RS232 rein?
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 Würde mich mal einfach so interessieren, was denn da geloggt werden soll ;-) Gruss Michael
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.
Hallo Rainer, Welche Sensoren liefern solche Datenmengen? Ich kann mir das irgendwie nicht vorstellen. Was misst du denn? Mfg Markus
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.
Neben den Opencores gibt es auch noch kommerzielles (siehe Anhang) Nachteil: kostest Geld Vorteil: getestet, bewährt, auf dem neusten Stand-> Implements ANSI ATA/ATAPI-6 standard protocol Supports connection up to 2 ATA devices Configurable ATA interface operating with the Maximum data transfer rate of 100 MB/s Supports all PIO Modes 0,1,2,3,4 Supports Multiword DMA modes 0,1,2 Supports all Ultra DMA modes 0,1,2,3,4,5 Übrigens CRC-Generierung in einem programmierbaren Logikbaustein ist wirklich kein Problem: Table 47 - Equations for parallel generation of a CRC polynomial CRCIN0 = f16, CRCIN8 = f8 XOR f13, CRCIN1 = f15, CRCIN9 = f7 XOR f12, CRCIN2 = f14, CRCIN10 = f6 XOR f11, CRCIN3 = f13, CRCIN11 = f5 XOR f10, CRCIN4 = f12, CRCIN12 = f4 XOR f9 XOR f16, CRCIN5 = f11 XOR f16, CRCIN13 = f3 XOR f8 XOR f15, CRCIN6 = f10 XOR f15, CRCIN14 = f2 XOR f7 XOR f14, CRCIN7 = f9 XOR f14, CRCIN15 = f1 XOR f6 XOR f13, f1 = DD0 XOR CRCOUT15 f2 = DD1 XOR CRCOUT14 f3 = DD2 XOR CRCOUT13 f4 = DD3 XOR CRCOUT12 f5 = DD4 XOR CRCOUT11 XOR f1 f6 = DD5 XOR CRCOUT10 XOR f2 f7 = DD6 XOR CRCOUT9 XOR f3 f8 = DD7 XOR CRCOUT8 XOR f4 f9 = DD8 XOR CRCOUT7 XOR f5 f10 = DD9 XOR CRCOUT6 XOR f6 f11 = DD10 XOR CRCOUT5 XOR f7 f12 = DD11 XOR CRCOUT4 XOR f1 XOR f8 f13 = DD12 XOR CRCOUT3 XOR f2 XOR f9 f14 = DD13 XOR CRCOUT2 XOR f3 XOR f10 f15 = DD14 XOR CRCOUT1 XOR f4 XOR f11 f16 = DD15 XOR CRCOUT0 XOR f5 XOR f12 NOTES 1 f = feedback 2 DD = Data to or from the bus 3 CRCOUT = 16-bit edge triggered result (current CRC) 4 CRCOUT(15:0) are sent on matching order bits of DD(15:0) 5 CRCIN = Output of combinatorial logic (next CRC)
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=17 VHDL 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.
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.