Searching \ for 'What's wrong with this macro?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=whats+wrong+with
Search entire site for: 'What's wrong with this macro?'.

Truncated match.
PICList Thread
'What's wrong with this macro?'
1997\03\06@105409 by mbonner

flavicon
face
Hi,

I think I'm missing something very basic.  I'm using ByteCraft's MPC and
the target controller is the PIC16C74A.  This macro is supposed to take
2 unsigned 8-bit chars (h: high, l: low), concatenate them, and return
the unsigned 16 bit result.  Instead, it's masking (zeroing) the high
byte.

#define WORD(h,l)   (((unsigned long)(h) << 8) | (unsigned char)(l))

Thanks, Matt

1997\03\06@115142 by Ed VanderPloeg

flavicon
face
At 08:00 AM 3/6/97 PST, you wrote:
>Hi,
>
>I think I'm missing something very basic.  I'm using ByteCraft's MPC and
>the target controller is the PIC16C74A.  This macro is supposed to take
>2 unsigned 8-bit chars (h: high, l: low), concatenate them, and return
>the unsigned 16 bit result.  Instead, it's masking (zeroing) the high
>byte.
>
>#define WORD(h,l)   (((unsigned long)(h) << 8) | (unsigned char)(l))
>
>Thanks, Matt
>
I don't use the MPC compiler, but have you tried:
- extra brackets around the first cast & the "(h)", like this:
#define WORD(h,l)   ((((unsigned long)(h)) << 8) | (unsigned char)(l))

- using a different cast like (uint16) or (word), to see if the compiler is
only allowing 8 bits for the "long".

- casting the whole macro to ensure a 16 bit output:
#define WORD(h,l)   (unsigned long)(((unsigned long)(h) << 8) | \
                                    (unsigned char)(l))

IMHO, it seems there should be a much more efficient way to create a word
out of two bytes than this.  I'm curious as heck what the compiler gives
you for that macro.  Maybe it actually sets up a loop and shifts eight
times (gross!).  Trouble is, I can't think of any alternatives right now.
Anyone got ideas?

-Ed V.

1997\03\06@122300 by mbonner

flavicon
face
Ed VanderPloeg wrote:
{Quote hidden}

Ed,
As you can see, the compiler stores the high byte, clears the storage
location for the low byte, and ORs the low byte into the cleared
location.  The only inefficiency that I can see is the ORing into a
known-clear location (instead of a MOV).

BCF    STATUS,RP0    Sample = WORD(Phi, Plo);
MOVF   39,W
BSF    STATUS,RP0
MOVWF  46
CLRF   45
BCF    STATUS,RP0
MOVF   3A,W
BSF    STATUS,RP0
IORWF  45

BTW, the extra brackets didn't change the assembled code.  I still have
to try it in my target system.

Matt

1997\03\06@123058 by Bill Durocher

flavicon
face
part 0 428 bytes
union word_byte_u
{
   unsigned char       low_byte;   /* the order of low_byte and high_byte
declaration */
   unsigned char       high_byte;  /* would be compiler specific */
   unsigned long       the_word;
} u_convert;

Then when you wanted to convert two bytes to one word in your code:

u_convert.low_byte = low_val;
u_convert.high_byte = high_val;
answer = u_convert.the_word;

Classic use of union.....

-Bill






More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...