Hallo,
bin absoluter Anfänger und da macht man halt komische Sachen :-)
Ich habe dieses kleine Programm geschrieben:
.include "m8def.inc"
main:
ldi r16, LOW (RAMEND)
out SPL, r16
ldi r16, HIGH (RAMEND)
out SPH, r16
start:
ldi r16, 0xFF
mov r17, r16
pruef0:
out ddrb, r17
ldi r20, $00
warten:
inc r20
ldi r18, $00
ldi r19, $00
pruef1:
inc r18
cpi r18, $FF
brne pruef1
pruef2:
inc r19
cpi r19, $FF
brne pruef2
cpi r20, $FF
brne warten
inc r17
cpi r17, $FF
brne pruef0
warte:
dec r21
brne warte
dec r22
brne warte
out portb, r17
rjmp main
ich experimentiere mit Zählschleifen zu Lernzwecken.
Wenn ich das Programm auf dem STK500 laufen lasse macht es eigentlich
alles wunderbar...................
Aber nur 4 mal, danach bleibts dunkel.
Ok, 4 x 256 = 4 Byte = 32 Bit.........und dann???
Wo laufen denn die Werte hin ???
Ich dachte das wiederholt sich immer wieder von vorn, aber Pustekuchen.
Das dies kein vernünftiger Programmstil ist weiss ich, aber ich weiss
nicht was nach dem vierten mal hochzählen passiert.
Kann mir das jemand für Newbies erklären?
Gruß Pebez
Peter Bednarz schrieb:
> Ok, 4 x 256 = 4 Byte = 32 Bit.........und dann???
Das ist doch Quatsch...Allerdings seh ich jetzt beim Durchlesen auch keinen Fehler. Das einzige, was mich wundert, ist, dass du wieder zu "main" hochspringst, und nicht zu "start". Markus
Hallo, ob ich nach start oder main rjmp ist egal. Die Leds werden genau 4 x durchgezählt und danach ist dunkel. Mit 1 x zählen meine ich die Leds binär von 0 bis 255 durchzählen bzw. blinken lassen 00000001,0000010,0000011,0000100,0000101............. bis 11111111. Das ganze läuft 4 x ab und dann läuft nix mehr. Die Sicherung vom SP habe ich im main nachträglich eingebaut, da ich dachte das es damit zusammenhängt. Wo liegt mein Gedankenfehler? Gruß Pebez
>Das dies kein vernünftiger Programmstil ist weiss ich
Dann tu Dir selbst einen Gefallen und beschäftige Dich gar nicht weiter
mit diesem Unsinn, Du lernst dabei nichts.
Wenn Du schon unbedingt eine Zeitschleife programmieren willst, dann
mach das mit dem Doppelregister R24/R25. Mit dem Befehl SBIW R24, 1
kannst dann 65536mal runterzählen, weil bei einem Unterlauf von R24
das High-Register R25 um eins verringert wird.
Auf diese Weise hast Du schon 4 * 65536 Takte, was je nach Systemtakt
schon eine schöne Anzahl von ms ergibt. Das Ganze dann in einer
äußeren Schleife 10 bis 20mal ablaufen lassen und am Ende Dein
Bitmuster ausgeben.
Wenn das klappt, dann vergiss die Zeitschleife wieder und mach das
gleiche
eleganter mit einem Timer-Interrupt, dann kann der Prozessor zwischen-
durch auch noch andere Aufgaben erledigen.
Die 16Bit-Schleife sieht so aus:
ldi R25, 0
ldi R24, 0
Loop:
sbiw R24,1 ;2 Takte
brne Loop ;2 Takte wenn nicht Null, 1 Takt bei Null
Nun brauchst Du noch ein 8Bit-Register für die äußere Schleife,
und nicht 6 wie in Deinem "Programm".
Hans schrieb: > Dann tu Dir selbst einen Gefallen und beschäftige Dich gar nicht weiter > > mit diesem Unsinn, Du lernst dabei nichts. > > > > Wenn Du schon unbedingt eine Zeitschleife programmieren willst, dann > > mach das mit dem Doppelregister R24/R25. Mit dem Befehl SBIW R24, 1 > > kannst dann 65536mal runterzählen, weil bei einem Unterlauf von R24 > > das High-Register R25 um eins verringert wird. Hallo Hans, ich möchte meine "Zählerei" nicht als Programmstil benutzen. Du hast Recht, wenn du sagst das man das mit Timer oder wenn unbedingt nötig mit r24/25 macht. Das ist soweit gut. Nur, kann ich mir im Moment nicht erklären warum die "Zählerei" von mir nach vier Durchläufen aufhört, darum gehts mir eigentlich. Irendwas muss doch "überlaufen"?? Der Ablauf geht doch nicht einfach so ins Nirwana :-). Mich würde interessieren warum es das tut, dadurch "lernt" man doch auch wiederum dazu. Gruß Pebez
Hi >pruef0: > out ddrb, r17 <- Damit änderst du nur das Richtungsregister > ldi r20, $00 ..... > inc r17 > cpi r17, $FF > brne pruef0 Außerdem sind r21 und r22 beim ersten Durchlauf unbestimmt. Mf Spess
>Nur, kann ich mir im Moment nicht erklären warum die "Zählerei" von >mir nach vier Durchläufen aufhört, darum gehts mir eigentlich. Na gut. Schau Dir mal Dein DDRB-Register an, was passiert damit?
Hans schrieb: > Na gut. > > Schau Dir mal Dein DDRB-Register an, was passiert damit? Hallo Hans, so, jetzt habe ich das Prog etwas umgestaltet und es läuft durch :-) main: ldi r23, 0xFF ldi r16, LOW (RAMEND) out SPL, r16 ldi r16, HIGH (RAMEND) out SPH, r16 out ddrb, r23 start: ldi r16, 0x00 mov r17, r16 pruef0: out portb, r17 ldi r20, $00 warten: inc r20 ldi r18, $00 ldi r19, $00 pruef1: inc r18 cpi r18, $FF brne pruef1 pruef2: inc r19 cpi r19, $FF brne pruef2 cpi r20, $FF brne warten warte: dec r21 brne warte dec r22 brne warte dec r17 cpi r17, $00 brne pruef0 loop: rjmp start Jetzt ist die Zuweisung für DDRB in keiner Zählschleife mehr. Vorher hat DDRB das gemacht, was eigentlich PORTB anzeigen sollte. Also DDRB aus Zählschleife raus und statt dessen PORTB rein in die Schleife. Soweit so gut. Nur so richtig verstehe ich es noch nicht, dass die vorherige Version: pruef0: out ddrb, r17 ldi r20, $00 . . . . . dec r17 cpi r17, $00 brne pruef0 out portb, r17 genau VIER Durchläfe geschafft hat ?!#**gmpf## Das bekomme ich noch nicht nachvollzogen................... Gruß Pebez
Peter Bednarz schrieb:
> Das bekomme ich noch nicht nachvollzogen...................
Dann nimm den Simulator von AVRStudio.
moin weil nach 4 Durchläufen im Datenrichtungsregister alle Bit auf Eingang gestellt sind .
Beitrag #5165627 wurde vom Autor gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.