MemBitBlink.asm i AVR Studio

[1802]

Kod: Markera allt

 ; MemBitBlink.asm i AVR Studio
 ;.ORG 1000
 
 LDI	r20, 0xff         ; indata 
 LDI	r21, 0x08	      ; kör 8 bitar
 ;LDI	r22, 0x00	      ; Till cp  cp Rxx,0x00 finns ej

loop:
 DEC r21
 LSL r20                  ; 
 BRCC skipp               ; hoppa om inte carry satt(brcs)
 ;CALL on                  ; Typ JSR (call icall rcall)
 NOP               
 ;CPY #$00                ; kolla om 8 varv gått
 ;CP r21,r22
 BREQ end                 ; avsluta om sant
 JMP loop
skipp: 
 CALL off
 ;CPY #$00                ; kolla om 8 varv gått
 ;CP r21,r22
 BREQ end                 ; avsluta om sant
 JMP loop 

end: 
 JMP end                  ; Avsluta  finns säkert bättre sätt

; OBS ofärdiga subrutiner  syns när jag debuggar
on:                       ; tänd i/o pinne
 LDI	r22, 0x01
 RET
off:                      ; släck i/o pinne
 LDI	r22, 0x00
 RET

När subrutinen on: är klar hoppar den till första raden i programmet, varför? Jag vill att den skall hoppa till raden efter "CALL on". Det verkar funka utan CP, för jag jämför mot noll. Men hur vet den vilket register jag menar? Vilka register är "fria"? R0 gav error vid build.

[Korken]

Friendly advice; använd indenting
http://blogs.mathworks.com/community/20 ... indenting/

[1802]

När jag klipper och klistrar blir det fel i rutan. Svårt att indentera då.
Register R16 är det lägsta som inte blir error. Och de sista 4 tror jag är till X och Y.

Edit: Verkar som det finns flera skolor om indenting. Så vad man än väljer blir det fel för nån .

[Korken]

Om jag får rekommendera en stil så är det den som heter "Indent all functions" i den jag länkade.
Den ger en mycket bra och överskådlig kod tycker jag.

Tyvärr kan jag inte hjälpa dig med assemblern, det var för länge sedan jag kollade på AVR asm.

[Icecap]

Lycklig obekant med ASM på AVR undrar jag bara om inte det jag lärde mig i sin tid med Z80: ska inte stackpekaren laddas till ett känd värde?

[1802]

I följande så funkar första RCALL. Men den andre hoppar till programstart efter RET. Jag tycker den borde fastna i Delay: .

Kod: Markera allt

;BlinkDelay.asm
;Ej mitt, men med mina moddar :-)
.include "m8515def.inc"
 
                ;Initialize the microcontroller stack pointer
                LDI    R16, low(RAMEND)
                OUT    SPL, R16
                LDI    R16, high(RAMEND)
                OUT    SPH, R16
 
                ;Configure portB as an output put
                LDI    R16, 0xFF
                OUT    0x04, R16
 
                ;Toggle the pins of portB
                LDI    R16, 0xFF
                OUT    0x05, R16
                RCALL  Delay
                LDI    R16, 0x00
                OUT    0x05, R16
                RCALL  Delay
 
                ;Delay subroutine
Delay:          LDI  R17, 0x01
loop:           DEC  R17
                BRNE loop
                RET

Edit: Lägger in källan. http://www.avr-tutorials.com/assembly/w ... controller inte bara för att jag skall hitta den lätt

[Johanb]

Du bör ha ett definierat avslut på programmet, en infinite loop, annars kan du få oväntade resultat.

[1802]

Johanb: Som jag skriver i kommentaren "Avsluta finns säkert bättre sätt" men jag kan inget ännu.

Jag tror jag har löst CALL problemet, om än lite skitigt.

Kod: Markera allt

 ; MemBitBlink.asm0_2 i AVR Studio
 ;.ORG 1000
; nedan hämtat från .include "m8515def.inc"
;.equ	SPH		=$3e
;.equ	SPL		=$3d
;.equ 	RAMEND =$25F

 
                ;Initialize the microcontroller stack pointer
                LDI    R16, low($25F)
                OUT    $3d, R16
                LDI    R16, high($25F)
                OUT    $3e, R16

 
 LDI	r20, 0b10101010   ; indata 
 LDI	r21, 0x08	      ; kör 8 bitar
 ;LDI	r22, 0x00	      ; Till cp  cp Rxx,0x00 finns ej
 
loop:
 LSL r20
 DEC r21                  ; 
 BRCC skipp               ; hoppa om inte carry satt(brcs)
 CALL on                  ; Typ JSR (call icall rcall)
 NOP               
  ;CP r21,r22
 BREQ end                 ; avsluta om sant
JMP loop
skipp: 
 CALL off
  ;CP r21,r22
loop2:
 BREQ end                 ; avsluta om sant
 JMP loop 

end: 
 JMP end                  ; Avsluta  finns säkert bättre sätt

; OBS ofärdiga subrutiner  syns när jag debuggar
on:                       ; tänd i/o pinne
 ;LDI r23,0x07
 ;out $3d,r23
 ;out 0x15,r23
 LDI	r22, 0x01
 ;POP r14
 RET
 ;JMP loop
off:                      ; släck i/o pinne
 LDI	r22, 0x00
RET
;JMP loop2

[jesse]

fungerar programmet nu?
testkör du det i simulatorn?

lite kommentarer efter att ha kollat lite snabbt på senaste versionen:

end: JMP end ; Avsluta finns säkert bättre sätt

Det är ett utmärkt sätt att avsluta på.

DEC r21 ;

Det där brukar man göra allra sist i loopen. Varför? Jo, eftersom Z-flaggan ettställs när du räknat ner till noll, så kan man använda den i nästa instruktion för att avsluta loopen med:

brne loop; // branch if not equal... (dvs fortsätt "loopa" så länge det inte blev noll)

och då slipper du dessa tre rader:

;CP r21,r22
BREQ end ; avsluta om sant
JMP loop

Det är också ett annat problem... som visserligen fungerar i ditt program, men som gör det svårt att tolka. Det är ordningen på dessa instruktionerna:

LSL r20
DEC r21 ;
BRCC skipp ; hoppa om inte carry satt(brcs)

BRCC ska alltså hoppa om carry biten är nolla. Men när blir carrybiten satt? Oftast gör man det i instruktionen strax innan, för att man ska få ett sammanhang. Men du har lagt DEC r21 i mellan. Tänk om DEC r21 ändrar i carryflaggan? Nu ser vi ju i AVR Assembler User Guide att instruktionen DEC bara påverkar flaggorna Z, N och V. Alltså klarar sig carry här. Men annars kan man tro att villkoret för hoppet är beroende av DEC-instruktionen, vilket alltså är fel. Så ditt program fungerar, men är svårrare att förstå än om du hade skrivit så här istället:

DEC r21
LSL r20
BRCC skipp ; hoppa om inte carry satt(brcs)

Assembler är svårt på det viset att man måste veta exakt vad som sker hela tiden (t.ex. att DEC inte påverkar carry) och därför är det jätteviktigt att man försöker skriva programmet så att det blir lätt att förstå. Annars kommer man själv senare inte att begripa vad det är man skrivit. Det går att tyda ett så enkelt program som detta, för det handlar bara om en loop och en byte med åtta bitar i. Men tänk om du ska skriva ett program som håller reda på en massa temperaturer , tider och som ritar grafer på en display.... Då gäller det att hålla tungan rätt i mun.

[1802]

Raden ";CP r21,r22" Börjar med ; alltså bara en kommentar. Kan slopas direkt. Jag kör koden i simulatorn än så länge, men den skall in i The Priate boy's kort med ATMega16u4. Angående avslut, så såg jag ett liknande på sidan jag länkade till ovan, Så den får duga.

Jag har några liknande .pdf, men inte den. Nu har jag den .

Men det är r21 som skall avgöra när det är klart. Är inte den närmst BRCC? Ev kommer subrutinerna on: och off: pilla på carry när de är klara. Så en CLC kan nog behövas på rätt plats.

Är man en hacker när man hämtar värden för hand i m8515def.inc ? Gäller bara att 16u4 är lik . Ett sånt här litet program skall inte behöva includes .

[jesse]

När det gäller dec r21 så är det ju Z-flaggan som processorn måste minnas hela vägen ända till efter subrutinerna (eftersom CP r21,r22 är bortkommenterat).... Det begränsar ju dig rejält när det gäller vad du kan göra i subrutinerna - du får inte pilla på Z-flaggan. Så jämförelsen, tycker jag, ska fortfarande vara precis innan det villkorade hoppet.

>Ev kommer subrutinerna on: och off: pilla på carry när de är klara. Så en CLC kan nog behövas på rätt plats.
Vanligtvis ska du inte behöva nollställa carryflaggan (eller någon annan flagga) när du ska påbörja något nytt. Den skrivs helt enkelt över när du t.ex. adderar eller subtraherar eller vad du ska göra. Värre är det om du förstör innehållet i Z-flaggan (så som programmet är skrivet nu). Då tappar du helt kontrollen över när loopen avslutas.

>Är man en hacker...
Ja, definitivt.

[1802]

Såklart är det z(zero) flaggan jag skall kolla . Kan man inte lagra den, pilla med den, och hämta tillbaka? PUSH PULL till stacken kanske?

Om man inte renskriver en skitig fungerande kod nästan direkt, kommer den då någonsin att renskrivas....

[Icecap]

Att kopiera värden från processordefinitionsfilen istället för att inkludera den är rakt av dumt. Efter vad jag kan se finns det redan rikligt med problem och en kopiering som blir fel kan vara förödande.

Och varje gång man skriver in eller kopierar något finns det risk för fel.

[jesse]

Såklart är det z(zero) flaggan jag skall kolla . Kan man inte lagra den, pilla med den, och hämta tillbaka? PUSH PULL till stacken kanske?

Men du behöver ju inte spara Z-flaggan om du istället gör DEC r21 i slutet av loopen, precis innan du ska testa Z-flaggan.

Kod: Markera allt

    LDI r21, 8
loop:
    ... ;
    ... ; en massa kod ... gör vad som helst i loopen
    ... ; förutom att förstöra r21
    ... ;
    ...;
    dec r21
    brne loop
end:
    rjmp end;