Hallo Miteinander, ich habe folgendes Problem: Ich möchte einige (16 mono-äquivalent) digitale Audiokanäle (24bit, 96kHz) in Echtzeit asynchron von einem FPGA an einen uC (evtl. Coldfire von Freescale) schicken. Welchen "Bus" könnt ihr da empfehlen. Ich liebäugle etwas mit dem seriellen TDM-Bus welcher aber nur bis maximal 16bit funktioniert, oder? Danke Grüße Pudl
Hi Pudl, du meinst vermutlich den TDM-Mode auf nem SPORT? (oder auch i2s) Mal eben laut gedacht, sollte das von der Bandbreite gerade noch gehen:
serieller Clock Ob dein DSP am SPORT auch 24 bit kann, muesstest du wohl im HRM nachgucken. Auf FPGA-Seite sollte es mit dem Multiplexing keine Probleme geben. Nur eine Frage der Resourcen (und wohl auch der Marke). Habe da bisher nur mit Xilinx+Blackfin-Gespann Erfahrungen gesammelt. Die knifflige Frage waer dann: Wie bekommst Du die Daten wieder raus...und wie eng wuerde das dann mit der Bandbreite. Wenn nur 100M Ethernet, und keine Verarbeitung, koennte das gerade eben so mit effizientem DMA-Einsatz gehen. Viel Erfolg, - Strubi
Hi Strubi, wie man die Daten aus dem uC wieder raus bekommt ist zum Glück nicht mein Problem. Ich muss sie nur reinbekommen. Hast du mit dem TDM-Mode schon mal gearbeitet? Gibt es da eine bessere, einfachere Möglichkeit, oder nimmt man einfach einen UART und strickt sich sein eigenes Protokoll? Grüße Pudl
Michael Pfab schrieb: > wie man die Daten aus dem uC wieder raus bekommt ist zum Glück nicht > mein Problem. Spricht hier die zukünftige Ingenieurselite? Wenn ich bei meinen Problemstellungen die Scheuklappen aufsetzen würde, könnte ich mir meine Arbeit auch leicht machen. Aber es würde dem Gesamtsystem nicht dienlich sein: Thinking out of the box! Duke
@Duke Ich habe mich vielleicht falsch ausgedrückt, aber ich meinte damit, dass das Problem schon gelöst ist ;-) Grüße Pudl
Hi Pudl, > > wie man die Daten aus dem uC wieder raus bekommt ist zum Glück nicht > mein Problem. Ich muss sie nur reinbekommen. Hast du mit dem TDM-Mode > schon mal gearbeitet? Gibt es da eine bessere, einfachere Möglichkeit, > oder nimmt man einfach einen UART und strickt sich sein eigenes > Protokoll? > Naja, es kann auch zu Deinem Problem werden, wenn es von der Bandbreite (Durchsatz) nicht hinhaut. Das kann dich naemlich schlimmstenfalls mitten in der Entwicklung zwingen, auf eine andere CPU umzusteigen, wenn dein Kollege, (der ev. den Output-Teil uebernimmt) am Flaschenhals steht. Ausser, deine Arbeit hat rein evaluierenden Charakter. Mehrkanal-SPORT habe ich bereits aufm FPGA implementiert, aber TDM-Mode nicht benutzt, das ist ansich ja nur eine moegliche Betriebsart für parallelen Codec-Betrieb. Vergessen habe ich zu sagen: asynchron geht das ganze sowieso nicht, abgesehen davon kannste den UART von der Geschwindigkeit her sowieso vergessen. SPORT ist nicht so schwierig zu implementieren und "standard". Im Endeffekt gibt dir eigentlich deine Hardware mehr oder weniger vor, welchen Port du am besten benutzt. Mir ist auch nicht ganz offensichtlich, warum du ein FPGA brauchst, da die meisten Codecs SPORT/TDM unterstuetzen. Gruesse, - Strubi
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.