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.
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.
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.
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.
