Hallo zusammen, ich möchte über längere Zeiträume kontinuierlich 4 analoge Signale aufzeichnen um diese später am Computer analysieren zu können. Samplerate soll 1MS/s sein, wichtig ist, das die Signale gleichzeitig gesampelt werden, da die Phaseninformation benötigt wird. Ich plane im Moment dafür 4 separate 12 Bit ADC Wandler (SPI) zu nutzen. Es sieht nicht so aus, als ob es Mirkocontroller gibt, die genügend SPI Hardware und vorallendingen schnelles USB haben um das kontinuierlich zu bewerkstelligen. Theoretisch könnte man die Daten auch auf eine SD Karte wegspeichern, aber bei dann müsste man die Daten vorher reduzieren (so eine Art Trigger auf Signalpegel), da ich etwa 1 Stunde lang aufzeichnen möchte. Ich glaube nicht das die Performance in einem Mikrocontroller dafür reicht. Die SD Karte muss eventuell auch noch mehrere 100 ms gepuffert werden (wear-leveling). Bisher habe ich noch keine Erfahrungen mit FPGAs gemacht, aber das scheint mir der bessere Ansatz dafür zu sein. Ich habe mal ein bischen mit Quartus gespielt und etwas für den MAX10 von Altera hingebasteltet. Nun geht es noch um die konkrete USB Anbindung. Ich hatte eigentlich geplant einen FX2 von Cypress zu nehmen, da könnte ich dann weite USB Endpoints mit mit dem 8051 bedienen um z.B. Einstellungen zu übertragen. Allerdings habe ich gelesen das USB2 größere FIFOs benötigt um verlässlich zu funktionieren. Datenrate wären so etwa 8MB/s (inklusive Zeitstempel) Platinenlayout mache ich selber, habe aber bisher nur ein- und zweilagige Designs gemacht. Folgende Möglichkeiten habe ich jetzt: Cypress FX2 + Altera 10M08: + Vermutlich Zweilagige Platine ausreichend + FX2 Firmware simpel + FPGA Code per USB über FX2 laden + Günstig - Intern max etwa 300kb FIFO. Bandbreite wird eventuell nicht erreicht, Daten gehen verloren ? Eventuell SD-RAM dran pappen. Das ist aber in VHDL für mich als Anfänger vermutlich nicht so einfach. Oder doch? Cypress FX3 + Altera 10M08: + USB3 hat wohl das Problem mit dem Streaming nicht so sehr, FIFOs werden nicht gebraucht + FPGA Code per USB über FX3 Laden - FX3 Firmware aufwändig (Allerdings kenne ich mich mit ARM926 von Berufs wegen gut aus) - FX3 ist sehr teuer (~30 EUR) ? USB3 mit zweilagiger Platine FTDI FT600Q + Altera 10M08: + USB3 + FT600Q sogar günstiger als FX2 - Programmieradapter für FPGA notwendig (JTAG?) - FT600Q FIFO Interface ist komplizierter zu bedienen als das des Cypress FX. - Steuerfunktionen müssen mit im FPGA erledigt werden (Bedienung zusätzlicher Endpoints) ? USB3 mit zweilagiger Platine Was meint Ihr ist der bessere Ansatz? Achso, der aktuelle VHDL code ist recht simpel: 4 Schieberegister, 8kB FIFO, kleine Statemachine. Vielen Dank für Anregungen! Gruß Andreas
Ich denke der Cypress PSOC5LP kann das alles mit on-board peripherals. Auf jeden fall 2x schneller ADC und er hat auch Sample/Hold moeglichkeiten. Der sollst du unbedingt mal bestudieren. Patrick
Andreas M. schrieb: > kontinuierlich 4 analoge Signale > aufzeichnen um diese später am Computer analysieren zu können. > Samplerate soll 1MS/s sein Wieviel Geld und wieviel Zeit darf denn das Ganze kosten? Duke
Moin, gibt es keinen passenden STM32* dafür? > Ich habe mal ein bischen mit Quartus gespielt und etwas für den MAX10 > von Altera hingebasteltet. Nun geht es noch um die konkrete USB > Anbindung. Ich hatte eigentlich geplant einen FX2 von Cypress zu nehmen, > da könnte ich dann weite USB Endpoints mit mit dem 8051 bedienen um z.B. > Einstellungen zu übertragen. Allerdings habe ich gelesen das USB2 > größere FIFOs benötigt um verlässlich zu funktionieren. Datenrate wären > so etwa 8MB/s (inklusive Zeitstempel) Das schafft der FX2 gut, die Frage ist, welchen Mode du nimmst, und wie die Auswirkungen sein dürfen, wenn der Host grade mal stockt: bulk: FIFO Overflow (du wirfst die Daten selber aufm FPGA weg) isochron: Daten verloren, aber Strom geht beim nächsten Paket weiter Bei isochron kommst du dann ohne FIFO-Logik aus. Ich nutze das für Bilddatentransfer bei ca. 24 MB/s, das geht, solange nix anderes den USB-Bus stört (wilde Mausbewegungen unter Windows stören schon). Der Vorteil vom FX2 ist halt, dass es eine Menge Code gibt (siehe Gnu-Radio) und er ein gnädiges Timing hat, im Vergleich zu anderen FIFO-Bausteinen. Beim FX3 bin ich nicht up to date. SDRAM ist nochmal etwas mühsam vom Timing her, aber mit nem fertigen Core machbar. Vielleicht passt ja auch ein SRAM. Und beim Platinendesign kannst du gleich 4 Lagen nehmen, die Anzahl würde ich da weniger als Kriterium nehmen als die elektrische Stabilität und den Krampf, das noch sauber zu routen. Spätestens bei RAM kommst du da eh nicht drum herum. Sonst: Viel Erfolg, - Strubi
pcrom schrieb: > Ich denke der Cypress PSOC5LP kann das alles mit on-board peripherals. > Auf jeden fall 2x schneller ADC und er hat auch Sample/Hold > moeglichkeiten. Der sollst du unbedingt mal bestudieren. USB ist zu langsam und genug RAM um MMC/SD Wear-Leveling abzufedern hat er auch nicht Strubi schrieb: > gibt es keinen passenden STM32* dafür? Naja ich brauche halt 4x SPI zum Lesen und USB2.0 zum wegschreiben. Da habe ich keinen gefunden der das bringt. Eventuell kann man noch I2S im TDM Mode dazu missbrauchen. > Das schafft der FX2 gut, die Frage ist, welchen Mode du nimmst, und wie > die Auswirkungen sein dürfen, wenn der Host grade mal stockt: Das ist genau der Punkt. Ich würde Bulk nehmen und versuche so viel wie möglich von der FPGA Seite her zu puffern. Host wird ein Linux sein, wenn ich richtig gelesen habe ist es da nicht ganz so kritisch. Ich denke ich werde mir das mit dem SDRAM mal ansehen. Gibt ja schon ein paar fertige IP cores.
Der SUMP auf GITHUB macht doch sowas fertig und passend. Muss man nur entsprechend triggern.
Du könntest einen Beaglebone Black nehmen. Der hat nur 2 Hardware SPI-Ports, dafür aber die PRUs. Damit kannst Du locker die 4 SPIs in Software abwickeln und über das Shared Memory an die Haupt-CPU übergeben. Dort kannst Du bei Bedarf gemütlich vorverarbeiten, auf SD Card speichern, oder sicher noch bequemer: übers Netzwerk gleich auf Deinem Fileserver ablegen.
STM32 haben USB 2.0, Du musst halt nur den HS Phy dranbauen (was aber einfacher ist als ne Platine mit FPGA + FX2). Die gibts natürlich auch mit 4 SPI Ports (sogar mit 6 + Quad SPI). Musst aber halt schauen, dass von der Pinbelegung her genug frei sind.
Der PIC32MZ den ich kürzlich angeschaut habe hat z.B. 6 SPI Peripherals aber auch einen schnellen ADC mit bis zu 6 separaten Sample&Holds, so dass du wahrscheinlich gar keine externen ADCs brauchst. Natürlich auch USB (Highspeed, OTG). Ausserdem 512kB Ram fürs Zwischenspeichern, und 1 oder 2 MB Flash. Erhältlich in TQFP64 oder TQFP100. MIPS Prozessor mit bis zu 252 MHz. Damit hast du alles in einem Chip anstatt FPGA + RAM + ADCs + USB Phy usw. zu einem Bruchteil des Preises eines mittleren FPGAs.
Gerd E. schrieb: > Du könntest einen Beaglebone Black nehmen. > > Der hat nur 2 Hardware SPI-Ports, dafür aber die PRUs. Damit kannst Du > locker die 4 SPIs in Software abwickeln und über das Shared Memory an > die Haupt-CPU übergeben. > > Dort kannst Du bei Bedarf gemütlich vorverarbeiten, auf SD Card > speichern, oder sicher noch bequemer: übers Netzwerk gleich auf Deinem > Fileserver ablegen. In der Theorie hört sich das ja schön an, aber klappt das wirklich, hast Du das schon implementiert? Da gibts doch schon noch eine lange TODO: - Kerneltreiber machen - (unabhängiger!) DMA-Support für alle 4 Kanäle - Abrissfreie Datenverarbeitung verifizieren - ..und offenbar noch einen sauberen Timestamp, wegen der Anforderungen bzgl. Phasenlage Für letzteres alleine ist IMO schon ein FPGA nötig, wenn man nicht beliebigen jitter bzw. Aufwand mit RT-Extensions haben will. Schliesst allerdings das embedded Linux front end ja nicht aus. Auf den OMAP/Sitaras und insbesondere den Beagles habe ich keine gute Erfahrungen mit Echtzeit-Datenacquisition gemacht, aber das lag v.a. am DMA und an der USB/Ethernet-Architektur. Wenn die Daten allerdings nicht roh rausmüssen und man deinem Vorschlag der Verarbeitung folgt, könnte es gehen. Grüsse, - Strubi
Gerd E. schrieb: > Du könntest einen Beaglebone Black nehmen. > > Der hat nur 2 Hardware SPI-Ports, dafür aber die PRUs. Damit kannst Du > locker die 4 SPIs in Software abwickeln und über das Shared Memory an > die Haupt-CPU übergeben. An sowas hatte ich noch gar nicht gedacht. Aber das "locker" glaube ich nicht ganz. Soweit ich das sehe gibt es in der PRU zwei Schieberegister, bleiben noch 2 SPI in Software übrig. Man müsste sehen das man das Timing der Schieberegister mit den Software SPIs synchronisiert bekommt? Bei den ADC die ich verwenden möchte muss das SPI dann mit 14 MHz laufen, da bleiben der PRU dann 14 Takte pro SPI Takt: - 1 Takt alle 4 MISO Leitungen samplen - 4 Takte schieben - 1+1 Takt um SCLK zu zählen und auf pin legen - 2 Takte CS Signal für ADCs generieren - 1+4 Takte nach 14 SCLK Takten um die Schieberegister in andere Register zu sichern damit die zweite PRU die dann irgendwie in den Speicher legt und/oder per DMA fortschafft. Eventuell kann man das ganze auch linear 14x runterprogrammieren um die Aufgaben zwischen den SPI Takten etwas zu verteilen. Dann könnte die ARM das noch nachverwursten und auf eine SD-Karte speichern. USB würde ich dann nicht nehmen wollen. Was ich vergessen habe zu sagen, ist das die Lösung portabel sein muss. (Akkubetrieb, USB) Daher fällt "Schieben auf Dateiserver" aus. Und Stromversorgung über USB fällt beim BeagleBone auch flach wenns halbwegs stabil laufen soll. Es gibt schon ein Cape mit 20 MS/s 2 Kanal ADC, allerdings mit paralleler Anschaltung der ADCs. Entspräche dann ~ 1.5MS/s mit SPI Bus/2Ch oder etwa 0.8 MS/s/4Ch bei SPI aus Sicht der PRU. Laut deren Doku ist die Sache dort wohl auch sehr knapp. Also "locker" ist dann doch was anderes. Zu den anderen Vorschlägen sage ich jetzt mal nichts. Es mag ja sein, das es STMs und PICs mit USB2.0 und genug SPI oder internen Wandlern gibt, das löst aber nicht das Problem des notwendigen FIFO Speichers um PC seitige USB2.0 "Stocker" oder auch SD/MMC abzupuffern. Wie sprechen hier von etwa 4MByte Ram. Außerdem würde ich gerne mal was mit einem FPGA machen. Das Thema interessiert mich schon länger :-)
Andreas M. schrieb: > Wie sprechen > hier von etwa 4MByte Ram. STM32er haben ein fertiges Speicherinterface für SRAM / SDRAM ;-P
Kreative Lösung für viele SPI interfaces... http://m.youtube.com/watch?v=XlKilhcP_ic Sollte auch von der Datenrate noch zu machen sein
Zoom Zoom schrieb: > Andreas M. schrieb: >> Wie sprechen >> hier von etwa 4MByte Ram. > > STM32er haben ein fertiges Speicherinterface für SRAM / SDRAM ;-P Kann ein STM32 gleichzeitig 4x SPI taktsynchron kontinuierlich lesend und schreibend bedienen und auf dem PC als virtuellen COM mit 40MByte/s zur Verfügung stellen? Dazu ein wenig Protokoll-Overhead zur Emulation von CTS/RTS? Inkl. Buffer auf SDRAM für das Senden an den PC.
:
Bearbeitet durch User
Der TO braucht nur 8 MByte/s wie er selbst schon sagt. Das ist eine ganz andere Hausnummer.
Die Atmel SAM3U (Cortex-M3 statt nervigem 8051 im FX2) haben einen integrierten hi-speed USB transceiver (ist meine ich einer der wenigen Cortex-Ms mit integriertem Phy - die meisten brauchen einen externen ULPI), dazu 4x USARTs die sich als SPI nutzen lassen (maximal 16MHz SCK allerdings) + normales SPI. Externes RAM lässt sich auch z.B. in Form von (P)SRAM (z.B. IS66WVE4M16) anbinden. (e)MMC mit 4 oder 8 Bit und S/MLC NAND Flash kann er auch ansteuern. Knackpunkt ist da vielleicht die 16MHz auf den USARTs - bei 1MS/s mit 12 Bit könnte das aber gerade so reichen.
Zoom Zoom schrieb: > Der TO braucht nur 8 MByte/s wie er selbst schon sagt. Das ist eine ganz > andere Hausnummer. Meine Frage war nicht als Kritik gemeint. Was ist machbar für ein komfortables Interface FPGA<>PC auf Basis eines STM32-discovery/nucleo?
Gute Frage, ich habe das für nen STM32 noch nie ausgereizt mangels Anwendung dafür. Würde aber stark vermuten, dass man dann doch besser auf einen FTDI oder Cypress USB FIFO Chip setzen sollte wenn man das Maximum aus der USB Leitung rausholen möchte.
Zoom Zoom schrieb: > Würde aber stark vermuten, dass man dann doch besser auf einen FTDI oder > Cypress USB FIFO Chip setzen sollte wenn man das Maximum aus der USB > Leitung rausholen möchte. Und welche Out-of-the-box-Lösung genau? Das USB-Problem mit dem Zwischenspeichern bleibt ja. Ein Problem, dass mit der jeweiligen FPGA-Applikation nichts zu tun hat. Ein Problem, dass immer wieder neu gelöst wird, nur von verschiedenen Personen und manchmal auch von den Selben. Eigentlich will man (ich) doch nur (paralleles, synchrones) UART am FPGA und virtuellen COM am PC. USB3 hat nun getrennte Leitungen für Empfangen und Senden. Ob das die Sache mittelfristig vereinfacht? > Gute Frage, ich habe das für nen STM32 noch nie ausgereizt mangels > Anwendung dafür. Tja...
Lars R. schrieb: > Zoom Zoom schrieb: >> Würde aber stark vermuten, dass man dann doch besser auf einen FTDI oder >> Cypress USB FIFO Chip setzen sollte wenn man das Maximum aus der USB >> Leitung rausholen möchte. > > Und welche Out-of-the-box-Lösung genau? Das USB-Problem mit dem > Zwischenspeichern bleibt ja. Ein Problem, dass mit der jeweiligen > FPGA-Applikation nichts zu tun hat. Ein Problem, dass immer wieder neu > gelöst wird, nur von verschiedenen Personen und manchmal auch von den > Selben. Eigentlich will man (ich) doch nur (paralleles, synchrones) UART > am FPGA und virtuellen COM am PC. FTDI FT2232H im 245 FIFO Mode. Schafft so an die 40MB/s, virtueller COM bin ich mir nicht mehr sicher, ich glaube man braucht einen Treiber (der leicht selbst zu schreiben ist). Für 8MB/s braucht man schon was besseres, das einfachste dafür ist der FTDI. Alternativ kannst du auch 100MBit Ethernet probieren, das kriegt die 8MB/s eigentlich auch gut hin...
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.