Wie warte ich mit Assembler?

[S. H. (fat32)]

Hallo,

ich will eine LED mit assembler blinken lassen. wie kann ich ca. 200ms 
vergehen lassen?

finde nix im tut und bei google auch nicht

[Johannes M. (johnny-m)]

Mit nem Timer.

[S. H. (fat32)]

genauer gehts nicht? :-D

[Elektrikser (Gast)]

Entweder du schlägst die Zeit tot und toggelst danach den Pin. Oder du 
verwendest einen Timer und immer, wenn der Timerinterrupt kommt, 
toggelst du den Pin.

Welcher Controller soll es denn sein?

[Simon K. (simon)]

S. H. wrote:
> genauer gehts nicht? :-D

Klar!
http://www.mikrocontroller.net/articles/AVR-Tutorial:_Timer

[Elektrikser (Gast)]

Genauer geht es schon, aber dazu sollte der Controller bekannt sein.

[Thomas B. (yahp)]

> finde nix im tut und bei google auch nicht

ROFL.

Ne, also lies das ganze Tutorial, da kommen durchaus Timer vor. Im LCD 
Teil ist auch mal beschrieben, wie man das ganze ohne Timer mit 
Warteschleife realisiert.

[S. H. (fat32)]

hab nen mega8

[Simon K. (simon)]

S. H. wrote:
> hab nen mega8

Jetzt fang nicht wieder so an. Unter dem Link oben haben sich schon 
mehrere Leute die Mühe gemacht einen Artikel mit Beispielcode zu 
veröffentlichen. Das steht da schließlich auch nicht zum Spass.

[Falk (Gast)]

Du musst eine Schleife programmieren, und in der Schleife ein paar NOPs 
(No Operation) einfügen. Da 200ms schon recht lange sind, musst du 
mehrere Schleifen verschachteln. Etwa so, als Funktion, aufrufbar mit 
rcall.

delay:
ldi r16,0xFF
loop_1:
ldi_r17,0xFF
loop_2:
nop
dec r17
brne loop_2
dec r16
brne loop_1
ret

MfG
Falk

[S. H. (fat32)]

also ich weiß ja nicht
mit basic hab ich meine projekte gut hinbekommen
wollte jetzt auf assembler umsteigen, weils angeblich besser sein soll


aber assembler ist wirklich nix für mich
trotzdem danke


der, der bei basic bleibt und jetzt C probiert

[Simon K. (simon)]

S. H. wrote:
> also ich weiß ja nicht
> mit basic hab ich meine projekte gut hinbekommen
> wollte jetzt auf assembler umsteigen, weils angeblich besser sein soll
>
>
> aber assembler ist wirklich nix für mich
> trotzdem danke
>
>
> der, der bei basic bleibt und jetzt C probiert

Jau mach das.

do
  waitms 100
  set portb.0
  waitms 100
  reset portb.0
loop

[Thomas (Gast)]

Du, C solltest Du besser sein lassen, ist viel zu alt!
Versuche mal D++, bzw E, das geht auch ganz gut.

Assembler kannst vergessen, weil, wie Du schon gemerkt hast, A kommt ja 
aus der Steinzeit, denn A ist ja noch vor "B" wie "Basic" und erst recht 
"C" wie "Comfort".

Aber wem sag ich das

[Simon K. (simon)]

Thomas wrote:
> Du, C solltest Du besser sein lassen, ist viel zu alt!
> Versuche mal D++, bzw E, das geht auch ganz gut.
>
> Assembler kannst vergessen, weil, wie Du schon gemerkt hast, A kommt ja
> aus der Steinzeit, denn A ist ja noch vor "B" wie "Basic" und erst recht
> "C" wie "Comfort".
>
> Aber wem sag ich das

Hehe, DAS hat mich nach alledem zum Lachen gebracht. Top! ;)

[Christian Erker (Gast)]

>aber assembler ist wirklich nix für mich
>trotzdem danke

Nicht so schnell aufgeben, es dauert einfach seine Zeit bis man es drauf 
hat sein Hirn so verknoten zu können das man alle Probleme mit 
Bitschubsen löst, dann ists aber nicht mehr wild.

Ist um WELTEN schneller als Basic, und immer noch ein gutes Eck flotter 
als C, wobei C doch schon OK ist.

Gruß,
Christian

[Stephan H. (stephan-)]

warte:   Nop
         jmp warte


das war´s..... warten bis der Arzt kommt :-))

[Assemblerfan (Gast)]

Ist wie mit jeder Sprache: Die ersten Schritte auf dem Weg zum Erfolg 
sind etwas steinig, aber mit jeder Zeile Code die man schreibt wird es 
immer besser.
Da du ja was mit µC machen willst, ist Assembler die beste Wahl, wegen 
der Hardware-Nähe. Und wenn du wirklich auch mal ein "Richtiges" 
Gerätchen bauen willst, dann kommst du eh nicht drumherum dich mit der 
Hardware des Prozessors zu beschäftigen, das nimmt dir auch "C" nicht 
ab.
Und um die Hardware kennenzulernen ist der "doofe, alte " ASM nun mal 
das beste, weil jeder Schritt klar nachvollziehbar ist. Bei C weiss man 
da schon nicht, ob was nicht funktioniert weil ´ne Klammer falsch 
gesetzt ist oder man tatsächlich z.B. einen Timer falsch initialisiert 
hat.
Und dann versuch mal im Assemblerlisting welches der Compiler auswirft 
den Fehler zu finden.

[S. H. (fat32)]

ja gut, dann probier ichs nochmal mit assembler

wo gibts ein GUTES tutorial? sorry, das hier auf der page ist für leute, 
die sonst immer nur mit BASIC und C gearbeitet haben einfach nicht 
geeignet ;-)

[Guest (Gast)]

Was erwartest du denn? Kannst dir ja nen Buch "Assembler für Anfänger" 
kaufen!

[Karl H. (kbuchegg)]

S. H. wrote:
> ja gut, dann probier ichs nochmal mit assembler
>
> wo gibts ein GUTES tutorial? sorry, das hier auf der page ist für leute,
> die sonst immer nur mit BASIC und C gearbeitet haben einfach nicht
> geeignet ;-)

Was stimmt daran deiner Meinung nach nicht?

[gtf (Gast)]

Wenn du das AVR ASM- Tutorial durchmachst dann wirst du
so gut wie keine Fragen mehr haben.
Wenn du in die "Oberliga" willst ;- ) dann würde ich dir empfehlen
zumindest jede  dritte Seite ausm Datenblatt zu lesen.
Mit jede zweiten Seite bist in der "Spitzenliga" ;- )

Wie Warte ich mit Assembler?
Anwort: Buch zu Computer aus.->
Und hol dir en Hefeweizen :-)

[S. H. (fat32)]

Karl heinz Buchegger wrote:
> S. H. wrote:
>> ja gut, dann probier ichs nochmal mit assembler
>>
>> wo gibts ein GUTES tutorial? sorry, das hier auf der page ist für leute,
>> die sonst immer nur mit BASIC und C gearbeitet haben einfach nicht
>> geeignet ;-)
>
> Was stimmt daran deiner Meinung nach nicht?



nicht gut genug erklärt

[Hannes L. (hannes)]

S. H. wrote:
> nicht gut genug erklärt

Dicke Lüge!!!

...

[Karl H. (kbuchegg)]

S. H. wrote:
> Karl heinz Buchegger wrote:
>> S. H. wrote:
>>> ja gut, dann probier ichs nochmal mit assembler
>>>
>>> wo gibts ein GUTES tutorial? sorry, das hier auf der page ist für leute,
>>> die sonst immer nur mit BASIC und C gearbeitet haben einfach nicht
>>> geeignet ;-)
>>
>> Was stimmt daran deiner Meinung nach nicht?
>
>
>
> nicht gut genug erklärt

Okay. Kannst du das auch in etwas konstruktiverer Kritik
festmachen?
Vorschlag: Geh das Tutorial von Anfang an durch. Wenn dir
etwas unklar ist, dann frage hier. Auf die Art kann ich sehen
wo's hapert, ob das ein Problem im Tutorium ist (oder ob du
dich einfach nur dumm anstellst) und kann versuchen das Tutorium
an dieser Stelle klarer zu formulieren oder zu überarbeiten oder
neue Passagen aufzunehmen.

Was aber unfair ist, das ist wenn du momentan ein konkretes
Problem hast, das zur Zeit nicht im Tutorial behandelt wird
und das dann als: "Nicht gut genug erklärt" abtust.

Auch wenn Warteschleifen nicht die feine Englische Art sind,
so kommen sie doch in einigen Programmen im Tutorium vor,
wenn auch nicht unbedingt in den Allerersten.

[R2D2 (Gast)]

nop

[Andreas W. (Gast)]

Jeder versteht einen Tutorial anders gut.

ich hab wa mit
http://www.avr-asm-tutorial.net/
gelernt.

Da ist dein Blinkled auch mehrmals drin.
http://www.avr-asm-tutorial.net/avr_de/avr_tut.html
beispiele 1-3

Es gibt ein ganz neues Gefühl für einen µC wenn man ein wenig ASM 
programmiert hat, versuch es einfach mal ein wenig vor allem die 
Interrupts.

[S. H. (fat32)]

@Karl heinz Buchegger:

z.B. das mit den AND, XOR, NOT-Dingen, das ist einfach nicht genau 
genug, finde ich

also ich kann damit gar nix anfangen

[Karl H. (kbuchegg)]

S. H. wrote:
> @Karl heinz Buchegger:
>
> z.B. das mit den AND, XOR, NOT-Dingen, das ist einfach nicht genau
> genug, finde ich
>
> also ich kann damit gar nix anfangen

Okay. Das BASIC Programmierer damit nichts anfangen können,
mag sein. Einen C Programmierer lässt das hingegen völlig
kalt.

Das hat jetzt aber alles nichts mit einer blinkenden LED und
dem Zusammenhang mit den Timern zu tun.
Ich hab mir nochmal den Abschnitt über Timer durchgelesen.
Ich finde eigentlich schon, dass der sogar ziemlich gut
auf die Problematik: "Wie lasse ich eine LED mit einem
Timer blinken" eingeht.

[S. H. (fat32)]

naja, egal... was anderes

.include "m8def.inc"
     ldi r16, 0b11100011
     out DDRD, r16

     ldi r16, 0x00
     out PORTD, r16




loop:
 
         

     sbis PIND, 2     

     rjmp ledan  

     rjmp ledaus

     rjmp loop
        
     
  

ledan: 
     ldi r16, 0b00100000
     out PORTD, r16
ret 

ledaus:
     ldi r16, 0b00000000
     out PORTD, r16
ret 

ende: rjmp ende

die LED leuchtet solange, bis der Taster gedrückt wird. lässt man ihn 
los, geht sie wieder an
das klappt soweit auch, ABER:
wenn der taster gedrückt ist, flackert sie alle paar sec immer noch ganz 
schwach

(habe das atmel evalutions board von pollin)
was mach ich hier falsch?

[S. H. (fat32)]

Andreas W. wrote:
> Jeder versteht einen Tutorial anders gut.
>
> ich hab wa mit
> http://www.avr-asm-tutorial.net/
> gelernt.
>
> Da ist dein Blinkled auch mehrmals drin.
> http://www.avr-asm-tutorial.net/avr_de/avr_tut.html
> beispiele 1-3
>
> Es gibt ein ganz neues Gefühl für einen µC wenn man ein wenig ASM
> programmiert hat, versuch es einfach mal ein wenig vor allem die
> Interrupts.

das schau ich mir mal an
danke für den link

[Rüdiger K. (sleipnir)]

Eine prima Gelegenheit um die Sache mit dem Takte-Zählen zu lernen!

 also:

        ldi  r15,N       ; (1T)
 loop:  dec  r15         ; (1T)
        brne loop        ; (2T/1T)

 Du brauchst einen Takt zum Laden der Zeitkonstante und in der Schleife 
bei einem Schleifendurchlauf 3 Takte (dec 1 Takt, 2 Takte für brne wenn 
gesprungen wird) und 2 Takte wenn die Schleife verlassen wird. Das 
gleicht sich aber mit dem Takt Ladebefehl aus. Insgesamt verbraucht das 
Konstrukt also N*3 Takte (Vorsicht: beim Aufruf mit CALL/RET kommen noch 
ein paar Takte dazu!). Läuft der µC mit 4 MHz benötigt ein Takt 
1/4e6=0.25 µs. Allgemein ist mit f=Taktfrequenz die Formel
 Dauer=3*N/f
oder N=Dauer*f/3

Bei 4 MHz Taktfrequenz bräuchtest Du also für 200ms
 N=200e-3*4e6/3=266666.67 Takte. Das ist mehr als in ein 8-Bit-Register 
paßt. Für diesen Fall könnte man zwei verschachtelte Schleifen nehmen 
ODER man benutzt einen Zeitgeber-Interrupt. Aber das ist ja hier im 
Tutorial beschrieben.

Versuch doch mal selbst ein Programm mit verschachtelten Schleifen zu 
entwerfen welches die 200ms hinkriegt! Sollte eine gute Übung sein.

[Tassilo B. (big_t)]

Also bei aller Freundschaft, aber was soll man denn bei AND, OR etc. 
noch erklären?

Tassilo

[Hannes L. (hannes)]

Karl heinz Buchegger wrote:
> Okay. Das BASIC Programmierer damit nichts anfangen können,
> mag sein.

Das stimmt nicht. Ich oute mich hiermit als jemand, der in BASIC 
programmiert hat (KC-Basic 3.1, CBM-Basic 3.5, QBASIC, VB6). Und die 
logischen Operationen AND, OR, EXOR, NOT sind auch in BASIC 
erforderlich, wenn man mit Einzelbits arbeiten will.

Ich vermute stark, dass da das Verständnis für die absoluten Grundlagen 
fehlt, das wurde früher (Schule?) versäumt, das kann ein noch so gutes 
Tutorial nicht nachholen. Das Alphabet sollte man schon beherrschen, 
wenn man einen Roman lesen will...

...

[Matthias (Gast)]

    rjmp ledaus

     rjmp loop
        
     
  

ledan: 
     ldi r16, 0b00100000
     out PORTD, r16
ret

Das geht nicht!

Wenn du ein Unterprogramm (ledan) schreibst, und diese dann 
(richtigerweise) mit RET verlässt, dann solltest du dieses mauch mit 
(R/I)CALL aufrufen!
springst du mit (R)JMP dahin, und mit RET zurück, holt der µC beim 
Zurückspringen (sinnlose) Adressen von Stack und springt da hin...

[Simon K. (simon)]

Matthias wrote:
> Zurückspringen (sinnlose) Adressen von Stack und springt da hin...

Der ohnehin nicht initialisiert wurde..


JAJA in BASIC braucht man das nicht... Ums dir schonmal vorweg zu 
nehmen.

[S. H. (fat32)]

> Wenn du ein Unterprogramm (ledan) schreibst, und diese dann
> (richtigerweise) mit RET verlässt, dann solltest du dieses mauch mit
> (R/I)CALL aufrufen!
> springst du mit (R)JMP dahin, und mit RET zurück, holt der µC beim
> Zurückspringen (sinnlose) Adressen von Stack und springt da hin...

achso
thx

so gehts :-)


>JAJA in BASIC braucht man das nicht... Ums dir schonmal vorweg zu
>nehmen.

kannst du mich vielleicht mal in ruhe lassen?

[Karl H. (kbuchegg)]

S. H. wrote:
>> Wenn du ein Unterprogramm (ledan) schreibst, und diese dann
>> (richtigerweise) mit RET verlässt, dann solltest du dieses mauch mit
>> (R/I)CALL aufrufen!
>> springst du mit (R)JMP dahin, und mit RET zurück, holt der µC beim
>> Zurückspringen (sinnlose) Adressen von Stack und springt da hin...
>
> achso
> thx
>
> so gehts :-)

Wenn deine Hauptschleife jetzt so aussieht

loop:
     sbis PIND, 2     
     rcall ledan  
     rcall ledaus

     rjmp loop

dann glaub ich dir das immer noch nicht, dass das jetzt geht.

Wenn der sbis zuschlägt, dann wird zwar korrekterweise der
rcall ledan
übergangen und mit dem
rcall ledaus
weitergemacht.

Aber: Wenn der sbis nicht zuschlägt, dann wird der
rcall ledan
ausgeführt, das Unterprogramm aufgerufen. Dieses kommt irgendwann
zurück, genau an die STelle von wo aus der Aufruf erfolgt ist.
Und weiter gehts dann mit dem
rcall ledaus

D.h. in diesem Fall 'blinkt' deine LED. Sie blinkt zwar rasend
schnell, aber die LED ist nicht auf Dauer-Ein.

Noch ein Hinweis:
Nicht umsonst wird im Tutorial gerade bei den ersten Programmen
immer wieder mal der Simulator im AVR-Studio erwähnt. Du solltest
den mal ausprobieren. Da müsste man den Effekt sehr gut sehen
können (und ausserdem schadet es überhaupt nicht, sich mit dem
Teil möglichst früh vertraut zu machen)