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 ?
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.
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.
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?
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 LPC4370Gee 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
