Hallo, ich hab da ein Problem mit der Ansteuerung des PCM5142 http://www.ti.com/lit/ds/symlink/pcm5142.pdf Seite 75 ich wollte testweise nur in das Register 3 von page 0 den Wert 0x11 schreiben! (Was da heißt linker und rechter Kanal stumm!) dann wollte ich den soeben geschriebenen Wert zurücklesen? leider bin ich nicht ganz sicher, wie das geht! mache das zurzeit über polling der zurückgelesene Wert liegt immer bei 0xFF? Sind denn meine SPI-Einstellungen korrekt? machen ich mit SPI-Lesen im Master-Mode eine Fehler? wäre für ein paar Tipps sehr dankbar! dann wollte ich das später mit Interrupts machen!
Ok habe gemerkt, dass ich mit meinem Atmega den PCM5142 mit 5V High-Pegel ansteuere! Der PCM5142 ist aber nur für LVTTL ausgelegt! max. Eingangspegel --> 3,9V Ich steuere allerdings mit 4,8V an!!! wie wahrscheinlich ist es, dass der PCM5142 nun defekt ist? mir fällt gerade keine Möglichkeit ein, dass herauszufinden? Der PCM5142 antwortet auf jeden Fall nicht auf das SPI MISO-Leitung bleibt auf low-Pegel!! und SPDR ist somit 0xFF!!!!
Atmega-Verleger schrieb: > wie wahrscheinlich ist es, dass der PCM5142 nun defekt ist? Nimm eine Standardabweichungskurve und lege sie über eine Skala von 0 - 100% Defektwahrscheinlichkeit. Den Mittelpunkt der Kurve würde ich willkürlich mal auf 60% setzen, Sigma auf etwa 40% festlegen. Jetzt hast du eine Wahrscheinlichkeitsverteilung, die das vieleicht ausdrückt.
So jetzt bin dort doch schon mal systematischer vorgegangen! Meine Schaltung sowie mein Programmer laufen jetzt komplett mit LVTTL also 3,3V Pegel. Ausserdem habe ich einen neuen PCM5142 aufgelötet! Der Baustein antwortet leider immer noch nicht der MOSI bleibt auf GND! http://www.ti.com/lit/ds/slas759a/slas759a.pdf wie man Seite 69 und Seite 75 entnehmen kann soll der Zugriff auf den PCM5142 wie folgt gemacht werden (wenn ich das so richtig verstanden habe!) also Übertragenes Wort ist: IDX6_IDX5_IDX4_IDX3_IDX2_IDX1_IDX0_RW_D7_D6_D5_D4_D3_D2_D1_D0 IDX -> register no. rw -> lesen oder schreiben D -> Daten wenn ich in register3 auf page0 schreiben möchte also ins "mute register"! Sende ich an den PCM via SPI: IDX = 0; rw = 0 also erstes Byte -> 0x00 D = 0; also zweites Byte -> 0x00 Also Wechsel auf page0 dann IDX = 0d3 (register3) rw = 0 also erstes Byte -> 0x06 D = 0x11 (wert, der in reg3 geschrieben werden soll) also zweites Byte -> 0x11 dann möchte ich überprüfen, ob auch tatsächlich in das reg3 auf page0 geschrieben wurde: also IDX = 0; rw = 0 also erstes Byte -> 0x00 D = 0; also zweites Byte -> 0x00 Also Wechsel auf page0 dann IDX = 0d3 (register3) rw = 1 (jetzt lesen) also erstes Byte -> 0x07 D = 0x00 (irgendein Wert, auf SPI muss geschrieben werden, um zu lesen) also zweites Byte -> 0x00 jetzt sollte vom MOSI gelesen worden sein Das Lesen vom Mosi klappt auch, jedoch ist der immer auf Vcc!!! Ist das Prinzip des Zugriff auf den PCM5142 überhaupt so, wie ich es gerade angedeutet habe? Wie, wenn anders? Achso die Datei "pcm_access.c" enthält nur den Aufruf der SPI-Funktionen und das Laden mit den Werte, für den Zugriff, wie ich ihn soeben erläutert habe! Ich hoffe ich kann diesen Thread so doch noch in eine ernsthaftere Richtung lenken ;)
Atmega-Verleger schrieb: > Ausserdem habe ich einen neuen PCM5142 aufgelötet! > Der Baustein antwortet leider immer noch nicht der MOSI bleibt auf GND! Und du bist sicher, dass du ihn für den SPI-Mode richtig verdrahtet hast. Sonst wäre jetzt ein toller Zeitpunkt, um den Schaltplan zu präsentieren.
Zunächst vorneweg: Atmega-Verleger schrieb: > jetzt sollte vom MOSI gelesen worden sein > > Das Lesen vom Mosi klappt auch, jedoch ist der immer auf Vcc!!! MOSI... Master Out, Slave In MISO... Master In, Slave Out Das was Du von Deinem Slave wissen möchtest, kommt also über die MISO-Leitung. Ist aber hier jetzt nicht so wichtig, da sowohl Ein- als auch Ausgang über das Register SPDR erfolgen. Was mir an Deiner Funktion avr_spi_read_reg aufgefallen ist:
1 | // read content of PCM5142 register an store it to second byte of (spi_data[])
|
2 | void avr_spi_read_reg(char *spi_data) |
3 | {
|
4 | SPDR = spi_data[0]; |
5 | while(!(SPSR & (1<<SPIF))); |
6 | spi_data[1] = SPDR; |
7 | SPDR = 0x00; // dummy read for reading from SPI MISO |
8 | while(!(SPSR & (1<<SPIF))); |
9 | }
|
Diese speichert das erste vom Slave übertragene Byte in spi_data[1]. Gemäß Datenblatt S.70 wird die Antwort des PCM aber im zweiten Byte übertragen.
Setzt du das CS selbst oder macht das der µC für dich? Soweit ich weiß sendet der nur 8 bit und setzt dann das CS wieder zurück. Der DAC will aber mehr als nur 8 bit mit einmal. Daher wirst du das CS selbst setzten und zurück setzten müssen.
Angehängte Dateien:
-
pcm5142_eagle.png
14 KB -
atmega8_eagle.png
16 KB
So ich hoffe man kann mit dem Auszug aus Eagle etwas anfangen! Das Layout zu posten macht wohl wenig Sinn?
J.-u. G. schrieb: > Was mir an Deiner Funktion avr_spi_read_reg aufgefallen ist:// read content of PCM5142 register an store it to second byte of (spi_data[]) > void avr_spi_read_reg(char *spi_data) > { > SPDR = spi_data[0]; > while(!(SPSR & (1<<SPIF))); > spi_data[1] = SPDR; > SPDR = 0x00; // dummy read for reading from SPI MISO > while(!(SPSR & (1<<SPIF))); > } > Diese speichert das erste vom Slave übertragene Byte in spi_data[1]. > Gemäß Datenblatt S.70 wird die Antwort des PCM aber im zweiten Byte > übertragen. d.h. ich muss das in einer anderen Reihenfolge machen? etwa so??? > SPDR = 0x00; // dummy read for reading from SPI MISO > while(!(SPSR & (1<<SPIF))); > spi_data[1] = SPDR; trotzdem bleibt der MISO aber die ganze Zeit auf Vcc!
Christian D. schrieb: > Setzt du das CS selbst oder macht das der µC für dich? Soweit ich weiß > sendet der nur 8 bit und setzt dann das CS wieder zurück. Der DAC will > aber mehr als nur 8 bit mit einmal. Daher wirst du das CS selbst setzten > und zurück setzten müssen. Ich werde mal schauen also mit dem Oszi, ob der CS /SS bzw. MS gesetzt wird! ich schalte /SS als OUTPUT! dann sollte der Atmega auch im SPI-Master-Modus laufen? Den Mode1-Pin (PB0) vom PCM5142 setze ich in void avr_spi_master_init(void) auf HI-Pegel, so dass der PCM im SPI-Mode sein sollte? Hatte vorhin vergessen, die Funktionsaufrufe also "pcm_access.c" anzufügen. Ist nur ein Auszug!
Atmega-Verleger schrieb: > Ich werde mal schauen also mit dem Oszi, ob der CS /SS bzw. MS gesetzt > wird! Nein, für das High- bzw. Low-Setzen des SS musst Du schon alleine sorgen. Woher soll der µC denn von selbst wissen, welchen Slave (es lassen sich ja mehrere an einem SPI-Interface betreiben) Du nun ansprechen möchtest? Du musst also am Beginn der read- und send-Funktonen den SS-Pin, an dem der PCM engeschlossen ist, auf "low" setzen und am Ende der Übertragungen auf "high". Atmega-Verleger schrieb: > trotzdem bleibt der MISO aber die ganze Zeit auf Vcc! Kein Wunder, wenn der PCM nicht per SS ausgewählt wurde, verhält er sich passiv.
J.-u. G. schrieb: > Kein Wunder, wenn der PCM nicht per SS ausgewählt wurde, verhält er sich > passiv. so bin nun dazu gekommen, es auszuprobieren! den /SS-Pin setze ich nun jedes Mal auf low vorm Lesen/Schreiben und danach wieder auf high. Der PCM antwortet mir leider immer noch nicht? Frage mich nun, an welcher "Schraube" ich nun noch drehen kann?
Atmega-Verleger schrieb: > den /SS-Pin setze ich nun jedes Mal auf low vorm Lesen/Schreiben und > danach wieder auf high. > Der PCM antwortet mir leider immer noch nicht? Empfängt der µC nichts oder sendet der PCM gar nicht (Du wolltest doch mit dem Oszilloskop die SPI-Leitungen überprüfen)? Hast Du Deine SPI-Empfangsroutine angepasst?
Atmega-Verleger schrieb: > Den Mode1-Pin (PB0) vom PCM5142 setze ich in void > avr_spi_master_init(void) > auf HI-Pegel, so dass der PCM im SPI-Mode sein sollte? Nö. Der Mode muß hart verdrahtet werden, da der Chip den Mode beim Reset einliest und danach nicht mehr verändern kann. Der PCM4152 hat nur einen Power-On-Reset, daher muß beim Power-Up des Chips der Mode festliegen. Der MODE1 Pin braucht also für SPI 'nen Pullup nach DVDD und keinen Port-Pin vom µC. Der kommt viel zu spät, es sei denn, der µC schaltet die Betriebsspannung des PCM auch erst per Software an. Gruß, Thosch
J.-u. G. schrieb: > Empfängt der µC nichts oder sendet der PCM gar nicht (Du wolltest doch > mit dem Oszilloskop die SPI-Leitungen überprüfen)? > > Hast Du Deine SPI-Empfangsroutine angepasst? Ja ich setze jetzt natürlich entsprechend den SS-Pin! Und ja der SPI sendet.... es kommt auf der MISO-Leitung nichts bleibt auf high? Ich habe jetzt auch mal den System-Clock für den PCM angeschlossen --> 50MHz sollte aber egal sein, da der SPI für die Konfiguration des PCM asynchron läuft!
Thosch schrieb: > Der MODE1 Pin braucht also für SPI 'nen Pullup nach DVDD und keinen > Port-Pin vom µC. Der kommt viel zu spät, es sei denn, der µC schaltet > die Betriebsspannung des PCM auch erst per Software an. Ok also nächste Verbindung über Silberlackdraht! klingt plausibel! DANKE!! wird umgehend ausprobiert!
Atmega-Verleger schrieb: > Ok also nächste Verbindung über Silberlackdraht! klingt plausibel! > DANKE!! wird umgehend ausprobiert! OK cool jetzt funzt es. hmmh sobald man es richtig macht, läuft's!
Atmega-Verleger schrieb: > OK cool jetzt funzt es. fein! Danke für die Rückmeldung. Freut mich, daß ich weiterhelfen konnte. > hmmh sobald man es richtig macht, läuft's! LOL, ja so ist das immer. Wenn man bloß schon in dem Moment wüßte, wo man's falsch macht, was man falsch macht... ;-)
Hmmh nun habe ich doch noch mal dazu ein Problem! an Pin 20 des PCM5142 führe ich extern denn Takt hinzu (SCK) 50MHz von nem FPGA-Board bzw. jetzt 1 bis 5MHz aus nem Funktionsgenerator! Zurzeit setze ich einige Register zur Konfiguration und lese die geschriebenen Werte zurück! Leider werden fs und das SCK ratio nicht eingestellt! das Register 91 (auf Seite 99) enthält den Wert 0x00! Wichtig scheint mir auch das Register 94 das mir den "clock detector status angibt! (auf Seite 100) Ich habe mich schon bei der Erstellung einiger Konfigurationsfunktionen gefragt, warum dieses Register 7bits enthält, die den Status anzeigen? In der Beschreibung steht schließlich nur, dass der Wert"0" sagt SCK ist da und "1" sagt SCK fehlt! Ich lese dieses Register und habe immer den Wert 0x67??? weiss nicht, was mir das sagt, der Wert bleibt unverändert, egal, ob ein Takt an Pin 20 ist oder nicht!? http://www.ti.com/lit/ds/slas759a/slas759a.pdf
Atmega-Verleger schrieb: > Ich lese dieses Register und habe immer den Wert 0x67??? weiss nicht, > was mir das sagt, der Wert bleibt unverändert, egal, ob ein Takt an Pin > 20 ist oder nicht!? ok habe gemerkt, dass bei sck fehlt oder 3,5MHz der Wert 0x6F in diesem Register steht. Bei SCK = 50MHz ist der Wert 0x2F! keine Ahnung was mir das sagen soll hmmh?
Hmm, warum tust du dir das an, mit einem Nicht-Standard Systemtakt arbeiten zu wollen? Dann mußt Du die gesamte PLL händisch aufsetzen und dabei gibts einige Randbedingungen zu beachten... (Datenblatt S.25 ff) Gib dem Teil doch einen normalen Audio-Master-Clock von z.B. 24,576 MHz damit gehen alle professional-Audio Raten (48 kHz und Vielfache). Und vergiß den Funktionsgenerator als Taktquelle! Die Taktquelle muß ein jitterarmer Quarzoszillator sein. Wenn ich das Datenblatt richtig verstehe, dann ist es ggf. das einfachste, wenn man SCK, BCK und LRCK passend für die gewünschte Samplerate liefert (alles synchron zu SCK) und die PLL durch PLLEN=0 abschaltet. Den SCK brauchst du ja sowieso als Takt für die Signalverarbeitung im FPGA, da ist es nicht weiter schwierig, BCK und LRCK gleich damit zu erzeugen und zusammen mit den Daten an den PCM auszugeben.
Angehängte Dateien:
-
bck_25MHz_by_fpga.png
7,1 KB -
sck_50MHz_by_fpga.png
8,3 KB
Thosch schrieb: > wenn man SCK, BCK und LRCK passend für die gewünschte Samplerate liefert > (alles synchron zu SCK) und die PLL durch PLLEN=0 abschaltet. OK ich habe über Register 0x04 Page0 die PLL disabled also PLLE = 0! Ich muss doch nicht wirklich exakt 49,1520MHz als SCK liefern? also zurzeit habe ich hier ein FPGA-Board, dass mit 50Mhz getaktet ist. Diesen Systemtakt gebe ich aus und auf den SCK-Pin des PCM5142 (Pin20). den BCK habe ich zu 25MHz gesetzt, dieses Signal gebe ich auf den Pin 21 des PCM5142. (Siehe Seite 36 I2S Slave Timings!!) den LRCLK habe ich noch nicht generiert, wäre dann aber doch: BCK geteilt durch (gewählte Datenwortbreite (16,20,24 oder 32bit)*2) also LRCLK = BCK/(DATA_width*2)? Ich habe mal zwei Oszillogramme also BCK und SCK angefügt! Sehen schon ziemlich "unschön" aus!!!
Thosch schrieb: > Den SCK brauchst du ja sowieso als Takt für die Signalverarbeitung im > FPGA, da ist es nicht weiter schwierig, BCK und LRCK gleich damit zu > erzeugen und zusammen mit den Daten an den PCM auszugeben. Ahh ok du meinst, ich solle mir nen Quarzoszillator z.B. 24,576 MHz oder 49,1520MHz holen, mir so den SCK generieren, diesen SCK an Pin 20 vom PCM5142 legen, diesen SCK auch über ein Pin/Kabel an mein FPGA-Board führen, diesen SCK auch in meinen VHDL-Modulen als CLK verwenden? in meinen HW-Modulen BCK und LRCK generieren und zurück (über Kabel) an den PCM5142 (Pin21 und Pin23) zurückführen? Thosch schrieb: > Hmm, warum tust du dir das an, mit einem Nicht-Standard Systemtakt > arbeiten zu wollen? Dann mußt Du die gesamte PLL händisch aufsetzen und > dabei gibts einige Randbedingungen zu beachten... (Datenblatt S.25 ff) Ok nun nochmal zum Verständnis ein Zitat aus dem Datenblatt: "SCK rates that are not common to standard audio clocks, between 1MHz and 50MHz, are only supported in software mode by configuring various PLL and clock-divider registers." Also kann ich das so verstehen, dass dieser "clk auto set mode" nur funktioniert, also sck erkannt werden kann, wenn SCK ziemlich genau eine Frequenz aus "Tabelle 6" ist? und alles weitere von diesem Takt abgeleitet wird? Mit meinen 50MHz vom FPGA bin ich dann also 848kHz zu flott für die automatische Erkennung am PCM5142? Hmmh testweise 49,152MHz von 50MHz ableiten mal schauen, ob das geht!?
Thosch schrieb: > Gib dem Teil doch einen normalen Audio-Master-Clock von z.B. 24,576 MHz > damit gehen alle professional-Audio Raten (48 kHz und Vielfache). Hmmh kann ich z.B. diese Oszillatoren nehmen: http://de.farnell.com/txc/7w-49-152mbb-t/osc-49-152mhz-3-3v-smd-7-0x5-0/dp/1842142 oder http://de.farnell.com/txc/7c-24-576mba-t/osc-24-576mhz-3-3v-smd-5-0x3-2/dp/1842028RL Haben beide 'ne "rise time" von 10ns und "fall time" von 7ns!!? der PCM5142 benötigt aber jeweils High und Low Zeit von minimum 9ns bei DVDD=3,3V!!! (Seite 22 Tabelle7 Datenblatt!)
OK habe jetzt mal verglichen: Hatte einen Funktionsgenerator dran! Der hat ne rise/fall time von typischerweise 100ns und ein Jitter von <25ns Quarzoszillatoren haben dagegen rise/fall times von 3 bis 9ns und jitter im Bereich von max. 3 bis 10ps ---> da liegt, dann wohl das Problem beim Funktionsgenerator mit einem um Faktor 2500 bis 8333 höheren jitter???? Also Quarze mal ausprobieren!
ähm, mal im Ernst... womit hast Du die Oszillogramme aufgenommen? Welche Samplerate, welche Analog-Bandbreite? Das sieht mir ja eher danach aus, als hättest Du ein Sinus-Signal von +/-5 V versucht, dem armen PCM als Takt vorzusetzen?! Oder Dein Oszi hat 'ne viel zu geringe Bandbreite... Nur mal zur Erinnerung: Der PCM5142 ist ein low-Voltage-Chip! Kein Eingangssignal darf kleiner 0V oder größer als DVDD sein, und DVDD ist maximal 3,3V. Kein Wunder, daß Dein "Taktsignal" verzerrt aussieht, wenn Du versuchst, da 'nen 5V-Sinus einzuspeisen. Atmega-Verleger schrieb: > Haben beide 'ne "rise time" von 10ns und "fall time" von 7ns!!? > > der PCM5142 benötigt aber jeweils High und Low Zeit von minimum 9ns bei > DVDD=3,3V!!! > (Seite 22 Tabelle7 Datenblatt!) jo, da steht auch: Cycle-time min 20ns d.h. bei 50MHz darf die rise/fall time jeweils nur max. 1ns betragen, da mindestens 9ns high-time und low-time gebraucht werden. Bei niedrigeren Taktraten entspannt sich die Situation dann etwas, aber 7-10ns rise/fall Time erscheint mir arg langsam, so schlappe Flanken sollte ein Taktsignal von rund 25MHz besser nicht haben...
Thorsten S. schrieb: > ähm, mal im Ernst... > womit hast Du die Oszillogramme aufgenommen? Welche Samplerate, welche > Analog-Bandbreite? Mit nem TEktronix Oszi mit 100MHz sample rate!!!! Das mit der Amplitude von 5 V kann auch nicht stimmen, denn der FPGA läuft eigentlich auch nur mit LVTTL! Thorsten S. schrieb: > jo, da steht auch: Cycle-time min 20ns > d.h. bei 50MHz darf die rise/fall time jeweils nur max. 1ns betragen, da > mindestens 9ns high-time und low-time gebraucht werden. Bei niedrigeren > Taktraten entspannt sich die Situation dann etwas, aber 7-10ns rise/fall > Time erscheint mir arg langsam, so schlappe Flanken sollte ein > Taktsignal von rund 25MHz besser nicht haben... hab jetzt einige Quarze bereit liegen und ich werde die dann mal ausprobieren! Einige sind auch deutlich schneller als 7-10ns !!! und der Jitter ist auch nur bei< 3ps!!! zum Vergleich Funktionsgenerator <20ns oder so!
Hab nun eine low jitter Quarz mit 24,576MHz Resonanzfrequenz dran! Das Problem ist, das wenn ich den Quarz in der Schaltung habe, das Signal total verzerrt.... und das Signal hat "Überschwinger" zwischen -2V und +5V ich kann mir das nicht erklären, schließlich ist dieser komplette Schaltungsteil komplett auf LVTTL???
Hallo Atmega-Verleger. woher bekommst du nur diese vielen Frage- und Ausrufungszeichen? Vielleicht solltest du dich weniger aufregen, dann klappt es auch. Q. Mark
Q. Mark schrieb: > woher bekommst du nur diese vielen Frage- und Ausrufungszeichen? > Vielleicht solltest du dich weniger aufregen, dann klappt es auch. Die gibt's hier gerade im Angebot. Nein aber mal im 'Ernst also dass ich nichts ordentliches messe liegt dann wohl an der Ausgangskapzität des Quarzes die bei ca.15pF in diesem Bereich liegt dann auch die des Tastkopfes! Das ist ein Problem. Außerdem ist es ein Problem, dass ich den Quarz über Kupferlackdraht angebunden habe? Oder verstehe ich es falsch und der PCM5142 benötigt für die automatische Konfiguration auch noch den Bit-Takt, BCK?
hmmh mein FPGA Akzeptiert jedenfalls den Takt als Eingangstakt... also irgendwas am PCM5142 bzgl. auto set clock?
Ungeduld ist kein guter Helfer! Nun habe ich es endlich geschafft! Der PCM5142 erwartet im Slave-Mode natürlich mindestens die Signale: SCK, BCK und LRCK (BCK und LRCK von SCK abgeleitet also in Phase!) anhand dieser Signale konfiguriert er sich dann ganz automatisch. Endlich ist Licht im Dunkeln.
Atmega-Verleger schrieb: > Der PCM5142 erwartet im Slave-Mode natürlich mindestens die Signale: > SCK, BCK und LRCK (BCK und LRCK von SCK abgeleitet also in Phase!) > anhand dieser Signale konfiguriert er sich dann ganz automatisch. Ich will ja nicht meckern, aber das hättest Du eher haben können, da ich Dir bereits am 27.02. schrieb: > Wenn ich das Datenblatt richtig verstehe, dann ist es ggf. das > einfachste, > wenn man SCK, BCK und LRCK passend für die gewünschte Samplerate liefert > (alles synchron zu SCK) und die PLL durch PLLEN=0 abschaltet. Hast Du vor lauter Ungeduld wohl überlesen... ;-) Egal, Hauptsache, der Knoten ist jetzt geplatzt und der Chip funzt.
Thorsten S. schrieb: > Hast Du vor lauter Ungeduld wohl überlesen... ;-) > Egal, Hauptsache, der Knoten ist jetzt geplatzt und der Chip funzt. Ja jetzt habe ich nur noch ein kleines Problem mit den Audiodaten: Aber das nur ganz kurz ich werd mich morgen mal näher damit befassen. Als hab den Chip nun ja mit SCK = 49,152MHz BCK = 24,576MHz und LRCK = 384kHz fs to SCK ratio liegt bei 128 Also die Daten auf DIN sind doch ähnlich wie beim einfachen SPI der MOSI also ich liefere Daten d.h. DIN wird vom PCM5142 auf der Flanke des BCK abgetastet? Testweise geben ich dann also einmal "High-Pegel" danach 31Bit low-Pegel (ich betreibe das Gerät im 32 Bit-Modus pro Kanal) also 0x8FFFFFFF das entspricht dann ja eigenltich (2^(32-1))-1? am Ausgang ist aber keine Spannung zu messen! Toggle ich nun die Daten an DIN z.B. mit BCK/2 dann habe ich je nach führenden Bit 2V bzw. -2V am Ausgang! Aber ich denke, dass kriege ich schon noch hin! Schönen Abend allen!
Jo Problem gelöst! Über ein einfaches SPI-Modul (in VHDL) bei 32Bit liegt der Ausgangswert zwischen ca. 1,4V und -1,4 V also 2,8V (peak to peak) entspricht unter der Annahme eines Sinussignals ca. 2V (rms) Ausgabe Wert für 1,4V ist x"40000000" statt x"7FFFFFFF" (wie urpünglich angenommen! für -1,4V ist es (Zweier-Komplement-Darstellung) 0x"C0000000" statt x"80000000" (wie urspünglich angenommen!)
Hmmh komme nun noch ein weiteres Mal draufzurück! Also ich habe auf meinen Ausgangssignalen immer ein überlagertes Signal von ca. 50 MHz, das einfach nicht wegzubekommen ist? sobald ein Takt auf der Platine ist meine Betriebsspannungs überlagert. Ich habe jetzt auch gemerkt, dass der PCM5142 auch mit dem internen 50MHz Takt des FPGA-Boards läuft aber dieses "Rauschen" koppel ich mir immer auf die Betriebsspannung! Nun habe ich sukzessive alle sich ändernden Signale, die ich am FPGA-Board generiere abgeschaltet. erst wenn ich alle Signal fest auf '1' bzw '0' gesetzt habe ist keine Kopplung auf der Betriebsspannung. Sogar, wenn ich nur DIN auf der Platine habe habe ich noch ca. +/- 200mV überlagert! Wenn sich nichts ändert ist es natürlich klar, dass kein Übersprechen stattfinden kann, aber ich habe keine Ahnung, ob ich mir das Übersprechen auf den verhältnismäßig langen Signalwegen auf der Platine oder erst am PCM5142 hole (ob der vielleicht schon "einen" mitbekommen hat??)
Die Überlagerung hole ich mir von der Platine! Habe den PCM5142 mal ausgelötet und ziehe mir, wenn ich Signal über den FPGA aufs Board die Störungen rein! Wie kann ich das bloß sinnvoll entkoppeln? Hab in dem Bereich einfach mal keine Erfahrung!
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.