Never seen this before!!

[Megahertz]

movlw -97
addwf TMR0


I have never come across any negative number getting loaded into a variable.
Is this the same as Loading 159-> (256-97=159) to Timer0 ?

[SteveB]

movlw -97
addwf TMR0


I have never come across any negative number getting loaded into a variable.
Is this the same as Loading 159-> (256-97=159) to Timer0 ?

It sure is.

You can look at the .LST file after you compile the program and find the line for "movlw -97". You will see that it will be something like:

00009E 0E9F 00232 movlw -97

00009E <-- Address of the the instruction

0E9F <-- Actual instruction code

If you look up the MOVLW code in the PIC datasheet, you will see the OP-CODE (most significant 8 bits of the 16 bit instruction) is $0E (%00001110). The literal is the 8 least significant bits, $9F in this case (which is 159).

[Megahertz]

Much appreciated your in-depth answer. Thanks Steve :)

[Mike, K8LH]

movlw -97
addwf TMR0


I have never come across any negative number getting loaded into a variable.
Is this the same as Loading 159-> (256-97=159) to Timer0 ?It sure is.

That's not exactly correct. Notice that the constant value is being added to the free running TMR0 register. In this case it seems the author is using Timer 0 to generate precise 100 cycle intervals. Of course this only works if you're not using the TMR0 prescaler since any write to TMR0 will also clear the prescaler. The -97 value accounts for one cycle for TMR0 overflow and the inherent two cycle delay you get after writing TMR0 before TMR0 starts counting again.

Hope this information helps.

Cheerful regards, Mike

[SteveB]

Good point. I was focused on the fact that the movlw had a negative value. Your explaination takes it to the next step as to why the value would be there in the first place. Nicely done!