AT8515L mit STK500

novski

Neues Mitglied
15. Juni 2009
9
0
0
Region Zentralschweiz
Sprachen
Hallo
Also vom STK500 wechsle ich nach hinweis hier unter Software...

Meine Frage ist zu http://www.avr-praxis.de/forum/showthread.php?t=290.

In den erklärungen wird die m8.def verwendet. ich habe aber nur einen ATMEGA8515 desshalb habe ich die .def auf m8515.def geändert. Nun springt mir das Programm im Debugmodus mit Autostep schon über 6435 zyklen immer zwischen "dec r17" und "brne zeit1



CodeBox assembler
.include "m8515def.inc"    ;Definitionsdatei fuer den ATmega8 dazuladen
.cseg ;Beginn eines Code-Segmentes
.org 0 ;Startadresse=0x0000 (Anfang des Flash)

ldi r16,0b11111111 ;PortD alle Bits auf Ausgang
out ddrd,r16 ;setzen

clr r16 ;Anfangswert setzen (alles Low)

mainloop: ;Ein Sprunglabel

out portd,r16 ;Daten an PortD ausgeben
inc r16 ;Datenwert erhoehen


; Unsere Zeitverbrater-Routine mit 16-Bit-Zaehler

clr r17 ;Anfangswert r17 setzen (auf 0)
clr r18 ;Anfangswert r18 setzen (auf 0)
zeit1: ;noch ein Sprunglabel
dec r17 ;Zaehler r17 vermindern (-1)
brne zeit1 ;Zum Label zeit1 springen wenn r17 noch nicht wieder 0 ist
dec r18 ;Zaehler r18 vermindern (-1)
brne zeit1 ;Zum Label zeit1 springen wenn r18 noch nicht wieder

rjmp mainloop ;Schleife neu beginnen (Eine Endlosschleife)




Besten Dank



ps. irgendwas stimmt mit dem forum nicht ich hab jetzt 2 mal nachgebessert weil es mir den letzten teil immer löscht...
 
Hi novski,

In den erklärungen wird die m8.def verwendet. ich habe aber nur einen ATMEGA8515 desshalb habe ich die .def auf m8515.def geändert. Nun springt mir das Programm im Debugmodus mit Autostep schon über 6435 zyklen immer zwischen "dec r17" und "brne zeit1



CodeBox assembler
.
..
...
; Unsere Zeitverbrater-Routine mit 16-Bit-Zaehler

clr r17 ;Anfangswert r17 setzen (auf 0)
clr r18 ;Anfangswert r18 setzen (auf 0)
zeit1: ;noch ein Sprunglabel
dec r17 ;Zaehler r17 vermindern (-1)
brne zeit1 ;Zum Label zeit1 springen wenn r17 noch nicht wieder 0 ist
dec r18 ;Zaehler r18 vermindern (-1)
brne zeit1 ;Zum Label zeit1 springen wenn r18 noch nicht wieder
...
..
.
das mit der "Zeitverbrater-Routine" kommt mir irgendwie bekannt vor :D

Hallo Novski,

ich weiß jetzt nicht genau, was dein Programm machen soll, bin inzwischen auch schon ziemlich müde :rolleyes:
Das Progrämmchen ist aus einer meiner FAQs. Das macht eigentlich nix
anderes als nen Binären Zähler an den LEDs am PortD zu generieren.
Es wird also mit den Bits durchgezählt. Oder anders ausgedrückt .. die
LEDs am PortD blinken verschieden schnell.

So wie es aussieht macht der Debugger was anderes als die Prozessoren :eek:
Der Befehl "dec" (decrement) subtrahiert 1 vom Registerinhalt und
beeinflußt damit auch die Bits im Statusregister (Zero, Carry, ..) und darum
sollte das mit dem "brne" (Branch If Not Equal) auch funktionieren, da der
Sprungbefehl auf das Zero-Flag reagiert. Bei mir läuft das auf jeden Fall
bis jetzt mit allen verwendeten Prozzis (AT90S2313, ATtiny2313, ATmega16,
ATmega32, ATmega8535, ATmega48, ATmega168, ATmega128). Also würde
ich eher dem Debugger als Fehlerquelle sehen ;) Sch... Software :eek: :D

Ich teste meine Programme mittlerweile auch nicht mehr im Debugger sondern
direkt auf der Hardware. Nach meinen Erlebnissen mit dem Debugger hab ich
mich dazu entschlossen. Bei kleinen Programmen mag das mit dem Debugger
noch irgendwie funktionieren aber bei Warteschleifen mit mehreren tausend
Durchläufen oder größeren Programmen die auf komplizierter Hardware laufen
sollen wird das Verfahren ziemlich witzlos.

Ich gebe Statusinfos vom Programm auf dem sowieso meißt angeschlossenen
LCD oder auf Status-LEDs oder auf der USART(RS232) zum PC aus. Und wenn
man die Programme im Fehlerfall im Kopf durchspielt und die Statusinfos dazu
betrachtet kommt man dem Fehler ziemlich schnell auf die Spur.

ps. irgendwas stimmt mit dem forum nicht ich hab jetzt 2 mal nachgebessert weil es mir den letzten teil immer löscht...
Das hab ich auch ab und zu mal. Das kommt bei mir aber vom Touchpad am
Lappi. Das ist überempfindlich :rolleyes: Da wird dann beim tippen aus versehen
was selektiert und dann werden die gedrückten Tasten aus Versehen als
Kommandos verstanden und evtl "Blocklöschen" ausgeführt. Als Gegenmaßnahme
hab ich mir jetzt angewöhnt ab und zu mal auf "Vorschau" zu klicken. Dann
kann man die "Veränderungen" oben mit "Rückgängig/Undo" bis zu dem
Punkt rückgängig machen an dem man das angeklickt hat.

Gruß
Dino
 
Interner Prozessoraufbau

Hi novski,

mal ne Frage ... kennst Du den internen Aufbau des Prozessors und die Funktionen
bzw den Ablauf von Aktionen im Prozessor (Accumulator, Flags, Stackpointer,
Programmcounter, ...) oder soll ich da mal ein wenig zu erzählen ?

Ich wollte den letzten Beitrag nicht noch länger machen ;)

Gruß
Dino
 
Auch gerade erkannt!

Hi Dino03
Wie schön es ist wenn man die gleichen fehlervermutungen aufstellt und dann der Profi das bestätigt. Ich hatte das forum nicht aktualisiert und ein wehnig mit der Hilfe des Programms den fehler eingegrenzt. so:

Code:
.include "m8515def.inc"    ;Definitionsdatei fuer den ATmega8 dazuladen
.cseg                   ;Beginn eines Code-Segmentes
.org 0                  ;Startadresse=0x0000 (Anfang des Flash)
 
   ldi r16,0b11111111  ;PortD alle Bits auf Ausgang
    out ddrd,r16        ;setzen
 
    clr r16             ;Anfangswert setzen (alles Low)
 
mainloop:               ;Ein Sprunglabel
 
    out portd,r16       ;Daten an PortD ausgeben
    inc r16             ;Datenwert erhoehen
 
    	
; Unsere Zeitverbrater-Routine mit 16-Bit-Zaehler

    clr r17         ;Anfangswert r17 setzen (auf 0)

zeit1: dec r17         ;Zaehler r17 vermindern (-1)

	cpi r17,-25
    brne    zeit1   ;Zum Label zeit1 springen wenn r17 noch nicht wieder 0 ist

    rjmp    mainloop    ;Schleife neu beginnen (Eine Endlosschleife)


bei "cpi r17, 0" geht der Debuger nie aus dem loop raus... bei "cpi r17, -25" bei jedem 25 zyklus aber schon...

cool danke für die bestätigung.

Ja klar bin ich interessiert... währe absolut grossartig eine einführung in die innereien eines uP zu bekommen...

nun aber vorerst gute Nacht.

novski

PS: das problem scheint immer zu sein. ab dem punkt wo der [.code.] fertig ist ist mein text erst einmal weg... mit zurück und copy paste kann ich ihn dann über ändern wieder einfügen... komischer editor...
 
Hi @novski,
also Simulator kann auch nicht alles:)
Zeitschleifen, Interrupts, Portzustandsabfragen, wie soll der das denn machen., hmmm?
Hier muß echt mal die Hardware ran, also Fuses einstellen, assemblieren (compilieren) Hexfile flashen. Dann mal gucken, was passiert (oder auch nicht).


Gruß von Oskar01
 
Hallo novski,

Hi Dino03
Wie schön es ist wenn man die gleichen fehlervermutungen aufstellt und dann der Profi das bestätigt. Ich hatte das forum nicht aktualisiert und ein wehnig mit der Hilfe des Programms den fehler eingegrenzt.
ich schätze mal du meinst das mit dem verlorenen Text ;)
Das hab ich auf der Arbeit mit meinem Firmenlaptop tlw auch. Ich nehme mal
an, es liegt an der Handhaltung auf der Tastatur, das man zu nahe ans Pad
kommt. Ist bei mir aber auch bei anderen Anwendungen. Aus dem Grund kann
man bei manchen Laptops das Pad abschalten.

so:

Code:
.include "m8515def.inc"    ;Definitionsdatei fuer den ATmega8 dazuladen
.cseg                   ;Beginn eines Code-Segmentes
.org 0                  ;Startadresse=0x0000 (Anfang des Flash)
 
   ldi r16,0b11111111  ;PortD alle Bits auf Ausgang
    out ddrd,r16        ;setzen
 
    clr r16             ;Anfangswert setzen (alles Low)
 
mainloop:               ;Ein Sprunglabel
 
    out portd,r16       ;Daten an PortD ausgeben
    inc r16             ;Datenwert erhoehen
 
    	
; Unsere Zeitverbrater-Routine mit 16-Bit-Zaehler

    clr r17         ;Anfangswert r17 setzen (auf 0)

zeit1: dec r17         ;Zaehler r17 vermindern (-1)

	cpi r17,-25    ; <<<<<< !!!!!!!
    brne    zeit1   ;Zum Label zeit1 springen wenn r17 noch nicht wieder 0 ist

    rjmp    mainloop    ;Schleife neu beginnen (Eine Endlosschleife)


bei "cpi r17, 0" geht der Debuger nie aus dem loop raus... bei "cpi r17, -25" bei jedem 25 zyklus aber schon...
Denk dran, du arbeitest mit Assembler. Das ist die unterste Ebene. Der
Prozessor kennt keine Fließkommazahlen, negative Werte, ... Nur Bits und
Bytes. Was der Assembler beim Übersetzen aus dem -25 macht kann ich dir
jetzt nicht auf Anhieb genau sagen. Es könnte ein 2er Komplement werden.
Sieh dir mal das an ...
Bascom: verzweigen wenn Wert nicht in Tabelle Beitrag #5
Da hab ich das mit dem 1er und 2er-Komplement mal erklärt.
Wenn ich das jetzt richtig gerechnet habe müßte da folgendes bei
rauskommen ...

dez -25 => dez 231 , hex 0xE7 , bin 0b11100111

das ist für den Prozessor alles identisch - nur andere Schreibweisen
Ich hoffe, du verstehst hier, auf was du dich da eingelassen hast :D ;)
Das sind die Werte, die der Prozessor dann als Bits in einem 8Bit-Register
stehen hat. Er würde also den Wert in r17 mit 231(dez) vergleichen.

cool danke für die bestätigung.
Meinst du den Debugger ? Wenn ja, ... den hab ich bei mir nur ein einziges
Mal genommen (ganz früh am Anfang) :D

Ja klar bin ich interessiert... währe absolut grossartig eine einführung in die innereien eines uP zu bekommen...
Kann ich ja mal nach und nach was zusammenschreiben ...

PS: das problem scheint immer zu sein. ab dem punkt wo der [.code.] fertig ist ist mein text erst einmal weg... mit zurück und copy paste kann ich ihn dann über ändern wieder einfügen... komischer editor...
Bedenke das du in einer Webanwendung arbeitest. So lange der Text nur im
Eingabefenster ist, existiert er nur in deinem Browser. Erst wenn man mal
auf Vorschau oder Antworten geklickt hat, wird der Text vom Server
übernommen und ist auch dort vorhanden. Ich hab auch aus versehen schon
mal nach der Vorschau den Browser-Tab geschlossen ;) Und schon waren
ein paar Bildschirmseiten im Nirvana :eek:

Ich hab also bei mir mit dem Firefox (immer die aktuelle Version) noch keine
Probleme gehabt. Wenn man allerdings beim Ändern von Beiträgen in der
Mitte was getippt hat, dann fügt er einen neuen Tag (Code oder Zitat, ...)
ans Ende an. Man muß also erst mal mit dem Cursor an die Stelle wo es hin
soll. Ist aber alles Gewöhnungssache.

Gruß
Dino
 
Umdenken bei Assembler ...

Hallo novski,

nun mal ein paar Infos, warum man in Assembler etwas Umdenken muß ...

Wie schon geschrieben, gibt es in Assembler keine negativen Zahlen oder
irgendwas mit Komma oder Exponent. Es gibt nur Bits und daraus aufgebaute
Bytes (8Bit) , Wörter (word / 16 Bit), Langwörter (longword / 32 Bit) , ...
Der Prozessor kennt nur Integerzahlen. Die gesamte Interpretation ob es
eine negative Zahl oder Fließkommazahl oder was auch immer ist, das macht
nur der Programmierer und nachher das Programm. Wie vorher schon gezeigt ...

-25 (dez) == 231 (dez) == 0xE7 (hex) == 0b11100111 (bin) == ç (chr)

das ist für den Prozessor absolut identisch. Es wird im Quellcode nur für den
Menschen anders reingetippt und man kann es vom Programm anders
behandeln lassen (wenn man es programmiert) sonst ist das Schnuppe.
Wenn man zB den Wert 0x51 (hex) == 81 (dez) zu nem LCD schickt um die
"Zahl" anzuzeigen, dann erscheint da nur ein goßes "Q" :D weil in der
Zeichentabelle des LCDs der Wert 0x51 ein Q ist (siehe ASCII-Tabelle).
Man kann also in Assembler wild zwischen den Definitionen eines Wertes
hin und her springen.

Ein Beispiel :

Man hat folgenden Wert ...

0x20 == 32 == 0b00100000

wenn man den Wert jetzt mit 2 multiplizieren möchte, verwendet man "lsr"
(logical shift right). Man schiebt also alle Bits nach rechts zum MSB
(Most Significant Bit = höchstwetigstes Bit). Dann sieht das so aus ...

0x40 == 64 == 0b01000000

Man hat also die Zahl mit 2 multipliziert obwohl man eigentlich nur die Bits
verschoben hat. :D

Löse dich also von Variablen und anderem Ballast, den du aus anderen
Programmiersprachen kennst. In Assembler kommt es nur darauf an, als
was du den Wert für dich in deinem Programm benutzt.

=== Bedingungen und Sprünge ===
In Assembler gibt es kein "If Then Else" ;) Auch hier muß man umdenken. Das
hat mit der internen Struktur des Prozessors und der Verarbeitung der Befehle
zu tun. Und das sieht folgendermaßen aus ...

Du benutzt einen Befehl wie zB "inc r16" . Der zieht vom r16 Eins ab.
Also wird das Register r16 incrementiert (-1). Dieser Befehl beeinflußt bei der
Bearbeitung auch die Statusbits im Statusregister. Je nachdem was bei der
Verarbeitung des Bytes im r16 rauskommt wird d zB das Carry-, Zero-,
HalfCarry-, Negative-Bit gesetzt usw. Diese Statusbits beinhalten jetzt das
Ergebnis dieser Operation. Und genau auf diese Statusbits kann dann der
nächste Befehl reagieren. Zum Beispiel mit "brcc" (Branch if Carry Cleared)
also springen wenn das Carry-Bit im Status-Register gelöscht (=0) ist.
In einer anderen Sprache würde das in etwa so aussehen ...

r16 = r16 - 1
if (r16>255 or r16<0) then Goto xyz

In Assembler so ...

inc r16
brcc xyz

Das Carry-Bit zeigt einen "Überlauf" des Registers an, zB von 255 auf 0 oder
umgekehrt. Man hat ja nur 8Bit und wenn man zu 255 eins addiert gibt es
keine 256 sondern 0 ;) und wenn man von 0 eins abzieht bekommt man keine
-1 sondern 255. Das Carry wird in dem Fall gesetzt und zeigt an, das die
8Bit des Registers beim letzten Befehl nicht mehr ausgereicht haben.

Man muß in Assembler also immer "zwischen den Zeilen lesen" und im
Hinterkopf immer an die Sstatusbits denken, die von den Befehlen beeinflußt
werden. Ich hab mir als Hilfe den "Instruction-Set" für die 8Bit-AVRs
ausgedruckt. Da steht für jeden Befehl eine Erklärung mit kurzem Beispiel und
was der Befehl für Status-Bits verändert oder auf welche er reagiert. Das
würde ich dir auch empfehlen. Welche Befehle mit welchen Registern und
in welchen Adressierungsarten arbeiten können, kann man nämlich nicht
unbedingt im Kopf haben. Dafür sind es zu viele Kombinationsmöglichkeiten.;)
Guckst du hier ... AVR Instruction Set (151 pages, revision G, updated 7/08)
Wenn der Link mal nicht funktioniert ...
Atmel.com >> AVR 8Bit-Risc >> Other Documents >> User Guide (ca auf 2/3 der Seite)

Assembler ist auf jeden Fall "ein Erlebnis" und man lernt die Hardware dabei
"richtig" kennen :D

Gruß
Dino

- - - - - Edit - - - - -
nimm mein Beispiel oben mit dem "inc" NUR als Beispiel. Es funktioniert mit
dem Carry-Bit nicht. Laut "Instruction-Set" ...
The C Flag in SREG is not affected by the operation, thus allowing the INC instruction to be used on a loop counter in multiple-
precision computations.
Es werden durch den "INC"-Befehl also nur die Status-Bits S,V,N,Z verändert.
Wie man sieht benötigt man die PDF beim Assembler programmieren :D
Wenn man also das Carry-Flag verwenden will muß man das wohl so machen ...

ldi r17,1 ; Eins in Register r17
adc r16,r17 ; die Eins zum Register r16 addieren (Add with Carry)
brcc xyz ; Springen wenn es einen "Überlauf" gab

so sieht das aus ;)
 
Nochn Gedicht - Ein hab ich noch

Nochmal Hallo,

hier ist mal ein Bild ...
AVR-ALU.png

es geht um den rot unterlegten Teil. Das ist das eigentliche Herz des Prozessors.
Die ALU (Arithmetic Logic Unit), also der Schaltungsteil der Rechen- und Logic-
Operationen mit den Register-Inhalten durchführt.

Oben sieht man die Registersätze (r0..r31) die dann für eine Operation in den
linken oder rechten Schenkel der ALU (das V) geladen werden. Das was dabei
rauskommt beeinflußt dann teilweise auch die Bits im Status-Register (unter
der ALU). Das Bild kann man in voller Schönheit im Datenblatt ansehen ;)

Alles was der Prozessor ausführen kann ist hier in der ALU in Hardware
gegossen. (Grob ausgedrückt).

Gruß
Dino
 
Assemblerkram auf dem STK500 mit ATmega8515

Hallo zusammen,
hallo dschi dschei,
hallo boeserkorn und
hallo novski,

ich hab mal was zusammengestellt (unter anderem wegen dem und diesem Thread) ...

Also mein STK500 mit ATmega8515 funktioniert an meinem EeePC1000 über
nen USB-RS232-Dongle ohne Probleme :D
Hier ein Bild ...
STK500.jpg

ich laß dieses Programm drauf laufen Anhang anzeigen Mega8515-Test.asm
(Sind noch Reste von ATmega8535-Bemerkungen drin).
Hier ist es im AVRStudio4 geladen ...
STK500_StudioM8515.gif

wegen Uploadfile-Reglementierung (max 5 Files) in neuem Beitrag weiter ...
 
weiter gehts ... (Fortsetzung)

jetzt mal ein paar Bilder vom Programmer-Fenster ...
STK500_MainM8515.gif
hier ist die Grundeinstellung zu sehen (Prozessortyp, ...)

Auf dem folgenden Bild hab ich den Prozessor gelöscht (Erase) ...
STK500_EraseM8515.gif
hat wunderbar funktioniert. Danach ist er mausetot und sagt an den Pins
keinen Mucks mehr (also kein LED-Geflacker)

Auf diesen Bildern hab ich das Programm geflasht (Program) ...
STK500_ProgM8515_1.gif STK500_ProgM8515_2.gif
bei den beiden Bildern sind unten die Log-Zeilen weitergedreht damit man
alles sieht. Hat auch wunderbar funktioniert.

und auf dem letzten Bild sind die Fuse-Einstellungen zu sehen, die ich
verwendet habe ...
STK500_FusesM8515.gif
Ich hab ihn auf 8MHz und internem Takt laufen lassen.

So ... nun viel Spaß beim basteln ;)

Gruß
Dino
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)