Hi Atmelexperten, Ich hoffe ihr könnt mir helfen denn ich bin seit ein paar Tagen am verzweifeln. Ich habe einen RGB-Fader mit dem ATMEGA88 aufgebaut mit 18-Fading-Kanälen. An den Ausgängen hängen ULN-Darlington-Transistor-Arrays. Mein Problem ist, dass drei Ausgänge (PC3,PC4,PC5), unter einer Last von 2mA (Basisstrom aus PortC in Transistor) von 5V auf 1,5V fallen. Die Flanke sieht am Oszi irgendwie auch aus, als wäre dort eine Kapazität die sich aufladen würde. Ich kann ausschließen, dass sich ein Hardwarefehler eingeschlichen hat oder dass der AVR oder das Transistorarray kaputt wären. Auch einen Softwarefehler kann ich ausschließen, habe nämlich ein Testprogramm geschrieben in dem ich einfach nur die betreffenden Ausgänge auf High-Low schalte. Vielleicht hab ich irgendwas im Datenblatt übersehen ? normalerweise müssten die Ausgänge des PortC doch als Ausgänge nutzbar sein ?
Stefan Schmidt schrieb: > Ich kann ausschließen, dass sich ein Hardwarefehler eingeschlichen hat > oder dass der AVR oder das Transistorarray kaputt wären. Auch einen > Softwarefehler kann ich ausschließen, Dann müsste es ja laufen. Wenn etwas nicht funktioniert, kann man gar nichts ausschliessen. AVcc angeschlossen? Ports auf Ausgang geschaltet? DDRC |= (1 << 3) | (1 << 4) | (1 << 5); und irgendwann später wird dann nochmal einer nachnominiert: DDRC = (1 << 0); Lötfehler? Daß der Controller oder der Treiber kaputt sind, sind die unwahrscheinlicheren Möglichkeiten. mfg.
Hört sich so an, als wären die Pins nur als Eingang konfiguriert und du schaltest nur die internen Pullups ein und aus.
Gast
#2905710
Martin Kreiner schrieb: > Hört sich so an, als wären die Pins nur als Eingang konfiguriert und du > schaltest nur die internen Pullups ein und aus. Wenn das nicht, dann BITTE Schaltplan und Testprogramm posten.
Habs gefunden ! Ich hatte Anfang des Programms und auch des Testprogramms noch in die OCR0A und OCR0B den Wert null reingeschrieben. Ich weiss selbst nicht mehr warum ich das gemacht hatte, aber ich hätte nicht gedacht, dass das solch einen Effekt hat. Nachdem ich die Zeilen aus Verzweiflung auskommentiert hatte, gingen plötzlich die Ausgänge PC0-PC3 ganz normal o_0
Gast
#2905951
Hi >Ich hatte Anfang des Programms und auch des Testprogramms noch in die >OCR0A und OCR0B den Wert null reingeschrieben. Ich weiss selbst nicht >mehr warum ich das gemacht hatte, aber ich hätte nicht gedacht, dass das >solch einen Effekt hat. Nachdem ich die Zeilen aus Verzweiflung >auskommentiert hatte, gingen plötzlich die Ausgänge PC0-PC3 ganz normal Willst du uns veralbern? Die PINs haben absolut nichts mit OCR0A und OCR0B zu tun. MfG Spess
> Nachdem ich die Zeilen aus Verzweiflung auskommentiert hatte, > gingen plötzlich die Ausgänge PC0-PC3 ganz normal Mit anderen Worten: Der Fehler ist immer noch in deinem Programm drinnen. Du hast ihn nur gut genug versteckt, dass du ihn nicht bemerkst. Soviel zu: ... einen Softwarefehler kann ich ausschließen ...
Fragt mich nicht was da los ist. Wie gesagt, nachdem ich die Zeilen
auskommentiert habe gings und dann ging auch meine RGB-Fading-Routine.
Ursprünglich wollte ich mit dem Programm den Timer0 ausprobieren und
habs dann so zurecht gelegt dass ich den PortC testen konnte.
Hier der Code vom Testprogramm:
.include "m88def.inc"
.def temp = r21
;====================================================
.org 0x0000
rjmp main ; Reset Handler
.org 0x020
rjmp timer0_overflow ; Timer Overflow Handler
main:
ldi temp, 0b11111111 ; Port B auf Ausgang
out DDRB, temp
ldi temp, 0b00111000 ; Port C (3,4,5) auf Ausgang
out DDRC, temp
ldi temp, 0b11111111 ; Port D auf Ausgang
out DDRD, temp
ldi temp, 0b00000001 ; CS01 setzen: Teiler 1
out TCCR0B, temp
; ldi temp, 0 ; Output Compare Register OCR0B
; sts OCR0B, temp
; ldi temp, 0 ; Output Compare Register OCR0B
; sts OCR0A, temp
ldi temp, 1<<TOIE0 ; TOIE0: Interrupt bei Timer Overflow
sts TIMSK0, temp
; sei ; Set Interrupt Enable
bla:
ldi temp, 0b00111000
out PORTC, temp
rjmp bla
timer0_overflow:
;ldi temp, 0b11111111
;out PORTB, temp
;ldi temp, 0b11111111
;out PORTD, temp
ldi temp, 0b00111000
out PORTC, temp
nop
nop
nop
ldi temp, 0b00000000 ; Port D auf Ausgang
out PORTB, temp
ldi temp, 0b00000000 ; Port D auf Ausgang
out PORTD, temp
ldi temp, 0b00000000 ; Port D auf Ausgang
out PORTC, temp
reti
Gast
#2906172
Wird der Stackpointer beim 88 automatisch initialisiert?
Gast
#2906179
Hi
>Wird der Stackpointer beim 88 automatisch initialisiert?
Ja.
MfG Spess
Ist ausserdem erst mal egal. Der sei ist auskommentiert. OK, zumindest in diesem Testprogramm seh ich keinen Fehler.
Irgendwie ist das total schräg. Vor allem, wenn man nach Fehlern suchen muss, wo man normalerweise keine erwarten würde o_O
Gast
#2906200
Auch wenn es schonmal auftauchte im Thread, aber leicht zu übersehen ist: AVCC korrekt angeschlossen? Da hängt auch der Digitalteil von PortC dran! Gruß, Christian
Das Problem sind die 'sts'. Die Register OCR0A und OCR0B liegen im in/out-Bereich. Die 'sts' schreiben also in den Memory-Mapped-Bereich an die IO-Adressen der beiden Register. Und was liegt dort? PORTC und DDRC.
ah ok, das mit dem sts/lds bzw. in/out fällt mir generell immer schwer zu unterscheiden
> Die Register OCR0A und OCR0B liegen im in/out-Bereich. Die 'sts' Och, Menno. Und ich hab extra noch nachgesehen, ob die sts stimmen. Das man da ja dann anders addressieren muss, hab ich übersehen. > ah ok, das mit dem sts/lds bzw. in/out fällt mir generell immer schwer > zu unterscheiden Datenblatt http://www.atmel.com/Images/doc2545.pdf Seite 344 und folgende. Alle Registeradresse größer als 0x3F sind nur per sts zu erreichen. Dort steht dann auch nur 1 Zahl und nicht 2 bei der Adressangabe. ... und genau das ist einer der Gründe, warum ich C bevorzuge. Um so einen Kleinkram will ich mich nicht kümmern müssen. Das macht der Compiler zuverlässiger.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.