Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > Hallo, > > meine Vermutung das sich die Bitfehler während der sequentiellen Übertragung einschleichen hat > sich leider nicht bestätigt. Es kommt noch viel schlimmer, der AD-Wandler selbst gibt die > falschen Wandlerwerte aus. > > Als erstes habe ich versucht die gesamte Wandler-Routine in Assembler zu schreiben, > da sich hier der Interrupt sperren lässt und ich hierin den Fehler vermutete. > Die Routine hab ich von "schnelles SPI" abgeleitet. > > <asm> > > $segmented > $model(medium) > $extend > $nomod166 > $stdnames(reg164ci.def) > $NOLOCALS > > regdef R1,R2,R3,R4,R5,R6,R7,R8,R9,R10,R11,R12,R13,R14,R15 > ;non-used Regs by I²C-Subs: R3, R5, R8, R9, R10, R11, ((R14), R15) > ;************************************************************************************************************** > > ; P1L.0 CC60IO > ; P1L.1 COUT60 > ; P1L.2 CC61IO > ; P1L.3 COUT61 > ; P1L.4 CC62IO > ; P1L.5 COUT62 > ; P1L.6 COUT63 Clock > ; P1L.7 CTRAP /CS > ; P1H.0 CC6POS0 > ; P1H.1 CC6POS1 > ; P1H.2 CC6POS2 > ; P1H.3 T7IN > ; P1H.4 CC24IO > ; P1H.5 CC25IO DIn > ; P1H.6 CC26IO SSTRB > ; P1H.7 CC27IO DOut > > P1L_ EQU 0FF04h > > ; Definition der OS-Routinen > OSsegment EQU 0 > POP_R4 EQU 0765AH ;uses: R4, R12, R13, R14 > PUSH_R12 EQU 075D6H ;uses: R1, R2, R12, R13,R14,R15 > POP_LONG EQU 07680H ;return in R4, R5 > PUSH_LONG EQU 075fEH ;Value in R12, R13 > > userseg SECTION CODE word at 33000h ; Segment 3, Adresse 0000h > assume dpp3:userseg > > ;************************************************************************************************************ > ; AD-Wandlung einlesen > ad1270 proc far > BCLR IEN > CALLS OSsegment,POP_R4 ;data > MOVB RH4, RL4 > MOV R13,#0h > BCLR CTRAP > nop > nop > _1: ;for i=0 ... 7 > ROL R4, #1 > BMOV CC25IO,C > BSET COUT63 ; Clock > nop > BCLR COUT63 > CMPI1 R13,#07h > JMPR cc_SLT,_1 ; next for; jump if R13 < 0x07 > BSET CTRAP > BCLR CC25IO > nop > nop > nop > nop > nop > nop > nop > nop > nop > MOV R12,#0 > _2: BMOV R12.0,CC26IO > CMP R12,#01h > JMPR cc_SLT,_2 > BCLR CTRAP > nop > nop > MOV R13,#0h > MOV R12,#0 > _3: SHL R12,#1 ; for i = 0... 11 > BMOV R12.0,CC27IO > BSET COUT63 ; Clock > nop > BCLR COUT63 > > CMPI1 R13,#11 > JMPR cc_SLT,_3 > CALLS OSsegment,PUSH_R12 > BSET CTRAP > POP R1 > POP R1 > BSET IEN > RETS > ad1270 endp > userseg ENDS > END > </asm> > > Als ich aber hier auch die selben Bitfehler erhalten habe wurde ich stutzig. > Da laut Datenblatt die Bits mit keiner minimalen Geschwindigkeit "ausgeshiftet" > werden müssen hab ich das Clock-Signal einfach mal auf 5 Sekunden gestreckt > und mir jedes "ausgeshiftete" Bit auf dem Ozi angesehen und mit dem Eingelesenen > verglichen... mit einem erschreckendem Ergebnis..... Der Wandler selbst > gibt die unsinnigen Werte aus. > Mein erster Gedanke.... "das Ding ist kaputt" bestätigte sich leider auch nicht. > (Ein niegelnagelneuer Max1270 verhielt sich genau so) > Ich bin mit meinem Latein am Ende :-( > > Ich wünsche euch dennoch eine schöne Maifeier (ich geh mich jetzt besaufen)