Printf statement used on IAR compiler / MSP430 processor

Oct 04, 2007 11 Replies

=_NextPart_000_01D7_01C80657.F2583E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable



I have been looking for a code sample written by IAR compiler for TI MSP430 processor especially when utilizing PRINTF statement for the purpose of transmitting/receiving characters serially to/from = PC terminal program . i.e "Hello world" for instance.



I have searched TI website but there was no luck.



Thanks in advance,


JIMMY



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

formatting link

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.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required