We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I am relatively new to the Keil / ARM development environment though have been programming microcontrollers and C for a few years now (though only in an amateur capacity :).
I am using sprintf to format a string for display on an LCD (though the same thing happens when sending the string over the serial port as well) and am getting a warning:
warning: argument of type "unsigned char *" is incompatible with parameter of type "char *restrict"
Everything works ok when I ignore this warning but ignoring these warnings doesn't sit well (especially as I don't really understand it). I get that "restrict" is a new keyword feature in C99 to enable compiler optimisations and it probably doesn't matter too much for the simple applications I am creating, but I would like to know if this is implemented in the ARM compilation toolchain and, if so, how I can use it. A snippet of my code is below:
// initialise some local values and the display buffer uint32_t val; static unsigned char disp_buffer[21]; // read the global variables to the local values val = global_val; // do string formatting before lcd display sprintf(disp_buffer, "Value: %4d", val); GLCD_DisplayString(6, 0, 1, disp_buffer);
Thanks for any help you can give,
Alex
signed vs unsigned? If you don't like warnings, use a cast and be explicit.
Thanks for your help. I don't think that is it - if I declare my buffer as:
char disp_buffer[21];
I just get the warning:
warning: #167-D: argument of type "char *" is incompatible with parameter of type "unsigned char *"
instead!
Then that suggests:
// initialise some local values and the display buffer uint32_t val; static char disp_buffer[21]; // read the global variables to the local values val = global_val; // do string formatting before lcd display sprintf(disp_buffer, "Value: %4d", val); GLCD_DisplayString(6, 0, 1, (unsigned char*)disp_buffer);
Thanks Dan - but I'm afraid I still get the warning:
Cheers,
Thanks Dan - but I'm afraid I still get the warning: But do you get it regarding the same source code line than the other one? I don't think so.