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
Mit nem Timer.
genauer gehts nicht? :-D
Gast
#608258
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?
S. H. wrote: > genauer gehts nicht? :-D Klar! http://www.mikrocontroller.net/articles/AVR-Tutorial:_Timer
Gast
#608260
Genauer geht es schon, aber dazu sollte der Controller bekannt sein.
> 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.
hab nen mega8
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.
Gast
#608271
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
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
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.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Gast
#608289
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
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! ;)
Gast
#608421
>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
warte: Nop
jmp warte
das war´s..... warten bis der Arzt kommt :-))
Gast
#608510
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.
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 ;-)
Gast
#608658
Was erwartest du denn? Kannst dir ja nen Buch "Assembler für Anfänger" kaufen!
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?
Gast
#608671
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 :-)
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
S. H. wrote:
> nicht gut genug erklärt
Dicke Lüge!!!
...
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.
Gast
#608721
nop
Gast
#608731
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.
@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
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.
naja, egal... was anderes
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
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?
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
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.
Also bei aller Freundschaft, aber was soll man denn bei AND, OR etc. noch erklären? Tassilo
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... ...
Gast
#608783
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
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...
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.
> 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?
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
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
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)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.