Large Integer Warning Problem

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

May I make a humble request if someone could guide me where I
could be making a mistake.

Compiler : WinAVR (GCC) 3.4.5
uC : ATmega16

In my code, I have following line. in either case, I get same
warning. Codes in both cases work on compiling, but the "warning" everytime at compile time, bugs me. I am using
PORTC to output to 8-LEDs, different LEDs "on" to indicate
where my code is progressing while running (at trouble-
shooting time).

PORTC = ~(unsigned char)0xF0;
warning: large integer implicitly truncated to unsigned type

PORTC = ~(0xF0);
warning: large integer implicitly truncated to unsigned type

Thanks to all in advance.

india_AVR

-----------------------------------------
Wonderful world of "0"s & "1"s
-----------------------------------------

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmmm--with that old version, perhaps hex constants are considered "long"? But you are casting them. [Does a decimal constant give the same results? Just guessing.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try
PORTC = (unsigned char)(~0xF0);

But even if that works the result of the ~0xF0 will probably be a signed short/int which are then type casted = unnecessary code. But you will at least probably get rid of the warning...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do have to wonder why you use 3.4.5 when 4.1.2 (in WinAVR20070525) is the most recent packaged release. But anyway I doubt it makes a difference. If you put the cast in the right place:

	PORTC = (uint8_t)~0xF0;

you don't get the warning and the code generated is:

  b6:	8f e0       	ldi	r24, 0x0F	; 15
  b8:	85 bb       	out	0x15, r24	; 21

In fact the same code is generated with both your versions (in 4.1.2) even though the warning is generated - so the warning is benign anyway.

I do wonder why you don't just use:

	PORTC = 0x0F;

as you, the programmer, must surely know what the binary inverse of 0xF0 is? This produces no warning and identical code to that above.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a lot Lee, Cola and Cliff. Sorry for the delay in reply as I had a crash with the kit and it required "first-aid". I have upgraded to 4.1.2 (in WinAVR20070525). Why I used ~0xF0, LEDs have pull-up R's, and I did not want to convert each place manually, also the higher nibble only was free to connect to LEDs as the lower nibble was pre-assigned in a "header" used in many programs :-). Please accept my humble thanks to all your directions.
india_AVR

-----------------------------------------
Wonderful world of "0"s & "1"s
-----------------------------------------

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What you have there is the classic argument for not coding literals but abstracting them to a single #define in a .h file somewhere. Then, when the bit pattern/wiring changes you edit one line in one file rather than becoming an expert on using grep

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Cliff, will follow your suggestion.
india_AVR

-----------------------------------------
Wonderful world of "0"s & "1"s
-----------------------------------------