Hallo,
ich habe ein kleines Testprog geschrieben, welches ohne Probleme im
Simulator läuft (AVR Studio 3.55). Aber wenn es im µC ist verhält es
sich nicht so wie es sollte.
Zur Funktion:
Ich habe zwei Taster, der eine soll ein Register hochzählen und der
Andere unterzählen. Um eine kontrollierte Zählung zu erreichen, frage
ich die Taster ab wann Sie losgelassen werden.
Programm:
.include "4433def.inc"
ldi r16, 0xFF
out DDRC, r16
ldi r16, 0x00
out DDRB, r16
out DDRD, r16
ldi r17, 0x00
loop: sbic PINB, 0
rjmp plus
sbic PIND, 0
rjmp minus
out PORTC, r17
ende: rjmp loop
plus:
inc r17
warte1:
out PORTC, r17
sbic PINb, 0
rjmp warte1
rjmp loop
minus:
dec r17
warte2:
out PORTC, r17
sbic PIND, 0
rjmp warte2
rjmp loop
Ich bin für jeden Vorschlag dankbar... Hans
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
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.