Arduino Internal Warning

Hi guys,

When I compile my program, which is 100 percent fully operational, in the Arduino IDE, I get this message warning:

  • D:\Programs\arduino-1.0.1\hardware\arduino\cores\arduino\Print.cpp:44: warning: 'progmem' attribute ignored

What does this mean?

Thank you,
RobertEagle

What does this mean?

It means that the progmem attribute has been ignored. Someone used it when it was inappropriate, and the compiler is ignoring it.

So, it doesn't affect in some way my sketch, right?

RobertEagle:
So, it doesn't affect in some way my sketch, right?

In the sense that it will still do what the code tells it to do, yes.

As far as your expectation? No idea.

The line in question reads:

  const char PROGMEM *p = (const char PROGMEM *)ifsh;

The PROGMEM is a macro, which (ultimately) translates to:

__attribute__((__progmem__))

So the whole line reads:

  const char __attribute__((__progmem__)) *p = (const char __attribute__((__progmem__)) *)ifsh;

At least one of those progmem attributes must be redundant in the context of how you are calling that function. The ifsh is defined in the function prototype as:

size_t Print::print(const __FlashStringHelper *ifsh)

where __FlashStringHelper is a class defined in WString.h and is associated with the F() macro.

Under normal circumstances that warning doesn't appear, so it must be related to how you are calling the print function. Check through your program for all the print and println functions and work out by means of elimination (comment them all out and enable them one by one until it happens) which is causing the warning to appear. Show us that bit of code, including the definitions for any variables used in it, and we can try and see why it might be bringing up the warning.

This is the code:

read(0x00,1);//this is a read function written for the Wire communication protocol which returns the tab variable
Serial.flush();//flushing the Serial
Serial.print("RdReg init process..\nADXL345 address:");
Serial.println(tab[0],BIN);

Which of those two print calls causes the warning?

What type is the tab variable?

The final instruction. The one with the "ln" suffix.
The tab variable is a byte.

Just as a matter of interest, do you have verbose compilation enabled?

Yes.

I thought so. That warning is always displayed when verbose compilation is enabled, and print is used. It doesn’t seem to matter what is printed.

Hah... I have got it to replicate the warning ... WITH verbose turned on.

That AND other warnings that are normally hidden!

/home/matt/arduino-1.0.1/hardware/arduino/cores/arduino/Tone.cpp:108: warning: only initialized variables can be placed into program memory area
/home/matt/arduino-1.0.1/hardware/arduino/cores/arduino/HardwareSerial.cpp: In function ‘void store_char(unsigned char, ring_buffer*)’:
/home/matt/arduino-1.0.1/hardware/arduino/cores/arduino/HardwareSerial.cpp:82: warning: comparison between signed and unsigned integer expressions
/home/matt/arduino-1.0.1/hardware/arduino/cores/arduino/HardwareSerial.cpp: In member function ‘virtual size_t HardwareSerial::write(uint8_t)’:
/home/matt/arduino-1.0.1/hardware/arduino/cores/arduino/HardwareSerial.cpp:390: warning: comparison between signed and unsigned integer expressions
/home/matt/arduino-1.0.1/hardware/arduino/cores/arduino/Print.cpp: In member function ‘size_t Print::print(const __FlashStringHelper*)’:
/home/matt/arduino-1.0.1/hardware/arduino/cores/arduino/Print.cpp:44: warning: ‘__progmem__’ attribute ignored

Messy. Very messy. Some of those warnings should be heeded - especially the comparison between unsigned and signed ones. And they are things that the Arduino maintainers should be actively fixing - not just sweeping under the carpet with hiding the output by default.

I always do my proper compiling with -Wall turned on, and strive to get ZERO warnings.

As for the progmem one, it can probably be ignored, but who knows with the Arduino...

Got it then. So ignore it. I’m not so comfortable with the idea, but that’s it.

Thank you, guys,
RobertEagle

both the two comparisons of signed/unsigned in this case are harmless as it is basically:

if (int != unsigned int)

where neither the int not the unsigned int should ever be more than 128 or less than 0.
[This is the only line of code which changes either of the two variables compared:
( + 1) % SERIAL_BUFFER_SIZE; //where SERIAL_BUFFER_SIZE is defined as 64]

In reality, its another case of the arduino core and examples loving to be wasteful of ram - they should just be bytes aka uint8_t types - the same goes for all the cases where variables are used to store pin names - for some reason they like ints when a byte is plenty sufficient.

Yes. I've seen this thing at them. Bytes variables instead of int's, or if it was necessary much data at least the short(int16_t).
Just when I was writing the library for my sensor, I found myself asking why the hack am I using the int's, so I've switched back to bytes, because they were much more smaller.

"int" is such a vague term as well.

Some systems it's 16 bits, some it's 32. It's even possible to have 64 bit ints should you desire.

"short", "long" and "char" is all you should ever need - that and the "unsigned" prefix.

(a "byte" is just an "unsigned char".)

Not to resurrect an old thread or anything, but this is a very interesting discussion. I have recently begun to make heavy use of the Arduino libraries, and have been noticing a number of compiler warnings in v1.0.5. I started out with the Arduino IDE, but have now configured Eclipse to provide a more robust development environment. This makes it easier to investigate the various compiler warnings, as all you have to do is to click on them to open the appropriate file directly. So in searching for some of these warnings I ran across this thread, and think it's an excellent discussion. Basically, I am somewhat amazed at a few of these warnings actually...as in, why are they even still there. In one case there was a "compared signed to unsigned int" warning, and it was quite ironic actually as the code went something like this:

int i = (unsigned int)(foo + 1) % SOME_VALUE;

...and then they tried to compare i' to another unsigned integer a few lines down. So I simply made 'i' an unsigned integer in the first place, and that was that.

But I have to wonder...how does something like this NOT get fixed? Why are simple little things like this left in the core Arduino library? I mean, the hover-help in Eclipse confirms what the compiler warned me about--that the thing being compared to "int i" is indeed an unsigned integer. So doesn't stuff like this give Arduino a bit of a black eye, in some ways? And there are also numerous instances of unused variables being scattered around various files, so I've been going through and removing those to resolve warnings where needed.

Anyway, I'll just fix these things were needed--and then build a "clean" version of the Arduino core libraries for my projects. But I just thought this issue was worthy of mention, simply due to the fact that (like has been pointed out here) it is quite a simple matter to resolve these things in the first place. But if you use the Arduino IDE, I think the tendency is to not even pay attention to stuff like that. For one thing the verbose compiler output isn't enabled by default (it wasn't in my IDE anyway), so you really have to know to go looking for that feature. Then the default compiler output window is so small (narrow) by default that any orange text messages fly by so quickly that most people probably aren't even going to notice them...much less go back and look at what they represent. This is just another reason why I like using a higher-powered IDE, and given the fact that it's so cross-platform, I have really been liking Eclipse for my work of late.

Now if I could only figure out the proper AVRDude settings for the Mega2560, I could get that bit working in Eclipse and I'd be off to the races. For some reason the settings hinted at in the boards.txt file don't result in a successful upload. Then I managed to hose one of the fuses in my Mega and had to spend 3-4 hours getting that reset with an ISP...lol. Needless to say, there have been LOTS of "learning opportunities" for me lately!

TB