Hi, there an example in CARM user guide:
#include <stdio.h> void test_getkey (void) { while ((c = _getkey ()) != 0x1B) { printf ("key = %c %bu %bx\n", c, c, c); } }
So what's the meaning of %bu and %bx? I can compile it, but responce is ey = a Bu Bx after pressing an a
"So what's the meaning of %bu and %bx?"
Please read the manual: http://www.keil.com/support/man/docs/ca/ca_printf.htm
"responce is ey = a Bu Bx"
Are you sure you typed it all correctly in your source file? It looks like you have omitted the percent signs '%', or maybe put in some spurious spaces? The missing 'K' could mean that your serial IO support is broken...
Where is your definition of c?
Well, actually the FM says no notin 'bout "%b" type or flag...
%b isn't a format specifier that I'm familiar with.
I've read the f***ing manual... but there's no hint about %bu or %bx. I've copied the example by cut and paste. My defination of c is unsigned char.
The missing 'K' could mean that your serial IO support is broken... The 'K' is missing all the time. Hardware or Software problem?
Note This message was edited because of rude or abusive language.
It looks like it was supported in the C51 version…
http://www.keil.com/support/man/docs/c51/c51_printf.htm
I would guess that the specific compiler has a feature where it may send parameters as bytes instead of following the C requirement of always upgrading them to int size.
printf() must then make use of a size modifier to know that it should just pick up one byte when printing the integer.
Relative to the missing 'K' character, I've seen hardware problems where it took some (usually small, but unspecified) amount of time from when the uC came out of RESET before you could get a character properly transmitted by a UART. I've seen other implementations where the 1st character transmitted by a UART after being configured just never came out right. These problems weren't due to the compiler, etc., but rather the uC or PCB hardware implementation. Sometimes a glitch could go out on a UART's TX line as that line was being [re]configured by the startup code (into a UART output), thereby preventing the device on the associated RX line from receiving the 1st character properly.
As for the %b stuff... why don't you just chalk it up to an error in the documentation and report it to KEIL's tech support, where they can take care of it for you? This forum is not where bug reports, etc. are supposed to be sent to KEIL for resolution. I've never seen %b as some kind of printf related format specifier in any of my C books.