PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [ERLEDIGT] MCP3551 - AD Wandler liefert unverständliche Daten



Lutzacht
07.05.2014, 08:52
Hallo Jungs,
ich habe einen PIC16F1938 mit AD421 und MCP3551 kombiniert. Der 4-20 mA Ausgang mit dem AD421 lässt sich inzwischen einwandfrei ansteuern. Doch beim MCP3551 hakt es. Bei single conversion liefert er 01010101... usw. Bei continuous conversion sind es nur lauter Nullen. Mir ist das Ergebnis ein völliges Rätsel. Im Forum von Microchip komme ich auch nicht weiter. Kennt sich Jemand mit dem Teil aus? Hier ist der Code vom Auslesen:

BANKSEL APFCON
BCF APFCON,T1GSEL
BCF APFCON,SRNQSEL
BCF APFCON,C2OUTSEL
BCF APFCON,SSSEL
BCF APFCON,GIE
BCF APFCON,PEIE
BANKSEL ANSELA
BCF ANSELA,0
BANKSEL TRISC
MOVLW b'00010011' ; RC6+7 Output (nicht genutzt), RC 5 (SDO) Output, RC4 (SDI) Input, RC3 (SCK) Output, RC2 (SS) Output, RC1+0 (Eingang+-) Input
MOVWF TRISC
BANKSEL TRISA
MOVLW b'00000000' ; RA0 Output (SS), Rest nicht genutzt
MOVWF TRISA

BANKSEL PORTC
BSF PORTC,2 ; SS für MCP3551 auf high
BANKSEL SSPSTAT
MOVLW b'00000000' ; CKE auf 0, SMP auf 0 --- CKP muss dann auf 1 (mode 1,1)
MOVWF SSPSTAT
BANKSEL SSPCON1
MOVLW b'00110010' ; SSPEN und CKP auf 1, SPI Master mode, clock = FOSC/16
MOVWF SSPCON1
BCF SSPCON1,SSPEN
BSF SSPCON1,SSPEN

; Start der continuous Conversion und Verzögerung 20 ms

BANKSEL PORTC
BCF PORTC,2 ; SS für MCP3551 auf low


; Verzögerung 80 ms

CALL delay10ms ; 11 mal 10ms
CALL delay10ms
CALL delay10ms
CALL delay10ms
CALL delay10ms
CALL delay10ms
CALL delay10ms
CALL delay10ms
CALL delay10ms
CALL delay10ms
CALL delay10ms

; SS auf MCP3551 statt AD421 und Port einrichten
; Conversion ist abgeschlossen
Schleife0
; SPI auslesen

; erstes Byte

BANKSEL SSPBUF
BCF SSPSTAT,BF
BCF SSPCON1,WCOL
MOVLW b'00000000'
MOVWF SSPBUF ; startet Transfer 1. Byte
Schleife1 BTFSS SSPSTAT,BF ; Test ob erstes Byte gelesen ist
GOTO Schleife1
MOVF SSPBUF,W
MOVWF Daten+2 ; erstes Byte auslesen

; zweites Byte

BCF SSPSTAT,BF
BCF SSPCON1,WCOL
MOVLW b'00000000'
MOVWF SSPBUF ; startet Transfer 2. Byte
Schleife2 BTFSS SSPSTAT,BF ; Test ob zweites Byte gelesen ist
GOTO Schleife2
MOVF SSPBUF,W
MOVWF Daten+1 ; zweites Byte auslesen

; drittes Byte

BCF SSPSTAT,BF
BCF SSPCON1,WCOL
MOVLW b'00000000'
MOVWF SSPBUF ; startet Transfer 3. Byte
Schleife3 BTFSS SSPSTAT,BF ; Test ob drittes Byte gelesen ist
GOTO Schleife3
MOVF SSPBUF,W
MOVWF Daten ; drittes Byte auslesen

PICture
07.05.2014, 10:01
Hallo!

Ohne Programmablaufdiagram (PAD) kann ich keine Programme analisieren und deshalb könnte ich nur vermuten, dass das Auslesen richtigen Daten bei "continuous conversion" zu langsam ist. ;)

Lutzacht
07.05.2014, 10:41
Moin PICture,
Ich habe ja nur den Code-Schnipsel ins Netz gestellt, der den MCP ausliest. Das muss irgendwo das Kaninchen im Curry liegen. Der Rest des Programms ist getestet und funktioniert. Was meinst Du mit zu langsam?

PICture
07.05.2014, 11:07
Sorry, aber mit Dir kann ich nicht diskutieren, wenn bei Dir 80 ms = 11 mal 10 ms ist._.

Lutzacht
07.05.2014, 11:27
Nun - ich vergaß, den Kommentar zu ändern.

Lutzacht
11.05.2014, 09:23
Hallo Jungs,
die Ursache des Problems ist inzwischen klar. Der Master soll mit den beiden Slaves reden. Doch haben auch die beiden Slaves miteinander getuschelt. Grund war unsauberes Setzen der beiden CS.