Bit operation

RE: Bit operation

Sagisawa Yukichi — Mon, 12 Sep 2016 00:44:28 GMT

Thanks many reply! and I'm sorry to reply late. Now I set Keil to c99, I think I use C language. I changed %d to %u, the code output 63577. From this point of view, I think RK-san said is true.

Thanks!

RE: Bit operation

Roger Clark — Fri, 09 Sep 2016 22:26:57 GMT

BTW. I was referring to gcc a toolchain rather than the compiler (perhaps I should have made this explicit)

I don't have time to try all the different gcc libs, I suspect they all behave the same

But as a matter of interest, I compiled the code in Visual Studio, targeted for Win32 and it also works fine.

I don't have any other 32 bit compilers, but perhaps someone else has IAR and can confirm the behavior under that toolchain

Perhaps the OP can try the different libs in Keil

RE: Bit operation

RK — Fri, 09 Sep 2016 12:06:18 GMT

yes but that bothers me too. Because printf() is always defined with an ellipsis and so you'd expect the compiler would have to turn it into a va_arg call, because you'd expect the library would use va_arg to parse it. So there is some kind of link between the compiler and the library. I know gcc has a __builtin_va* so perhaps that's the glue.

RE: Bit operation

awneil — Fri, 09 Sep 2016 11:07:32 GMT

So this would depend on the particular library you're using - less directly on the actual compiler.

Keil has a number of options, and there are various libraries that can be used with GCC...

RE: Bit operation

RK — Fri, 09 Sep 2016 10:47:49 GMT

gcc (at least this version) treats printf as an ordinary function with lots of arguments, so the first few go in registers, the next go on the stack, but all promoted to 32 bit as per the usual ARM ABI. Keil, I believe from what I have read, treats printf as a va_arg function and concatenates all the arguments into a block of memory then passes that and printf reads it with the equivalent of va_start() .. etc. So if you get the format specifier wrong on keil, you read (in this case) two extra bytes of random junk.

RE: Bit operation

Roger Clark — Fri, 09 Sep 2016 10:30:35 GMT

OK. Thanks. I didn't see that.

gcc seems to behave differently to keil

I tried

char buf[64];
sprintf(buf,"%d",us);

and it gave the result the OP expected.

I tried using us as an int as a short (still no problem using gcc )

Perhaps gcc automatically casts unsigned short to unsigned int in sprintf

RE: Bit operation

awneil — Fri, 09 Sep 2016 08:19:33 GMT

Stated in OP: it's Keil.

www.keil.com/.../armcc_chr1359125009502.htm

RE: Bit operation

Roger Clark — Fri, 09 Sep 2016 07:58:38 GMT

What compiler are you using.

I've tried to replicate this using gcc and I get the correct value.

The number you quoted as being display by printf is 0x2553F444FB which makes no sense at all

You could try

us = (tmp[0] *256 ) + tmp[1];

As the compiler is smart enough to realize that * 256 can be done by shifting.

RE: Bit operation

Sagisawa Yukichi — Fri, 09 Sep 2016 07:46:32 GMT

I mistake printf format. Thank you!

RE: Bit operation

Sagisawa Yukichi — Fri, 09 Sep 2016 07:39:41 GMT

Oh, I think short is 2byte integer data.

RE: Bit operation

Sagisawa Yukichi — Fri, 09 Sep 2016 07:37:59 GMT

while(1){printf("%d\r\n",us);} It did print out 160, 322, 307, 323.

In detail my question, I use sensor what communication i2c. tmp is data from the sensor. I try the following code,

unsigned short us = (tmp[0] << 8) | tmp[1]; printf("%x,%x -> %d\r\n",tmp[0],tmp[1],us);

It output f8,59,322 .

But unsigned short us = (0xf8 << 8) | 0x59; printf("%x,%x -> %d\r\n",tmp[0],tmp[1],us); It output f8,59,63577 . What shall I do?

RE: Bit operation

awneil — Fri, 09 Sep 2016 07:30:21 GMT

Agreed: this is standard 'C' - nothing specific to Nordic.

What number does it print? Have you thought about the significance of that number?

%d expects an int - not a short.

www.cplusplus.com/.../

RE: Bit operation

RK — Fri, 09 Sep 2016 07:22:31 GMT

Not really a Nordic question at all in any way - what number does it print out?