Servus. Da ich eine Abtastrate im Bereich von 40 MSPS benötige und die Interne Abtastrate meines dsPICs von praktisch 1,3 MSPS nicht ausreicht möchte ich den ADC12DL040 von Ti verwenden. Dieser benötigt aber als Zwischenspeicher einen Buffer (wenn ich das richtig verstanden habe DRAM) Nun hab ich noch nie mit ICs gearbeitet die einen externen Speicherbaustein benötigen. Wie läuft das ab ? Klar ist, der ADC12DL040 schreibt die Messwerte in den externen Speicher (mir genügt eine Aufzeichnung von 50µs). Aber wie lese ich die Daten dann wieder in meinen PIC ein? zB via SPI, benötige ich da noch einen Speichercontroller ?
"Buffer" ist hier kein Speicher, sondern nur ein Treiber. Wie kommst Du auf DRAM?
Die bezeichen das als Buffer (Puffer). D0..D11 paralell Bus Anbindung kann ja kein Treiber sein
Gee schrieb: > D0..D11 paralell Bus Anbindung > kann ja kein Treiber sein Doch, genau das ist es. Ein Bustreiber. Auf Seite 25 und 26 des Datenblattes werden dafür Latches (74ACT574) verwendet.
Gee schrieb: > Nun hab ich noch nie mit ICs gearbeitet die einen externen > Speicherbaustein benötigen. Wie läuft das ab? Datenblatt lesen? Dann würde dir auch klar, daß da nichts mit DRAM ist. <kopfschüttel/> Du kannst das Datenblatt doch nicht mal überflogen haben!
Gee schrieb: > Nun hab ich noch nie mit ICs gearbeitet die einen externen > Speicherbaustein benötigen. Wie läuft das ab ? Die Daten werden in einem Speicher linear gespeichert. ach > Klar ist, der ADC12DL040 > schreibt die Messwerte in den externen Speicher Nö, das tut er nicht, denn dafür hat er gar nicht die Signale. Er kann nur die Daten an seinen Datenausgängen zur Verfügung stellen. > (mir genügt eine > Aufzeichnung von 50µs). Macht bei 40MSPS gerade mal 2000 Samples. Nicht viel. > Aber wie lese ich die Daten dann wieder in > meinen PIC ein? zB via SPI, benötige ich da noch einen > Speichercontroller ? Ja, heute meist in einem CPLD oder kleinen FPGA. Dazu ein schnelles SRAM und fertig ist das DSO für Arme. Wobei die meisten FPGAs die 2000 Samples intern speichern können, auch die relativ kleinen.
Für solch eine Anwendung würde ich heutzutage auch keinen externen Speicher mit viel Glue Logic anbinden, sondern eher ein kleines FPGA bzw. SOC mit FPGA-Anteil verwenden, z.B. einen Zynq oder Artix. Damit spart man sich auch den zusätzlichen Microcontroller.
OK dann hat er eben keine direkte Speicheranbindung aber er stellt mir die 12 Bit Daten an einem Paralell Bus dar in eienr geschwindigkeit die ich unäglich mit meinem PIC erfassen kann, zumal ich keine 12 bzw 24 Ports (ich muss zwei Kanäle simultan lesen) mehr frei habe. Ich benötige also einen Zwischenspeicher der mit die Daten dann "langsam" via SPI an den PIC weiterschickt. Wie Falk schon richtig erkantn habt sind es ja nur 2k Samples die kann ich problemlos auch im PIC ram speichern, nur halt nicht in Echtzeit..
Gee schrieb: > Ich benötige > also einen Zwischenspeicher der mit die Daten dann "langsam" via SPI an > den PIC weiterschickt. Richtig, die 2K samples @ 24 bit lassen sich problemlos in einem statischen RAM (z.B. 3x 8bitx2k) speichern. Die Komplexität liegt in der Ansteuerung von ADC und Speicher. Diese muss das richtige Timing der Taktsignale sowie die Adressen des Speichers erzeugen. Außerdem muss eine Schnittstelle (z.B. SPI) zum Auslesen implementiert werden. Am besten macht man das wie schon erwähnt per FPGA, aber auch ein GAL würde hier bereits reichen. Mit einem knappen Dutzend 74HCxxxx wäre das angesichts der moderaten Geschwindigkeit natürlich auch diskret möglich.
Ich habe Dir schon eine Möglichkeit skizziert. Natürlich kannst Du so etwas auch mit diskreter Logik realisieren, aber das wird ggf. schon ziemlich aufwändig. Spätestens seit Anfang der 1990er Jahre greift man für so etwas auf CPLD, FPGA o.ä. zurück, statt ein Backblech mit Gattern vollzupflastern.
Mit zweien hiervon sollte sich ein Teil des Problems lösen lassen: https://www.renesas.com/us/en/products/memory-logic/fifo-products/asynchronous-fifos/5962-89567-2k-x-9-asyncfifo-50v Betrachte die Schaltung auf Seite 25 des ADC-Datenblatts, ersetze die beiden Latches rechts (74HCT574) durch je einen dieser Bausteine. Die vom ADC kommenden Daten werden an den Eingängen D0..D8* der FIFOs angelegt, das Taktsignal CLK kommt an /W der Fifo-Bausteine. An die Ausgänge Q0..8 beider Bausteine kommt Dein PIC, der die /R-Leitung bedient und damit einen Lesezyklus auslöst. Die Bausteine haben Platz für 2048 Wörter (à 9 Bit), damit kannst Du also 2048 Samples speichern. Du brauchst für Deine 40 MSamples entweder die Variante mit 15 oder 12 nsec Zugriffsgeschwindigkeit (IDT7203L12 bzw. IDT7203L15), die anderen sind zu langsam. *) die Dinger sind 9 Bit breit, wie Du die Bits Deines ADCs aufteilst, bleibt Dir überlassen
Mike schrieb: > Mit einem knappen Dutzend 74HCxxxx wäre das > angesichts der moderaten Geschwindigkeit natürlich auch diskret möglich. Vorsicht, der TE will ja unbedingt ein DRAM verwenden, d.h. neben der eigentlichen Logik werden ja auch noch Adressmultiplexer, RAS/CAS-Logik und je nach Geschwindigkeit bzw. Langsamheit des Auslesen auch noch eine Refreshlogik benötigt. Erst bei SDRAMs können die Refreshzyklen komplett intern ablaufen. Das wäre ein schönes Retrocomputing-Projekt, aber der moderne dsPIC und der ADC12DL040 passen nicht dazu. Bei SRAMs könnte man einen gewaltigen Teil dieses Aufwandes sparen und käme mit dem geschätzten knappen Dutzend an Logikbausteinen hin. Warum es für nur ca. 2 kS unbedingt ein DRAM sein muss, weiß wohl nur der TE.
DerEgon schrieb: > Mit zweien hiervon sollte sich ein Teil des Problems lösen lassen: > > https://www.renesas.com/us/en/products/memory-logic/fifo-products/asynchronous-fifos/5962-89567-2k-x-9-asyncfifo-50v Die wären sicherlich geeignet, sind aber leider SRAMs und keine DRAMs.
Mike schrieb: > besten macht man das wie schon erwähnt per FPGA, aber auch ein GAL würde > hier bereits reichen. Gan sicher nicht. Und wer im Jahr 2022 noch mit GALs anfängt, macht was falsch. > Mit einem knappen Dutzend 74HCxxxx wäre das > angesichts der moderaten Geschwindigkeit natürlich auch diskret möglich. Moderat? Bei 40 Msps? Ne, oder? Bau mal einen Adresszähler mit HC Bauteilen bei 40 MHz.
Andreas S. schrieb: > Mike schrieb: >> Mit einem knappen Dutzend 74HCxxxx wäre das >> angesichts der moderaten Geschwindigkeit natürlich auch diskret möglich. > > Vorsicht, der TE will ja unbedingt ein DRAM verwenden, Nö, das will er nicht, das war nur eine Frage, basierend auf mangelndem Wissen bzw. Mißverständnis. > d.h. neben der > eigentlichen Logik werden ja auch noch Adressmultiplexer, RAS/CAS-Logik > und je nach Geschwindigkeit bzw. Langsamheit des Auslesen auch noch eine > Refreshlogik benötigt. Quark. Für 2000 lausige Sample nimmt kein Mensch einen DRAM! > Bei SRAMs könnte man einen gewaltigen Teil dieses Aufwandes sparen und > käme mit dem geschätzten knappen Dutzend an Logikbausteinen hin. Warum > es für nur ca. 2 kS unbedingt ein DRAM sein muss, weiß wohl nur der TE Na dann lies einfach nochmal.
Andreas S. schrieb: > Vorsicht, der TE will ja unbedingt ein DRAM verwenden Ich WILL keinen DRAM verwenden, ich dachte nur ich muss. Das ist ein Unterschied und auch eine Erleichterung ;) Welcher FPGA kähme denn da in Frage? Wiegesagt 2x 12 Bit Paralellport in und 1x SPI out Reicht
Gee schrieb: > Wiegesagt 2x 12 Bit Paralellport in und 1x SPI out Reicht Etwas mehr ist es schon. Du kannst die Daten ja nicht kontinuierlich als SPI Stream übertragen weil die Clk Rate viel zu hoch wäre für deinen dsPic (2*12Bit*40MSPS + Overhead). Also muss die Pufferung der FPGA übernehmen --> 2*2000*12Bit RAM im FPGA. Je nachdem ob der FPGA selbst triggern soll, braucht er eine Logik dafür. Alternativ brauchst Du ein Trigger-Pin am FPGA oder ein Register wo du über SPI triggern kannst. Willst Du auch noch einen einstellbaren Pre/Post-Trigger? Dann brauchst Du noch 1-2 Register und die Zähllogik wann der FPGA aufhören soll zu sampeln. Dann das Register-Interface selbst um die Daten und Einstellungen über SPI lesen/schreiben zu können. Ein paar Zellen wird das schon kosten. Vielleicht mal ein EVA-Board deiner Wahl dein Konzept evaluieren und dann schauen wie klein du werden kannst...
MaNi schrieb: > Du kannst die Daten ja nicht kontinuierlich als SPI Stream übertragen > weil die Clk Rate viel zu hoch wäre für deinen dsPic (2*12Bit*40MSPS + > Overhead). Ist völlig klar das will ich auch nicht. Ich benötige lediglich alle paar Sekunden einen Ausschnitt von 50us
Gee schrieb: > Welcher FPGA kähme denn da in > Frage? Wiegesagt 2x 12 Bit Paralellport in und 1x SPI out Reicht Wozu denn noch SPI? Der Microcontroller kann dann auch gleich im FPGA landen, d.h. entweder als Hardcore (Zynq) oder als Softcore (Microblaze, usw.), was die Zugriffe deutlich einfacher macht.
Andreas S. schrieb: > Wozu denn noch SPI? Der Microcontroller kann dann auch gleich im FPGA > landen, d.h. entweder als Hardcore (Zynq) oder als Softcore (Microblaze, > usw.), was die Zugriffe deutlich einfacher macht. Den uC hab ich schon und behalte ich auch, er soll schließlich noch um einiges mehr machen
Gee schrieb: > Den uC hab ich schon und behalte ich auch, er soll schließlich noch um > einiges mehr machen Diese Antwort schießt den Vogel bezüglich Ahnungslosigkeit bei weitem ab...
Andreas S. schrieb: > Wozu denn noch SPI? Der Microcontroller kann dann auch gleich im FPGA > landen, d.h. entweder als Hardcore (Zynq) oder als Softcore (Microblaze, > usw.), was die Zugriffe deutlich einfacher macht. So hätte ich es wahrscheinlich auch erschlagen. Selbst in einem kleinen Max/Cyclone10 bekommt man einen Softcore rein der bei weitem reicht. Die schnellen Dinge dann in Logik. Und maximale Flexibilität hat man dann auch.
N. M. schrieb: > Die schnellen Dinge dann in Logik. > Und maximale Flexibilität hat man dann auch. Der TE möchte aber seine Zeit aber ausdrücklich damit verbringen, viel Hirnschmalz und Testaufwand in die Synchronisation seines Microcontrollers mit dem (egal ob in HW oder mit programmierbarer Logik implementierten) Interface zu seinem ADC zu stecken. Er möchte ja ausdrücklich nicht die Vorzüge der heutigen "Wizards" nutzen, die einen eigenen Peripherieblock ohne Synchronisationsprobleme an den internen Prozessorkern knüppern. Außerdem soll die strikte Trennung von Prozessor und ADC-Logik wirksam verhindern, das ganze bei Erweiterungen problemlos nach oben zu skalieren. Und ich gehe davon aus, dass das Startsignal für die Datenaufzeichnung auch durch den dsPIC statt durch die ADC-Logik generiert werden soll, um die Streuung der Latenz zu maximieren.
Andreas S. schrieb: > Gee schrieb: >> Welcher FPGA kähme denn da in >> Frage? Wiegesagt 2x 12 Bit Paralellport in und 1x SPI out Reicht > > Wozu denn noch SPI? Weil es ausreichend ist. > Der Microcontroller kann dann auch gleich im FPGA > landen, d.h. entweder als Hardcore (Zynq) oder als Softcore (Microblaze, > usw.), was die Zugriffe deutlich einfacher macht. SPI ist ja such sooo schwer. Mensch Meier, du hast mir mal einen schönen Tunnelblick. Der Op kennt seinen dsPIC und gut. as ganze Geraffel mit der Toolchain und embedded uC im FPGA ist auch nicht in drei Tagen verdaut. Die meisten Anwendungen von embedded uCs in FPGAs sind so oder so nur Spielerei.
Andreas S. schrieb: >> Den uC hab ich schon und behalte ich auch, er soll schließlich noch um >> einiges mehr machen > > Diese Antwort schießt den Vogel bezüglich Ahnungslosigkeit bei weitem > ab... Kann es sein, daß du einen KLITZEKLEINEN Gottkomplex hast? Such dir mal was zum Ausgleich.
Schau, ob nicht ein RP2040 (oder ein anderer µC) die ADC-Daten schnell genug entgegennehmen und dann gemütlich (per UART/SPI/I2C/...) an die Haupt-CPU weitergeben kann ...
Falk B. schrieb: > SPI ist ja such sooo schwer. Mensch Meier, du hast mir mal einen schönen > Tunnelblick. Der Op kennt seinen dsPIC und gut. as ganze Geraffel mit > der Toolchain und embedded uC im FPGA ist auch nicht in drei Tagen > verdaut. Die meisten Anwendungen von embedded uCs in FPGAs sind so oder > so nur Spielerei. AHMEN und Danke! Was sich hier einige rausnehmen und Anmaßen ist echt lächerlich. Ich werde ganz sicher nicht mein 45k Zeilen Projekt komplett nochmal neu für ne Andere Architektur umschreiben. Und lasst mal bitte Latenzen und "Streuungen" meine Sorge sein. Was ich will steht explizit da und genau darum soll es gehen und um nichts anderes. Die Frage: Wie binde ich meinen vorhandenen PIC am besten via SPI an o.g. ADC
foobar schrieb: > Schau, ob nicht ein RP2040 (oder ein anderer µC) die ADC-Daten schnell > genug entgegennehmen und dann gemütlich (per UART/SPI/I2C/...) an die > Haupt-CPU weitergeben kann ... Wäre sicherlich eine Option aber es muss auch einfacher gehen mit einem paralell zu spi wandler zB falls es sowas gibt
Evtl. gäbe es vielleicht noch die Variante eine Schnittstelle eines Controllers mit DMA zu benutzen. Um parallel per DMA und GPIO Daten auszugeben gibt z.B. für den STM32 ein Beispiel. Vielleicht geht ja auch die andere Richtung. Auch das DCMI lässt sich evtl. verbiegen.
Edit: zu schnell geschrieben zu langsam gedacht. Ein einfacher converter würde mir ja nix bringen da SPI ja nicht im Ansatz schnell genug ist die Daten in Echtzeit entgegenzunehmen. Müsste also etwas mit integriertem Puffer Speicher sein
Soneidee schrieb: > Evtl. gäbe es vielleicht noch die Variante eine Schnittstelle eines > Controllers mit DMA zu benutzen. Um parallel per DMA und GPIO Daten > auszugeben gibt z.B. für den STM32 ein Beispiel. Vielleicht geht ja auch > die andere Richtung. Auch das DCMI lässt sich evtl. verbiegen. Ja dachte ich mir gerade auch so.. Wird warscheinlich darauf hinauslaufen das ich entweder einen zweiten oder einen größeren dsPIC nehme die haben einen Paralell Port Interface welches die Daten problemlos in Echtzeit via DMA in den RAM puffern kann
Falk B. schrieb: > SPI ist ja such sooo schwer. Es ist nicht schwer, es ist schlicht zu langsam um die Daten in Echtzeit zu übertragen. Mehrere Instanzen (QSPI/OSPI dann noch eher). Ohne Overhead sind es 960Mbit. Also braucht er etwas was die Daten zwischenspeichert. Und außer einem FPGA/CPLD o.ä. meine ich noch nichts brauchbares gelesen zu haben wo dies könnte. Der dsPic selbst kann das mit Sicherheit nicht, oder? Parallel mit DMA vielleicht. Wobei 40MSPSx2 auf den internen Bussen mit Sicherheit auch nicht so ohne ist. Je nach Architektur (ich kenne den dsPic nicht so arg) geht da vermutlich nicht mehr so viel mit dem Prozessor in der Zeit des sampelns. Falk B. schrieb: > Der Op kennt seinen dsPIC und gut. as ganze Geraffel mit der Toolchain > und embedded uC im FPGA ist auch nicht in drei Tagen verdaut. Muss er sich so oder so mit auseinandersetzen, ob mit oder ohne Softcore oder HPS. Denn ohne FPGA/CPLD als Puffer wird es wohl nur schwer gehen.
:
Bearbeitet durch User
N. M. schrieb: > Falk B. schrieb: >> SPI ist ja such sooo schwer. > Es ist nicht schwer, es ist schlicht zu langsam um die Daten in Echtzeit > zu übertragen. Mehrere Instanzen (QSPI/OSPI dann noch eher). > Ohne Overhead sind es 960Mbit. Aber er will doch nur alle Jubeljahre 2000 Samples übertragen. Echtzeit war nirgends gefordert. > Also braucht er etwas was die Daten zwischenspeichert. Und außer einem > FPGA/CPLD o.ä. meine ich noch nichts brauchbares gelesen zu haben wo > dies könnte. Ja. Genau darüber reden wir. Er braucht einen schnellen Puffer für 2x 12 Bit x 2000 Samples. 6 KByte insgesamt. Das kann er in einem FPGA zwischenspeichern oder eine Platine mit diskreter Logik vollklatschen. Aber wenn er ein FPGA verwendet, muß er sich schon fragen lassen, warum er seinen µC (oder welche Logik er immer da braucht) da nicht gleich reinprogrammiert. Denn beim µC ist die Welt ja nicht zu Ende. Was kommt denn nach dem µC?
Es gibt auch uC mit z.B. hier 80 Msps ADC mit DRAM Interface / DMA https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/lpc4300-cortex-m4-m0/32-bit-arm-cortex-m4-plus-2-x-m0-mcu-282-kb-sram-ethernet-two-hs-usbs-80-msps-12-bit-adc-configurable-peripherals:LPC4370FET100
Axel S. schrieb: > Aber er will doch nur alle Jubeljahre 2000 Samples übertragen. Echtzeit > war nirgends gefordert. Das ist mir klar. Aber entweder Echtzeit abkönnen ODER puffern. Axel S. schrieb: > Ja. Genau darüber reden wir. Er braucht einen schnellen Puffer für 2x 12 > Bit x 2000 Samples Jupp. Axel S. schrieb: > Das kann er in einem FPGA Wahrscheinlich und realistisch. Axel S. schrieb: > oder eine Platine mit diskreter Logik vollklatschen. Unwahrscheinlich/unrealistisch. Axel S. schrieb: > Aber wenn er ein FPGA verwendet, muß er sich schon fragen lassen, warum > er seinen µC (oder welche Logik er immer da braucht) da nicht gleich > reinprogrammiert. Das war die bereits erwähnte Spalte Hard/Softcore weiter oben. Das ist aber Ansichtssache ob der uC im FPGA sein soll. Dagegen gesetzt ist, dass es ein FPGA geben muss.
N. M. schrieb: > Falk B. schrieb: >> SPI ist ja such sooo schwer. > Es ist nicht schwer, es ist schlicht zu langsam um die Daten in Echtzeit > zu übertragen. Davon war nie die Rede und ist auch nicht gefordert. Lern lesen. > Also braucht er etwas was die Daten zwischenspeichert. Und außer einem > FPGA/CPLD o.ä. meine ich noch nichts brauchbares gelesen zu haben Dito! Beitrag "Re: ADC mit DRAM Buffer an µC anbinden" >> Der Op kennt seinen dsPIC und gut. as ganze Geraffel mit der Toolchain >> und embedded uC im FPGA ist auch nicht in drei Tagen verdaut. > > Muss er sich so oder so mit auseinandersetzen, ob mit oder ohne Softcore > oder HPS. Denn ohne FPGA/CPLD als Puffer wird es wohl nur schwer gehen. Laberkopp!
Axel S. schrieb: > Aber wenn er ein FPGA verwendet, muß er sich schon fragen lassen, warum > er seinen µC (oder welche Logik er immer da braucht) da nicht gleich > reinprogrammiert. Ja. Und die Frage wurde schon dutzendfach beantwortet, nicht nur in dieser Diskussion! Es ist schlich in vielen Fällen weder nötig noch vorteilhaft. Es ist nur ein Fetischismus. > Denn beim µC ist die Welt ja nicht zu Ende. Was kommt > denn nach dem µC? Das Ende der Welt . . . (Ohje, jetzt wird's philosophisch)
> Die Frage: Wie binde ich meinen vorhandenen PIC am > besten via SPI an o.g. ADC Du bist ja echt suess. :-) Ich wuerde ja einfach einen LPC4370 nehmen und das mit dem internen ADC machen. Damit ist das eine Kleinigkeit. Die Alternative dazu ist dann nur ein FPGA. Vermutlich auch keine grosse Sache wenn du regelmaessig mit FPGAs arbeitest. Aber hey, du musst dann erstmal einen finden den du auch gerade kaufen kannst. .-) Olaf
Falk B. schrieb: > Laberkopp! Früher dachte ich noch ein Falk B ist eine Bereicherung für dieses Forum. Scheinbar ist er auch nur einer der traurigen, alten Männer die hier im Forum rumpöbeln.
Olaf schrieb: > Ich wuerde ja einfach einen LPC4370 Gee schrieb: > Ich werde ganz sicher nicht mein 45k Zeilen Projekt komplett nochmal neu > für ne Andere Architektur umschreiben.
Im frei zugänglichen Schaltplan meines alten HM208 Oszilloskops kann man schön sehen wie man so etwas ohne FPGA lösen kann (jedenfalls den Sample-Teil, der ja schnell sein muss). Es ist zwar nicht simpel aber mit einfachen Logik-ICs machbar. Es ist halt die Frage, wo man seinen Aufwand hinein steckt.
Ich möchte nochmal auf meinen gestrigen Beitrag verweisen: Beitrag "Re: ADC mit DRAM Buffer an µC anbinden" Damit ist der schnelle ADC entkoppelt. Zwar gibt es hier keine SPI-Schnittstelle, aber der PIC kann sich alle Zeit der Welt lassen, um die FIFOs nach dem Erzeugen eines Samplesatzes auszulesen. Wenn zuwenig I/O-Leitungen verfügbar sind, kann man da auch noch ein Schieberegister drandengeln und das wiederum via SPI auslesen. Ist keine Raketenwissenschaft und braucht kein FPGA, sonden nur zwei dieser FIFO-RAMs.
DerEgon schrieb: > Ist keine Raketenwissenschaft und braucht kein FPGA, sonden nur zwei > dieser FIFO-RAMs. Genau das ist der richtige Ansatz. Sowas (in 5 Volt und damals nur 8 Bit ADC 40 MHz) habe ich vor vielen Jahren schon gebaut. Ob das allerdings ein "Anfänger" hinkriegt ist auch nicht ganz trivial. U.a. muss man "triggern" bzw. wissen wann man den Abtastzeitraum startet. Es braucht exakte Spezifikation und mehr als 2 Wochen echte Arbeit für Erstmuster. Und was ist als Analog-Frontend vor dem 12 Bit ADC? Ist das fertig? Gruss
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.