Wer findet den Fehler?

egal ob "Betätigen" oder "Loslassen" mechanische Kontaktgeber z.B. 
Taster prellen im. Du must diese per Software (z.B. 10-20 ms Delay) 
entprellen.

Mikki Du hast recht, aber das ändert nichts an meinem Problem. Wenn das 
Prog im µC ist kann ich nur ein Schritt rauf und dann wieder runter 
zählen :(  Halte ich zB. ein Taster gedrückt, dann kann ich mit dem 
Anderen problemlos zählen. Nicht ganz problemlos, da ich noch keine 
Entprellung drin habe. Es kommt dann zwar zu mehrfach Zählungen, aber 
das ist momentan nicht das Problem.

Ich habe mich wirklich bemüht, aber ich kann auch keinen logischen 
Fehler in der Software finden. Also kann es nur noch an der Hardware 
liegen. Wie hast Du denn die beiden Taster angeschlossen?

MfG
Gerd

Hi,

kann es sein, dass Du den Stack noch initialisieren musst ??

Gruß

UBoot-Stocki

Wie hast du den die Taster angeschlossen ?
Bei diesem kurzen Programm ist eine Stack-Initialisierung noch nicht 
erforderlich, keine RCALLs und keine Interrupts.

Hallo

Bin Selber Anfänger aber was ich nicht nachvolziehen kann ist das alle 3 
Ports als ausgabe dienen und das der Register R16 2mal hintereinander 
mit unterschiedlichen werten geladen wird.

Kann mich bitte einer Aufklären!

Danke

loop: sbic PINB, 0   muss heissen "sbis PINB, 0"
   rjmp plus
         sbic PIND, 0 muss heissen "sbis PINB, 0"
   rjmp minus
   out PORTC, r17
rjmp Loop

wenn ein Taster gedr.wird, steht low-Pegel an, dann erst Aktion.
Initialisierung des Stackes unbedingt notwendig ! Ohne Entprellung
herrscht absolutes Chaos :-)

SG Josef

Wenn dann bitte richtig lesen

ldi r16, 0xFF
out DDRC, r16          ;Port C alles Ausgänge
ldi r16, 0x00
out DDRB, r16          ;Port B alles Eingänge
out DDRD, r16          ;Port D alles Eingänge

Hat nichts mit der Datenrichtung zu tun- die stimmt.

Hi

Ich glaubst dir ja allerdings kann ich es als neuling trotzdem nicht 
nachvolziehen.

Wenn ich (out ddrb, r16 )lese heißt das für mich "Inhalt vom Register 
r16 am Port b Ausgeben.

Vieleicht lerne ich es ja noch.

(out ddrb, r16 ) heißt, dass du nur in das Datenrichtungs-Register 
schreibst. Hat nichts mit der Port-Ausgabe zu tun.
Müsste heißen: out PORTB,R16.

sg Josef

@josef
Bei diesem Programm ist solange keine RCALLS und keine INTERRUPTS 
erfolgen keine!!! Stack-Initialisierung erforderlich. Ist allerdings 
nicht unbedingt guter Programmierstil.
Du setzt hier auch voraus, daß der Eingabetaster ein normaler 
Arbeitskontakt ist, der in überlicher Weise vom Portpin nach Masse 
angschlossen ist.

Richtig! Aber es kommt vor, dass die Mühle trotz keiner Calls
spinnt. Stack-Initialisierung muss der 1. Befehl sein- ganz Wurst
wie das Programm aussieht.


sg Josef

Lieber Josef, die "Mühle" macht in Assembler wirklich nur das, was der 
Programmierer ihr mitteilt. Da kannst Du Dich schon drauf verlassen. Die 
schaltet keine Ints ein und lässt auch keine von selbst zu, wenn der 
Programmierer das nicht gemacht hat. Nein, das mit dem Stack ist 
wirklich egal.
Ich habe allerdings immer noch keine Idee, was mit der Software kaputt 
ist. Wie sind denn nun die Taster angeschlossen, bevor wir weiter ghier 
im Nebel stochern?

MfG
Gerd

@josef
Ohne Stack-Initialisierung (welche nicht immer notwendig ist) darf dein 
Programm natürlich auch keine PUSH und POP Befehle enthalten. Wenn deine 
"Mühle" dann immer noch spinnt, dann ist wirklich der Prozessor kaputt 
oder der Programmierer hat einen logischen Fehler in seinem Programm 
gemacht.

Erst einmal vielen Dank für Eure zahlreichen Tips. Die Taster sind so 
angeschlossen, das Sie den Pin auf Masse ziehen. Somit meine ich, das 
auch sbic richtig ist. Wie schon oben beschrieben funktioniert die 
Simulation 100%tig, nur wenn ich das Prog geflasht habe macht es nicht 
das, was es in Simulation macht, auch nicht mit einer 
Softwareentprellung von 20ms :( Ich habe es auch schon mit einem 
Tiefpass versucht und der das Ergebnis war das gleiche =( Ich habe das 
Prog dahingehend umgeschrieben, das ich nun ein Pin für die Richtung 
(up/down) und den Anderen für den Takt nehme. Und siehe da es läuft.

SBIC war schlecht gewählt und kann so auch nicht funktionieren. Heißt ja 
im Klartext für deine Hardware "überspringe nächste Anweisung wenn 
Taster gedrückt ist". SBIS wäre an dieser Stelle richtig gewesen.

@mikki. das stimmt nicht, da ich die Pins auf Masse ziehe passt schon 
SBIC. Das bedeutet, wenn ich den Taster drücke geht der Pin gegen 0V.

Hans, da bist du dir aber ziemlich sicher in deiner Sache, da du auf 
wiederholten Hinweis immernoch noch nicht genauer über Mikkis Aussagen 
nachdenkst?!

Schmittchen.

Hier nochmals dein Code:

loop: sbic PINB, 0
      rjmp plus          ;Klartext Ausführung plus bei nicht! gedrücktem 
Taster???

         sbic PIND, 0
   rjmp minus
   out PORTC, r17

ende: rjmp loop

Wad das beabsichtigt?

@Schmittchen: Aber sicher habe ich über Mikkis Aussagen und derandern 
nachgedacht und sogar ausprobiert. Ich möchte auch etwas lernen.
@Mikki: Ich habe gerade die Eingänge nochmals durchgemessen. Ergebnis:
loop: sbic PINB, 0
      rjmp plus ;Klartext Ausführung plus bei gedrücktem!!! Taster, denn 
dann wird das Eingangsbit auf Null "gezogen".

   sbic PIND, 0
   rjmp minus
   out PORTC, r17

ende: rjmp loop

Ich habe diese Prozedur schon in anderen Prog's erfolgreich eingesetzt. 
Diese Programme laufen bis jetzt sehr stabil. Danke für Deinen Hinweis.

SBIC = Skip if Bit in I/O is CLEARED!!!
Also ich spare mir hier die wörtliche Übersetzung des SBIC Befehls, aber 
ein gelöschtes Bit (0) trifft nur dann zu, wenn der Taster gedrückt (L = 
0) ist.
Klartext Überspringe nächsten Befehl wenn Bit = 0 entsprechend L Pegel 
am Port-Pin entsprechen Taster gedrückt!

Hurraaaaaaaaaaa!!!! Ich habe jetzt den Fehler (Danke Mikki). In der 
Simulation ist das Bit default-mäßig gelöscht und in meiner Schaltung 
ist es Eins :)))))))
Danke an alle, ganz besonderen Dank an Mekki, die mir bei meinem Problem 
geholfen haben. Ist ein gutes Gefühl zu wissen woran es lag, am 
Programmierer (wie immer:) )

Die Input Pins im Simulator verhalten sich ja nicht wie offene oder mit 
PullUp an VCC gelegte Eingänge sondern dort wird ein definiter Pegel 
angenommen und der ist wie bei fast allen anderen Registern L-Pegel nach 
einem RESET.

Du arbeitest aber nicht mit den internen Pullups, hast außen extra 
welche, oder? Sonst fehlt der Schritt mit dem Einschalten der Pullups.

MfG
Gerd

Hauptsache Hans hat seinen gedanklichen Fehler gefunden. Das Einschalten 
der PullUp Widerstände wäre natürlich guter Programmierstil und erhöht 
die Funktionssicherheit ungemein, war allerdings nicht der Fehler. Und 
im Simulator ist der L-Pegel im PINx Register beim Programmstart nicht 
ganz logisch wenn man von einer realen CPU ohne angeschlossene 
Peripherie ausgeht. Nach meinem Verständnis wäre hier die Vorbelegung 
mit H-Pegel sinnvoller gewesen.

Wieso? Ein offener Inputpin liegt ohne Signal erst mal auf Low. Ist ja 
kein TTL-Eingang, der von sich aus auf 1 zieht.

MfG
Gerd

Ist auch nicht ganz richtig. Der ist normalerweise undefiniert, Atmel 
bezeichnet diesen Zustand als TriState HiZ. Im Bezug auf Eingänge ist 
dieser Begriff auch etwas unglücklich gewählt. Ja nach Prozessorfamilie 
haben unbeschaltete Eingänge (also ohne interne oder externe PullUp ein 
undefiniertes Verhalten), meistens werden diese beim AVR als H 
interpretiert was aber so natürlich nicht als Zustand definiert ist.