Bei den ganzen Controllern auf dem Markt habe ich den Durchblick verloren. Zudem ist die Maximale IO Geschwindigkeit selten angegeben. Ehrlich gesagt weiß ich auch nicht genau wie ich hier bei der Suche vorgehen muss. In einer aktuellen Anwendung möchte ich einen FPGA ersetzen. Dieser steuert direkt einen ADC an. Ich müsste in diesem Fall 150MHz als Takt erzeugen und seriell Daten einlesen. Der neue Teensy 4.0 taktet mit 600MHz, schafft aber gerade so 150MHz mit den IOs. Die Raspberries liegen da sogar noch drunter. Kennt jemand irgend ein Board, was einen µC ab 16Bit besitzt und intern mit 500MHz kurbelt? Wie schnell die IOs dann genau sein müssen kann ich gerade nicht einschätzen. Der Teensy 4.0 ist da ggf. etwas nah an der grenze. 200MHz sollten die IOs aber schon schaffen sollen vermute ich. Ab und zu habe ich gelesen, dass man via bare metal noch einiges raus holen könnte. Da fehlt mir aber das Einschätzungsvermögen.
Ganz einfach wenn du direkt ins Register schreibst brauchst du einen Takt zum ein und einen zum ausschalten. Also macht der Pin theoretisch die halbe CPU Taktfrequenz. Was limitieren kann ist wenn der perepheriebus nicht mit dem Takt läuft das ist dem entsprechenden Reference Manual zu entnehmen. Der STM32H7 läuft mit 480MHz allerdings ist es schwer da irgendwas zu sagen wenn man den ADC nicht kennt und wie dieser angesteuert wird.
Guest schrieb: > Also macht der Pin theoretisch > die halbe CPU Taktfrequenz. Das hast du dir zu einfach gedacht, da die Peripherie typischerweise langsamer getaktet wird, als der CPU Kern.
> möchte ich einen FPGA ersetzen. Dann ersetze ihn durch einen anderen FPGA. SPI mit 150 MHz geht damit ja einigermassen problemlos.
Guest schrieb: > Ganz einfach wenn du direkt ins Register schreibst brauchst du einen > Takt zum ein und einen zum ausschalten. Also macht der Pin theoretisch > die halbe CPU Taktfrequenz Natürlich nur wenn der I/O Bereich nicht langsamer getaktet wird, wie das bei hochfrequenten uC wie DSP und dem Teensy aber gemacht wird, Kern mit niedriger Spannung und gigahertz-schnellen Transistoren, I/O mit höherer Spannung aber langsameren Transistoren.
> da die Peripherie typischerweise > langsamer getaktet wird, als der CPU Kern. Es gibt schon Controller die man so zwiebeln kann, dass die Peripherie mit dem Coreclock laueft.
svedisk ficklampa schrieb: > Es gibt schon Controller die man so zwiebeln kann, dass die > Peripherie mit dem Coreclock laueft. Deswegen schrieb ich typischerweise. Die Auswahl an Mikrocontrollern mit I/O Pins die mit einem Vielfachen von 150MHz getaktet werden, dürfte sehr klein sein.
Patrick schrieb: > Kennt jemand irgend ein Board, was einen µC ab 16Bit besitzt und intern > mit 500MHz kurbelt? Wie schnell die IOs dann genau sein müssen kann ich > gerade nicht einschätzen. Der Teensy 4.0 ist da ggf. etwas nah an der > grenze. 200MHz sollten die IOs aber schon schaffen sollen vermute ich. Für solche Anwendungen sind die meisten COntroller nicht gemacht. Zumindest kannst Du schon mal stumpf alle ARM und MIPS Controller streichen. Ohne Ausnahme. Grund dafür: die Anbindung der IOs an den Kern. Der Prozessorkern ist da ein fertiger Baustein, der zugekauft wird. Der hat bestimmte, definierte Schnittstellen wie AHB und APB, wo der Chiphersteller seine Peripherie anschließen kann. Diese Schnittstellen sind vom Prozessorkern entkoppelt und laufen asynchron, und das ist für Deine Anwendung tötlich. Bei allen ARM- und MIPS-Controllern kann der Prozessorkern z.B. selber kein atomares Bit-Set oder Bit-Clr auf einen Portpin durchführen. Diese Funktionalität muss innerhalb der Peripherie durch spezielle Register und Bit-Banding etc nachgebildet werden. Controller mit proprietären Cores wie z.B. PIC24/dsPIC33 haben diese archtektonische Grenze nicht. Inzwischen gibts ja dsPIC33 mit Dual-Core 100 MHz Cores. Die dürften deterministischer sein. Eine andere alternative wäre z.B. TI C2000. Da ist die Peripherie auch viel direkter an den Kern angebunden. Oder die PRUs der TI Sitara-Controller. Und dann brauchst Du vielleicht auch keine 500MHz CPU-Core-Takt mehr. Wobei der eh seine Grenzen hat, wenn der COde aus dem Flash kommt. fchk
Dann werde ich die Sache anders lösen müssen. Danke euch allen für die Hilfe! Der FPGA macht wirklich nicht viel. Den hatte ich damals verwendet weil ich noch so ein Board in der Ecke liegen hatte. Alles bis auf den ADC ist "super langsam". Eine kleine 74er Schaltung, die den ADC betaktet und die Daten via Schieberegister parallel an einen langsameren µC führt, sollte das Problem auch lösen.
Stefan F. schrieb: > Das hast du dir zu einfach gedacht, da die Peripherie typischerweise > langsamer getaktet wird, als der CPU Kern. ..... Guest schrieb: > Was limitieren kann ist wenn der perepheriebus nicht mit dem Takt läuft > das ist dem entsprechenden Reference Manual zu entnehmen. Wer lesen kann ist klar im Vorteil :D
Patrick schrieb: > In einer aktuellen Anwendung möchte ich einen FPGA ersetzen. Dieser > steuert direkt einen ADC an. Ich müsste in diesem Fall 150MHz als Takt > erzeugen und seriell Daten einlesen. > > Kennt jemand irgend ein Board, was einen µC ab 16Bit besitzt und intern > mit 500MHz kurbelt? Wie schnell die IOs dann genau sein müssen kann ich > gerade nicht einschätzen. Der Teensy 4.0 ist da ggf. etwas nah an der > grenze. 200MHz sollten die IOs aber schon schaffen sollen vermute ich. > Schau Dir die LPC43xx von NXP an. Kann zwar "nur" 200MHz doch mit dem verbauten M0 sollte Dein Deserializer ggfs möglich sein und mit dem M4 dann verarbeitbar sein. Viel Erfolg.
Patrick schrieb: > Ich müsste in diesem Fall 150MHz als Takt > erzeugen und seriell Daten einlesen. Dann mußt Du mal schauen, welche Geschwindigkeit das SPI kann. Mit SPI+DMA sollte die CPU-Last gering sein.
Frank K. schrieb: > Grund dafür: die Anbindung der IOs an den Kern. Der Prozessorkern ist da > ein fertiger Baustein, der zugekauft wird. Der hat bestimmte, definierte > Schnittstellen wie AHB und APB, wo der Chiphersteller seine Peripherie > anschließen kann. Diese Schnittstellen sind vom Prozessorkern entkoppelt > und laufen asynchron, und das ist für Deine Anwendung tötlich. Bei so einer Anwendung möchtest Du aber eigentlich genau diese Entkopplung haben. Denn die CPU soll sich eben nicht um jedes Bit kümmern müssen. Ansonsten reicht ein Interrupt oder sonstwas und schon verpasst Du ein Bit. Was Du eigentlich willst, ist ein von der CPU entkoppelter Bus, an dem eine DMA-Einheit hängt, die ganz ohne Beteiligung der CPU die Daten von den Pins einliest und in einen Puffer im RAM schreibt. Alternative wäre ein Coprozessor, der einen schnellen und einigermaßen direkten "Draht" zu den IO-Pins hat. Eine andere Möglichkeit wäre eine dedizierte Hardwareeinheit, die die Daten einliest und per DMA weiterreicht. Was ist das denn für ein serielles Protokoll für den ADC? Ist das SPI oder ähnlich zu SPI? > Bei allen ARM- und MIPS-Controllern kann der Prozessorkern z.B. selber > kein atomares Bit-Set oder Bit-Clr auf einen Portpin durchführen. Der Cortex-M0+ kann direkt und ohne Bus auf Portpins zugreifen. Der ist für die Aufgabe des TO aber ungeeignet. > Oder die PRUs der TI > Sitara-Controller. Die PRUs wären denke ich für die Aufgabe des TO geeignet.
Patrick schrieb: > Bei den ganzen Controllern auf dem Markt habe ich den Durchblick > verloren. Zudem ist die Maximale IO Geschwindigkeit selten angegeben. Diese Zahl ist auch weitgehend irrelevant. > In einer aktuellen Anwendung möchte ich einen FPGA ersetzen. Dieser > steuert direkt einen ADC an. Ich müsste in diesem Fall 150MHz als Takt > erzeugen und seriell Daten einlesen. Das würde man nicht durch das Wackeln an irgendwelchen IO-Pins machen wollen, sondern eine dedizierte serielle Schnittstelle wie z.B. SPI nutzen. Der ADC hat doch sicher eine definierte Schnittstelle? Guest schrieb: > Ganz einfach wenn du direkt ins Register schreibst brauchst du einen > Takt zum ein und einen zum ausschalten. Also macht der Pin theoretisch > die halbe CPU Taktfrequenz Aber nur sehr theoretisch. Abgesehen davon ist es wenig hilfreich, wenn die CPU 100% damit beschäftigz ist, an Pins zu wackeln. Irgendwas muß mit den Daten ja auch noch geschehen. Und sei es nur, sie in einen RAM Puffer zu schreiben. Auch das geht nicht in Nullzeit. Mit einem SPI mit Empfangspuffer und DMA zum Daten durch die Gegend schieben wird das alles deutlich entspannter. Wobei sich natürlich die Frage stellt, warum man eine existierende FPGA Lösung 1. überhaupt und 2. aufgerechnet durch einen µC ersetzen wollen würde.
Axel S. schrieb: > Aber nur sehr theoretisch. Abgesehen davon ist es wenig hilfreich, wenn > die CPU 100% damit beschäftigz ist, an Pins zu wackeln. Irgendwas muß > mit den Daten ja auch noch geschehen. Und sei es nur, sie in einen RAM > Puffer zu schreiben. Auch das geht nicht in Nullzeit. Was das theoretisch angeht finde ich das nicht so theoretisch. Bei einem F3 kann man den Pin mit 36MHz toggeln. Das das sinnvoll ist habe ich nie behauptet. Ich habe lediglich seine Frage beantwortet. Wie von mir erwähnt kann man ohne Infos über den ADC nicht wirklich was hilfreiches sagen.
Welcher ADC ist das genau? Ich habe bisher SPI nur bis 105 MHz gesehen.
Guest schrieb: > Was das theoretisch angeht finde ich das nicht so theoretisch. Bei einem > F3 kann man den Pin mit 36MHz toggeln. Womit dann die Geschwindigkeitsanforderung zu ca 1/4 erfüllt wäre ;-) Also theoretisch schön, wenn da nicht die böse Praxis wäre.
Habs nicht früher geschafft rein zu schauen, sorry. Im Datenblatt des ADCs steht er wäre SPI kompatibel. Das ist schonmal gut. Noch habe ich nicht direkt mit SPI gearbeitet, das sollte aber schaffbar sein. Auf dem FPGA habe ich den ADC "gebitbangt" Der SPI takt ist scheinbar auch etwas niedriger, als ich es in Erinnerung hatte, sorry! Es sind "nur" rund 90MHz, wobei die eigentliche Frage für diese Frequenz noch immer gültig sein sollte. Ich debke aber, dass die Chancen sowas mit einem Teensy 4.0 zu schaffen deutlich besser sind. Oder sehe ich das Falsch? Der ADC ist dieser hier: https://www.analog.com/en/products/ltc2315-12.html
Ein STM32H7xx schafft per SPI eine Übertragung mit 240 MBd. Aber damit kommt der ADC wohl nicht mehr klar.
Patrick schrieb: > Der ADC ist dieser hier: > > https://www.analog.com/en/products/ltc2315-12.html Und was sagt uns das Datenblatt? 5Msps. Ich fasse mal die Zahlenwerte zusammen: Patrick schrieb: > Ich müsste in diesem Fall 150MHz als Takt > erzeugen und seriell Daten einlesen. Patrick schrieb: > Der SPI takt ist scheinbar auch etwas niedriger, als ich es in > Erinnerung hatte, sorry! Es sind "nur" rund 90MHz Ich lese aus dem Datenblatt: Shift Clock Frequency max 87.5 MHz Das bedeuted aber nicht dass du das erfüllen musst. Du darfst auch wesentlich weniger machen. Ich fasse zusammen. Du hast noch gar nichts verstanden und mit deinen Anforderungen hast du dich auch noch nicht wirklich auseinandergesetzt. Oh my god!
Weihnachts Ente schrieb: > mit deinen Anforderungen hast du dich auch noch nicht wirklich > auseinandergesetzt. ... aber von vorne herein mit Maximalforderungen daherkommen von 150 MHz mit PIO-Pin-Wackeln erreichen zu müssen ....
Wenn die 5 MSample seriell ueber SPI auszuszulesen zu stressig ist, wuerd ich auf einen ADC mit parallelem Interface gehen. zB https://www.analog.com/en/ad9220
Weihnachts Ente schrieb: > Du hast noch gar nichts verstanden Ich geb zu, dass ich die Anforderungen nicht ganz auf dem Schirm hatte. Weihnachts Ente schrieb: > Das bedeuted aber nicht dass du das erfüllen musst. Das wollte ich auch nicht sagen. In meiner Anwendung läuft der ADC kontinuierlich mit maximaler sample rate. Der Datenstrom wird kontinuierlich verarbeitet.
Eine andere Frage wäre, ob die Chip-Strukturen eines Pins plus Anschlusstechnik derart hohe Frequenzen überhaupt sauber mitmachen. Immerhin sind I/O-Pins für eine viel höhere Last gebaut, als der Rest des Chips. Ob der Hersteller beim Design davon solche Frequenzen im Auge hatte?
Patrick schrieb: > In meiner Anwendung läuft der ADC > kontinuierlich mit maximaler sample rate. Der Datenstrom wird > kontinuierlich verarbeitet. Ok, wenn das alles schon läuft sind ja alle Fragen geklärt und der Thread kann zugemacht werden. Weg mit dem Troll ! Aber subito schrieb: > Die bisher fehlende Information : Was das Ganze soll ? Diese Frage habe ich mir auch seit langer Zeit schon gestellt. Denn die Randbedingungen sind so pervers/verquer dass man unwillkürlich auf das Thema Troll kommen muss.
Der BeagleBone Black hat zwei Echtzeitkerne, welche mit 200 MHz laufen, man kann damit also 100 MHz am Ausgang schaffen. Wenn das zu wenig ist: nimm den neuen BeagleBone AI, dessen PRU-Cores sind noch höher getaktet (ich kann nur gerade den genauen Wert nichr finden)
A. K. schrieb: > Ob der Hersteller beim Design davon solche Frequenzen im Auge hatte? Beim H7xx sicherlich.
Arduino Fanboy D. schrieb: > Womit dann die Geschwindigkeitsanforderung zu ca 1/4 erfüllt wäre > ;-) > Also theoretisch schön, wenn da nicht die böse Praxis wäre. Richtig es war auch nur ein Beispiel..... Der H7 macht das locker. Soll er lieber einen Arduino nehmen der macht das bestimmt besser und ist auch in der Praxis schön ? Wenn er dir 5MSPS mit 12 Bit nutzen will braucht er 60Mbit also 60 MHz SPI Clock. Wenn man etwas Puffer will auch gerne mehr. Das sind Anforderungen die ein H7 locker erfüllt.
Mich würde mal interessieren wofür er die 5MSPS überhaupt brauch. Je nachdem wäre es ja schon fast sinnvoller den ADC im µC zu benutzen, wenn er eh einen nehmen will. Ich meine der H7 hat 3.6MSPS und bis zu 16 Bit und es besteht die Möglichkeit ADC1 und ADC2 im interleaved Mode zu betreiben.
Martin schrieb: > Mich würde mal interessieren wofür er die 5MSPS überhaupt brauch. Willst du ihm diese dann ausreden? > Ich meine der H7 hat 3.6MSPS und bis zu 16 Bit > und es besteht die Möglichkeit ADC1 und ADC2 im interleaved Mode zu > betreiben. Einen externen ADC würde ich immer bevorzugen, wenn die Messwerte nicht zappeln sollen und der ADC noch eine gute Vref bietet. Guest schrieb: > Wenn er dir 5MSPS mit 12 Bit nutzen will braucht er 60Mbit also 60 MHz > SPI Clock. Nein, denn die SH-Stufe braucht auch noch ihre Takte.
Gans Gebraten schrieb: > Nein, denn die SH-Stufe braucht auch noch ihre Takte. Was interessiert dich denn da das Sample and Hold Glied? Wenn der ADC die Daten mit 5MSPS und 12 Bit bereitstellt stimmt die Rechnung doch. Gans Gebraten schrieb: > Einen externen ADC würde ich immer bevorzugen, wenn die Messwerte nicht > zappeln sollen und der ADC noch eine gute Vref bietet. Ich benutze eigentlich fast nur interne ADCs es sei denn ich brauche eine höhere Auflösung. Bei den STMs kann man externe Referenzen anschließen und bei mir zappelte da gar nichts. Man muss die Versorgung eben entsprechend sauber haben das muss man bei externen ADCs aber auch.
Gans Gebraten schrieb: > Willst du ihm diese dann ausreden? Nein will ich nicht. Wie gesagt es ist Interesse halber. 5MSPS sind ja schon eine Hausnummer. Und vielleicht kann er bei seinem nächsten Projekt ja einen internen ADC ins Auge fassen. Gans Gebraten schrieb: > Einen externen ADC würde ich immer bevorzugen, wenn die Messwerte nicht > zappeln sollen und der ADC noch eine gute Vref bietet. Also ich sehe den Grund für externe ADCs auchnur wenn eine höhere sampel Rate oder Auflösung gefordert ist. Von mir aus auch noch wenn man eine spezielle Messung hat und es fertige ADCs mit Frontend gibt. Bei mir hat noch kein Messwert gezappelt zumindest nicht mehr als bei einem Externen. Vielleicht kannst du einfach keine anständige Versorgung auslegen oder das Datenblatt lesen und feststellen das man externe Referenzen verwenden kann ;)
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.