Hallo, ich möchte eine Schaltung aufbauen, in der ein ADC von Comport Data eingesetzt werden soll: https://www.comport-data.com/wp-content/uploads/2016/03/CDI64500_datasheet.pdf Was mir Bauchschmerzen bereitet, ist die Auswertung der Ausgangsdaten des ADC. Vom Hersteller ist zur Signalübertragung ein LVDS Interface mit <30 MHz Taktung vorgesehen. Bis jetzt habe ich keinen µC gefunden, der mit dem LVDS output klar kommen könnte. Hat jemand eine Idee, ob das ganze von einem Raspberry PI bewerkstelligt werden kann? Auf ein FPGA würde ich gerne aus Kosten- und Programmieraufwand-Gründen verzichten... Vielen Dank
Ein PI ist so ziemlich das ungeeignetste, was Du nehmen kannst. Die Peripherie ist einfach mager. Das geeignetste währe in der Tat eine FPGA-Plattform, z.B. mit Zynq oder Cyclone 10 SOC. fchk
fchk schrieb: > Das geeignetste währe in der Tat eine FPGA-Plattform, z.B. mit Zynq oder > Cyclone 10 SOC. Wenn er mit MATLAB entwickeln- , einige LVDS-Receiver-Cores instanziieren und diese per Zynq oder NIOS konfigurieren und in Echtzeit monitoren will, dann sind solche FPGA-Kavenzmänner sicher angebracht. Wenn er aber nur LVDS annehmen und in einen parallelen Datenstrom übersetzen will, reicht ein 9,- Euro FPGA mit einer Seriel-Parallel-Wandlung und anschließendem Speicher (aka Schieberegister mit Latch). Davon kriegt man Dutzende in einem FPGA unter. Programmieraufwand 30min. FPGAs sind die besten ÜBersetzer zwischen Quellen und Senken mit stark unterschiedlichen Taktfrequenzen (in beide Richtungen). Beitrag "BRAMs packen (lassen) - wie konfigurieren / instaziieren?"
Wo sollen die Daten hin? Was ist der Durchsatz? Die ZynQ-Lösung ist dann gut, wenn man Daten per UDP und dem Linux-Overhead verschippern will, vorausgesetzt, man hat den passenden Kerneltreiber. Hat man ihn nicht, zieht man besser ein Interface in ein bare-metal Referenzdesign ein. Da gibt es fertige Setups mit UDP/IP-Stack und Eingangs-Datenport. Oder nimmt eine USB-Lösung auf Basis Cypress FX2/FX3.
Vielen Dank für eure schnellen Antworten! Da ich gar keine Erfahrung mit FPGAs habe: was wäre denn ein einfach programmierbarer und günstiger FPGA, der LVDS annehmen kann und die Daten dann z.B. als I2C oder Uart wieder rausgibt? Danke für eure Hilfe
Moin, Kurt R. schrieb: > Da ich gar keine Erfahrung mit > FPGAs habe: was wäre denn ein einfach programmierbarer und günstiger > FPGA, der LVDS annehmen kann und die Daten dann z.B. als I2C oder Uart > wieder rausgibt? Hm - kanns sein, dass du nicht nur keine Erfahrungen mit FPGAs hast, sondern auch keine Erfahrungen mit dem Durchsatz verschiedener Interfaces? Irgendwie passt das alles nicht zusammen. Erst so ein Dickschiff als ADC und dann spaeter auf I2C oder UART? Was brauchst du denn tatsaechlich an Kanaelen, Aufloesung und Abtastraten. Und jetzt "in echt", nicht geprahlt. Gruss WK
Am Ende sollen die Daten auf einem PC zur Visualisierung landen. Zwischen FPGA und PC muss sowieso noch ein microcontroller geschaltet sein(oder?). Ich probier daher gerade herauszufinden, ob der PSoc 5 mit seinem hardware implementieren Schieberegister in der Lage ist, den LVDS Datenstrom zu verarbeiten. Zum Datendurchsatz: der CDI64500 ist ein 18bit ADC, dessen system clock nicht unter 30 MHz arbeitet. Von den 64 möglichen Eingängen werde ich maximal fünf nutzen. Vielen Dank für eure Antworten PS: Ich bin relativ neu in der ganzen Thematik, verzeiht mir also dumme Kommentare / Ideen ^^
Der ADC ist für meine Anwendung interessant, weil er mit sehr kleinen Kapazitäten am analogen Frontend arbeit und dadurch eine hohe Verstärkung ermöglicht. Ich möchte sehr kleine Ströme (im Picoampere Bereich) von Pyroelementen mit dem ADC verarbeiten. Und du hast recht "Dergute W.": ich habe bislang nur ein bisschen Erfahrung mit I2C und Uart Schnittstellen. Deswegen bin ich leider auch mit dem lvds output ein bisschen überfordert. Danke für eure Hilfe.
Moin, Kurt R. schrieb: > Am Ende sollen die Daten auf einem PC zur Visualisierung landen. > Zwischen FPGA und PC muss sowieso noch ein microcontroller geschaltet > sein(oder?). Nicht unbedingt. Es waere denkbar, die Daten direkt vom ADC in einem FPGA direkt in RTP/UDP Pakete zu verpacken und die dann ueber 100MBit Ethernet an den PC zu verschicken. Das ginge unter Bequemlichkeitsabstrichen (IP/MAC Adresse/Port ist alles fest im FPGA-Bitstream einprogrammiert, etc.) ohne CPU. Das wuerde wahrscheinlich mit dem kleinsten Spartan6 (und externem Ethernet-PHY) schon hinhauen. Aber die Frage ist ja auch, ob's fuer dich machbar ist. Kurt R. schrieb: > PS: Ich bin relativ neu in der ganzen Thematik, verzeiht mir also dumme > Kommentare / Ideen ^^ Kein Ding. Es macht halt stutzig, weils fuer mich so aussieht, als ob der ADC-Typ eher nicht so zum Rest passst. Gruss WK
Moin Kurt, das ist ein sehr interessanter Chip. Wenn ich fragen darf, wie ist die Verfügbarkeit und der ungefähre Kostenrahmen? Viele Grüße, liggi
liggi schrieb: > Moin Kurt, > > das ist ein sehr interessanter Chip. Wenn ich fragen darf, wie ist die > Verfügbarkeit und der ungefähre Kostenrahmen? > > Viele Grüße, > liggi Hey liggi, comportdata hat mir freundlicherweise (auch sehr schnell) zwei Chips für erste Tests frei zur Verfügung gestellt. Mit evaluation board kostet der Chip 500 US$. Deswegen möchte ich auch gerne eine eigene Platine mit der ganzen benötigten Peripherie erstellen.
Kurt R. schrieb: > ich möchte eine Schaltung aufbauen, in der ein ADC von Comport Data > eingesetzt werden soll: > https://www.comport-data.com/wp-content/uploads/2016/03/CDI64500_datasheet.pdf Respekt. Ein 64 Kanäle, 18 Bit ADC für Anwendungen im Bereichen wie Computertomographie. Bevor ich, nach meditativen Übungen, auch nur eine Sekunde Zeit in einen Systementwurf stecken würde, würde ich erst einmal evaluieren ob es jemanden gibt, der mir / meinem Arbeitgeber, welche verkaufen würde. Und zu welchem Preis? Größer oder kleiner als der Preis eines Kleinwagens? > Hat jemand eine Idee, ob das > ganze von einem Raspberry PI bewerkstelligt werden kann? Das passt systemtechnisch jetzt gar nicht zusammen. Eigentlich müsste man mit dem FAE des Herstellers reden wie die sich ein Gesamtsystem vorstellen oder was deren Kunden normalerweise machen. Vom Gefühl her würde ich sagen die Idee ist die Daten gehen direkt, nicht durch eine CPU und schon gar durch einen μC, in ein Acquisition-Memory. Vielleicht sogar Dualport-Memory, bei dem auf der anderen Seite die Rohdaten gelesen und weiter verarbeitet werden. > Auf ein FPGA würde ich gerne aus Kosten- und Programmieraufwand-Gründen > verzichten... Ich glaube, beim Preis für den ADC wird das nicht mehr ins Gewicht fallen.
Dergute W. schrieb: > Nicht unbedingt. Es waere denkbar, die Daten direkt vom ADC in einem > FPGA direkt in RTP/UDP Pakete zu verpacken und die dann ueber 100MBit > Ethernet an den PC zu verschicken. Das ginge unter > Bequemlichkeitsabstrichen (IP/MAC Adresse/Port ist alles fest im > FPGA-Bitstream einprogrammiert, etc.) ohne CPU. Das wuerde > wahrscheinlich mit dem kleinsten Spartan6 (und externem Ethernet-PHY) > schon hinhauen. Nicht nur wahrscheinlich, das haut hin, optimalerweise mit CPU. Den ARP/UDP-Stack in hart zu codieren kann ich nicht empfehlen. Mit DMA kriegt man die Bandbreite bis 10MByte/s gut ausgereizt. Wenns nicht reicht, muss man halt komprimieren, wie z.B. mit DPCM. Dann reicht allerdings der kleinste Spartan6 kaum noch aus, da geht man dann besser auf USB, hat dann halt wieder eher Software-Aufwand und Treiber-Murks an der Backe. Der TO müsste halt mal einige Details über die Bandbreite loswerden, damit man ihm die entsprechenden Tips zum richtigen System liefern kann.
Kurt R. schrieb: > Zum Datendurchsatz: der CDI64500 ist ein 18bit ADC, dessen system clock > nicht unter 30 MHz arbeitet. Von den 64 möglichen Eingängen werde ich > maximal fünf nutzen. Du solltest dir zu aller erst über die Nettorate klarwerden, die es hinten zu verarbeiten gilt.
Danke für die vielen Hinweise! Ich werde es mir einfach machen, und einfach den Chip mit Evalution Board kaufen. Bei meinem Nichtwissen erscheint mir das als beste Lösung.
Beitrag #6060374 wurde von einem Moderator gelöscht.
Beitrag #6060394 wurde von einem Moderator gelöscht.
Schonmal das Datenblatt gelesen? Die Systemclock ist nicht die Sampleclock. Die Framerate beträgt laut Datenblatt bei 18 Bits 2,32 kHz. Das macht je Kanal also 2320*18 Bits/s. Für alle 64 Kanäle sind das dann 2320*18*64 Bits/s = 2,61 MBits/s. Das passt locker durch einen UART wie den FT232H mit 12 MBaud. Aber: Während der Übertragung von den jeweils 18 Bits ist die Datenrate höher. Ein großer Teil jedes Frames ist ja Pause auf den Digitalausgängen. Da hilft dann ein kleiner FIFO im FPGA. LVDS kann man aber auch auf CMOS übersetzen. Ganz ohne FPGA. Bei den geringen Frequenzen sollte das gut funktionieren.
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.