8bit var holds 16bit data!??

# Thread: 8bit var holds 16bit data!??

1. ## 8bit var holds 16bit data!??

hi all,

so i've been having very odd problems with signed math lately, and have recently gone through the trouble to make a pic serial calculator to test a few things. using the following code as an example of what i'm testing, i am quite confused by the pic's behaviour. in this example, assume a and b are always less than \$80 (positive).

in hex (2's comp math) take the following example,
\$00 - \$05 = \$FB
since the result is greater than \$80, it is negative.
to find the magnitude of a negative number:
result = ~\$FB+1 = \$05

''''''''''''''''''''
a var byte
b var byte
result var byte
neg var bit

neg = 0
a = 0
b = 5

result = a - b 'the answer is -5, in 2's comp: \$FB

if (result > \$80) then neg = 1 ' test for negative numbers

result = ~(result) ' this yeilds \$04
result = result +1 ' this should yield 5 - the correct magnitude
''''''''''''''''''''

what i get instead, is a 16 bit value for result. as soon as i NOT the result the binary value dumped over serial is 16 bits - \$FF04. if i hserout he decimal value, i get 65284. how is this happening?

if someone could please explain this, i'd really appreciate it. i can't see how the pic can allocate a byte for the variable, then write a word to it without crashing. i must be doing something wrong, the pic couldn't function if memory allocation was that untrustworthy - the stack would get hosed.  Reply With Quote

2. ## mofarngo

We can't debug your code as you have not posted the part that is actually causing the "problem".

Using appropriate modifiers with HSEROUT would do the trick.

See: Manual Section 5.31
Last edited by NavMicroSystems; - 6th August 2005 at 15:54.  Reply With Quote

3. ## mofarngo

We can't debug your code as you have not posted the part that is actually causing the "problem".

Using appropriate modifiers with HSEROUT would do the trick.

See: Manual Section 5.31  Reply With Quote

4. ## I've run into this problem before. The ~ operator returns a 16 bit result. If you store the result into your one byte var, the upper word is truncated thus removing the uneccesary bits.

I suspect you were doing something like:
HSEROUT ["0-5=", ~Result+1]

If so, that would cause exactly what you describe. The pseudo code posted however does not suffer from this problem.  Reply With Quote

5. ##  Originally Posted by pwhitt
I've run into this problem before. The ~ operator returns a 16 bit result. If you store the result into your one byte var, the upper word is truncated thus removing the uneccesary bits.

I suspect you were doing something like:
HSEROUT ["0-5=", ~Result+1]

If so, that would cause exactly what you describe. The pseudo code posted however does not suffer from this problem.
The problem is:
You are outputting a VAR that has been declared as BYTE with a resolution of 16 bits,
that doesn't make much sense, does it?

Try:
HSEROUT [DEC3 result] ' for Decimal output (3 Digits)

HSEROUT [HEX2 result] ' for Hexadecimal output (2 Digits)

See: Manual Section 5.31  Reply With Quote

6. ## <i>"The problem is:
You are outputting a VAR that has been declared as BYTE with a resolution of 16 bits, that doesn't make much sense, does it?"</i>

NavMicroSystems, if you mean the output of the HSEROUT statement:

HSEROUT ["0-5=", ~Result+1]

No, I'm outputting the result of a 16bit operation, not a VAR at all (this would likely end up in a terminal full of garbage - not numbers at all). I should have been more clear and typed:

HSEROUT ["0-5+",BIN ~Result+1]
which should yield: 1111111100000101 and I think this corresponds to the incorrect value given above.

However if our friend Mofarngo were to write this value to Result first, the leading word would be truncated, resulting in: 00000101, which is what he wants.  Reply With Quote

7. ## pwhitt is right. When you include the equation inline with HSEROUT ["0-5=", ~Result+1] you're telling PBP to output the "result" of ~result+1.

And since the compliment is handled as a 16-bit operation, HSEROUT is going to send a 16-bit result computed internally by the inline equation ~result+1.

You can see how this works with something like this;

HSEROUT ["100 * 50 = ", DEC 100*50,13,10]

Note there's no reference to any variable. Only an equation. That's pretty much the same thing as passing ~result+1 to HSEROUT. It's going to print the result of the equation, and not the byte variable result.  Reply With Quote

8. ## thanks guys - that was a stupid oversight on my part.

i was doing exactly "serout [~result+1]" to get the result.

writing the result to the var and then sending over serial fixed it right away. oops!  Reply With Quote

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts