Printf statement used on IAR compiler / MSP430 processor

terminal program .

This has no meaning. printf by definition prints to stdout, which is the console. There is no console on an MSP430 unless you put together an operating system that defines what a console is, and provides an I/ O driver to talk to one. You can certainly write a serial I/O driver and use sprintf to format strings that you then send with that driver.

Some compiler vendors by default have printf communicate with the debugger to show a virtual console in the debug window. I believe IAR does this. But it is not "serial to PC terminal program".

Sure, it does make sense. I come from the ARM world utilizing KEIL IDE tool. We have done something like this all the time. I am looking for IAR equivalent of the following:

int main (void) {

configure_pll_clk(); config_uarts(); //setup UART port EIC_IRQConfig(ENABLE); // Configure ALL IRQ's GPIO_Config(GPIO2, 0xff00, GPIO_OUT_PP); printf("\n\rARM PROCESSOR TEST PROGRAM\n"); printf("\rCompiled: %s %s\r\n", __DATE__, __TIME__); ///DATE + TIME displayed on PC termninal lcd_initialize(); //initialize LCD }

The printf statements above would send the character to PC terminal program via RS232 interface. Hardware must consist of the followings:

1. 2 pins ( RX and TX)
2. RS232 translator chip ..i.e MAX232 or equivalent
3. 9-pin D connector to be connected to PC serial port.
4. RS232 cable

Thanks,

JIMMY

So Keil includes a library that directs printf output to a serial port. That is a proprietary feature, where Keil has arbitrarily defined a serial port to be the console. In effect they have made an OS decision for you. It is not standard printf behavior, and IAR's library does not (to the best of my knowledge) do it this way. Certainly the default behavior is to connect to the proprietary debug console.

terminal program .

This isn't a TI problem but an IAR one. Look through the stdio.h and anything referenced on by that, to find out what they've defined printf as. Often you'll find it's something like "_printf( _print_char(),...)" and that _print_char() is just a stub in the library. Adding something like "#define _print_char(c) uart0_out(c)" to your project header or whatever will then get you your output.

IIRC, the IAR libc expects the user to provide a putchar function of some sort for printf to use. The OP should check his compiler's manual.

--
Grant Edwards                   grante             Yow! LOOK!!  Sullen
                                  at               American teens wearing
                               visi.com            MADRAS shorts and "Flock of
                                                   Seagulls" HAIRCUTS!

Huh. On the ez430 at least I thought it defaulted to debugger output. But I so rarely use printf in any form, on a tiny system like that!

You could be right. I might be remembering the wrong compiler. The compiler's manual would know for sure.

printf isn't too useful On the ones with 2K of codespace and

128-256 bytes of RAM. On ones with 60KB of codespace and 4K of RAM, it can be very useful. Since I rarely have a spare HW UART, I ususally bit-bang the printf output. I also use a carefully optimized, custom printf function that's only a couple KB of code and requires very little RAM.

--
Grant Edwards                   grante             Yow! A shapely CATHOLIC
                                  at               SCHOOLGIRL is FIDGETING
                               visi.com            inside my costume..

This is fairly standard stuff (providing a stub for a putchar, usually implemented with a serial port send). Certainly the IAR compiler (and its more recent replacements) for the H8 does this, and I'm sure I've seen this on other compilers too.

So the OP is basically asking for a serial port support routine. My answer: read the UART section(s) of the manual(s). It ain't hard - and if you do find it hard, consider it an ideal learning exercise for embedded CPU work. (Hint: an interrupt-driven circular FIFO is a good way to do this, but for starting out just poll the port...)

Steve

One of the basic example which I think it is quite useful is for instance if you want to find out what the output pins of PORT1 are at certain point in the program --- that way you don't have to physically put the scope probe on them.

void read_port_value(void) { uchar value; value = PORT1; //read CPU port1 printf(" Display Port1 value = %X", value); //Display port1 in hex on PC terminal }

Which is fine if you've got the spare RAM and ROM for printf. On some of my projects I've only got a few bytes of extra RAM, and printf just can't run with that little available RAM for it to use.

--
Grant Edwards                   grante             Yow!  In Newark the
                                  at               laundromats are open 24
                               visi.com            hours a day!

It really depends if you want to pull in all that extra baggage.

Converting an 8-bit value to ASCII hex is a few lines of C or assembler, and it doesn't require any RAM [on most architectures I can think of]; it can be done entirely in registers.