Sida 2 av 3
Postat: 3 juli 2007, 11:24:12
av 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.
Postat: 3 juli 2007, 11:36:47
av 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.
Postat: 3 juli 2007, 13:53:21
av 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...
Postat: 3 juli 2007, 14:24:38
av 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
Postat: 3 juli 2007, 14:47:54
av 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...)
Postat: 3 juli 2007, 15:29:55
av 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.
Postat: 3 juli 2007, 15:38:21
av 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
Postat: 3 juli 2007, 16:09:12
av 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...
Postat: 3 juli 2007, 22:20:14
av 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.
Postat: 3 juli 2007, 22:32:54
av 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...
Postat: 3 juli 2007, 23:01:11
av 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.
Postat: 3 juli 2007, 23:04:09
av 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" ?
Postat: 3 juli 2007, 23:18:50
av 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.
Postat: 3 juli 2007, 23:35:45
av 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...
Postat: 4 juli 2007, 17:33:35
av 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.