mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega8 Anfängerproblem


Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

hab vor kurzem begonnen mich mit µC's zu beschäftigen. Hab das AVR 
Tutorial durchgemacht und mir die passende Hardware besorgt.

Doch der Anfang ist schwer und deshalb wende ich mich an euch.

Ich hab mir den Yampp Programmer zusammengelötet und mit dem ATmega 8 
verbunden. Auf der µC Platine befinden sich 2 led's, die an PB0 und PB1 
über ein R an +5V angeschlossen sind.

Um die Funktionstüchtigkeit zu testen hab ich folgendes Progrämmchen 
geschrieben (Im Anhang).

Die LED's sind aber die ganze Zeit an, anstatt zu blinken.

Oder mach ich was falsch???

Übrigens der Yampp programmer erkennt den ATmega8.

Gruß Alex

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi!

kenne mich mit assembler nicht so aus, aber es ist gut möglich das deine 
led´s blinken, nur geht das ganze so schnell das du es nicht sehen 
kannst. wenn möglich mit nem oszi mal messen, oder die 
oszillatorfrequenz so weit wie möglich runter schrauben und die 
warteschleifen länger machen.

gruss michael

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alex,

wenn ich das jetzt richtig sehe, dann werden in Deinen warteschleifen 
nur je 258 mal "Dinge" getan. Du hast aber eigentlich mit 3 * 256 
"Dinge" gerechnet.
Das könnte kurz werden.
Brne überprüft das Zero Flag, das wird aber nur einmal Null und rauscht 
dann aus allen Schleifen raus. Es gibt nur ein Zeroflag, Du musst es 
also auch auswerten, wenn eine Operation es gesetzt haben kann. Hm, und 
jetzt finde BRNE nur als Test nach CP, CPI, SUB und SUBI, jedenfalls in 
meinem AVR Instruction Set.
Ich bin kein Profi, habe selbst gerade angefangen, kann mich also auch 
täuschen.

Ach so, ich hab mich beim testen darauf beschränkt, einfach eine LED 
anzuschalten und die andere aus. Im nächsten Programm habe ich dann das 
Muster umgedreht. Damit hatte ich keine Probleme mit zu schnell 
blinkenden LED's.

Viele Grüße
Sebastian

Autor: Crush (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls du denn Quellcode einfach nur kopiert hat liegt es vielleicht ja 
auch an dem Rechtschreibfehler: brne scleife1

Autor: Hansi Lein (fabian87)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nunja ohne nen timer bzw. ein delay (primitiv) wirste da nicht viel 
sehen, wenn die led sich in der sekunde nen paar tausendmal an und 
ausschalten soll

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und wieso '.include "4433def.inc"', wenn Du den Mega8 benutzt?

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

@Oli
was wird denn sonst eingefügt, so ist es doch im Tutorial beschrieben, 
zumindest heißt es, dass der mega8 zu dem dort eingesetzten µC 
kompatibel ist.



@Fabian
Wieso ein paar tausend mal? 3xSchleife je 256=16Mio. Und bei 4MHz müsste 
die LED doch alle 4sec blinken? Zwar hat sebastian geschrieben, dass die 
Schleife nur einmal durchlaufen wird, doch beim debuggen im AVR Studio 
laufen die Schleifen genauso geschachtelt durch und springt auch nichts 
raus

Gruß Alex

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich geb dir Recht, dass das im Tutorial nicht klar genug
herausgearbeitet wird.
Für einen Mega8 nimmst du
.include "m8def.inc"

> Wieso ein paar tausend mal?
Weil es ganu das ist was passiert.

> 3xSchleife je 256=16Mio.

Nicht wirklich. Deine Schleifen sind nämlich in Wirklichkeit
nicht ineinander geschachtelt. Ich kann dir nur raten
spiel das mal im AVR-Simulator durch.

schleife1:   dec r17
schleife2:   dec r18
schleife3:   dec r1
             brne schleife3
             brne schleife2
             brne scleife1

In dem Moment in dem die Statusflags so sind, dass die
innerste Schleife (über r1) verlassen werden kann, sind
die Flags auch für den nächsten brne so, dass er nicht
mehr springt. Und auch für den dritten.
D.h. deine 3 'Schleifen' zählen nur r1 runter. Die
beiden restlichen brne testen nämlich nicht ab, ob r18
bzw. r17 zu 0 gewroden sind. Die testen immer noch
ob r1 zu 0 geworden ist. Wenn man es genau nimmt, und
das sollte man in Assemblerprogrammierung, dann testet
der brne auch nicht ab ob r1 zu 0 geworden ist. Dem
brne ist r1 sowas von Schnuppe. Den interessieren nur
die Statusflags. Wer oder was die Statusflags auf
einen bestimmten Zustand eingestellt hat, interessiert
ihn nicht die Bohne. Nur leider ändern sich die Status
Flags nicht wenn der erste brne nicht springt. Der nächste
brne testet dieselben Statusflags mit denselben Werten wie
der brne direkt vor ihm und kommt, das sollte jetzt nicht
verwundern, zum gleichen Ergebnis: nicht springen.

Durch deine Einrückung hast du dich selbst ausgetrickst.

schleife:    dec r1
             brne schleife
             dec r18
             brne schleife
             dec r17
             brne schleife

Jetzt gehen die Schleifen tatsächlich 256*256*256 mal
rundum.



Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.