Tolkade tabellen helt fel och trodde det som var decimaltalen var tecknet... Menmen nu förstår jag! 
PIC16F886 lookup tables
Re: PIC16F886 lookup tables
Hehe nu vet jag hur jag såg fel! Tolkade tabellen helt fel och trodde det som var decimaltalen var tecknet... Menmen nu förstår jag!
Tolkade tabellen helt fel och trodde det som var decimaltalen var tecknet... Menmen nu förstår jag! Re: PIC16F886 lookup tables
Nu kommer en liten uppdatering av klockan!
Så här ser den ut nu och funkar kanon! 
Har suttit med det här ganska länge nu och klockan börjar bli liiiite för mycket med tanke på att jag har föreläsning imornbitti kl 08:15... Men hur som helst så har jag lite småbuggar i programmet fortfarande.. Bla så funkar inte ADCn riktigt som den ska.. Värderna tycker jag ändras väldigt mycket fram och tillbaka och stämmer inte riktigt.. :/
Så några generella tips eller fallgropar när man använder ADCn? Och hur är det när man kopplar in den, jag har testat både med och utan motstånd men är lite osäker på vad som är "rätt"? (har kopplat det till labbagget för att testa lite olika spänningar, men jag är lite osäker där också med jord/minus hur det ska hanteras när man använder flera olika strömkällor så där..)
Sen har jag försökt titta in lite mer på det där med flash-read nu men förstår inte riktigt hur man får till just "table" biten, något simpelt kod exempel (länk eller här) vore jätte bra! Den första lilla tabellen gick ju bra att ha kvar ändå, men sen vart jag tvungen att göra en ny eftersom det ska visas "meter under ytan" på displayen... Och den vart naturligtvis ganska lång och gjorde så att alla värden vart helkonstiga.. Så känns som jag borde lära mig det där "riktiga" sättet istället..
Nej nu ska jag gå och sova... God natt och tack för all hjälp!
Kod: Markera allt
; *** Clock ***
clock
incf s1
call check_sec
call check_min
return
check_sec
movfw s1
sublw d'10'
btfsc STATUS,Z
goto check_sec_2
return
check_sec_2
movfw s2
sublw d'5'
btfsc STATUS,Z
goto inc_m1
clrf s1
incf s2
return
inc_m1
clrf s1
clrf s2
incf m1
return
check_min
movfw m1
sublw d'10'
btfsc STATUS,Z
goto inc_m2
return
inc_m2
incf m2
clrf m1
return
Har suttit med det här ganska länge nu och klockan börjar bli liiiite för mycket med tanke på att jag har föreläsning imornbitti kl 08:15... Men hur som helst så har jag lite småbuggar i programmet fortfarande.. Bla så funkar inte ADCn riktigt som den ska.. Värderna tycker jag ändras väldigt mycket fram och tillbaka och stämmer inte riktigt.. :/
Så några generella tips eller fallgropar när man använder ADCn? Och hur är det när man kopplar in den, jag har testat både med och utan motstånd men är lite osäker på vad som är "rätt"? (har kopplat det till labbagget för att testa lite olika spänningar, men jag är lite osäker där också med jord/minus hur det ska hanteras när man använder flera olika strömkällor så där..)
Sen har jag försökt titta in lite mer på det där med flash-read nu men förstår inte riktigt hur man får till just "table" biten, något simpelt kod exempel (länk eller här) vore jätte bra! Den första lilla tabellen gick ju bra att ha kvar ändå, men sen vart jag tvungen att göra en ny eftersom det ska visas "meter under ytan" på displayen... Och den vart naturligtvis ganska lång och gjorde så att alla värden vart helkonstiga.. Så känns som jag borde lära mig det där "riktiga" sättet istället..
Nej nu ska jag gå och sova... God natt och tack för all hjälp!
Re: PIC16F886 lookup tables
> Värderna tycker jag ändras väldigt mycket fram och tillbaka
Hur mycket fram och tillbaka. Att några av de lägsta bitarna "fladdrar" är helt normalt.
> men förstår inte riktigt hur man får till just "table" biten
*vad* är oklart ?
> något simpelt kod exempel (länk eller här)
Mitt HD44780 kodexempel
Hur mycket fram och tillbaka. Att några av de lägsta bitarna "fladdrar" är helt normalt.
> men förstår inte riktigt hur man får till just "table" biten
*vad* är oklart ?
> något simpelt kod exempel (länk eller här)
Mitt HD44780 kodexempel
Re: PIC16F886 lookup tables
> Eller bara 'x'.
Fungerar oftast, men det är sämre och otydligare.
Fungerar oftast, men det är sämre och otydligare.
Re: PIC16F886 lookup tables
Sämre? På vilket sätt är det sämre? Slutresultatet blir *exakt* detsamma.
Och huruvida det är otydligare eller inte är nog mer en smaksak. Jag hade aldrig sett konstruktionen a'x' tidigare - så det var helt otydligt för mig - medan 'x' redan funnits i C-världen i många år.
Samma gäller heltal. Vill minnas att en del föredrar d'5' framför 5. Själv begriper jag inte varför, men det är ju ett fritt land. Bra är iallafall att man det finns möjlighet att själv välja vilken variant av talrepresentation man själv föredrar.
Och huruvida det är otydligare eller inte är nog mer en smaksak. Jag hade aldrig sett konstruktionen a'x' tidigare - så det var helt otydligt för mig - medan 'x' redan funnits i C-världen i många år.
Samma gäller heltal. Vill minnas att en del föredrar d'5' framför 5. Själv begriper jag inte varför, men det är ju ett fritt land. Bra är iallafall att man det finns möjlighet att själv välja vilken variant av talrepresentation man själv föredrar.
Re: PIC16F886 lookup tables
Jag kan nog delvis hålla med bos. Noteringen 'x' (eller möjligen "x" eller bara "x) eller liknande, har varit "standard" i både assembler och C-sammanhang i massor av år. I stort sett oavsett assemblerdialekt. Jag tycker inte att a'x' är tydligare. Är man så mycket nybörjare att man inte känner igen 'x', så måste man titta i manualen i vilket fall. Varianten a'x' har jag däremot inte stött på särskilt mycket. Det är nog faktiskt bara i Microchips miljö jag har sett det. Därmed inte sagt att det inte kan finnas på fler ställen.
Re: PIC16F886 lookup tables
Inget speciellt man ska tänka på när det gäller inkopplingen?
Nej alltså när det borde se ut såhär: (och jag har labbagget på säg 1.
När den står på 1.8V så borde den visa ca 100 kPa, men istället så hoppa fram och tillbaks mellan "010" och "255" och ibland stanar den till på något annat värde imellan... hm.. :/
Nej alltså när det borde se ut såhär: (och jag har labbagget på säg 1.
Kod: Markera allt
Bit 0 = 0.00 V = 10 kPa
Bit 1 = 0.02 V = 11 kPa
Bit 2 = 0.04 V = 12 kPa
Bit 3 = 0.06 V = 13 kPa
Bit 4 = 0.08 V = 14 kPa
Bit 5 = 0.10 V = 15 kPa
Bit 6 = 0.12 V = 16 kPa
Bit 7 = 0.14 V = 17 kPa
Bit 8 = 0.16 V = 18 kPa
Bit 9 = 0.18 V = 19 kPa
Bit 10 = 0.20 V = 20 kPa
Bit 11 = 0.22 V = 21 kPa
Bit 12 = 0.24 V = 22 kPa
Bit 13 = 0.25 V = 22 kPa
Bit 14 = 0.27 V = 23 kPa
Bit 15 = 0.29 V = 24 kPa
Bit 16 = 0.31 V = 25 kPa
Bit 17 = 0.33 V = 26 kPa
Bit 18 = 0.35 V = 27 kPa
Bit 19 = 0.37 V = 28 kPa
Bit 20 = 0.39 V = 29 kPa
Bit 21 = 0.41 V = 30 kPa
Bit 22 = 0.43 V = 31 kPa
Bit 23 = 0.45 V = 32 kPa
Bit 24 = 0.47 V = 33 kPa
Bit 25 = 0.49 V = 34 kPa
Bit 26 = 0.51 V = 35 kPa
Bit 27 = 0.53 V = 36 kPa
Bit 28 = 0.55 V = 37 kPa
Bit 29 = 0.57 V = 38 kPa
Bit 30 = 0.59 V = 39 kPa
Bit 31 = 0.61 V = 40 kPa
Bit 32 = 0.63 V = 41 kPa
Bit 33 = 0.65 V = 42 kPa
Bit 34 = 0.67 V = 43 kPa
Bit 35 = 0.69 V = 44 kPa
Bit 36 = 0.71 V = 45 kPa
Bit 37 = 0.73 V = 46 kPa
Bit 38 = 0.75 V = 47 kPa
Bit 39 = 0.76 V = 47 kPa
Bit 40 = 0.78 V = 48 kPa
Bit 41 = 0.80 V = 49 kPa
Bit 42 = 0.82 V = 50 kPa
Bit 43 = 0.84 V = 51 kPa
Bit 44 = 0.86 V = 52 kPa
Bit 45 = 0.88 V = 53 kPa
Bit 46 = 0.90 V = 54 kPa
Bit 47 = 0.92 V = 55 kPa
Bit 48 = 0.94 V = 56 kPa
Bit 49 = 0.96 V = 57 kPa
Bit 50 = 0.98 V = 58 kPa
Bit 51 = 1.00 V = 59 kPa
Bit 52 = 1.02 V = 60 kPa
Bit 53 = 1.04 V = 61 kPa
Bit 54 = 1.06 V = 62 kPa
Bit 55 = 1.08 V = 63 kPa
Bit 56 = 1.10 V = 64 kPa
Bit 57 = 1.12 V = 65 kPa
Bit 58 = 1.14 V = 66 kPa
Bit 59 = 1.16 V = 67 kPa
Bit 60 = 1.18 V = 68 kPa
Bit 61 = 1.20 V = 69 kPa
Bit 62 = 1.22 V = 70 kPa
Bit 63 = 1.24 V = 71 kPa
Bit 64 = 1.25 V = 72 kPa
Bit 65 = 1.27 V = 72 kPa
Bit 66 = 1.29 V = 73 kPa
Bit 67 = 1.31 V = 74 kPa
Bit 68 = 1.33 V = 75 kPa
Bit 69 = 1.35 V = 76 kPa
Bit 70 = 1.37 V = 77 kPa
Bit 71 = 1.39 V = 78 kPa
Bit 72 = 1.41 V = 79 kPa
Bit 73 = 1.43 V = 80 kPa
Bit 74 = 1.45 V = 81 kPa
Bit 75 = 1.47 V = 82 kPa
Bit 76 = 1.49 V = 83 kPa
Bit 77 = 1.51 V = 84 kPa
Bit 78 = 1.53 V = 85 kPa
Bit 79 = 1.55 V = 86 kPa
Bit 80 = 1.57 V = 87 kPa
Bit 81 = 1.59 V = 88 kPa
Bit 82 = 1.61 V = 89 kPa
Bit 83 = 1.63 V = 90 kPa
Bit 84 = 1.65 V = 91 kPa
Bit 85 = 1.67 V = 92 kPa
Bit 86 = 1.69 V = 93 kPa
Bit 87 = 1.71 V = 94 kPa
Bit 88 = 1.73 V = 95 kPa
Bit 89 = 1.75 V = 96 kPa
Bit 90 = 1.76 V = 97 kPa
Bit 91 = 1.78 V = 97 kPa
Bit 92 = 1.80 V = 98 kPa
Bit 93 = 1.82 V = 99 kPa
Bit 94 = 1.84 V = 100 kPa
Bit 95 = 1.86 V = 101 kPa
Bit 96 = 1.88 V = 102 kPa
Bit 97 = 1.90 V = 103 kPa
Bit 98 = 1.92 V = 104 kPa
Bit 99 = 1.94 V = 105 kPa
Bit 100 = 1.96 V = 106 kPa
Bit 101 = 1.98 V = 107 kPa
Bit 102 = 2.00 V = 108 kPa
Bit 103 = 2.02 V = 109 kPa
Bit 104 = 2.04 V = 110 kPa
Bit 105 = 2.06 V = 111 kPa
Bit 106 = 2.08 V = 112 kPa
Bit 107 = 2.10 V = 113 kPa
Bit 108 = 2.12 V = 114 kPa
Bit 109 = 2.14 V = 115 kPa
Bit 110 = 2.16 V = 116 kPa
Bit 111 = 2.18 V = 117 kPa
Bit 112 = 2.20 V = 118 kPa
Bit 113 = 2.22 V = 119 kPa
Bit 114 = 2.24 V = 120 kPa
Bit 115 = 2.25 V = 121 kPa
Bit 116 = 2.27 V = 121 kPa
Bit 117 = 2.29 V = 122 kPa
Bit 118 = 2.31 V = 123 kPa
Bit 119 = 2.33 V = 124 kPa
Bit 120 = 2.35 V = 125 kPa
Bit 121 = 2.37 V = 126 kPa
Bit 122 = 2.39 V = 127 kPa
Bit 123 = 2.41 V = 128 kPa
Bit 124 = 2.43 V = 129 kPa
Bit 125 = 2.45 V = 130 kPa
Bit 126 = 2.47 V = 131 kPa
Bit 127 = 2.49 V = 132 kPa
Bit 128 = 2.51 V = 133 kPa
Bit 129 = 2.53 V = 134 kPa
Bit 130 = 2.55 V = 135 kPa
Bit 131 = 2.57 V = 136 kPa
Bit 132 = 2.59 V = 137 kPa
Bit 133 = 2.61 V = 138 kPa
Bit 134 = 2.63 V = 139 kPa
Bit 135 = 2.65 V = 140 kPa
Bit 136 = 2.67 V = 141 kPa
Bit 137 = 2.69 V = 142 kPa
Bit 138 = 2.71 V = 143 kPa
Bit 139 = 2.73 V = 144 kPa
Bit 140 = 2.75 V = 145 kPa
Bit 141 = 2.76 V = 146 kPa
Bit 142 = 2.78 V = 146 kPa
Bit 143 = 2.80 V = 147 kPa
Bit 144 = 2.82 V = 148 kPa
Bit 145 = 2.84 V = 149 kPa
Bit 146 = 2.86 V = 150 kPa
Bit 147 = 2.88 V = 151 kPa
Bit 148 = 2.90 V = 152 kPa
Bit 149 = 2.92 V = 153 kPa
Bit 150 = 2.94 V = 154 kPa
Bit 151 = 2.96 V = 155 kPa
Bit 152 = 2.98 V = 156 kPa
Bit 153 = 3.00 V = 157 kPa
Bit 154 = 3.02 V = 158 kPa
Bit 155 = 3.04 V = 159 kPa
Bit 156 = 3.06 V = 160 kPa
Bit 157 = 3.08 V = 161 kPa
Bit 158 = 3.10 V = 162 kPa
Bit 159 = 3.12 V = 163 kPa
Bit 160 = 3.14 V = 164 kPa
Bit 161 = 3.16 V = 165 kPa
Bit 162 = 3.18 V = 166 kPa
Bit 163 = 3.20 V = 167 kPa
Bit 164 = 3.22 V = 168 kPa
Bit 165 = 3.24 V = 169 kPa
Bit 166 = 3.25 V = 170 kPa
Bit 167 = 3.27 V = 171 kPa
Bit 168 = 3.29 V = 171 kPa
Bit 169 = 3.31 V = 172 kPa
Bit 170 = 3.33 V = 173 kPa
Bit 171 = 3.35 V = 174 kPa
Bit 172 = 3.37 V = 175 kPa
Bit 173 = 3.39 V = 176 kPa
Bit 174 = 3.41 V = 177 kPa
Bit 175 = 3.43 V = 178 kPa
Bit 176 = 3.45 V = 179 kPa
Bit 177 = 3.47 V = 180 kPa
Bit 178 = 3.49 V = 181 kPa
Bit 179 = 3.51 V = 182 kPa
Bit 180 = 3.53 V = 183 kPa
Bit 181 = 3.55 V = 184 kPa
Bit 182 = 3.57 V = 185 kPa
Bit 183 = 3.59 V = 186 kPa
Bit 184 = 3.61 V = 187 kPa
Bit 185 = 3.63 V = 188 kPa
Bit 186 = 3.65 V = 189 kPa
Bit 187 = 3.67 V = 190 kPa
Bit 188 = 3.69 V = 191 kPa
Bit 189 = 3.71 V = 192 kPa
Bit 190 = 3.73 V = 193 kPa
Bit 191 = 3.75 V = 194 kPa
Bit 192 = 3.76 V = 195 kPa
Bit 193 = 3.78 V = 196 kPa
Bit 194 = 3.80 V = 196 kPa
Bit 195 = 3.82 V = 197 kPa
Bit 196 = 3.84 V = 198 kPa
Bit 197 = 3.86 V = 199 kPa
Bit 198 = 3.88 V = 200 kPa
Bit 199 = 3.90 V = 201 kPa
Bit 200 = 3.92 V = 202 kPa
Bit 201 = 3.94 V = 203 kPa
Bit 202 = 3.96 V = 204 kPa
Bit 203 = 3.98 V = 205 kPa
Bit 204 = 4.00 V = 206 kPa
Bit 205 = 4.02 V = 207 kPa
Bit 206 = 4.04 V = 208 kPa
Bit 207 = 4.06 V = 209 kPa
Bit 208 = 4.08 V = 210 kPa
Bit 209 = 4.10 V = 211 kPa
Bit 210 = 4.12 V = 212 kPa
Bit 211 = 4.14 V = 213 kPa
Bit 212 = 4.16 V = 214 kPa
Bit 213 = 4.18 V = 215 kPa
Bit 214 = 4.20 V = 216 kPa
Bit 215 = 4.22 V = 217 kPa
Bit 216 = 4.24 V = 218 kPa
Bit 217 = 4.25 V = 219 kPa
Bit 218 = 4.27 V = 220 kPa
Bit 219 = 4.29 V = 220 kPa
Bit 220 = 4.31 V = 221 kPa
Bit 221 = 4.33 V = 222 kPa
Bit 222 = 4.35 V = 223 kPa
Bit 223 = 4.37 V = 224 kPa
Bit 224 = 4.39 V = 225 kPa
Bit 225 = 4.41 V = 226 kPa
Bit 226 = 4.43 V = 227 kPa
Bit 227 = 4.45 V = 228 kPa
Bit 228 = 4.47 V = 229 kPa
Bit 229 = 4.49 V = 230 kPa
Bit 230 = 4.51 V = 231 kPa
Bit 231 = 4.53 V = 232 kPa
Bit 232 = 4.55 V = 233 kPa
Bit 233 = 4.57 V = 234 kPa
Bit 234 = 4.59 V = 235 kPa
Bit 235 = 4.61 V = 236 kPa
Bit 236 = 4.63 V = 237 kPa
Bit 237 = 4.65 V = 238 kPa
Bit 238 = 4.67 V = 239 kPa
Bit 239 = 4.69 V = 240 kPa
Bit 240 = 4.71 V = 241 kPa
Bit 241 = 4.73 V = 242 kPa
Bit 242 = 4.75 V = 243 kPa
Bit 243 = 4.76 V = 244 kPa
Bit 244 = 4.78 V = 245 kPa
Bit 245 = 4.80 V = 245 kPa
Bit 246 = 4.82 V = 246 kPa
Bit 247 = 4.84 V = 247 kPa
Bit 248 = 4.86 V = 248 kPa
Bit 249 = 4.88 V = 249 kPa
Bit 250 = 4.90 V = 250 kPa
Bit 251 = 4.92 V = 251 kPa
Bit 252 = 4.94 V = 252 kPa
Bit 253 = 4.96 V = 253 kPa
Bit 254 = 4.98 V = 254 kPa
Bit 255 = 5.00 V = 255 kPa
Re: PIC16F886 lookup tables
> medan 'x' redan funnits i C-världen i många år.
Var det C som diskuterades ?
> Slutresultatet blir *exakt* detsamma.
Det har inte heller med slutresultatet att göra.
Det har att göra med läsbarhet, tydlighet och att undvika fel (OK,
kanske inte så lätt att förstå vad det betyder för de som har
sjunkit ner i C-träsket... )
Om man skriver a'5' så är det tydligt att man faktiskt avsåg just
ASCII-teknet "5" och inte menade t.ex decimalt 5 men glömde radix.
Det är ju en väldig skillnad på d'5' och '5'. För vissa tecken som t.ex 'M'
så kanske det blir entydigt, men det gäller ju inte alla tecken. Så man
kan lika gärna göra det till en (god) vana att alltid sätta ut radix till
sina konstanter så vet man att det alltid kommer att tolkas
rätt både av MPASM eller av någon annan som läser koden.
> Vill minnas att en del föredrar d'5' framför 5.
Exakt. Bättre, tydligare och undviker en del rena skit-fel. I fallet
med just 5 så är det ju samma i alla radix, men t.ex d'10' och h'10'
är ju inte samma sak. Om man då bara skriver 10 så är det inte självklart
och entydigt vad som avses.
Alltså, a'5' eller '5' har inte med slutresultatet att göra (i just det fallet blir
det alltid samma resultat) utan det har med läsbarhet och tydlighet att göra.
Jag föredrar skrivsetten :
b'01010101'
d'123' (inte .123)
h'CE' (inte CEh eller 0xCE)
a'M' (inte enbart 'M')
för att göra koden entydig och ge samma stil på alla radix.
> Själv begriper jag inte varför,...
På den punkten vet du betydligt mer än mig...
Var det C som diskuterades ?
> Slutresultatet blir *exakt* detsamma.
Det har inte heller med slutresultatet att göra.
Det har att göra med läsbarhet, tydlighet och att undvika fel (OK,
kanske inte så lätt att förstå vad det betyder för de som har
sjunkit ner i C-träsket...
)Om man skriver a'5' så är det tydligt att man faktiskt avsåg just
ASCII-teknet "5" och inte menade t.ex decimalt 5 men glömde radix.
Det är ju en väldig skillnad på d'5' och '5'. För vissa tecken som t.ex 'M'
så kanske det blir entydigt, men det gäller ju inte alla tecken. Så man
kan lika gärna göra det till en (god) vana att alltid sätta ut radix till
sina konstanter så vet man att det alltid kommer att tolkas
rätt både av MPASM eller av någon annan som läser koden.
> Vill minnas att en del föredrar d'5' framför 5.
Exakt. Bättre, tydligare och undviker en del rena skit-fel. I fallet
med just 5 så är det ju samma i alla radix, men t.ex d'10' och h'10'
är ju inte samma sak. Om man då bara skriver 10 så är det inte självklart
och entydigt vad som avses.
Alltså, a'5' eller '5' har inte med slutresultatet att göra (i just det fallet blir
det alltid samma resultat) utan det har med läsbarhet och tydlighet att göra.
Jag föredrar skrivsetten :
b'01010101'
d'123' (inte .123)
h'CE' (inte CEh eller 0xCE)
a'M' (inte enbart 'M')
för att göra koden entydig och ge samma stil på alla radix.
> Själv begriper jag inte varför,...
På den punkten vet du betydligt mer än mig...
Re: PIC16F886 lookup tables
> men istället så hoppa fram och tillbaks mellan "010" och "255"
Du menar mellan just dessa två värden ? Inte lika ofta 009, 011
eller 254 ? Du har läst allt om ADC, speciellt om "aquisition time" ?
Du menar mellan just dessa två värden ? Inte lika ofta 009, 011
eller 254 ? Du har läst allt om ADC, speciellt om "aquisition time" ?
Re: PIC16F886 lookup tables
Det är en fördel att även läsa början på den meningen, då får man sammanhanget.sodjan skrev:Var det C som diskuterades ?
Och jag föredrar dessa: b'01010101', 123, 0xCE, 'M'. Andra personer föredrar nog något annat. Vissa vill ha tab-tecken i koden, andra vill ha space. Vissa vill ha tab-stops på 8, andra på 2. Osv.Jag föredrar skrivsetten :
b'01010101'
d'123' (inte .123)
h'CE' (inte CEh eller 0xCE)
a'M' (inte enbart 'M')
Det finns olika metoder att åstadkomma samma sak, och folk gillar olika metoder. Inget konstigt med det. Jag tycker dock det är lite väl naivt att predika "foo är bättre än bar!" när slutresultaten blir desamma. Huruvida de är tydliga eller inte är upp till var och en. Det som är tydligt för någon behöver inte innebära att det är tydligt för någon annan.
Du föredrar h'42' medan jag föredrar 0x42. Båda återger exakt samma resultat och inget av dem är fel på något sätt men det beror på vad man jämför med eller vad man är van vid. Då jag själv använt formen 0xNN i C- och Python-programmering sen mer än 10 år tillbaka känns det mest naturligt att fortsätta använda samma konvention för att representera hexadecimala tal. För mig är därför h'42' mer "otydligt" än 0x42.
Re: PIC16F886 lookup tables
Helt OK, så länge man bara skriver kod till sig själv, kanske...
Vad du är van vid sedan 10 år tillbaka från andra verktyg har liten rellevans för
vad som *generellt* är "rätt" i MPASM kod. Lite lite som det är rellevant hur jag
har angivit radix under drygt 30 års programmerande i alla möjliga verktyg och plattformar.
Jag har inte valt skrivsett i MPASM utifrån mina tidigare erfarenheter från andra plattformar
och verktyg, det skulle sannolikt inte bli helt bra (vilket du ju tydligt visar med dina exempel).
Just nu är det MPASM och hur man får den koden entydig och lättläst som gäller. Inget annat.
Mitt enda syfte med att tjata om detta är att ge de som börjar med PIC/MPASM goda
vanor från början och undvika en del enkla skitfel. Jag struntar i princip helt i hur du
skriver i just din kod, så länge den inte finns här på forumet som exempelkod. Eller att
du "rättar" ett korrekt och tydligt skrivsätt med ett (i och för sig fungerande) mindre
tydligt skrivsätt (a'M' => 'M').
> Och jag föredrar dessa: b'01010101', 123, 0xCE, 'M'.
Notera att default radix är HEX, så 123 kommer att tolkas som h'123' *OM* man inte ser
till att ändra default radix med t.ex "radix dec" tidigare i koden. Du kanske gör det, men någon
annan som använder din kod kanske inte gör det. Ditt sätt att skriva det kanske inte är
direkt fel (i alla fall inte under vissa omständigheter) men speciellt bra är det definitivt inte.
Slutligen, för att citera MPASM manualen :
Men som sagt, var och en för naturligstvis skriva som man vill, och så länge som man bara
skriver kod för/till sig själv så är det ju bara en själv som "drabbas"...
Vad du är van vid sedan 10 år tillbaka från andra verktyg har liten rellevans för
vad som *generellt* är "rätt" i MPASM kod. Lite lite som det är rellevant hur jag
har angivit radix under drygt 30 års programmerande i alla möjliga verktyg och plattformar.
Jag har inte valt skrivsett i MPASM utifrån mina tidigare erfarenheter från andra plattformar
och verktyg, det skulle sannolikt inte bli helt bra (vilket du ju tydligt visar med dina exempel).
Just nu är det MPASM och hur man får den koden entydig och lättläst som gäller. Inget annat.
Mitt enda syfte med att tjata om detta är att ge de som börjar med PIC/MPASM goda
vanor från början och undvika en del enkla skitfel. Jag struntar i princip helt i hur du
skriver i just din kod, så länge den inte finns här på forumet som exempelkod. Eller att
du "rättar" ett korrekt och tydligt skrivsätt med ett (i och för sig fungerande) mindre
tydligt skrivsätt (a'M' => 'M').
> Och jag föredrar dessa: b'01010101', 123, 0xCE, 'M'.
Notera att default radix är HEX, så 123 kommer att tolkas som h'123' *OM* man inte ser
till att ändra default radix med t.ex "radix dec" tidigare i koden. Du kanske gör det, men någon
annan som använder din kod kanske inte gör det. Ditt sätt att skriva det kanske inte är
direkt fel (i alla fall inte under vissa omständigheter) men speciellt bra är det definitivt inte.
Slutligen, för att citera MPASM manualen :
Vilket är ungefär samma sak som jag försöker säga...The MPASM assembler supports a clean and consistent method of specifying radix.
You are encouraged to develop using the radix and other directive methods described
within this document, even though certain older syntaxes may be supported for
compatibility reasons.
Men som sagt, var och en för naturligstvis skriva som man vill, och så länge som man bara
skriver kod för/till sig själv så är det ju bara en själv som "drabbas"...
Re: PIC16F886 lookup tables
Notera att default radix är HEX, så 123 kommer att tolkas som h'123' *OM* man inte ser
till att ändra default radix med t.ex "radix dec" tidigare i koden.
Det är egentligen den enda orsaken som jag tycker är väsentlig. Och så in i h*lsike bakvänt. Jag har aldrig sett någon annan assembler som har hex som default radix. Och väldigt ovant för alla, både nybörjare och vana programmerare.
Eftersom alla assemblers kanske inte har direktiv för decimala tal, eftersom det är default, så tycker jag det är bättre att köra default radix decimalt även i MPAsm och få mer enhetlig kod rent allmänt. Visst är direktiv och instruktioner olika ändå, men jag tycker inte man behöver ytterligare en faktor som är olika. Jag kör i flera olika miljöer och språk, och tycker det är trevligt att ha sådana saker som radix lika i möjligaste mån.
till att ändra default radix med t.ex "radix dec" tidigare i koden.
Det är egentligen den enda orsaken som jag tycker är väsentlig. Och så in i h*lsike bakvänt. Jag har aldrig sett någon annan assembler som har hex som default radix. Och väldigt ovant för alla, både nybörjare och vana programmerare.
Eftersom alla assemblers kanske inte har direktiv för decimala tal, eftersom det är default, så tycker jag det är bättre att köra default radix decimalt även i MPAsm och få mer enhetlig kod rent allmänt. Visst är direktiv och instruktioner olika ändå, men jag tycker inte man behöver ytterligare en faktor som är olika. Jag kör i flera olika miljöer och språk, och tycker det är trevligt att ha sådana saker som radix lika i möjligaste mån.
Re: PIC16F886 lookup tables
Alltså som lite "nybörjare" och även lite "perfektionist" så tycker jag att b'xxxxxxxx' h'0A' d'10' a'R' verkar bäst för mig iallafall..
Om vi ska komma tillbaks till ämnen.. *host* Så har jag testat lite mer nu men tycker mig fortfarande få lite konstiga resultat... Angående "aquisition time" så misstänkte jag att det kunde vara en felande faktor men tycker också att det är lite halv svårt att riktigt veta hur långt det ska vara, jag hade 5ms från början men ökade ordentligt nu bara för att för att se om värderna vart bättre, sen drog jag ner uppdateringen av lcdn (dvs också antalet mätningar av ADC eftersom allt går i samma loop med en massa call's) för att kunna logga resultaten ADC gav och här är resultatet: (Det är en mätning var femte sekund)
Som man kan se så är det inte riktigt så stabilt som jag skulle vilja ha det, men samtidigt så vet jag ju inte riktigt vad man kan "förvänta sig" men lite bättre än det här borde jag väl få? Under hela testet så var spänningen inställd på 1.8volt vilket skulle motsvara ungefär 100 kPa, men det var ju riktigt det hela tiden..
Om det är någon som orkar så kan jag väl visa den delen av koden som gör detta också:
Tänkte att det kanske är bra att ta med "init delen" också bara för att...
Själva huvudloopen som anropar subrutiner för att utföra andra saker, den börjar med att anropa ADC och då görs AD omvandlingen och resultatet ska läggas i "TEMP_ADC" och "PRESSURE_ADC", sedan används dessa för att göra uträkningar och sortera upp från "tre siffror i en byte" till en siffra per byte för att kunna skicka ut till displayen. Sen så är det utskrivning av alltihop, "call clock" som står längre ner anropar "clock" som jag postade tidigare...
Subrutiner för ADC som anropas ovan:
Om vi ska komma tillbaks till ämnen.. *host* Så har jag testat lite mer nu men tycker mig fortfarande få lite konstiga resultat... Angående "aquisition time" så misstänkte jag att det kunde vara en felande faktor men tycker också att det är lite halv svårt att riktigt veta hur långt det ska vara, jag hade 5ms från början men ökade ordentligt nu bara för att för att se om värderna vart bättre, sen drog jag ner uppdateringen av lcdn (dvs också antalet mätningar av ADC eftersom allt går i samma loop med en massa call's) för att kunna logga resultaten ADC gav och här är resultatet: (Det är en mätning var femte sekund)
Som man kan se så är det inte riktigt så stabilt som jag skulle vilja ha det, men samtidigt så vet jag ju inte riktigt vad man kan "förvänta sig" men lite bättre än det här borde jag väl få? Under hela testet så var spänningen inställd på 1.8volt vilket skulle motsvara ungefär 100 kPa, men det var ju riktigt det hela tiden..
Om det är någon som orkar så kan jag väl visa den delen av koden som gör detta också:
Tänkte att det kanske är bra att ta med "init delen" också bara för att...
Kod: Markera allt
start
banksel ansel
movlw h'FF'
movwf ansel
clrf anselh
banksel trisa
movlw h'FF'
movwf trisa
clrf trisb
clrf trisc
;
banksel adcon1
clrf adcon1
banksel adcon0
movlw b'11000001'
movwf adcon0
;
banksel intcon
clrf intcon
banksel cm1con0
clrf cm1con0
banksel cm2con0
clrf cm2con0
banksel portb ; Change to bank 0
;
call lcd_init_hd44780 ; Setup LCD
; Set clock to 00:00
movlw b'00000000'
movwf m1
movwf m2
movwf s1
movwf s2
Kod: Markera allt
;
; Write to display...
;
write_lcd
call ADC
; *** Take care of TEMP_ADC value ***
movfw TEMP_ADC
movwf TEMP_RES
call TEMP_SPLIT
; *** Take care of PRESSURE_ADC value ***
movfw PRESSURE_ADC
;call METER_TABLE
movwf PRESSURE_M
movfw PRESSURE_ADC
movwf X
movlw d'246'
movwf Y
call mpy_F ; The result of X*Y is in locations H_byte & L_byte
movlw b'00001010' ; Add d'10' to result
addwf H_BYTE,W
movwf PRESSURE_RES
call PRESSURE_SPLIT
; *** Write "Tryck:" ***
movlw a'T'
call lcd_send_data
movlw a'r'
call lcd_send_data
movlw a'y'
call lcd_send_data
movlw a'c'
call lcd_send_data
movlw a'k'
call lcd_send_data
movlw a':'
call lcd_send_data
; *** Print pressure value ***
movfw PRESSURE_HNDS
call binary_convert
call lcd_send_data
movfw PRESSURE_TENS
call binary_convert
call lcd_send_data
movfw PRESSURE_ONES
call binary_convert
call lcd_send_data
; *** Write kPa ***
movlw a'k'
call lcd_send_data
movlw a'P'
call lcd_send_data
movlw a'a'
call lcd_send_data
; *** Move to position 0x0E
movlw b'10001110'
call lcd_send_cmd
; *** Print depth ***
movfw PRESSURE_M
call lcd_send_data
; *** Write "m" ***
movlw a'm'
call lcd_send_data
; *** Move to first character in secund row, position 0x40 ***
movlw b'11000000'
call lcd_send_cmd
; *** Write "Temp:" ***
movlw a'T'
call lcd_send_data
movlw a'e'
call lcd_send_data
movlw a'm'
call lcd_send_data
movlw a'p'
call lcd_send_data
movlw a':'
call lcd_send_data
; *** Print Temp value ***
movfw TEMP_TENS
call binary_convert
call lcd_send_data
movfw TEMP_ONES
call binary_convert
call lcd_send_data
; *** Write "C" ***
movlw b'01000011'
call lcd_send_data
; *** Move to left right part of lcd ***
movlw b'11001011'
call lcd_send_cmd
; *** Show clock ***
movfw m2 ; First minute number
call binary_convert
call lcd_send_data
movfw m1 ; Secund minute number
call binary_convert
call lcd_send_data
movlw b'00111010' ; :
call lcd_send_data
movfw s2 ; First second number
call binary_convert
call lcd_send_data
movfw s1 ; Second second number
call binary_convert
call lcd_send_data
call clock
call delay_lcd
call delay_lcd
call delay_lcd
call delay_lcd
call delay_lcd
movlw b'00000001' ; Clean screen
call lcd_send_cmd
goto write_lcd
;
; Multiply x*y and produce a 16bit result. The high byte of the
;result is aliased with x.
;
;*** Define a macro for adding & right shifting ***
;
mult MACRO bit ; Begin macro
btfsc X,bit
addwf H_byte,1
rrf H_byte,1
rrf L_byte,1
ENDM ; End of macro
; *** Begin Multiplier Routine ***
mpy_F
clrf H_byte
clrf L_byte
movf Y,W ; Move the multiplicand to W reg.
bcf STATUS,C ; Clear the carry bit in the status Reg.
mult 0
mult 1
mult 2
mult 3
mult 4
mult 5
mult 6
mult 7
;
retlw 0
PRESSURE_SPLIT
call GET_HNDS
movwf PRESSURE_HNDS
movfw PRESSURE_RES
call GET_TENS
movwf PRESSURE_TENS
movfw PRESSURE_RES
call GET_ONES
movwf PRESSURE_ONES
return
TEMP_SPLIT
call GET_HNDS
movwf TEMP_HNDS
movfw TEMP_RES
call GET_TENS
movwf TEMP_TENS
movfw TEMP_RES
call GET_ONES
movwf TEMP_ONES
return
;This routine will return the number of decimal
;hundreds from an 8-bit binary
;Input: w
;Output: w
;RAM:2
;Cycles: 12-24
GET_HNDS
movwf t1
clrf w2
get_hnds_loop
movlw .100
incf w2,f
subwf t1,f
btfsc STATUS,C
goto get_hnds_loop
decf w2,w
return
;This routine will return the number of decimal
;tens from an 8-bit binary
;Loop based, so it might take some time...
;It needs getones too
GET_TENS
movwf t1
clrf w2
get_tens_loop
movlw d'10'
incf w2,f
subwf t1,f
btfsc STATUS,C
goto get_tens_loop
decf w2,w
goto get_ones
GET_ONES
movwf w2
movlw d'10'
del_tens_loop
subwf w2,f
btfsc STATUS,C
goto del_tens_loop
addwf w2,w
return
Kod: Markera allt
;
; **********************************************
; **** Subrutins for ADC ****
; **********************************************
;
;{
ADC
call TEMP_START
call ADC_START
call TEMP_STORE
call PRESSURE_START
call ADC_START
call PRESSURE_STORE
TEMP_START
banksel ADCON0
bcf ADCON0,CHS0 ; Set AN0 on
call SampelTime ; Call delay
return
PRESSURE_START
banksel ADCON0
bsf ADCON0,CHS0 ; Set AN1 on
call SampelTime ; Call delay
return
ADC_START
bsf ADCON0,GO ; Start conversion
btfsc ADCON0,GO ; Is conversion done?
goto $-1 ; No, test again...
return
TEMP_STORE
banksel ADRESH
movf ADRESH,W ; Read upper 8 bits
movwf TEMP_ADC ; Store in TEMP_ADC (Don't care about the 2 low bits, only use 8 bits)
return
PRESSURE_STORE
banksel ADRESH
movf ADRESH,W ; Read upper 8 bits
movwf PRESSURE_ADC; Store in PRESSURE_ADC (Don't care about the 2 low bits, only use 8 bits)
return
SampelTime
call delay_5ms
call delay_5ms
call delay_5ms
call delay_5ms
call delay_5ms
call delay_5ms
call delay_5ms
call delay_5ms
call delay_5ms
call delay_5ms
return
;}
Re: PIC16F886 lookup tables
Titta på tabell 9-1 i databladet på sida 101. Du använder RC-klocka (FRC) till din ADC, vilket innebär att du ska titta på sista raden; Tad = 2-6µs således. Fotnot 1 säger: "The FRC source has a typical TAD time of 4 μs for VDD > 3.0V", men du kan använda 6 som Worst Case.Scorpiion skrev:Angående "aquisition time" så misstänkte jag att det kunde vara en felande faktor men tycker också att det är lite halv svårt att riktigt veta hur långt det ska vara,
Tabell 9-2 på samma sida säger att ADC:n behöver 11st Tad för en konvertering, samt tiden "Tcy to Tad". Jag vet inte vad du klockat kretsen i, men Tcy = 4 / Fosc. Är klockan på 4MHz blir Tcy alltså 4 / 4000000 = 1µs, vilket är lägre än vad Tad och eftersom första tiden ska vara "Tcy to Tad" så kan du räkna med "Tad" här eftersom Tcy är mindre.
Total väntetid som minst behövs är alltså: 12 * Tad (worst case) = 12 * 6µs = 72 µs eller 12 * Tad (typical) = 12 * 4µs = 48µs. Förutsatt att din funktion "delay_5ms" gör vad den är döpt till så ligger felet någon annanstans.
Jag orkar inte riktigt sätta mig in i din LCD- och talsplittarkod, men det jag skulle gjort för att undersöka om ADC:n spottar ut förväntade värde är att stega igenom ADRESH och ADRESL bit för bit och skriva ut bitpositionen på LCD:n. Ett tal varannan sekund eller så, så att du hinner med. På detta vis kan du eliminera ADC:n helt och hållet från felsökningen och kan krypa ner felsökningsområdet.
