Ich suche einen möglichst bastelfreundlichen Controller, der eine audiotaugliche I2S Schnittstelle hat. Sonst braucht er nicht viel können, wenige Pins reichen. Mit meinen geliebten 8bit Atmels wird es wohl diesmal nicht reichen, weil der SSC nicht dafür taugt? Vielleicht den kleinsten AVR32, den AT32UC3B164, hätte den Vorteil daß ich meinen Debugger dafür verwenden kann. Habe aber noch kein Bastelmodul mit dem gefunden. Oder ein ARM, oder...?
@Jörg Also die ARMs sind denke ich dafür sehr gut geeignet. Ein SAM7S256 hat I2S mit drauf, kostet nicht viel, kann einiges und ist einigermaßen bastelfreundlich. Habe selbst schon ein bissl damit gespielt. Klappte so ziemlich auf Anhieb. Ist aber auch schon wieder was her wo ich damit rumprobiert hab, aber funktionieren tut es ohne weiteres.
du koenntest dir auch die dsPIC33F ansehen, die gibts sogar in 28pin DIP. Leider nicht ganz leicht zu bekommen, ich habe meine von Digikey aber ich denke man kann sie auch bei Farnell bestellen. Der DSPIC33FJ64GP802 hat zB 64kB Flash, 16kB Ram, i2s, dac, adc in einem 28pin dip/soic. Was er wirklich bringt kann ich noch nicht sagen, ich habe die mir einfach interessehalber einmal bestellt, da es mir die Features und die Gehaeseform recht angetan haben. ^^
> Sonst braucht er nicht viel > können, wenige Pins reichen. Was soll das ganze den werden? Ich meine du kannst die ganze Schnittstelle ja auch in Software machen. Und fallst du jetzt stoehnst das sei zu langsam, was kann man denn mit I2S machen woefuer so ein oller AVR schnell genug ist? Olaf
>Ich meine du kannst die ganze Schnittstelle ja auch in Software machen.
Das wage ich mal zu bezweifeln. Selbst wenn man nur 8kHz hat liegt die
Datenrate dennoch bei 2,048MHz, was zwar per HW-SPI zu schaffen ist,
aber die LRClk dürfte einem da einen Strich durch die Rechnung machen.
In Software würd ich sagen kannst du das ganze vergessen. So jedenfalls
meine Einschätzung. Und wenns dann auch noch CD-Qualität sein soll hast
du in SW gar keine Chance.
Hardware-SPI / Hardware-USI kannste doch verwenden, das einzige was du beim Datenschreiben machen musst ist die WS-Leitung toggeln.
Das soll schon nicht ganz so langsam werden, spricht deutlich gegen Bitbanging. Der Tipp mit dem dsPIC klingt ganz gut. Nik, leihst du mir deinen? ;-) Wie sieht's denn mit der Toolchain aus? Übliche DACs brauchen auch noch einen MCLK, z.B. 256*Fs, für ihre interne Signalverarbeitung oder so. I2S muß also voll synchron dazu laufen. Zweckmäßigerweise würde ich den MCLK auch als CPU-Clock nehmen (mit einem passenden Oszillator/Quarz). Jörg
Passt doch, nimm nen at tiny2313, den clockausgang als MCLK, Hardware-USI-Interface mit eingestellten Vorteiler, und im usi-complete-register immer das Wordselect toggeln. Dann läuft alles synchron und die (fast) nichts belastet die Rechenzeit des Prozessors. ;-)
>das einzige was du beim Datenschreiben machen musst ist die WS-Leitung >toggeln. Ganz so einfach ist das nicht. Gerade wenn man das Timing einfach halten will kommt es darauf an das die WS-Leitung synchron zum Bitclock ist, sonst erzeugt man sich Jitter bzw das Datenwort wird falsch übernommen. @Jörg Der dsPIC würde auch gehen. Hatte mal selbst vorgehabt damit was zu machen. Aber der ARM war zu verlockend :-) Und ich hatte nicht unbedingt Lust wieder Ewigkeiten auf der Suche nach ner IDE, nem Developmentboard und nem Programmer zu sein mal ganz abgesehen vom Geldausgeben :-)
Und ein AVR als I2S Slave? Der LRCLK geht auf einen Interrupt-Pin, Bitclock und Daten dann per HW-SPI...
@vorbeigeschaut Das geht. Das macht TravelRec in seinem Wave SD Karten Recorder mit XMega genauso. Nur da werden die Clocks eben von außen (bzw vom Wandler selbst) erzeugt und nicht vom uC. Edit: Der AVR macht aber dann auch nichts anderes außer die Daten in Empfang zu nehmen und an den XMega durchzureichen. Also mit Verarbeitung ist da nichts. Wenn es zur Verarbeitung von I2S unbedingt ein AVR sein muß und man eben mit 8kHz leben kann, kann man auch einen kleinen CPLD nehmen der I2S serialisiert/deserialisiert und dem AVR über ein paralleles Interface zur Verfügung stellt. Nur denke ich das der AVR dennoch recht beschäftigt ist wenn die Daten auch noch verarbeitet werden sollen.
Ich habe zu dem Thema DAC/I2s an ATmega gerade noch was gefunden, scheinbar hat Elmchan mal wieder was wahnsinniges gebaut ;-) http://elm-chan.org/works/pcmp/report.html Zitat:
1 | DAC controls |
2 | |
3 | The software DAC control is the main feature in this project. The sampling clock (LRCK) is generated with PWM function of TC1. The audio data is sent via USART1 configured in SPI mode. When LRCK is low, the left sample is sent to the DAC, and vice versa. Two separated interrupts are generated on both edge of the LRCK and each ISR reads audio data from data FIFO, mix beep sound (if it in sound) and send it to the USART1. These background processes occupy the CPU power of about 3.8MHz at sampling rate of 48kHz. The left processing power for the main process is about 11MHz. Some CPU registers are reserved for the background process so that it must be declared in all modules. |
Nik Bamert schrieb: > Ich habe zu dem Thema DAC/I2s an ATmega gerade noch was gefunden, > scheinbar hat Elmchan mal wieder was wahnsinniges gebaut ;-) > > http://elm-chan.org/works/pcmp/report.html Abgefahren! Das werde ich mir mal genauer anschauen, danke! ATmega hat den Vorteil, daß ich die Tools schon habe. Im Hinblick auf dsPIC habe ich am Wochenende erfolglos auf einen MPLAB ICD 3 geboten... Jörg
Bitte 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.