Hallo, und zwar möchte ich für ein größeres Projekt einen externen ADC mittels eines Microcontroller von ST per SPI ansteuern bzw. die Daten auslesen. Als AD-Wandler wäre der AD4001 von Analog Devices vorgesehen. Dieser hat eine Samplingrate von 2 Msps mit einer Auflösung von 16Bit. Als Microcontroller war bisher der STM32F767ZI Nucleo geplant. Das Problem dabei ist, dass der AD-Wandler für die vollen 2 Msps einen SPI-Takt von mindestens 70 MHz erfordert. Laut Reference Manual reicht der maximale SPI-Takt beim Nucleo jedoch bis 54 MHz. Mir ist jedoch aufgefallen, dass das Nucleo auch Quad-SPI unterstützt, damit wäre eine Frequenz von maximal 108 MHz machbar. Im Manual zum AD4001 steht eine Unterstützung von QSPI (was bei mir momentan noch für etwas Verwirrung sorgt, weil ST sein Quad-SPI auch gerne mal mit QSPI abkürzt, mir aber auch schon mehrmals Queued SPI als Abkürzung für Quad-SPI über den Weg gelaufen ist, vielleicht kann mir da jemand mal etwas Klarheit verschaffen). Mein Problem ist nun, ob sich das Quad-SPI Interface für die oben genannte Problematik eignet, bzw. ob es möglich ist, damit die nötige Taktfrequenz hinzubekommen? Alternativ steht die Überlegung im Raum, ein Board der H7 Reihe anzuschaffen. Die schaffen zwar den SPI-Takt, haben aber einen höheren Stromverbrauch, den ich mir nur ungerne mit ins Boot holen würde. Viele Grüße Kevin
Gast
#5897204
bei Dual / Quad SPI bekommen aber die MISO/MOSI Pins eine andere Funktion. Ob das der AD Mitmacht ?
Gast
#5897208
datascheet : SPI-/QSPI-/... -compatible serial interface sollte daher gehen
Gast
#5897215
wobei wiki hier was anderes zu QSPI sagt https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Related_terms Demnach nur Queued SPI und damit klappt das interface nicht mehr. Bei dem Dual Quad Interface werden lese/schreib operationen über mehrere Datenleitungen realisiert. Damit steigt die Bandbreite Das kann der ADC aber leider nicht
Gast
#5897287
Der AD4001 kann lt. Datenblatt nur Daten über 2 Leitungen (jeweils unidirektional) und offenbar kein DDR. Aber die max. 108 MHz sollten ja auch so reichen. Aber ... Bevor man damit anfängt, sollte man genauestens prüfen, ob ALLE benötigten Transfermodi mittels QuadSPI auch möglich sind! Das Interface ist ja für NOR-Flash gedacht, und manche Transfermodi, die bei einem "simplen" SPI-Interface möglich sind, sind damit einfach nicht möglich. Z. B. nur vollständige Bytes, 11 Bytes senden und gleichzeitig (oder anschließend) 9 Bytes lesen während CS ununterbrochen aktiv ist, geht nicht.
A. B. schrieb: > Der AD4001 kann lt. Datenblatt nur Daten über 2 Leitungen (jeweils > unidirektional) und offenbar kein DDR. Aber die max. 108 MHz sollten ja > auch so reichen. > > Aber ... > Bevor man damit anfängt, sollte man genauestens prüfen, ob *ALLE* > benötigten Transfermodi mittels QuadSPI auch möglich sind! Das Interface > ist ja für NOR-Flash gedacht, und manche Transfermodi, die bei einem > "simplen" SPI-Interface möglich sind, sind damit einfach nicht möglich. > Z. B. nur vollständige Bytes, 11 Bytes senden und gleichzeitig (oder > anschließend) 9 Bytes lesen während CS ununterbrochen aktiv ist, geht > nicht. Vielen Dank für die Antwort. Im Reference Manual steht zum SDR, dass die Daten beim Empfangen immer bei fallender Taktflanke ausgegeben werden und einen halben Takt später vom Quad-SPI gesampled werden. Wäre das die Erklärung, weshalb vollständige Bytes sich nicht empfangen lassen? Oder hat das andere Gründe? Mir würde dazu nämlich spontan als Lösung einfallen, ein Taktsignal mehr zu senden, damit die 16 Bit pro Übertragung auch beim Microcontroller ankommen.
Zum Problem. Allenfalls waere ein ADC mit parallelem interface besser geeignet. Die gibt's auch wie Sand am Meer. zB https://www.analog.com/en/ltc2389-16
Gast
#5897442
Kevin L. schrieb: > Daten beim Empfangen immer bei fallender Taktflanke ausgegeben werden > und einen halben Takt später vom Quad-SPI gesampled werden. Wäre das die > Erklärung, weshalb vollständige Bytes sich nicht empfangen lassen? Oder > hat das andere Gründe? Mir würde dazu nämlich spontan als Lösung Hm, vielleicht habe ich mich missverständlich ausgedrückt: Beim QuadSPI sind immer nur komplette Bytes möglich. Bei den "normalen" SPI-Interfaces sind i. d. R. ja auch "krumme" Frame-Größen einstellbar. Ansonsten sind beim QuadSPI nur die Clock-Modi 0 und 3 möglich, d. h. mit der fallende Flanke wird herausgeschoben, mit der steigenden hinein (aus Master-Sicht). Ausnahme: mit SSHIFT kann man das hinein auf die nachfolgende fallende Flanke hinauszögern.
Gast
#5897608
Hinweis: es schön die Daten so schnell zu bekommen, aber meist muss man dann damit noch was machen. Würde das dein F7 denn überhaupt hinbekommen?
Für 70MHz auf dem SPI brauchts einen 140MHz APB Takt. Das haben ja nichtmal die STM32H7xx (da ist bei 120MHz schluss). Dafür haben die H7 drei eingebaute 16Bit ADC mit diff Eingängen zu jeweils 2,4MSps (Tsar+TSampling = 416ns) Musste mal gucken ob dir die reichen. Was solls denn eigentlich werden am Ende?
A. B. schrieb: > Kevin L. schrieb: > >> Daten beim Empfangen immer bei fallender Taktflanke ausgegeben werden >> und einen halben Takt später vom Quad-SPI gesampled werden. Wäre das die >> Erklärung, weshalb vollständige Bytes sich nicht empfangen lassen? Oder >> hat das andere Gründe? Mir würde dazu nämlich spontan als Lösung > > Hm, vielleicht habe ich mich missverständlich ausgedrückt: Beim QuadSPI > sind immer nur komplette Bytes möglich. Bei den "normalen" > SPI-Interfaces sind i. d. R. ja auch "krumme" Frame-Größen einstellbar. > > Ansonsten sind beim QuadSPI nur die Clock-Modi 0 und 3 möglich, d. h. > mit der fallende Flanke wird herausgeschoben, mit der steigenden hinein > (aus Master-Sicht). Ausnahme: mit SSHIFT kann man das hinein auf die > nachfolgende fallende Flanke hinauszögern. Vielen Dank für die Klarstellung, dann werde ich mich mal daran setzen. Clock Modus 0 müsste auch der Modus sein, den der AD4001 bedienen kann.
nfet schrieb: > Hinweis: es schön die Daten so schnell zu bekommen, aber meist muss man > dann damit noch was machen. Würde das dein F7 denn überhaupt > hinbekommen? Geplant ist, schon auf dem Mikrocontroller eine FFT über die gesammelten Daten laufen zu lassen und das Ergebnis dann über Ethernet an einen zentralen Steuerungscomputer laufen zu lassen. Dazu müsste ich aber noch genauere Zeitmessungen durchführen, um zu schauen, ob die FFT auf dem Mikrocontroller schnell genug abläuft. Mw E. schrieb: > Für 70MHz auf dem SPI brauchts einen 140MHz APB Takt. > Das haben ja nichtmal die STM32H7xx (da ist bei 120MHz schluss). > > Dafür haben die H7 drei eingebaute 16Bit ADC mit diff Eingängen zu > jeweils 2,4MSps (Tsar+TSampling = 416ns) > Musste mal gucken ob dir die reichen. > > Was solls denn eigentlich werden am Ende? Mit dem ADC soll später eine ZF von 1 MHz abgetastet werden, die sich aus einem Radarsystem ergibt. Dafür bieten die onboard ADCs leider kein gutes SNR, da die Zwischenfrequenz gut 1 MHz beträgt. Das H7, zumindest das H743, für das ich jetzt exemplarisch geschaut habe, generiert seinen Takt über einen Clock Generator, der vom Kernel Takt gespeist wird. Soweit ich sehen kann, ist da keine Abhängigkeit vom AP-Bus was die Erzeugung des SPI-Clocks angeht.
Da hatte ich wohl beim tippen den falschen Clocktree im Kopf. Der SPI 1-3 des H743 kann direkt mit den 480MHz ARM Kern Frequenz gespeist werden. Mit einem Prescaler von 4 im SPI haste dann 120MHz SPI. Sollte reichen oder? Ist dann aber gleich wieder etwas zu viel, daher kann der Takteingang des SPI 1-3 auch auf die PLL2Q gestellt werden (die anderen SPI auch). Also diese PLL2Q auf 140 oder 160MHz stellen und dein SPI Takt ist wie er soll. Gleichzeitig haben die H7 bis zu 480MHZ CPU Takt und nicht nur 216. Das gibt mehr Rechenpower für deine FFT. Eine auf die ARM Kerne zugeschnittene FFT findeste in den CMSIS DSP Sourcen.
Mw E. schrieb: > Da hatte ich wohl beim tippen den falschen Clocktree im Kopf. > Der SPI 1-3 des H743 kann direkt mit den 480MHz ARM Kern Frequenz > gespeist werden. > Mit einem Prescaler von 4 im SPI haste dann 120MHz SPI. > Sollte reichen oder? > > Ist dann aber gleich wieder etwas zu viel, daher kann der Takteingang > des SPI 1-3 auch auf die PLL2Q gestellt werden (die anderen SPI auch). > Also diese PLL2Q auf 140 oder 160MHz stellen und dein SPI Takt ist wie > er soll. > > Gleichzeitig haben die H7 bis zu 480MHZ CPU Takt und nicht nur 216. > Das gibt mehr Rechenpower für deine FFT. > Eine auf die ARM Kerne zugeschnittene FFT findeste in den CMSIS DSP > Sourcen. Vielen Dank für den Workguide. Die Lib für die FFT habe ich schon gefunden, dankeschön. Die hohe Rechenleistung des H7 erkaufe ich mir aber leider mit einem höheren Stromverbrauch, die ich nur äußerst ungerne mit ins Boot holen möchte. Aber gut zu wissen, dass es notfalls mit dem H7 eine Alternative gibt. Vielen Dank.
Wieso alternative? Nur der H7 kann deinen hohen SPI Takt oder haste noch was anderes gefunden? (Würd mich jetz auch interessieren) Ansonsten muss der Kern ja nicht auf 480MHz laufen, dann zieht er auch weniger Strom.
Mw E. schrieb: > Wieso alternative? Nur der H7 kann deinen hohen SPI Takt oder haste noch > was anderes gefunden? > (Würd mich jetz auch interessieren) > > Ansonsten muss der Kern ja nicht auf 480MHz laufen, dann zieht er auch > weniger Strom. Das stimmt, daher war die Überlegung mittels Quad-SPI, das ja auch im F7 enthalten ist, eine höhere Taktrate zu erzielen, der sich bis zum AHB Takt hochziehen lässt. Da der AD-Wandler aber keine 4 Datenlinien unterstützt, sondern nur eine in jede Richtung, ist der momentane Plan, Quad-SPI als "reguläres" SPI zu nutzen, wobei ich momentan noch genau schaue, ob der benötigte Transfermodus auch realisierbar ist. Den Kern nicht auf 480 MHz laufen zu lassen, würde natürlich auch gehen, wobei ich da den tatsächlichen Verbrauch nochmal nachmessen müsste, dazu steht nichts genaueres im Reference Manual.
Richtig, der Stromverbrauch steht nicht im RefMan, sondern im Datenblatt zum jeweiligen STM32. Beim QSPI musste dann den indirekt write/read Mode (FMODE) nehmen mit DMA. Instruktion senden deaktivieren (IMODE) Adresse senden deaktivieren (ADMODE) Im Datenmode kann er auch auf Singlebit (DMODE) senden/empfangen Die Datenlänge eben auf 2 Byte stellen. SPannend wird es dann das Protokoll des ADC darauf abzubilden.
Mw E. schrieb: > Richtig, der Stromverbrauch steht nicht im RefMan, sondern im Datenblatt > zum jeweiligen STM32. > > Beim QSPI musste dann den indirekt write/read Mode (FMODE) nehmen mit > DMA. > Instruktion senden deaktivieren (IMODE) > Adresse senden deaktivieren (ADMODE) > Im Datenmode kann er auch auf Singlebit (DMODE) senden/empfangen > > Die Datenlänge eben auf 2 Byte stellen. > SPannend wird es dann das Protokoll des ADC darauf abzubilden. Ja, da stehen 620 mA Spitze, im Gegensatz zu den maximal 500mA vom F7. Aber da würde ich nochmal nachmessen, sofern alles andere passt, um den tatsächlichen Verbrauch zu messen, der ja dann je nach Clockkonfiguration usw. variieren kann. Ah okay, dann werde ich mich mal daran setzen. Vielen Dank für die Hilfe.
Gast
#5901581
Ich wuerd's vergessen mit 2Sample eine FFT in Echtzeit zu machen. Denn zusaetzlich zu diesen vielen Operationen kommen noch die Interrupts hinzu. Nomm einen Parallel samplenden ADC, dann hat du zumindest diese 70 clocks zeit pro Sample. Naja, abzueglich der Zeit, wo das Resultat, welches gleich gross ist noch duch ein Ethernet kabel geschoben werden soll. Eine Megaschlechte idee.
Megatroll schrieb: > Ich wuerd's vergessen mit 2Sample eine FFT in Echtzeit zu machen. Denn > zusaetzlich zu diesen vielen Operationen kommen noch die Interrupts > hinzu. > Nomm einen Parallel samplenden ADC, dann hat du zumindest diese 70 > clocks zeit pro Sample. Naja, abzueglich der Zeit, wo das Resultat, > welches gleich gross ist noch duch ein Ethernet kabel geschoben werden > soll. > > Eine Megaschlechte idee. Es soll ja auch nicht fortlaufend gesampled werden. Ein Trigger aktiviert das Radar und in dieser Zeit soll die ZF mit 2 MSps abgetastet werden. Da sich das im Zeitrahmen von 2 bis 3 ms bewegt, gibt es keinerlei Speicherprobleme, es sollen schlussendlich 4096 Messpunkte werden. Die werden dann in die FFT reingegeben und zu guter Letzt über Ethernet rausgejagt. Die Totzeit zwischen 2 Triggern beträgt um die 5ms, mehr als genug um die FFT durchzuführen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.