Guten Abend. Zunächst wünsche ich allen Lesern und Forenteilnehmern noch ein frohes Fest und einen fleißigen Weihnachtsmann. Vorsorglich auch schon einen guten Rutsch ins neue Jahrzehnt. Da ich nur gelegentlich und alle paar Jahre wieder mal zu einem Mikrocontroller greife, habe ich nur einen geringen Überblick über den Markt. Viele Profis hier die täglich mit Controllern umgehen und damit ihr Brot & Butter verdienen kennen wahrscheinlich mehrere Produktfamilien in- und auswendig. Ich suche für ein Privatprojekt einen Controller der über einen ADC (mit mehreren Kanälen) oder mehrere ADCs im Ersten Schritt 8 Stereo-Audiosignale mit je 48 kHz bei 10 - 16 Bit Auflösung digitalisieren kann. Eine digitale Nachbearbeitung der Audiosignale (Equalizer, Filter oder so) im Controller ist nicht nötig, lediglich die Samplewerte werden mit Metadaten versehen und neu verpackt/gemuxt. Das so erstellte Signal soll auf zwei Ausgänge des Controlles mit je 10,24 Mbit/s per Bit Banging ausgegeben werden. Welcher Controller würde eine solche Aufgabe eurer Meinung nach hinbekommen? Da das ein Hobbyprojekt ist, wäre es ideal wenn es für den geeigneten Controller einen freien/kostenlosen Compiler/Toolchain gäbe. Fällt Euch Profis da spontan ein Controller oder Eval-Board ein um die Aufgabe erledigen zu können? Gruß Themas
Auch nur die Idee zu haben, Daten mit einer spezifizierten Datenrate im MBit-Bereich per Bit-Banging ausgeben zu wollen, zeugt von völliger Ahnungslosigkeit. Vergiss das. Ein FPGA würde das können, ein Mikrocontroller nicht. fchk
Frank K. schrieb: > Auch nur die Idee zu haben, Daten mit einer spezifizierten Datenrate im > MBit-Bereich per Bit-Banging ausgeben zu wollen, zeugt von völliger > Ahnungslosigkeit. Vergiss das. Ein FPGA würde das können, ein > Mikrocontroller nicht. > > fchk Das kommt auf die Geschwindigkeit des Controllers an. Wenn er schnell genug ist (xxx MHz) sollte die Erzeugung eines solchen doch Signals kein Problem sein. Es muss doch nicht immer gleich zum FPGA gegriffen werden.
:
Bearbeitet durch User
Thomas W. schrieb: > Frank K. schrieb: >> Auch nur die Idee zu haben, Daten mit einer spezifizierten Datenrate im >> MBit-Bereich per Bit-Banging ausgeben zu wollen, zeugt von völliger >> Ahnungslosigkeit. Vergiss das. Ein FPGA würde das können, ein >> Mikrocontroller nicht. >> >> fchk > > Das kommt auf die Geschwindigkeit des Controllers an. Wenn er schnell > genug ist (xxx MHz) sollte die Erzeugung eines solchen doch Signals kein > Problem sein. Es muss doch nicht immer gleich zum FPGA gegriffen werden. Du übersiehst zwei Probleme: 1. Bei vielen Controllern mit zugekauften Cores (alle ARM und MIPS-Controller z.B.) sind die IO-Pins über interne Busse angekoppelt, die wesentlich langsamer als die CPU laufen, und dann noch asynchron. 2. Jitter. Du wirst es nicht schaffen, ein wirklich präzises Timing einzuhalten. Dazu müsstest Du von allen Befehlen die exakten Ausführungszeiten wissen. Bei 8 Bit Controllern ist das noch kein Problem, bei ARM oder MIPS ist das ziemlich komplex, und wenn Caches und Interrupts da mit hinkommen, hast Du verloren. Und Jitter willst Du im Audiosignal nicht haben. Das hörst Du. fchk
Wie genau soll das Ausgangssignal denn aussehen ? Jenachdem gibt es vielleicht ja Hardware dafür. I2S zum Beispiel. Wenn du einen schnellen Controller willst gäbe es den STM32H7 wobei der vielleicht auch schon etwas overkill ist. Den gibt's auch als Dual Core. Alternativ hat ST auch eine Baureihe für Multimedia Anwendung ich meine das ist die STM32Gxxx.
Frank K. schrieb: > sind die IO-Pins über interne Busse angekoppelt, > die wesentlich langsamer als die CPU laufen, und dann noch asynchron. Die laufen meistens mit dem Halben CPU Takt und wo sind die asynchron? Sie werden alle aus der selben Clock gespeist.
Hallo Gast. Das Ausgangssignal besteht aus einem Rahmen von 320 Bits mit einer Wiederholfrequenz von 32 kHz. Jeder Rahmen hat ein 11 Bit Synchronwert gefolgt von vier Datenblöcken zu 77 Bit und einem Sonderbit. Gruß Thomas
Das solltest du mit einem SPI machen können. Entweder 40 Byte verschicken bei 8 Bit Datenweite oder 10 mal 32 Bit Datenbreite, letzteres kann nicht jedes SPI. Die Clock musst du ja nicht nutzen. Die STMs haben meistens 3 ADCs mit 12 Bit oder mehr und idr. etwas um die 3 bis 5 MSPS (kommt auf die Familie an) Wenn du die Daten vom ADC per DMA in den Speicher schaufelst und die Aufbereiteten Daten per DMA an den SPI sollte die CPU genug Zeit haben für den ganzen anderen Kram zu machen.
Guest schrieb: > Das solltest du mit einem SPI machen können. Entweder 40 Byte > verschicken bei 8 Bit Datenweite oder 10 mal 32 Bit Datenbreite, > letzteres kann nicht jedes SPI. Die Clock musst du ja nicht nutzen. SPI wäre in der Tat eine Möglichkeit. Die STM-Peripherie kenne ich jetzt nicht so, aber z.B. PIC32 hat sehr flexible SPI-Einheiten, mit denen man auch I2S und andere Sachen machen kann. Ich würde auch eher externe Audio-I2S-ADCs verwenden, wegen besserer Signalqualität. Aber eigentlich ist ein FPGA hier die bessere Lösung. Das muss dann ja noch nicht mal besonders groß sein. So ein Lattice MachXO2 ist einfach zu löten und braucht nur eine Versorgungsspannung und kostet etwa 10€. fchk
Thomas W. schrieb: > Das kommt auf die Geschwindigkeit des Controllers an. Wenn er schnell > genug ist (xxx MHz) sollte die Erzeugung eines solchen doch Signals kein > Problem sein. Es muss doch nicht immer gleich zum FPGA gegriffen werden. Man merkt, dass du keine Ahnung von µCs hast. Allein das erzeugen eines definierten Bitstromes nach deinem Muster mit der genannten Frequenz ist mit den üblichen µCs fast ein Ding der Unmöglichkeit. Dazu noch mit Bit-Banging. Das ganze dann auch noch auf zwei Kanälen des Controllers. Da sind die ganzen Daten noch nicht mal im µC drin. Das Einlesen und verarbeiten kostet auch noch erhebliche Rechenzeit. > Da ich nur gelegentlich und alle paar Jahre wieder mal zu einem > Mikrocontroller greife, habe ich nur einen geringen Überblick über den > Markt. Ist klar, und dann gleich so ein Projekt. Denkst du im Vorfeld auch mal über solche Projekte nach? Oder bist du vielleicht BWLer...? Wenn überhaupt, geht ein µC mit DMA. Das ist dann aber kein µC ala ATTiny mehr, da sollte man in der ARM-Klasse suchen. Die sind aber bei den IOs und HW-Module etwas komplexer, die Einarbeitung dauert Monate.
Frank K. schrieb: > Aber eigentlich ist ein FPGA hier die bessere Lösung. Das muss dann ja > noch nicht mal besonders groß sein. So ein Lattice MachXO2 ist einfach > zu löten und braucht nur eine Versorgungsspannung und kostet etwa 10€. und Thomas W. schrieb: > Da ich nur gelegentlich und alle paar Jahre wieder mal zu einem > Mikrocontroller greife, passen irgendwie nicht zusammen. Ich interpoliere die vermuteten Kenntnisse des TE im µC-Sektor einfach mal auf FPGAs.
Darf man fragen was für ein Gerät der µC füttern soll? Das Datenformat ist dann schon etwas speziell.
Moin, Thomas W. schrieb: > Hallo Gast. > > Das Ausgangssignal besteht aus einem Rahmen von 320 Bits mit einer > Wiederholfrequenz von 32 kHz. Jeder Rahmen hat ein 11 Bit Synchronwert > gefolgt von vier Datenblöcken zu 77 Bit und einem Sonderbit. > > Gruß Thomas Ist das sowas wie NICAM? Angesichts der Datenraten und speziell der "krummen" Laengen wuerd' ich doch auch ganz stark weg vom µController und hin zum FPGA tendieren. Gruss WK
Thomas W. schrieb: > Ich suche für ein Privatprojekt einen Controller der über einen ADC (mit > mehreren Kanälen) oder mehrere ADCs im Ersten Schritt 8 > Stereo-Audiosignale mit je 48 kHz bei 10 - 16 Bit Auflösung > digitalisieren kann. Ein Audio-ADC in einem µC ist seltenst eine gute Idee. Klassisch löst man das mit einem separaten Chip (Audio-CoDec). Und die kanonische Schnittstelle zur Anbindung an einen µC heißt I²S. Allerdings geht da üblicherweise immer nur ein Stereosignal drüber. Du bräuchtest also 8 davon. > Eine digitale Nachbearbeitung der Audiosignale > (Equalizer, Filter oder so) im Controller ist nicht nötig, lediglich die > Samplewerte werden mit Metadaten versehen und neu verpackt/gemuxt Dann wäre ein FPGA wohl die bessere Wahl. µC mit mehreren I²S Schnittstellen gibt es zwar, aber 8 habe ich noch nicht gesehen. Es sei denn, deine 8 Stereo-Signale sind unabhängig. Dann kannst du natürlich einfach 8-mal das Gleiche bauen.
Ich empfehle ebenfalls einen externen Audio-Codec je Kanal zu verwenden. Ein µC der 5 I2S Kanäle hätte gäbe es, jedoch ob dieser die Datenmengen schafft bezweifle ich (STM32F41x / STM32F42x) Vielleicht wäre dieser Aufbau eine Idee: 3 µC: µC1: 4 I2S Kanäle einlesen, verrechnen und auf dem 5ten Kanal ausgeben. µC2: das gleiche wie µC 1. µC3: liest die vorberechnete Daten von µC1/2 mit 2 I2S Kanäle ein, verrechnet diese und gibt diese auf einen I2S wieder aus. Die Ausgabe der I2S Daten geht zu einem Audio-Codec der wieder Audio Analogsignale erzeugt. So könnte man diese 8 Kanäle zusammen fassen. Und es wäre noch erweiterbar auf 16 Kanäle, wenn man µC1 noch 2x kopiert (dann wären es insgesamt 5µC). Ob man das Spiel noch weiter Kaskadieren kann, indem man z.B. µC 3 kopiert und man dann insgesamt: 4 Kanäle ** 4 µC1 ** 4 µC3 = 64 weiß ich nicht, kommt wohl auf die Programmierung drauf an. Das Prinzip sieht in der Theorie schön modular aus, ob es in der Praxis so hin haut sollte man mal mit ein paar Demo-Boards mal testen. Ist schon relativ aufwändig, ich denke mit einem FPGA kann man solche Datenmengen leichter verarbeiten.
:
Bearbeitet durch User
Axel S. schrieb: > Ein Audio-ADC in einem µC ist seltenst eine gute Idee. Klassisch löst > man das mit einem separaten Chip (Audio-CoDec). Und die kanonische > Schnittstelle zur Anbindung an einen µC heißt I²S. Es gibt genug Audio Codecs bzw. Audio ADCs die I2C oder SPI haben. Analog Devices hat da einiges. In Anbetracht der Datenmenge würde ich hier SPI Bevorzugen da kann man auch mehrere an einen Bus Hängen.
Guest schrieb: > Es gibt genug Audio Codecs bzw. Audio ADCs die I2C oder SPI haben. Ja für die Config! Zur Übertragung wird dann I2S genutzt.
Jens schrieb: > Man merkt, dass du keine Ahnung von µCs hast. Tschuldigung, das beruht wohl auf Gegenseitigkeit. Jens schrieb: > Das ist dann aber kein µC ala ATTiny mehr, da sollte man in der > ARM-Klasse Was ist denn eine ARM- Klasse? Cortex M0 oder doch eher A76? Da ist ja auch noch ein kleiner Leistungsunterschied drin...
Mw E. schrieb: > Ja für die Config! > Zur Übertragung wird dann I2S genutzt. Für viele mag das stimmen es gibt aber auch andere. AD7768-1 AD7768-4
Guest schrieb: > Mw E. schrieb: >> Ja für die Config! >> Zur Übertragung wird dann I2S genutzt. > > Für viele mag das stimmen es gibt aber auch andere. > > AD7768-1 > AD7768-4 Weil das kein Audio ADC is ;)
Teensy 4.0 + selbstgestricktes Audioshield wäre meine Wahl. An der Entwicklung des Audioshields wäre ich auch interessiert. Brauch sowas auch
Mw E. schrieb: > Weil das kein Audio ADC is ;) Deshalb ist er auch unter Audio OpAmp gelistet und deshalb steht es auch im Datenblatt. PS: ich habe den schonmal für eine Audio Anwendung verwendet.
Mw E. schrieb: > Darf man fragen was für ein Gerät der µC füttern soll? > Das Datenformat ist dann schon etwas speziell Hallo. Es handelt sich um ein Gerät mit dem verschiedene NF Quellgeräte (von CD über DAT bis zum Micro) in einem Rundfunkstudio nach einer alten EBU-Norm zusammengeführt werden. Ich habe zwei alte Originalgeräte aus den späten 80iger, frühen 90ier. Eines mit 4 das andere mit 6 Kanälen. Bei einem Gerät erfolgt die Takterzeugung für die 10,24 MBit extern und die Signale werden über einen TSM320 (Custom?) auf den Takt ge-AND-ed. Bei dem 4-Kanaler wird das alles mit einem U5200 ASIC von ZMD (Zentrum Microelektronic Dresden) gemacht. Zu void: meine bisherigen Projekte gehen von Z80 über diverse PIC18 bis zum ESP32. Ich mache die Sachen halt nur nicht täglich im Gegensatz zu einigen Profis hier, da fällt mir die Marktorientierung und Leistungseinschätzung bei aktuellen Controllern schwer. Und da die Taktfrequenzen der Dinger ja seit einiger Zeit fast quartalsweise auf 400, 500, 600 ... MHz gehen (damit meine ich nicht diese Linux SoCs, sondern “normale“ Controller) wollte ich das ganze mal mit einem aktuellen System mit 8-Stereokanälen in Software umsetzen ohne gleich einen FPGA einsetzen zu müssen. Wenn es eine passende serielle Hardwareschnittstelle im Controller gibt, die man per DMA ... füttern kann, umso besser. Aber auch Bit Banging und “Zyklen zählen“ würde mich jetzt nicht abschrecken, alles schon bei anderen (wenn auch langsameren) Protokollen gemacht. Natürlich funkte da kein OS oder Sprungvorhersage dazwischen! Bestenfalls ein kleiner selbst geschriebener Prozess-Scheduler. Ideal wäre natürlich auch wenn der ADC (mehrkanalige oder mehrere Wandler) im Controller verbaut ist. Ob man spezielle Audio-ADCs braucht? Hmm, müsste man sich mal anhören was der Wandler in der dann geeigneten Controller(-familie) draus macht und nachträglich entscheiden. Welcher Profi hier hat denn schon mit ähnlichen schnellen (10.24 Mbit/s) seriellen Datenströmen auf einem Controller gearbeitet und welchen Controller habt Ihr dabei eingesetzt? Gruß Thomas
Wie gesagt STM32H7 oder G4. Wenn du nur umpacken willst reicht vermutlich der G4 der hat jede Menge ADCs. Wenn du etwas mehr machen willst gibt es den H7 unter anderem auch mit Dual Core (M7 für Berechnung, M4 sammelt Daten und haut sie wieder raus wäre eine Option). Auf dem H7 verwende ich zu Debug Zwecken für live Daten zu sammeln einen SPI zu USB Chip von FTDI und Feuer mit dem DMA über SPI zwischen 12 und 16MBit das macht das Ding gemütlich mit. Ein Kollege von mir verwendet den G4 der nutzt dieses Interface ebenfalls ohne Probleme, ich selbst habe mit dem G4 allerdings noch nicht gearbeitet. Ob die ADCs für deine Anwendung geeignet sind kann ich dir nicht beantwortet ich würde es einfach mal probieren. Externe ADCs kannst du ja dann immer noch nehmen.
Moin, Da bist du aufm Holzweg, wahrscheinlich wird dich keiner davon abbringen koennen, aber es aendert nix an der Holzigkeit. Nimm!ein!FPGA! - und dazu ein paar ADCs Da wuerden z.b. 8x PCM1808 und der kleinste Spartan-3 ausreichen. Oder auch gerne irgendwas moderneres. Aber in einem FPGA ist das voellig popelig; bei einer CPU kriegst du 10.24MBit/sec nicht ohne Hardwareunterstuetzung hin - und selbst wenn du dann irgendwie aus einem SPI-Master per DMA sowas ausgeben kannst und dir den Wolf programmierst, um irgendwelche 11Bit SyncWords und 77bit Blocks mit Gewalt an nicht 8bit-Grenzen aneinander zu pappen - dann brauchst du immernoch deine 8x I2S Interfaces und krumme Takte fuer den ganzen Zirkus. Da hat ein FPGA fertige PLLs, DCMs und all so'n Zeugs dafuer. Gruss WK
Maxim schrieb: > Deshalb ist er auch unter Audio ADC gelistet und deshalb steht es auch > im Datenblatt. > > PS: ich habe den schonmal für eine Audio Anwendung verwendet. Okay, interessantes Teil. Mono Audio ADC, dann noch SPI und extern triggerbar. Durchaus speziell das Teil ;) @Thomas W: Durchaus ein interessantes Gerät was du da angeschleppt hast. Also bei einem STM32F429 mit 160MHz ist ungefähr bei 10 - 12MHz Bitbang auf einen GPIO per DMA Schluss. Denn zwischen dem ARM Kern und der Peripherie steckt noch eine Busmatrix und die braucht ein paar Takte zur Arbitrierung. Jedenfalls hab ich das bei meinem Videowallprojekt so rausgefunden. Durch die Ausgabe von 16Bit per DMA Zugriff warens dann doch 20Mbyte/s. Wenn der Bitstream synchron zu einem Takt ist ließe sich jeweils ein Frame im Speicher ablegen und dann per DMA Ausgeben. So sind auch völlig krumme Bursts machbar. Dazu brauchst 2 verschaltete Timer. Timer x zählt die Auszugebenen Takte/Bits. Timer y ist im gated Mode und gibt nur so lange eine PWM aus wie ihm Timer x befiehlt. Diese PWM ist DC 50/50 und somit das Taktsignal. Bei einer PWM Flanke wird der DMA getriggert. Dauervollgas mit Doublebuffer DMA geht natürlich auch. Das Problem liegt jetzt noch dabei einen Controller zu finden mit 8 I2S Peripherien. Da kenn ich jetzt keinen, andere hier vllt schon. Oder du nutzt einen 8 Kanal ADC mit TDM Interface: https://www.mouser.de/ProductDetail/Cirrus-Logic/CS5368-CQZ?qs=bUPhaerQQeGDWhh8BBq%2FwQ== STM32 haben nicht nur SPI, welche als I2S nutzbar sind, sondern auch einen SAI (Serial Audio Interface). Der kann auch TDM. Du brauchst dann eben 2 dieser ADC für 8x Stereo. edit: Aber eigentlich ist das FPGA Gebiet.
:
Bearbeitet durch User
Thomas W. schrieb: > Und da die Taktfrequenzen der Dinger ja seit einiger Zeit fast > quartalsweise auf 400, 500, 600 ... MHz gehen (damit meine ich nicht > diese Linux SoCs, sondern “normale“ Controller) wollte ich das ganze > mal mit einem aktuellen System mit 8-Stereokanälen in Software umsetzen > ohne gleich einen FPGA einsetzen zu müssen. Ein Profi würde wissen, dass die 400...500...600 MHz nur auf den innersten CPU-Kern beschränkt sind, die Pintreiber und das ganze dazwischen aber viel langsamer ist. Rechenleistung ist was anderes als IO-Leistung. Ein Profi würde wissen, dass fast alle Controller, die 8 bis 20 und mehr analoge Eingänge haben, nur einen einzigen ADC mit einem Multiplexer davor haben. Du kannst gar nicht 16 Kanäle gleichzeitig einlesen, sondern nur reihum. Und dann müsste man sehen, ob der ADC nach dem Umschalten nicht noch eine Einschwingzeit braucht. Externe I2S Stereo-Audio-ADCs gibts bei Digikey ab 2€, das ist also nicht der Kostenfaktor. Eher die analoge Beschaltung und die XLR-Buchsen davor, aber die brauchst Du ohnehin. Ein Profi würde auch wissen, wann ein FPGA sinn macht, und hier macht es Sinn. Er hätte keine Angst, ein solches einzusetzen - ist ja auch nur programmierbare digitale Logik, die im Vergleich zu den 90'ern jetzt echt bezahlbar geworden ist. Die kleinsten FPGAs liegen im Euro-Bereich. > Welcher Profi hier hat denn schon mit ähnlichen schnellen (10.24 Mbit/s) > seriellen Datenströmen auf einem Controller gearbeitet und welchen > Controller habt Ihr dabei eingesetzt? Meine Datenströme liegen eher im GBit/s Bereich, aber ich verwende da natürlich auch Hardware, die das verarbeiten kann. Stichwort PCIe. fchk
Frank K. schrieb: > Ein Profi würde wissen, dass die 400...500...600 MHz nur auf den > innersten CPU-Kern beschränkt sind, die Pintreiber und das ganze > dazwischen aber viel langsamer ist. Rechenleistung ist was anderes als > IO-Leistung. Viel langsamer ist übertrieben! Bei einigen Modellen ist das immer noch locker im 3-stelligen MHz Bereich. Ein “Profi“ würde das Wissen .... >Ein Profi würde wissen, dass fast alle Controller, die 8 bis 20 und mehr analoge Eingänge >haben, nur einen einzigen ADC mit einem Multiplexer davor haben. Du kannst gar nicht 16 >Kanäle gleichzeitig einlesen, sondern nur reihum. Hatte ich oben schon mehrfach erwähnt. Ein Profi hätte das gelesen. >Ein Profi würde auch wissen, wann ein FPGA sinn macht, und hier macht es Sinn. Er hätte >keine Angst, ein solches einzusetzen - Klar geht ein FPGA, aber um den geht es mir nicht! Ich habe auch keine Angst vor FPGAs, habe sogar ein paar zu liegen, nur ist mein Interesse das auf einem Controller zu implementieren und zu schauen wie gut er das kann. Das ganze ist nur Hobby und der Weg ist das Ziel. Ein Profi hätte auch das mittlerweile kapiert! Da du also überall ein Fail hast, gehe ich mal davon aus das Du auch kein Profi bist, sondern hier nur wiederholend auf die Kacke haust! Gähn....
:
Bearbeitet durch User
Thomas W. schrieb: > Ich suche für ein Privatprojekt einen Controller der über einen ADC (mit > mehreren Kanälen) oder mehrere ADCs im Ersten Schritt 8 > Stereo-Audiosignale mit je 48 kHz bei 10 - 16 Bit Auflösung > digitalisieren kann. Eine digitale Nachbearbeitung der Audiosignale > (Equalizer, Filter oder so) im Controller ist nicht nötig, lediglich die > Samplewerte werden mit Metadaten versehen und neu verpackt/gemuxt. Das > so erstellte Signal soll auf zwei Ausgänge des Controlles mit je 10,24 > Mbit/s per Bit Banging ausgegeben werden. Das ist kein grosses Ding, und geht mit jedem Cortex M0+ oder M4/M7, der mit mindestens 2 * 10.24 MHz getaktet ist. Also z.B. STM32F405 oder STM32H750 (mit 3x 16 Bit ADCs mit mehreren Eingängen, und effektiv 12 - 14 Bits).
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.