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.