mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Nochmal Frage zum Assemblerporgramm ATmega16


Autor: Heiner H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe nocheinmal eine Frage zu meinem Programm. Denn es funktioniert 
nicht richtig.
;***************************************
.include "m16def.inc"
;***************************************

.def temp = r16
.def schieb = r17
.def aus = r18
.def an = r19
.org 0x0000
        rjmp    init                  ; Reset Handler
.org OVF0addr
.cseg

init:  ldi     temp, LOW (RAMEND)    ; Stackpointer initialisieren
        out     SPL, temp
        ldi     temp, HIGH (RAMEND)
        out     SPH, temp
    LDI    R22, 0b11111111     ;initialisieren
    OUT    DDRA, r22
    OUT    DDRB, r22
    OUT    DDRC, r22
    OUT    DDRD, r22
    LDI    aus, 0b00000000
    LDI    an, 0b11111111
main:  LDI    schieb, 0b00000000  ;aufbau in rot
main1:  ROL    schieb
    out    PORTA, schieb
    call warten
    CPI    schieb, 0b11111111
    BRNE  main1
main2:  LDI    schieb, 0b00000000
main3:  ROL    schieb
    out    PORTB, schieb
    call warten
    CPI    schieb, 0b11111111
    BRNE  main3
    call warten2
    out    PORTA, aus    ;alles aus
    out    PORTB, aus
main4:  LDI    schieb, 0b00000000  ;aufbau in grün
main5:  ROL    schieb
    out    PORTC, schieb
    call warten
    CPI    schieb, 0b11111111
    BRNE  main5
main6:  LDI    schieb, 0b00000000
main7:  ROL    schieb
    out    PORTD, schieb
    call warten
    CPI    schieb, 0b11111111
    BRNE  main7
    call warten2
    out    PORTC, aus    ;alles aus
    out    PORTD, aus
main8:  LDI    schieb, 0b00000000  ;aufbau in orange
main9:  ROL    schieb
    out    PORTA, schieb
    out    PORTC, schieb
    call warten
    CPI    schieb, 0b11111111
    BRNE  main9
main10:  LDI    schieb, 0b00000000
main11:  ROL    schieb
    out    PORTB, schieb
    out    PORTD, schieb
    call warten
    CPI    schieb, 0b11111111
    BRNE  main11
    call warten2
    out    PORTA, aus    ;alles aus
    out    PORTB, aus
    out    PORTC, aus
    out    PORTD, aus
    nop
    call warten
    out    PORTA, an    ;schrift rot  
    out    PORTB, an
    nop
    call warten2
    out    PORTA, aus    ;alles aus
    out    PORTB, aus
    out    PORTC, an    ;alles grün
    out    PORTD, an
    nop
    call warten2
    out    PORTC, aus    ;alles aus
    out    PORTD, aus
    out    PORTA, an    ;alles orange
    out    PORTB, an
    out    PORTC, an
    out    PORTD, an
    nop
    call warten2
    out    PORTA, aus    ;alles aus
    out    PORTB, aus
    out    PORTC, aus
    out    PORTD, aus
    call warten2  
    rjmp  main


; warte 1999998 Zyklen:
warten: ldi  R23, $12
WGLOOP0:ldi  R24, $BC
WGLOOP1:ldi  R25, $C4
WGLOOP2:dec  R25
        brne WGLOOP2
        dec  R24
        brne WGLOOP1
        dec  R23
        brne WGLOOP0  
    ret

; lange warten
warten2:  ldi  R27, $48
WGLOOP3:  ldi  R28, $BC
WGLOOP4:  ldi  R29, $C4
WGLOOP5:  dec  R29
          brne WGLOOP5
          dec  R28
          brne WGLOOP4
          dec  R27
          brne WGLOOP3
ret

Es geht auch richtig los. zuerts leuchten die roten LED.
Es wird aber Port B2, B1, B5 ausgelassen. Keine Ahnung warum. Dann 
warter er eine Weile und fängt wieder bei von vorn an.
Was ist da los???

Warum geht er nicht im Programm wieter und warum werden die LEDs 
ausgelassen.
Die LEDs sidn aber nicht defekt.
Bitte um Hilfe

Heiner

Autor: Georg C. (citkid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heiner H. wrote:
> Es geht auch richtig los. zuerts leuchten die roten LED.
> Es wird aber Port B2, B1, B5 ausgelassen. Keine Ahnung warum. Dann
> warter er eine Weile und fängt wieder bei von vorn an.
> Was ist da los???

Er warte eine Weile. Was ist eine Weile? 64ms?
Dann klingt das nach Watchdog-Auslösung. Ist Watchdog auf immer aktiv 
geschaltet?

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

Bewertung
0 lesenswert
nicht lesenswert
Heiner H. wrote:

> Es geht auch richtig los. zuerts leuchten die roten LED.
> Es wird aber Port B2, B1, B5 ausgelassen. Keine Ahnung warum. Dann
> warter er eine Weile und fängt wieder bei von vorn an.
> Was ist da los???

Sagte ich schon mal, dass du dich mit deinem Debugger beschäftigen
sollst?

Du brauchst das Ding!
Also beschäftige dich damit, wie man das Teil bedient!
Damit kannst du dein Programm in Einzelschritten durchgehen
und nachsehen, welche Register sich wie verändern.
Du kannst einen Breakpoint setzen und das Programm
simulieren lassen, bis die Programmausführung einen
bestimmten Befehl erreicht. Dort kannst du dann wieder
nachsehen, welche Register welchen Wert haben etc.

Beschäftige dich damit! Du brauchst den Simulator.

Autor: Heiner H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja im Simulator habe ich schon alles ausprobiert. DAs ist ja das 
komische. Dort funktioniert alles.
Wie ist das mit der Watchdog? Ist die von allein angeschaltet?
Und as passiert dann?

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

Bewertung
0 lesenswert
nicht lesenswert
Heiner H. wrote:
> ja im Simulator habe ich schon alles ausprobiert. DAs ist ja das
> komische. Dort funktioniert alles.

Wenn auch nur zufällig. Aber du hast recht, es funktioniert.

> Wie ist das mit der Watchdog? Ist die von allein angeschaltet?

Nein. Hast du an den Fusebits rumgespielt?

> Und as passiert dann?

dann macht der µC einen Reset und fängt wieder von vorne an.

Autor: Heiner H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe an den Fusebits das JTAGEN ausgestellt. Weil sonst der PORTc 
nicht funktioniert.

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

Bewertung
0 lesenswert
nicht lesenswert
Mein Fehler.
Der Mega16 hat gar keine Watchdog Fuse.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Heiner,
schau Dir mal den Befehl ROL in der AVR-Dokumentation an.
Vielleicht klärt sich dann, wie aus
LDI schieb, 0b00000000
über
ROL schieb
eine Abfrage
CPI schieb, 0b11111111
sinnig oder unsinnig wird.
Stichwort carry-bit...

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

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Hallo Heiner,
> schau Dir mal den Befehl ROL in der AVR-Dokumentation an.
> Vielleicht klärt sich dann, wie aus
> LDI schieb, 0b00000000
> über
> ROL schieb
> eine Abfrage
> CPI schieb, 0b11111111
> sinnig oder unsinnig wird.
> Stichwort carry-bit...

Drum sagte ich auch, dass es Zufall ist, dass sein Programm
funktioniert. Die 'warten' Subroutines setzen das
Carry Flag.

Ich brenn das ganze jetzt mal in einen Mega16.

Eine Frage noch: Wie sind die LED angeschlossen?
Direkt ueber einen Widerstand oder ist da noch was
dazwischen?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl Heinz,

>Drum sagte ich auch, dass es Zufall ist, dass sein Programm
>funktioniert. Die 'warten' Subroutines setzen das
>Carry Flag.

Nein, tun sie nicht.
DEC beeinflusst kein Carry-Bit.
Dafür gibt es SUBI.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag zu oben...
Nicht, dass ich SUBI in den Warte-Unterprogrammen
empfehlen würde. ;-)
So war das nicht gemeint.
Es wäre extrem schlechter Programmierstil, ein gesetztes
Carry-Bit aus einer Warteschleife heraus zu nutzen.
Wenn es denn so sein soll, bitte die Anweisung
SEC
vor dem
ROL
einfügen.
Kostet nichts und schafft klare Verhältnisse.

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

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Ich brenn das ganze jetzt mal in einen Mega16.

Gesagt, getan.
Sieht eigentlich gut aus. Das Programm setzt eine LED
nach der anderen, so wie es programmiert ist.

Wenn es das bei dir nicht tut, dann liegt die Ursache
irgendwo anders in einem Bereich, den wir nicht einsehen
können.

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

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Hallo Karl Heinz,
>
>>Drum sagte ich auch, dass es Zufall ist, dass sein Programm
>>funktioniert. Die 'warten' Subroutines setzen das
>>Carry Flag.
>
> Nein, tun sie nicht.
> DEC beeinflusst kein Carry-Bit.
> Dafür gibt es SUBI.

OK.
Dann ist es der CPI der das Carry setzt.
(Ist auch logisch, x - FF setzt immer das Carry
es sein denn x sei gleich FF, dann endet aber die
Schleife sowieso. Ich denke trotzdem immer noch nicht,
dass das so beabsichtigt war :-)

Wie auch immer, beim 2.ten und folgendem Durchlauf durch die
Schleife wird definitiv eine 1 aus dem Carry hereinrotiert.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau ;-)
Das ist ein ziemlich tückischer Fehler.
Ich empfehle, mit
SEC
ROL schiebe
für klare Verhältnisse zu sorgen.

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

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Genau ;-)
> Das ist ein ziemlich tückischer Fehler.

Yep.
Ich hab mich auch gewundert als im ersten Schleifendurchlauf
(klarerweise nichts passierte), aber im nächsten Durchlauf
tauchte dann plötzlich die 1 auf. Hab nicht weiter nachgedacht
wo die herkommt und habs mal fälschlicherweise auf die warten
geschoben.

> Ich empfehle, mit
> SEC
> ROL schiebe
> für klare Verhältnisse zu sorgen.

Das ist sicher ein guter Rat. Dadurch ist alles klar.

Aber das erklärt noch nicht, warum bei ihm PB1, PB2 und PB5
nicht mitspielen. An PB5 hängt noch MOSI, d.h. da ist die
ISP Schnittstelle dran. Das liefert aber keine Erklärung für
PB1 und PB2.

Und für die restlichen beiden Ports sowieso nicht.

Was ich mir vorstellen könnte:
Alle 32 LED sind auf ca. 20 mA eingestellt. Dadurch wird
die maximale Stromabgabe überschritten oder das Netzteil
geht soweit in die Knie, dass die Versorgungsspannung
zusammenbricht. Irgendsowas in der Art.

Autor: Georg C. (citkid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Software ist i.O..
Ist deine Energieversorgung auch i.O.?
Wenn du viele LEDs an hast wird auch viel Strom gezogen. Schafft das 
deine Stromversorgung? Mit Oszi überprüfen ob Einbrüche vorhanden. Würde 
Resetverhalten erklähren.
Einzelne Bits werden ausgelassen -> Hardware überprüfen. Schiebe doch 
einfach mal nur ein Bit durch. Dann wird nur eine LED je Port 
ausgegeben. Kurzschlüsse zwischen den Pins lassen sich so leicht finden. 
Auch braucht nur eine LED viel weniger Strom.

Autor: Georg C. (citkid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:
>> Ich empfehle, mit
>> SEC
>> ROL schiebe
>> für klare Verhältnisse zu sorgen.
Der Vergleich sorgt für Carry. SEC ist nicht nötig.
warten erzeugt kein Carry sondern Zero.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PB1, PB2 und PB5?
Verdrahtung prüfen.
LEDs prüfen.
Die betreffenden LEDs sind richtig gepolt?

Autor: Georg C. (citkid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Die betreffenden LEDs sind richtig gepolt?
Und wie ist das mit Kurzschlüssen zwischen den Pins?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Karl heinz Buchegger wrote:
>>> Ich empfehle, mit
>>> SEC
>>> ROL schiebe
>>> für klare Verhältnisse zu sorgen.
>Der Vergleich sorgt für Carry. SEC ist nicht nötig.
>warten erzeugt kein Carry sondern Zero.

Karl kann nichts dafür - der Vorschlag wuchs auf meinem
Mist.
Der erste Rotiervorgang bei mainX wird mit Carry = 0
ausgeführt. Erst die weiteren nach dem Vergleich (CPI)
dann mit Carry = 1.
Ich kann mir nicht vorstellen, dass das bewusst so
vorgesehen war. Wenn doch, dann war es extrem pfiffig
ausgedacht. Dazu passt aber der ganze Programmierstil
nicht so recht. :-)

Wie auch immer - schön (in den Augen eines AVR-Assembler-
Anwenders) ist es nicht.
Auch wenn es vermeintlich überflüssig scheint, das
eingefügte SEC trägt zur Transparenz bei.

Es sind genau solche Optimierungen, die einem bei
komplexeren Projekten dann eine Menge Zeit für
Debugging stehlen.

Autor: Michael Waiblinger (wiebel42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.org 0x0000
        rjmp    init                  ; Reset Handler
.org OVF0addr
.cseg
Ich bin ja auch blutiger Anfänger in AVRasm, aber was erhoffst du dir 
von dem Timer0 Overflow Interrupt? Oder hab ich was übersehen?
Gut, mal abgesehen davon das du gar keinen timer verwendest sondern 
knallhart die Zyklen abwartest. Ich hab mir mal sagen lassen das es NIE 
ein Fehler ist die Interruptvektoren vollständig einzubauen.
Das kann hier zwar nicht zu einem Fehler füren, weil der Interrupt ja 
nie kommt, aber schön ist das nicht.  -wiebel

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
das ".org OVF0addr" ist in der Tat entbehrlich.
Es schadet nicht und es nützt nicht.
Im schlimmsten Falle kann es verwirren.

Allerdings würde ich ".cseg" noch vor ".org 0x0000"
setzen. Der Ordnung halber.

Das sind typische Anfängerfehler. Mit ein wenig
mehr Routine wird das schon. :-)

Autor: Heiner H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe jetzt erstmal noch alle LEDs getestet. Defekt ist 
ausgeschlossen.
Alles richtig gepolt und angeschlossen. Ich habe alle LEDs über ein 
Transisor Array angeschlossen (UDN2981A).
Das komische ist ja aber auch, das das Programm dann einfach von vorne 
anfängt. Vielleicht hat ja noch jemand irgendwelche Tips, bitte...
mfg

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das komische ist ja aber auch, das das Programm
> dann einfach von vorne anfängt.

stellt sich die Frage nach der Spannungsversorgung - wie sieht die denn 
aus ?

Gruss Otto

Autor: Heiner H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also habe es jetzt auch mit dem SEC probiert, ändert auch nichts.
Bei den Pins hatte ich mich verschrieben. denn es sind die Pin B0,1,2 
und 5.
Wie gesagt, LEDs gehen auf jeden Fall alle.
Das komische ist aber auch, das ieder von vorne angefangen wirde, wenn 
er mit dem roten fertig ist.
Was ist da blos los???
Kann jemand helfen?
mfg
Heiner

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie sieht die Spannungsversorgung aus ?

Autor: Heiner H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
achso, hatte ich ganz vergessen. Ihr habt recht, die stößt an ihre 
Grenzen. das NT geht bis 1A, die LEDs ziehen alleine schon 980mA. Aber 
warum fängt er dann immer wieder von vorne an, bei rot,wenn er mit dem 
roten Aufbau fertig ist.
Wie ist das bei einem ComputerNT, kann ich das da ranhängen? Wie viel 
Strom kann man da pro Molex ziehen? und komisch ist ja auch, das ein 
paar ausgelassen werden.

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Spannung bricht ein, "Brown out" spricht an, Reset und von vorne.

NEIN - nimm kein Computernetzteil - das braucht eine Mindestlast und 
wenn die (kurz) nicht mehr da ist, bekommst Du wieder einen "Reset"

Gruss Otto

Autor: Heiner H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich meine wenn ich es in den Computer stecken will.
extra zu den anderen komponenten

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja - funktionieren wird es, Du solltest nur den Strompfad zu Deiner 
Schaltung seperat absichern (z.B. mit 2A), denn ein Computernetzteil hat 
"richtig" Power.....

Otto

Autor: Heiner H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso, diese schaltung zeiht doch nur so viel wie sie brauch.
oder ist gerdae das das problem?
eigentlich doch nicht.

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber wenn es einen "Kurzen" gibt, liefert so manches SN 30A auf der 5V 
Schiene und das kokelt ganz nett.....

Otto

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.