Post by thread:16-bit arithmetic in C

I copy them into a single int using the following code: int capture; ... #asm movf CCPR1L,w movwf _capture+0 movf CCPR1H,w movwf _capture+1 #endasm Now capture has the value I want to play with. If capture is a local (auto) variable, you need to change the _capture to something in a slightly different format _routine$capture (for 7.85) _routine_captuer (for 7.84 and earlier) Andy "David E. Olson" <spam_OUTdolsonTakeThisOuTPROGRESS.COM> on 03/21/2000 12:43:09 PM Please respond to pic microcontroller discussion list <.....PICLISTKILLspam@spam@MITVMA.MIT.EDU> To: PICLISTKILLspamMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: 16-bit arithmetic in C Here's an easy one, I hope... I'm working with Hi-Tech C on a 16C73 project where I have to do some arithmetic on a 16-bit value - specifically the hi and lo bytes of the capture register CCPR1(H and L). How can I smash, concatenate, whatever the two 8-bit hi and low bytes into a 16-bit one? I'm guessing I need to shift them in. Or would it be more efficient to work with the hi and low bytes separately. Specifically, I'm trying to figure out the delta of two samples and I thought it would be easier to work with it as a single int value. -DO

part 0 8344 bytes Or to keep it in C you could use a union like so: union intchar           /* define the union variable type */ {         struct         {                 unsigned char lo;                 unsigned char hi;         }byte;         unsigned int total; } union intchar myvar;    /* declare the variable */ To use this you would load the two halves as follows: myvar.byte.lo = CCPR1L; myvar.byte.hi = CCPR1H; Your 16 bit total will then reside in myvar.total I try and use these constructs to stay away from inline asm wherever possible, but sometimes it really is needed.  You can use this method to access bits in a char or int as well.  Have a look on HiTechs FAQ page at <A HREF="http://www.htsoft.com/" TARGET="_blank">http://www.htsoft.com/</A> for more details. Hope that helps Mike Rigby-Jones <UL> {Original Message removed}

part 0 3314 bytes content-type:text/html;At one time I believe I checked and found the HTC generated comparable code to what I proposed in assembly. I think it does this correctly: int counter; counter = (CCPR1H << 8) | (CCPR1L); Andy Michael Rigby-Jones <.....mrjonesKILLspam.....NORTELNETWORKS.COM> on 03/21/2000 10:39:12 AM Please respond to pic microcontroller discussion list <EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU> To: PICLISTspam_OUTMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: 16-bit arithmetic in C Or to keep it in C you could use a union like so: union intchar /* define the union variable type */ { struct { unsigned char lo; unsigned char hi; }byte; unsigned int total; } union intchar myvar; /* declare the variable */ To use this you would load the two halves as follows: myvar.byte.lo = CCPR1L; myvar.byte.hi = CCPR1H; Your 16 bit total will then reside in myvar.total I try and use these constructs to stay away from inline asm wherever possible, but sometimes it really is needed. You can use this method to access bits in a char or int as well. Have a look on HiTechs FAQ page at http://www.htsoft.com/ for more details. Hope that helps Mike Rigby-Jones > {Original Message removed}

First of all, many thanks on the input. [Various bits from Michael and Andy snipped...] > union intchar /* define the union variable type */ I thought about a union too. It, for some late night reason, seemed clunky. But now that I see it after some rest, it doesn't look too bad. I may try a few options and see what I get out when it compiles. > I try and use these constructs to stay away from inline asm wherever possible, but sometimes it really is > needed. You can use this method to access bits in a char or int as well. Have a look on HiTechs FAQ page at > http://www.htsoft.com/ for more details. Forgot to go to the FAQ - perused the PIC archives and Hi-Tech's on-line discussions. > At one time I believe I checked and found the HTC generated comparable code to > what I proposed in assembly. > > I think it does this correctly: > > int counter; > counter = (CCPR1H << 8) | (CCPR1L); > This is what I thought could be done. While the union gives me access to all the entities, I'll have to further look to see I need the hi and low order bytes when I'm done. Chances are, no. Question for Andy - is the above example what you found to be comparable to the assembly routine you posted? Unfortunately I'm not at my dev machine right now to try it out. -DO

Yes, this is the C that I believe generated the good code. I can't test now myself either :-( Boating season is here! Andy "David E. Olson" <@spam@dolsonKILLspamPROGRESS.COM> on 03/21/2000 06:11:49 PM Please respond to pic microcontroller discussion list <KILLspamPICLISTKILLspamMITVMA.MIT.EDU> To: RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: 16-bit arithmetic in C First of all, many thanks on the input. [Various bits from Michael and Andy snipped...] > union intchar /* define the union variable type */ I thought about a union too. It, for some late night reason, seemed clunky. But now that I see it after some rest, it doesn't look too bad. I may try a few options and see what I get out when it compiles. > I try and use these constructs to stay away from inline asm wherever possible, but sometimes it really is > needed. You can use this method to access bits in a char or int as well. Have a look on HiTechs FAQ page at > http://www.htsoft.com/ for more details. Forgot to go to the FAQ - perused the PIC archives and Hi-Tech's on-line discussions. > At one time I believe I checked and found the HTC generated comparable code to > what I proposed in assembly. > > I think it does this correctly: > > int counter; > counter = (CCPR1H << 8) | (CCPR1L); > This is what I thought could be done. While the union gives me access to all the entities, I'll have to further look to see I need the hi and low order bytes when I'm done. Chances are, no. Question for Andy - is the above example what you found to be comparable to the assembly routine you posted? Unfortunately I'm not at my dev machine right now to try it out. -DO

part 0 2198 bytes Ok, been doing a bit of fiddling. I found an include that I downloaded while back, but never really looked at.  Amongst other stuff, the file defines the following: #define byte0(x)                (unsigned char)(*(((unsigned char *)&x)+0)) #define byte1(x)                (unsigned char)(*(((unsigned char *)&x)+1)) To use this you would do the following (assuming count is your 16bit var):         byte0(count) = CCPR1L;         byte1(count) = CCPR1H; This compiles to the expected 4 instructions.  The file, along with some other good stuff for HiTech C can be found at <A HREF="http://www.keyghost.co" TARGET="_blank">http://www.keyghost.co</A>m/ Regards Mike Rigby-Jones </BODY> </HTML> </x-html>

part 0 5383 bytes Andy Kunz proposed: <UL> > At one time I believe I checked and found the HTC generated comparable code to > what I proposed in assembly. > > I think it does this correctly: > >      int counter; >      counter = (CCPR1H << 8) | (CCPR1L); > </UL> David E. Olson replied: <UL> This is what I thought could be done. While the union gives me access to all the entities, I'll have to further look to see I need the hi and low order bytes when I'm done. Chances are, no. Question for Andy - is the above example what you found to be comparable to the assembly routine you posted? Unfortunately I'm not at my dev machine right now to try it out. </UL> Andy Kunz came back with: <UL> Yes, this is the C that I believe generated the good code.  I can't test now myself either :-( Boating season is here! Andy </UL> It certainly would make a neat macro if it worked.  However, I've just tried it on V7.85, compiling for a 16F877 with maximum optimisation and it got it's knickers in a twist: This is moving the CCPR1H and CCPR1L registers in a global unsigned int called "count"         movf    21,w    ;volatile         movwf   btemp+1         clrf    btemp         movf    22,w    ;volatile         iorwf   btemp,w         movwf   _count         movf    btemp+1,w         movwf   _count+1     As all registers are in bank 0, this should boil down to 4 instructions, with no temps being needed.  Any comments Clive if you're listening? Regards Mike Rigby-Jones </BODY> </HTML> </x-html>

On Wed, Mar 22, 2000 at 09:51:16AM -0000, Michael Rigby-Jones wrote: > It certainly would make a neat macro if it worked. However, I've just tried > it on V7.85, compiling for a 16F877 with maximum optimisation and it got > it's knickers in a twist: You didn't show your C code, but here's what I tried: ;x.c: 7: count = (CCPR1H << 8) + CCPR1L; movf 22,w ;volatile movwf _count+1 movf 21,w ;volatile movwf _count Looks fine to me. Of course, the other (better) way to do it, which works since CCPR1L and CCPR1H are adjacent and in the right order, is this static unsigned int CCPR1 @ 0x15; Now you can just use it directly. Regards, Clyde PS - Mick, I don't think Clive James reads the PIClist. -- Clyde Smith-Stubbs | HI-TECH Software Email: spamBeGoneclydespamBeGonehtsoft.com | Phone Fax WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885 PGP: finger TakeThisOuTclydeEraseMEspam_OUThtsoft.com | AUS: +61 7 3355 8333 +61 7 3355 8334 --------------------------------------------------------------------------- HI-TECH C: compiling the real world.

part 0 9556 bytes Sorry about the name cock-up Clyde.  How embarrasing. OK, I've just tried this code: #include <pic.h> unsigned int count; void main( ) {         count = (CCPR1H << 8) + CCPR1L; } Compiled through MPLAB which produces the following command line: C:\HT-PIC\BIN\PICC.EXE -Gmicrochip -O -Zg9 -D24 -16F877 -C -IC:\HT-PIC\INCLUDE -ASMLIST C:\HT-PIC\PROJECTS\MISC\TEST.C This gives me:         movf    22,w    ;volatile         movwf   btemp+1         clrf    btemp         movf    21,w    ;volatile         addwf   btemp,w         movwf   _count         movf    btemp+1,w         btfsc   3,0         incf    btemp+1,w         movwf   _count+1 I was sure I must be doing something screwy here, so I have re-installed V8.75 just to make sure I had the right version and the results are the same. Your idea of using it directly is superb, I just wouldn't have thought of that.  However it obviously only works in the minority of cases, a more general solution is needed for most jobs. Regards Mike Rigby-Jones <UL> {Original Message removed}

> #include <pic.h> > unsigned int count; > void main( ) > > count = (CCPR1H << 8) + CCPR1L; > } I was going to reply to Michael's comment that his compiler barfed over this statement - when I did it worked fine. Had me worried until I read the other posts. However... > static unsigned int CCPR1 @ 0x15; This looks even cooler. Got to love it when folks want to try to optimize a seemingly innocuous function. >Your idea of using it directly is superb, I just wouldn't have thought of that. However it obviously > only works in the minority of cases, a more general solution is needed for most jobs Michael - are you saying that either CCPR1 is not adjacent in all pics or it's not at 0x15? -DO

part 0 3064 bytes >         count = (CCPR1H << 8) + CCPR1L; > } I was going to reply to Michael's comment that his compiler barfed over this statement - when I did it worked fine. Had me worried until I read the other posts. </UL> Well, it's got me well and truly worried.  I just can not get this to work no matter what I do.  Are you using the compiler through MPLAB or are you using the HPDPIC IDE?  I have to admitt, I have been seeing some odd things recently... <UL> However... > static unsigned int     CCPR1 @ 0x15; This looks even cooler. Got to love it when folks want to try to optimize a seemingly innocuous function. >Your idea of using it directly is superb, I just wouldn't have thought of that.  However it obviously > only works in the minority of cases, a more general solution is needed for most jobs Michael - are you saying that either CCPR1 is not adjacent in all pics or it's not at 0x15? -DO </UL> No, I'm saying that using this method is great for the case of grabbing a 16 bit result from a peripheral that happens to have the hi-lo bytes adjacent and in the right sequence.  There are other times when you may want to construct an 16 bit integer from two bytes where this just is not applicable, for instance building a 16 bit value from the two 8 bit SPI transfers of an ADC. AFAIK CCPR1 will have it's registers in the same place on any particular PIC family. </BODY> </HTML> </x-html>

> Well, it's got me well and truly worried. I just can not get this to work no matter what I do. > Are you using the compiler through MPLAB or are you using the HPDPIC IDE? I have to admitt, > I have been seeing some odd things recently... Nope. Using it standalone and through a Mathias. I'm up to 7.85. I got it to work through TDE from Tech-Tools. No extra optimization flags either. Just plain build and emulate. Could it be PIC dependent? I'm specifically using the 16C73A emulation (even though the target chip will be a 73B - wish Tech Tools supported the 73B!). > No, I'm saying that using this method is great for the case of grabbing a 16 bit result from a peripheral that > happens to have the hi-lo bytes adjacent and in the right sequence. There are other times when you may > want to construct an 16 bit integer from two bytes where this just is not applicable, for instance building a > 16 bit value from the two 8 bit SPI transfers of an ADC. > AFAIK CCPR1 will have it's registers in the same place on any particular PIC family. That's what I thought - portability. -DO

I just tried Michael Rigby-Jones' code and confirmed his results - 10 instructions. (V7.85 with a code generator only a couple of weeks old). I know I have seen the four instruction sequence in the past, but the test code certainly doesn't generate it. Regards, Jim Ham At 08:55 PM 3/22/2000 +1000, you wrote: >On Wed, Mar 22, 2000 at 09:51:16AM -0000, Michael Rigby-Jones wrote: >> It certainly would make a neat macro if it worked. However, I've just tried {Quote hidden}>> it on V7.85, compiling for a 16F877 with maximum optimisation and it got >> it's knickers in a twist: > >You didn't show your C code, but here's what I tried: > >;x.c: 7: count = (CCPR1H << 8) + CCPR1L; > movf 22,w ;volatile > movwf _count+1 > movf 21,w ;volatile > movwf _count > >Looks fine to me. > > Jim Ham, Porcine Associates (650)326-2669 fax(650)326-1071 "http://www.porcine.com"

> I just tried Michael Rigby-Jones' code and confirmed his results - 10 > instructions. (V7.85 with a code generator only a couple of weeks old). I > know I have seen the four instruction sequence in the past, but the test > code certainly doesn't generate it. > Jim Ham > > >You didn't show your C code, but here's what I tried: > >;x.c: 7: count = (CCPR1H << 8) + CCPR1L; > > movf 22,w ;volatile > > movwf _count+1 > > movf 21,w ;volatile > > movwf _count > > > >Looks fine to me. Any news on this? Friendly Regards Octavio Nogueira =================================================== nogueiraEraseME.....propic2.com ICQ# 19841898 ProPic tools - low cost PIC programmer and emulator http://www.propic2.com ===================================================

On Wed, Mar 22, 2000 at 11:15:59AM -0000, Michael Rigby-Jones wrote: > I was sure I must be doing something screwy here, so I have re-installed > V8.75 just to make sure I had the right version and the results are the I'll look into it further - I was testing with 7.86 but I did not think there should be a difference. I'll report back when I have some more info. Regards, Clyde -- Clyde Smith-Stubbs | HI-TECH Software Email: EraseMEclydehtsoft.com | Phone Fax WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885 PGP: finger RemoveMEclydeEraseMEEraseMEhtsoft.com | AUS: +61 7 3355 8333 +61 7 3355 8334 --------------------------------------------------------------------------- HI-TECH C: compiling the real world.