Mit Tastendruck vorwärtszählen

[Einsteiger (Gast)]

Hallo liebe Mikrocontroller Fans,

ich steige in der Programmierung mit dem Atmega8 und hier ist mein 2. 
selbstgeschriebenes Code.
Mein Ziel ist binär vorwärtszählen, nach tastendruck, also:

1.Tastendruck : Led: 00000001
2.Tastendruck : Led: 00000010
3.Tastendruck : Led: 00000011
usw

aber nachdem ich das Code auf die Platine geflascht habe, zeigen die 
Leds folgend:

Led: 00000001 (also 1 dezimal)

Also es zählt ab 1 (dezimal) statt ab 0(dezimal)

was mache ich denn falsch?

Danke schon mal

Hier das COdes:


.equ DDRD =$11
.equ DDRB =$17
.equ PINB =$16
.equ PORTD =$12
.def temp1 =r19
.def temp2 =r20

ldi  r16,0xFF     ; Port D als Ausgang
out  DDRD,r16

ldi  r16,0x00  ; Port B als Eingang (wo die Taster angeschossen sind)
out  DDRB,r16

ldi r17,0x00      ; initialieren den register mit 0d

ldi r16, 0xFF     ;Alle Leds an
out PORTD, r16

warten:

sbis PINB, 0     ;solange keine Taste gedrückt wird
rjmp warten       ; wird gewartet, dann wenn gedrückt
                  ; springt raus

ldi temp1, 0xFF   ; wegen Entprellung habe ich temp1

warten2:
ldi temp2, 0xFF   ; und temp2 definiert, die werden

warten3:

dec temp2       ; bis 0x00 decrementiert nach dem
brne warten3    ; Tastendruck, damit der µC das Loslassen
dec temp1            ; nicht merkt also
brne warten2         ; ein paar millisekunden

inc r17            ; dann wir r17 incrementtiert und

out PORTD, r17    ; seinen Wert wird ausgeben

warten4:
sbic PINB,0      ; wenn die Taste losgelassen ist dann
rjmp warten4        ; springt aus dem Schleifen sonst warten

cpi r17, 0xFF       ; wenn r17 den wert 256 erreicht hat, dann
breq ende      ; springt zum ende, sonst springt wieder zum
rjmp warten         ; warten
ende:
rjmp ende

[Niels H. (monarch35)]

Wie ist denn der Taster am uc angeschlossen?

[Karl H. (kbuchegg)]

Drück mal deine Taste gaaaanz langsam.
Wann genau erfolgt das Umschalten der Led auf
die nächste Ziffer?
Nachdem du die Taste gedrückt hast?
Oder nachdem du die Taste losgelassen hast?


Hintergrund (Niels vermutet dasselbe).

Meist sind Taster so angeschlossen, dass der Grundzustand,
also Taster nicht gedrückt, einer 1 entspricht und der PortPin
auf 0 wechselt wenn der Taster gedrückt wird.

Wenn das Verhalten deines Programmes so ist, dass das Höherschalten
erst nach dem Loslassen passiert, dann ist das bei dir auch so.
sbis und sbic tauschen.

[Niels H. (monarch35)]

Karl heinz Buchegger wrote:

> Hintergrund (Niels vermutet dasselbe).

Naja, eigendlich vermute ich, das der Taster ohne Pullup oder sonstwas 
betrieben wird; also der Port im "ungedrückten" Zustand einfach offen 
ist.

[Thilo M. (Gast)]

Pullup hat er drin, 'da wo die Taster angeschossen ;) sind'

[Niels H. (monarch35)]

Thilo M. wrote:

> Pullup hat er drin, 'da wo die Taster angeschossen ;) sind'

Pullups? also sind die taster low-aktiv. Ist das vieleicht schon das 
Problem? Kenn mich jetzt mit Assembler nicht genau aus....

[Karl H. (kbuchegg)]

Niels Hüsken wrote:

> Pullups? also sind die taster low-aktiv. Ist das vieleicht schon das
> Problem?

Könnte sein. Solange Einsteiger sich nicht meldet werden wir
es nicht erfahren.

> Kenn mich jetzt mit Assembler nicht genau aus....

Er hat zur Zeit seine Taste auf high-aktiv programmiert.
Ohne internen Pullup.

sbis  bedeutet: Skip (next instruction) if Bit Is Set
sbic            Skip (next instruction) if Bit Is Cleared

damit müsstest da das Programm nachvollziehen können.
Der Rest vom Programm ist ja eher selbsterklärend.

[Niels H. (monarch35)]

Dann ist der Code offensichtlich High-Aktiv programmiert und die Logic 
muss umgedreht werden...entweder software- oder hardwaremässig.

> Also es zählt ab 1 (dezimal) statt ab 0(dezimal)

Das ist auch nicht ganz richtig. Der Code initialisiert PortD mit 0xFF.

[Thilo M. (Gast)]

>Er hat zur Zeit seine Taste auf high-aktiv programmiert.

Und genau deshalb zählt er beim Start (RESET) schon eins hoch.

[Thilo M. (Gast)]

Ups, PINB wären die Tasten, da sind natürlich kein Pullups programmiert!

[Karl H. (kbuchegg)]

Niels Hüsken wrote:
> Dann ist der Code offensichtlich High-Aktiv programmiert und die Logic
> muss umgedreht werden...entweder software- oder hardwaremässig.
>
>> Also es zählt ab 1 (dezimal) statt ab 0(dezimal)
>
> Das ist auch nicht ganz richtig. Der Code initialisiert PortD mit 0xFF.

Sieh es ihm für den Moment nach:-)
Seine Led dürften ebenfalls low-activ sein.

Das wird dann die nächste Frage: Warum zählt der so komisch?
Zuerst brennt keine Led, drücke ich die Taste brennen dann auf
einmal alle.

[Niels H. (monarch35)]

Sondern? Wie sieht die verdrahtung am uc aus?

[Niels H. (monarch35)]

Karl heinz Buchegger wrote:
> Seine Led dürften ebenfalls low-activ sein.
>
> Das wird dann die nächste Frage: Warum zählt der so komisch?
> Zuerst brennt keine Led, drücke ich die Taste brennen dann auf
> einmal alle.

Okey, gehen wir mal davon aus, das die Logic am Taster jetzt stimmt....
Wenn die LEDs Low-Aktiv sind, bedeutet das, das der Zustand des Zählers 
"negiert" dargestellt wird, wenn du ihn "ungefilterert" auf die Ports 
ausgibst.

Zuerst wird der Port mit 0xFF initialisiert. Keine LED leuchtet.
Nach dem ersten Tastendruck wird das register R17, das mit 0x00 
initialisiert worden ist, auf 0x01 hochgezählt und auf dem Port 
ausgegeben. Alle LEDs, bis auf die erste, leuchten.... so müsste es laut 
code zumindest sein.

Möchtest du(ihr) die negierung aufgeben, macht ihr das entweder 
Hardwaremässig (LEDs umpolen bzw umdrehen) oder Softwaremässig (über ein 
zwischenregister den Wert von R17 negieren)