Ich versuche seit Stunden einen AC97 Codec am DCI eines dsPIC30F4013 zum Laufen zu bekommen. Der dspic wird mit 117MHz getaktet und läuft. Das DCI wird initialisiert (die Ausgänge gehen auf Low, die Eingänge auf tristate), der AC97 Codec (ein WM9701) liefert den 12,288MHz Bittakt, nur der dspic reagiert nicht auf diesen Takt. Es werden also keine FrameSync Signale erzeugt und keine Daten übertragen. Wenn ich den Bittakt auf intern umschalte, erzeugt der dspic den Bittakt, Framesync und überträgt Daten. Die Initialisierung müsste also passen, aber wieso arbeitet der dspic nicht mit externem Takt ?
"Der dspic wird mit 117MHz getaktet und läuft" Die 117MHz werden über die interne PLL erzeugt, nehme ich an, da die maximale externe Frequenz (aus external clock (EC) 40MHz sind), oder ? ! Gerhard
Ja, der Quarz hat 22,1184MHz. Der PLL ist auf HS/3 * 16 eingestellt. Das ergibt etwa 29,5MIPs. Bei diesem Takt dürften auch die 12,288MHz des AC97 Codec nicht zu schnell sein.
War nur ne Idee. Mit Codec hab ich noch nix gemacht. Kennst du die PIC Foren www.fernando-heitor.de oder http://forum.microchip.com ?
Damit hatte ich auch Probleme, der Bittakt des Codecs muß synchron mit dem Takt des dsPICs sein sonst gibts Probleme. Ich hatte seinerzeit dann einfach ein Quarzoszillator genommen, der sowohl den dsPIC als auch den Codec mit Takt versorgt.
Am Bittakt scheint es nicht zu liegen, ich hatte hier auch schon ein 1MHz Signal eingespeist, aber auch da funktionierte es nicht.
Hallo, wurde das Problem je gelöst ? Ich benutze den DCI eines dsPIC30F4013 im IIS Frame Sync Mode, CSCK & COFSD = Input, DJST = 0, Frame länge = 1 Wort. CSDO wird 0, Eingänge werden Tristate, Clock, CSDI und Frame Impuls liegen an trotzdem keine Datenausgabe auf CSDO Auch wenn DLOOP = 1 wird CSDI nicht an CSDO durchgereicht. Der dsPIC bekommt einen 4.096 Mhz Takt mit ECIO *4 (16,384Mhz) Der IIS Codec bekommt den gleichen 4Mhz Takt *3 (12,288Mhz) Der Bittakt beträgt 512Khz Mein Hardwaredesign läßt keinen Masterbetrieb des dsPIC zu, deswegen ist das noch ungetestet. Hat hier jemand den DCI des dsPIC30F4013 überhaupt schon mal im Slave Mode zum laufen gebracht ? Wenn ja, welche Chip Revision ? Ich habe hier die Rev A1 Für den großen Bruder, den dsPIC30F6013 beschreibt das Errata Sheet eine Fehlfunktion (keine Details) des DCI im beschriebenen Slave Betrieb wenn Framelängen > 1 Wort eingestellt sind. Für den 4013 ist nichts dergleichen beschrieben.
Ich habe es am Ende aufgegeben und habe dann einen I2S DAC und den internern ADC verwendet. Das DCI lief dann aber im Master Mode.
Bei mir: Master & slave Mode, Senden ok, Empfang = 0 ! Dieser Fehler ist seit dem 17.Jan.2006 bei Microchip bekannt, nur das der Microchip Tech. Support nichts davon weiß. Ebensowenig wie die aktuelle Errata, Family Reference, dsPic30F4013 Datasheet, der neue MPLAB C30 Compiler V2.05, die Language tools libraries oder, oder, oder. Kursieren tut die Lösung im Microchip Forum und als Beispielcode unter dsPic Code Examples auf der Web Site. Das Geheimniss ist das der DCI gemeinsam mit dem AD Konverter genutzt wird und nicht die Kontrolle über den CDI erlangt, wenn nicht der AD Pin auf Digital In gestellt wird. Über den Rest seiner Pins kann er aber anscheinend trotzdem frei verfügen was die Sache natürlich undurchschaubar macht. Die Fam. Ref ist ja auch nur 772 Seiten lang + das Datasheet mit 220 Seiten . Ich währe da schon irgendwann drauf gekommen wenn ich das Geraffel von Anfang bis Ende durchgelesen hätte. Hab ja auch sonst nichts zu tun. ADPCFG |=0x0F00; // ist die Lösung Das witzige war, sobald ich in den Debug Modus gewechselt bin, mit dem ICD2 als Debugger, war der Fehler weg. Auch dieses Verhalten hat sich der Tech. Support nicht die Mühe gemacht mir zu erklären. Hab ich einen Hals..... @benedikt Danke für Deine Antwort, ich dachte schon ich würde es als einziger nicht raffen...
Danke für diese Lösung. Ich werde es mal ausprobieren. Je mehr ich mit den dsPICs arbeite, desto schlechter finde ich sie. Soviele Bugs in den Controllern und den Entwicklungstools findet man selten.
Ein Fehler kommt selten alleine... ADPCFG = 0x1E00; Sonst ist AN8 auf Dig Input statt COFS, d.h. der slave frame geht nicht. Bei einem sich dem slave frame modus verweigernden SPI Bus könnte das setzen von AN2 auf Dig. In auch helfen. Ich hab zwar schon alles umgestrickt weil der Mist nicht lief, aber versuchen werde ich das auch noch mal. Mit Deiner Aussage hast Du zwar völlig recht, aber wenn denn irgendwann einmal alle Bugs raus, bzw. wenigstens vernünftig dokumentiert sind, und die dsPics die Stabilität eines 8031 erreicht haben, kommt das der eierlegenden Wollmilchsau ziemlich nahe. Die Typenvielfalt sucht man woanders vergebens und das Preis- Leistungsverhältniss würde stimmen, wenn man nicht so eine elendig lange Zeit mit Fehlersuche verbringen könnte.
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.