Try:

1L << bit

The L makes the constant a long, and thus able to be shifted 23 bits over.=
=20

~ Bob Ammerman
RAm Systems

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
Harold Hallikainen
Sent: Wednesday, August 13, 2014 6:40 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] Bit Test in XC8

It'd be interesting to experiment with it. The advantage to the shifting of
the bit number instead of the variable is that it can be done at compile
time instead of run time. A couple possibilities come to mind...

Try just doing 1<<23 and see if you get the right result. Perhaps the macro
arithmetic is not handling that large an int.

I'm not sure of the exact operation of ! when the following item is not 0 o=
r
1. Perhaps a compare to zero can be included in your macro. Also, on naming=
,
testbit does not clearly indicate to me whether it returns true if the bit
is high or low. It says we test the bit, but does not tell us much about th=
e
result.

So, how about this (untested) code?

#define  BithHigh(var, bit)  (0!=3D(var & (1 <<bit)))

Harold

> Hi all,
>
> Once again...back at my C project after a few weeks away. This time=20
> I'm trying to streamline bit testing. I know there isn't a direct=20
> equivalent to BTFSC in C, so I'm following some advice from the XC=20
> manual, section 3.4.4.2 "How can I access individual bits of a=20
> variable". It proposes creating a bit testing define like this:
>
> #define  testbit(var, bit)  ((var) & (1 <<(bit)))
>
> I am using this code in the following way:
>
>       if(!(testbit(this_led, 23)))
>       {          // test fixed bit 23
>           SSP2BUF =3D ws2811_one;
>       }
>       else
>       {
>           SSP2BUF =3D ws2811_zero;
>       }
>
> What I am doing is testing the individual bits of a variable, then=20
> using the result to decide what to send out via SPI (not relevant at=20
> this point, but I am trying to control WS2812 LEDS). I am always=20
> testing bit 23, then shifting the variable to the left to get at the=20
> next value.
>
> My issue is that my testbit always ends up returning 0. With the "!",=20
> that means my code is always transmitting a 1. If I remove the "!", I=20
> am always transmitting a 0.
>
> My thought is that perhaps this is happening because of the bit I am=20
> testing? The temp variable testbit is declared like this: "static=20
> uint32_t this_led;", so it is actually a large enough variable to be=20
> testing bit 23.
>
> I had a look at the listing output of the compiler, and I found this:
>
> 852                           ;ws2812_lib.c: 37: if((((this_led) & (1
> <<(23)))))
> 853  000548  A03E                   btfss    send_frame@this_led,0,c
> 854  00054A  D002                   goto    l1127
>
> To me, it looks like the assembly code is testing bit 0. This would=20
> make sense in that the assembly code doesn't natively support 32 bit=20
> variables.
>
> If my guesses are correct, what might be a better way to deal with=20
> this? I would prefer to avoid testing bit 0 and shifting the other way=20
> due to the order in which I need to send the bits.
>
> Thoughts?
>
> Thank you!
>
> Josh
> --
> A common mistake that people make when trying to design something=20
> completely foolproof is to underestimate the ingenuity of complete=20
> fools.
>         -Douglas Adams
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive=20
> View/change your membership options at=20
> http://mailman.mit.edu/mailman/listinfo/piclist
>


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
Not sent from an iPhone.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/chang=
e
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.