Gämföra lösen i ASM

[bos]

Exempel på stegvis koll:

Kod: Markera allt

BTFSS destination1
call lab1
bcf korekt_kod
return

lab1
BTFSS destination2
call lab2
bcf korekt_kod
return
...

[/quote]

Jag skulle rekommendera å det grövsta att du INTE gör sådär. Du får fem adresser på stacken, och eftersom en PIC-stack bara kan bli 8 adresser djup så har du inte särskilt långt kvar till din kod blir överskriden. Antagligen inte i detta projekt, men då du börjar använda ISR och liknande med nästlade anrop, så kommer det att skita sig rejält.

[TomasL]

Nackdelen med din senaste kod är att alla tester körs oavsett om koden är fel eller ej, om du gör som jag skrev skippas efterföljande kod om det är fel.

[sodjan]

Eller, men en extra variabel men lite färre instruktioner :

Kod: Markera allt

    clrf    sumtmp
    bsf     correct_code

    movf    var5, w
    xorwf   var1, w
    addwf   sumtmp, f

    movf    var6, w
    xorwf   var2, w
    addwf   sumtmp, f

    movf    var7, w
    xorwf   var3, w 
    addwf   sumtmp, f

    movf    var8, w
    xorwf   var4, w
    addwf   sumtmp, f

    btfss   status, z
    bcf     correct_code

    return

; Om *ordningen* som koden matas in med inte spelar
; någon roll kan det skrivas :


    bsf     correct_code

    movlw   h'00'
    xorwf   var5, w
    xorwf   var1, w
    xorwf   var6, w
    xorwf   var2, w
    xorwf   var7, w
    xorwf   var3, w
    xorwf   var8, w
    xorwf   var4, w

    btfss   status, z       ; Z=1 betyder rätt kod (W-reg = h'00').
    bcf     correct_code

    return
;
; Det intressanta med XOR är att ovanstående även kan skrivas
;
    xorwf   var1, w
    xorwf   var2, w
    xorwf   var3, w
    xorwf   var4, w
    xorwf   var5, w
    xorwf   var6, w
    xorwf   var7, w
    xorwf   var8, w
;
; med exakt samma resultat... :-)
; Ordningen man gör XOR på spelar ingen roll.
; Det är det som gör att den "öppnar" för koden oavsett i vilken
; ordning den skrivs in...

 

Hur som helst, den första koden bör fungera om ordningen
på koden är viktig (vilket det ju normalt är...)

En sak som saknas i din kod är hur kod5 - kod8 hamnar i sina
RAM platser. De har ju hårdkodade, eller hur ?
Alltså skulle det kanske se ut så här :

Kod: Markera allt

    clrf    sumtmp
    bsf     correct_code

    movlw   var5
    xorwf   var1, w
    addwf   sumtmp, f

    movlw   var6
    xorwf   var2, w
    addwf   sumtmp, f

    movlw   var7
    xorwf   var3, w 
    addwf   sumtmp, f

    movlw   var8
    xorwf   var4, w
    addwf   sumtmp, f

    btfss   status, z
    bcf     correct_code

    return

Där var5 till var8 är symboler som du sätter i källkoden.

Hopp att alt blev rätt nu...

[squiz3r]

Nu har jag hållt på i ett par timmar med att försöka få koden att fungera... Jag har kollat så att jag får in rätt siffror i var5-8, men STATUS, Z verkar ändå alltid bli "0"...

Jag ska testa med din kod istället sodjan.

//Daniel Andersson

[sodjan]

OK.
Notera att jag hade kastat om var1-4 med var5-8, men det ser du säkert...

Hur ser den kod ut som du har testat med ?
Det du visade var ju inte riktigt komplett, "rätt kod" ska ju vara fast
i prorammet (och finns alltså inte i var1-4 från början, så att säga...)

[Marta]

Kära nån, vad håller Ni på med?

Koden skall givetvis sparas i EEPROM och ar inte processorn sådant så skall den sparas som tabell. Använd sedan indirekt adressering.

Givetvis skall ordningsföljden vara viktig, annars minskar kombinationerna kraftigt. Anordningen skall inte hellre rapportera fel innan alla siffror slagits, annars blir den högst trivial att forcera.

[squiz3r]

Jag lyckades få igång den, det var en variabel som hade blivit "dubblerad" Men nu funkar hela kodlåset (Fasst bara precis ).

Tanken är att man från en meny ska kunna ändra koden men det får bli senare.

Mvh. Daniel Andersson

[sodjan]

> Kära nån, vad håller Ni på med?

Hm, du kanske skulle kolla igenom tråden lite nogrannare...

> Koden skall givetvis sparas i EEPROM

Ja visst, t.ex.
Men det ligger ju utanför kontext för det aktuella problemet !
(D.v.s att jämföra koden med nyckeln...)

Självklart måste nyckeln *lagras* någonstans, om det är i
EEPROM (för att kunna ändras) i Flash (och kunna ändras
i de processorer som kan skriva till sin egen flash) eller på annat
sätt är en helt annan fråga (som jag i och för sig kommentrerade
i ett av mina inlägg)...


> Givetvis skall ordningsföljden vara viktig,...

Självklart ! Jag ville bara visa effekten av XOR, att det inte spelar någon
roll i vilken ordning man gör flera XOR efter varandra. Och jag skrev även
i inlägget att det sannolikt inte var rellevant...

> Anordningen skall inte hellre rapportera fel innan alla siffror slagits,...

Notera också att *ALLA* exempel bygger på att testen görs efter att
*ALLA* siffror har slagits, så jag förstår inte din poäng.

Det var bara *testen* i koden som avbröts efter första felaktiga koden,
men det vet ju inte användaren ett smack om...

[Micke_s]

Sodjan: precis så jag menade i min c-kod, blev inte alls så mycket assemblerinstruktioner.

Att testa alla och sedan säga fel eller rätt ser jag inte som ett problem.
Det tar ju 20 instruktioner att utföra hela testet, så i 4Mhz så blir det
ca 20uS, tror inte användaren upptäckter den lilla extra tiden.

[sodjan]

Ja det blev det visst! Tänkte inte på det...
En annan sak är att man ibland *vill* ha isosynkron kod, d.v.s
att en viss sekvens alltid tar exakt lika många cykler vilken "väg"
den än tar genom koden. Kod utan hopp gör naturligtsvis alltid
det. Kan vara kritiskt i kod för snabb kommunikation...

[Marta]

En av finesserna att med en gång lägga koden i eeprom är att man då har tillgång till indirekt adressering av *både* kod och inmatning. Gör man det som tabell med koden i flash blir det lite stökigare.

Det är kanske inte mycket lönt att lägga kontrollen som en loop med bara 4 tecken, allt som behövs för att sätta upp det hela gör att skillnaden blir liten. Fast det är ju ett mycket snyggare sätt och sedan lätt att byga ut om man vill ha en längre kod.

[sodjan]

Nu är jag inte helt med...
Menar du att man *varje gång* som någon knappar koden ska
lägga över den i EEPROM ? Alltså inte bara "nyckeln" ?

[Marta]

Givetvis inte. Den inslagna koden lagras i RAM och koden att kontrollera mot i EEPROM. Sedan kan man adressera indirekt på båda, men det är ju lite stökigt hur man än gör, det behövs ju bankswitch för att läsa EEPROM. Läsa tabell blir nog faktiskt färre. Fast att explicit ladda immediate och komparera varje siffra är kanske trots allt den enklaste när det bara är 4 stycken.

[sodjan]

OK, då är jag helt med...
Det finns flera sätt att lägra/läsa nyckeln, men dels vet vi inte
hur "skyddad" nyckeln ska vara, dels låg den frågan (lagringen) utanför
grundfrågan i tråden...

[Marta]

Tja, i assembler är där starka band mellan hur nyckeln är lagrad och hur den skall accessas och därmed hur kontrollrutinen skall implementeras på bästa sätt.