Hi, ist I2S was spezielles, oder kann man die I2C Schnittstelle dafür nehmen und die Senderoutine anpassen? Mein Problem ist, dass mein ausgesuchter uC kein I2S hat. An den Controller soll dieses IC dran gehängt werden. http://www.ti.com/lit/ds/symlink/tlv320aic3104-q1.pdf Und die zweite Frage: Mit welchen Daten möchte der Codec gefüttert werden? Sorry, eine leichte Anfängerfrage. Danke
I2S ist für Audiodaten, hat garnichts mit I2C zu tun... Der von Dir gewählte CODEC hat I2C für die Konfiguration und I2S für Audio.
>I2S ist für Audiodaten, hat garnichts mit I2C zu tun... Ist mit schon klar. Aber das ist eine serielle Schnittstelle. Dann kann man die Daten auch per Hand rausschieben? >Der von Dir gewählte CODEC hat I2C für die Konfiguration und I2S für >Audio. Dies ist mir ebenfalls bekannt ;)
Markus schrieb: > Aber das ist eine serielle Schnittstelle. Dann kann man die Daten auch > per Hand rausschieben? Wenn Du das schnell genug kannst, dann mach' doch. Da hier niemand weiß, was Du dem Codec überhaupt mitteilen willst, kann es gehen oder auch nicht. Die ersten paar Zeilen des Datenblattes sagen, dass die Bitrate der reinen Audiodaten (ohne Overhead) pro Richtung eine Bitrate zwischen 128kbit/s und 6144kbit/s haben können. Ob Du das mit Deinem unbekannten uC schaffst ist fraglich. Mit I²C wird das jedenfalls nichts evtl. könntest Du eine andere serielle Schnittstelle dafür vergewaltigen. Manche uCs haben ja ziemlich flexible USARTs oder ähnliches.
Oh, ich habe jetzt erst gesehen, was für ein Blödsinn ich geschrieben habe. Ich meine natürlich SPI. Also SPI als I2S nutzen :-) Muss locker gehen, oder?
Nimm besser von Haus aus einen µC mit Hardware-I2S. Sowas ist nicht wirklich selten. Beispiel Microchip: http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MX470F512H Beispiel ST: http://www.st.com/web/en/resource/technical/document/datasheet/DM00035129.pdf Welchen Hersteller bevorzugst du? Ich denke, auch der wird welche haben.
>Weil I2S Daten, Clock und Wordselect benutzt.
SPI Daten, Clock, SS.
Wenn die SPI Kommunikation "halb-handgeschtricht" ist, kann man SS
sicherlich als Wordselect nutzen, oder?
Ich möchte mich entschuldigen, wenn das etwas naiv rüber kommt. Ist aber
alles ernst gemeint. Ich habe durchaus eine Menge Erfahrung mit uC und
C-Programmierung. I2S ist für mich leider komplett neu. Ich denke, ich
habe das Prinzip noch nicht ganz verstanden.
Beim I2S werden die Daten Seriell mit Clock (ähnlich wie SPI) zum CODEC
übertragen. Wordselect bestimmt für welchen Kanal die Daten bestimmt
sind.
Bei konstanter Bitrate (ist in der Regel ja auch) wird die fWordselect
1/2 Abtastrate entsprechen.
Ich hoffe, das ist soweit richtig. Wenn nicht bitte korrigieren.
Dann habe ich noch paar Fragen, die eventuell nicht wichtig, bzw mich
nicht zu interessieren haben, aber ich möchte es gerne wissen.
| bedeutet "zeit der Abtastrate" kann es nicht besser beschreiben
... bedeutet Daten
--- passiert nichts
im folgenden Beispiel passen die Daten mit der Abtastrate von der Zeit
her zusammen:
...|..........|..........|..........|..........| usw.
was ist aber wenn die Daten kützer sind? Macht man da gar nichts?
---|......---|......---|......---|......---| usw.
Anders gesagt, wenn die Daten schneller geschickt wurden, als der
"Zeitpunkt der Abtastrate"
Ich hoffe man kann mich verstehen.
Danke
Dann werden die Samples halt auf 32 oder 64 Bits aufgeblasen (alle unteren Bits 0). Viele Codecs wollen auch noch eine stabile Master-Clock haben (typischerweise 256 x Samplerate).
Markus schrieb: > ist I2S was spezielles Ja, das ist ein Hersteller "intelligenter" Sensoren für diverse Parameter. http://www.i2s-sensors.de/
Die Beschreibung findet sich hier: https://sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf >Beim I2S werden die Daten Seriell mit Clock (ähnlich wie SPI) zum CODEC >übertragen. Wordselect bestimmt für welchen Kanal die Daten bestimmt >sind. Ja, das ist im Prinzip richtig. Dabei ist aber zu beachten, dass die Daten für den jeweiligen Kanal erst ab der zweiten Bitclock (SCK)-Periode übertragen werden >Bei konstanter Bitrate (ist in der Regel ja auch) wird die fWordselect >1/2 Abtastrate entsprechen. Nein, die Periodendauer des Wordselect (WS) Signals ist mindestens 2*Bitbreite*Periodendauer SCK, denn in jeder WS-Periode müssen 2*N bits übertragen werden, wobei N die Bitbreite eines Datenworts ist (i.a. 16 oder 24) Natürlich sind auch mehr SCK-Perioden innerhalb einer WS-Periode möglich, die überschüssigen Datenbits werden dann einfach ignoriert. SPI kann man im Prinzip nutzen, allerdings ist es schwer, das WS-Signal zum richtigen Zeitpunkt zu generieren, wenn der µC dafür keine Hardware vorgesehen hat.
Ich habe noch eine Frage. Als Codec habe ich einen etwas anderen genommen, weil ich keine freie I2C Schnittstelle mehr hatte. http://www.ti.com/lit/ds/symlink/tlv320aic3106-q1.pdf Die eigentliche Frage ist, in welchem Format braucht der Codec die Daten? 16 bit signed PCM ist so als Rohdaten OK? Also ein normales WAVE Format. Schicken will ich die nicht über IIS, sondern per Left-Justified-Mode mittels SPI. Danke
@ Markus (Gast) >Als Codec habe ich einen etwas anderen genommen, weil ich keine freie >I2C Schnittstelle mehr hatte. >http://www.ti.com/lit/ds/symlink/tlv320aic3106-q1.pdf Was nützt dir das jetzt? >Die eigentliche Frage ist, in welchem Format braucht der Codec die >Daten? >16 bit signed PCM ist so als Rohdaten OK? Also ein normales WAVE Format. Ja, das geht, man muss nur den Header weglassen. >Schicken will ich die nicht über IIS, sondern per Left-Justified-Mode >mittels SPI. Geht nicht. Der Knackpunkt ist, dass du ein wie auch immer gestalteten Wordclock erzeugen musst. Das kann dein SPI nicht. Man kann es zwar per Bit Banging nachbauen, dann ist aber die CPU-Last umso höher. Das klappt nicht wirklich! Jetzt kann man das natürlich per CPLD/TTL Grab whatever nachbauen, aber die Wahl eines geeigneten Prozessors mit verfügbarem I2S wäre die deutlich bessere Lösung.
Danke Falk! >Was nützt dir das jetzt? Die Konfiguration des Codecs über SPI. Früher hatte ich den anderen im Visier, aber er hatte als Steuerung nur den I2C. Von diesen habe ich aber keine mehr frei. Dafür 3 SPI über. >Ja, das geht, man muss nur den Header weglassen. Habe nun Testweise ein Sinus erstellt und als WAVE abgespeichert. Es sieht so aus, dass LSB zuerst kommt. Laut CODEC Datenblatt wird immer MSB zuerst gefordert. Also umdrehen? >Geht nicht. Der Knackpunkt ist, dass du ein wie auch immer gestalteten >Wordclock erzeugen musst. Das kann dein SPI nicht. Ich glaube, wir nutzen unterschiedliche µController :))) Es spielt jetzt keine Rolle, welchen ich nutze. Wie SPI gesendet wird, kann ich ganz gut selbst bestimmen. ich kann ganz easy nach jedem Byte etwas machen (WCLK umdrehen) wie ich will. Kann sein, dass ich aber ein Denkfehler drin habe.
@ Markus (Gast) >>Was nützt dir das jetzt? >Die Konfiguration des Codecs über SPI. >Früher hatte ich den anderen im Visier, aber er hatte als Steuerung nur >den I2C. Von diesen habe ich aber keine mehr frei. Dafür 3 SPI über. Ach so. ABer auch I2C kann man problemlos per Software emulieren. Das macht man sowieso nur einmal, da ist es egal ob das effizent ist oder nicht. >>Ja, das geht, man muss nur den Header weglassen. >Habe nun Testweise ein Sinus erstellt und als WAVE abgespeichert. Es >sieht so aus, dass LSB zuerst kommt. Laut CODEC Datenblatt wird immer >MSB zuerst gefordert. Also umdrehen? Kann sein. http://soundfile.sapp.org/doc/WaveFormat/ "The default byte ordering assumed for WAVE data files is little-endian. Files written using the big-endian byte ordering scheme have the identifier RIFX instead of RIFF. " >>Geht nicht. Der Knackpunkt ist, dass du ein wie auch immer gestalteten >>Wordclock erzeugen musst. Das kann dein SPI nicht. >Ich glaube, wir nutzen unterschiedliche µController :))) >Es spielt jetzt keine Rolle, welchen ich nutze. Wie SPI gesendet wird, >kann ich ganz gut selbst bestimmen. ich kann ganz easy nach jedem Byte >etwas machen (WCLK umdrehen) wie ich will. Kann sein, dass ich aber ein >Denkfehler drin habe. Probier es auch und berichte uns. Ein weiteres Problem ist der diskontunuierliche Takt bei SPI, denn kann man nicht als Mastertakt zur Audioausgabe nutzen, da muss man die Takterzeugung im OC anders konfigurieren, ggf. über ein Extra-Pin einen kontinuierlichen Takt einspeisen.
>Probier es auch und berichte uns. Im Zweifel kann man doch WCLK hoch ziehen, 16-bit an Daten (linker Kanal) senden, dann sofort WCLK auf LOW und nächtse 16 Bit senden für rechten Kanal. Geht das nicht? >als Mastertakt zur Audioausgabe nutzen Dafür ist ein PWM Pin eingerichtet. Danke
Mit nem XMega geht das per Uart, die als Master-SPI konfiguriert ist. Da es hier einen Sendepuffer gibt, kann man kontinuierlich senden. Die WordClock kann mit einem an die Uart gekoppelten Timer geschehen, der mittels Eventsystem getriggert wird. Die MasterClock wird vom Controllertakt abgeleitet, eventuell mit einem OC-Pin geteilt.
PIC24 und PIC32 haben Framed SPI, und das ist genau TDM (Sammelbegriff für alle Codec-Formate) oder I2S (ein spezielles). DMA ist auch noch dabei. Wozu also der Krampf? fchk
Frank K. schrieb: > PIC24 und PIC32 haben Framed SPI, und das ist genau TDM > (Sammelbegriff > für alle Codec-Formate) oder I2S (ein spezielles). DMA ist auch noch > dabei. > Nimm besser einen STM32. Der kann auch I2S, hat aber einen Cortex-M3 oder Cortex-M4 Kern. Ist deutlich weiter verbreitet und ausserdem bekommst Du für den hier im Forum viel mehr Infos.
Mit hat irgendwann mal ein Lieferant den STM32F4 Discovery board zugeschickt. Habe mir den angeschaut, da ist eine 3.5mm Buchse und ein Codec von CIRRUS drauf. Muss mal gucken, ob ich das in Betrieb nehmen möchte. Da ist mein Problem, dass ich damit noch nie was gemacht habe. ;)
Weiß jemand, welcher Pin beim http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MX570F512H als MCLK benutzt werden soll? Ich habe es eindeutig nicht gefunden. Vermutlich der SCKx Pin vom SPI. Aber was ist dann mit dem BCLK? Gerade für den hätte ich jetzt den SCKx Pin genommen. Im Datenblatt Seite 179. Danke
Angehängte Dateien:
-
image1.JPG
140 KB
Ich habe so was ähnliches auch vor. Bei mir sieht das dann so aus: Siehe Bild. Ist nicht perfekt, man kann es besser machen. Problem dabei ist, die Daten müssen über die ganze Framezeit gezogen werden. Also 125µS bei 8Khz. Damit das so funktioniert, muss die Baudrate angepasst werden. Problem konkret ist, dass der µC in der Zeit quasi nicht anderes machen kann, weil er die Daten permanent sendet. Man müsste DMA dafür nehmen, aber ich weiß nicht, ob meine Möhre das kann. DMA kann das zwar, aber ich weiß nicht, ob sich die Einarbeitung lohnt, und ob am Ende was gescheites heraus kommt ;-) Grüße Alex
Markus schrieb: > Weiß jemand, welcher Pin beim > http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MX570F512H > als MCLK benutzt werden soll? > Ich habe es eindeutig nicht gefunden. Vermutlich der SCKx Pin vom SPI. > Aber was ist dann mit dem BCLK? Gerade für den hätte ich jetzt den SCKx > Pin genommen. > Im Datenblatt Seite 179. > Danke Der PIC braucht den MCLK nicht. BCLK geht an SCLK, LRCLK/FCLK an SS. fchk
Frank K. schrieb: > Der PIC braucht den MCLK nicht. BCLK geht an SCLK, LRCLK/FCLK an SS. Nö, aber der TLV320 braucht ihn, um seine Filter einzustellen. Markus schrieb: > Habe mir den angeschaut, da ist eine 3.5mm Buchse und ein Codec von > CIRRUS drauf. Der Cirrus CS43L22 auf dem dem F307 Disco Board ist ein reiner DAC und hat keine Eingänge. Dafür könntest du an den F407 einen ADC über den zweiten I2S andocken.
Matthias S. schrieb: > Frank K. schrieb: >> Der PIC braucht den MCLK nicht. BCLK geht an SCLK, LRCLK/FCLK an SS. > > Nö, aber der TLV320 braucht ihn, um seine Filter einzustellen. MCLK ist üblicherweise 64|128|256*fs. Nimm einen passenden Oszillator, hänge ihn an MCLK, betreibe den PIC als SPI Slave und Frame Slave und den Codec als Master, d.h. der erzeugt dann Bit und Frame Clocks. Problem gelöst. fchk
Frank K. schrieb: > Nimm einen passenden Oszillator, > hänge ihn an MCLK, betreibe den PIC als SPI Slave und Frame Slave und > den Codec als Master, d.h. der erzeugt dann Bit und Frame Clocks. > Problem gelöst. Ich verstehe ja, das du den PIC unbedingt retten willst, aber wenn da schon ein F407 mit 2 I2S Kanälen fertig rumliegt, ist der Aufwand für die MCLK einfach zu viel. Der F407 behandelt das alles mit links und kann nebenbei locker mit den Daten rumwurschteln, ohne das I2S davon aus dem Tritt gerät. Das funktioniert alles recht gut, habe vor einiger Zeit damit rumgespielt.
Matthias S. schrieb: > Frank K. schrieb: >> Nimm einen passenden Oszillator, >> hänge ihn an MCLK, betreibe den PIC als SPI Slave und Frame Slave und >> den Codec als Master, d.h. der erzeugt dann Bit und Frame Clocks. >> Problem gelöst. > > Ich verstehe ja, das du den PIC unbedingt retten willst, aber wenn da > schon ein F407 mit 2 I2S Kanälen fertig rumliegt, ist der Aufwand für > die MCLK einfach zu viel. > Der F407 behandelt das alles mit links und kann nebenbei locker mit den > Daten rumwurschteln, ohne das I2S davon aus dem Tritt gerät. Das > funktioniert alles recht gut, habe vor einiger Zeit damit rumgespielt. Das hat nichts mit dem PIC zu tun, der ist auch hinreichend leistungsfähig. Die Architektur spielt eigentlich hier auch nichts zur Sache. MCLK wird in realen Designs eigentlich nie direkt vom Prozessor generiert, sondern immer von einem Quarzoszillator. Sonst hättest Du Jitter, und den willst Du nicht, weil Du (oder der Kunde) den hören würdest. Und der Prozessor (egal welcher) braucht MCLK auch nicht, der ist nur für die digitalen Filter in den Codecs da. Auch das ist architekturunabhängig. fchk
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.