Hi,
ich habe hier einen PIC18, an den ist ein DAC per SPI (SDA/SCL an Port C
6/7) angeschlossen. Der DAC kann auf der SCL-Leitung Pulsweiten von 18
nsec, also einen Takt, der weit über dem maximalen Clock des PIC liegt.
Also initialisiere ich den EUSART im synchronen Modus folgendermaßen:
1
TRISCbits.TRISC6=1;//???
2
TRISCbits.TRISC7=1;//???
3
4
ANSELCbits.ANSC7=0;
5
ANSELCbits.ANSC6=0;
6
7
TXSTA1bits.SYNC=1;
8
TXSTA1bits.CSRC=1;
9
RCSTA1bits.SPEN=1;
10
RCSTA1bits.SREN=0;
11
RCSTA1bits.CREN=0;
12
13
TXSTA1bits.TXEN=1;
14
15
TXSTA1bits.BRGH=1;
16
BAUDCONbits.BRG16=1;
17
18
SPBRGH1bits.SPBRGH=0;// 15,9 MHz clock
19
SPBRG1bits.SPBRG=1;
Die Übertragung der Daten erfolgt dann auf diese Art:
1
PORTBbits.RB0=0;// /SYNC des DAC's auf 0
2
3
TXREG1bits.TX1REG=data[0];// Daten ins Senderegister
4
while(PIR1bits.TX1IF==0);// warten bis alles gesendet ist
5
TXREG1bits.TX1REG=data[1];
6
while(PIR1bits.TX1IF==0);
7
TXREG1bits.TX1REG=data[2];
8
while(PIR1bits.TX1IF==0);
9
10
PORTBbits.RB0=1;// /SYNC des DAC's auf 1
Trotzdem liefert der DAC nichts an seinem Ausgang. Da ich keinen
(Speicher)Oszi habe, der mit diesem Clock zurechtkommt: was könnte hier
falsch sein? Stimmt irgendwas mit meiner Initialisierung und
Datenübertragung nicht?
Satz K. schrieb:> ich habe hier einen PIC18, an den ist ein DAC per SPI (SDA/SCL an Port C> 6/7) angeschlossen.
Du schließt das SPI des DAC an EUSART des PIC an? SPI und UART sind
physikalisch verschieden. Ich kann mir nicht vorstellen, wie das
funktionieren soll.
Hat dein PIC18-Typ kein SPI Modul?
>Du schließt das SPI des DAC an EUSART des PIC an?
Natürlich tut er das. Das 'S' in EUSART steht für synchron.
Und das ist SPI. Ein UART kann kein SPI, ein USART schon.
Satz K. schrieb:> an den ist ein DAC per SPI (SDA/SCL an Port C 6/7) angeschlossen.
Die Bezeichnung SDA/SCL bringe ich eher mit I2C in Verbindung als mit
SPI.
Liegt da vielleicht ein Missverständnis vor?
>EUSART hat nichts mit SPI oder I2C zu tun.>Ganz einfach.
I2C nicht, aber SPI schon. Man muss dazu logischerweise
in der Lage dazu sein ein Datenblatt zu lesen und zu verstehen.
Das ist bei dir wohl nicht der Fall.
holger schrieb:> I2C nicht, aber SPI schon. Man muss dazu logischerweise> in der Lage dazu sein ein Datenblatt zu lesen und zu verstehen.> Das ist bei dir wohl nicht der Fall.
Kennst du den genauen Typ, den der TO benutzt? SPI liegt normalerweise
auf Pin 3 - 5 von PortC, I2C auf Pin 3 und 4.
@TO:
Deine Beschreibung ist wirr. Es ist nicht klar, ob du SPI, I2C oder eine
UART verwenden willst, deshalb:
- Welchen PIC verwendest du?
- Welchen Baustein möchtest du ansprechen?
- Schema?
holger schrieb:> Man muss dazu logischerweise> in der Lage dazu sein ein Datenblatt zu lesen
Anscheinend scheinst du nichts verstanden
zu haben.
TROLL.
Satz K. schrieb:> was könnte hier> falsch sein?
- SCK(?) Pin des DAC -> TX Pin des PIC (RC6)
- SDO oder MOSI Pin des DAC -> RX Pin des PIC, (RC7)
- Die Initialisierungssequenz ist im Datenblatt beschrieben - erst der
Baudraten Generator mit (SPBRGHx, SPBRGx, BRGH, BRG16) und dann den Rest
- schau mal ins Errata deines speziellen µC, ob zum EUSART irgendwelche
bekannten Bugs existieren
OK, um mal ein wenig aufzuklären: der DAC ist ein AD5663R, der will zur
Datenübertragung ein CLK und eine Datenleitung haben, das Datenbit wird
jeweils bei der fallenden CLK-Flanke übernommen. Das hätte ich jetzt für
SPI gehalten - ist aber auch egal, da der synchrone EUSART-Modus des
PIC18F23K22 meiner Meinung nach genau das passende Signal liefert.
Die /LDAC-Leitung des DAC halte ich ständig auf LOW, /CLR auf HIGH, SYNC
setze ich vor der seriellen Datenübertragung auf LOW, danach wieder auf
HIGH.
Die Übertragenen Daten sind jeweils 0x18, 0xLL, 0xHH bzw. 0x19, 0xLL,
0xHH (wobei LL und HH für Low/High-Byte stehen).
Satz K. schrieb:> das Datenbit wird> jeweils bei der fallenden CLK-Flanke übernommen.
Dafür sollte BAUDCON1bits.CKT1P = 1, Defaultwert ist 0 -> steigende
Flanke
Mir ist da einiges immer noch nicht klar ;-)
Warum nicht das SPI Modul benutzen?
Wie kommt man auf 15,9MHz Clock?
Werden die Bits/Bytes in der richtigen Reihenfolge gesendet?
(also alles vorher entsprechend umsortiert?)
Volker S. schrieb:> Warum nicht das SPI Modul benutzen?
Weil es mit dem EUSART genau so gut geht. Und wenn ich den SPI nehmen
würde, käme garantiert einer daher und würde fragen warum ich nicht den
EUSART verwende ;-)
> Wie kommt man auf 15,9MHz Clock?
64 MHz Systemclock, Baudratenzähler SPBRG auf 1, kleinster Teiler 4 (OK,
es sind eher 16 MHz).
> Werden die Bits/Bytes in der richtigen Reihenfolge gesendet?> (also alles vorher entsprechend umsortiert?)
Wieso sollte ich was umsortieren?
Was ist mit dem +1 in der Baudratenformel?
Ich dachte man müsse das umsortieren, weil die USART zuerst das LSB
(bit0) schickt und der DAC aber das MSB (bit23) erwartet. (kann mich
aber irgendwo verguckt haben)
Volker S. schrieb:> Was ist mit dem +1 in der Baudratenformel?
Das ist im Prinzip ziemlich egal. Der DAC kann >50 MHz Clock, da kann
ich vom PIC aus mit allem draufgehen, was er hat - und da ist es Wurst,
ob es 16 Mhz sind oder 15,9 MHz oder was auch immer, an das Maximum des
DAC kommt er eh' nicht ran.
> Ich dachte man müsse das umsortieren, weil die USART zuerst das LSB> (bit0) schickt und der DAC aber das MSB (bit23) erwartet. (kann mich> aber irgendwo verguckt haben)
Hmmmm, das hätte ich jetzt nicht gesehen, muss ich mir noch mal
anschauen...
Satz K. schrieb:> da ist es Wurst,> ob es 16 Mhz sind oder 15,9 MHz oder ...,
8MHz? Kann dir aber vermutlich wirklich egal sein ;-)
Das mit der Bit/Byte Reihenfolge eher weniger.
Bytes wären natürlich kein Problem aber bei den Bits scheint mir dann
doch SPI besser geeignet zu sein. (Falls ich mich nicht verg...)
