Hi folks,

I have four terminal output lines that I'm using with my ez430-F2013
system to report the data. But I would like to further reduce the code
size and was wondering: Does it make sense to minimize my use of
"stdio.h" and "printf()" to the minimum code foot-print?

Today, I am using "CLIB" and sized Library options "Small." But I'm
only using a "%d" format string for char, int and long values. I don't
need the code overhead for anything else. I couldn't find in the
documentation anything that said only the needed routines from the
library will be in the final load image (or did I miss that section?)

What tools or mechanisms exist in the IAR / ex430-F2013 to further
minimize the terminal output library routine foot-print?

Is there a good description of the most primative routines that
operate the USB debugger's terminal I/O?

My original design was going to use the LED to flash ASCII output into
a photodetector that was suitably biased on the Rx line of an RS-2323
port. Crude, I knew it would absolutely minimize the output code
foot-print. But I'm getting a little lazy in my old age and the
terminal output on the USB adapter works nicely too.

Comments? Thoughts?

Bob Wilson Start a New Thread

Robert J. Wilson wrote:
> I have four terminal output lines that I'm using with my ez430-F2013
> system to report the data. But I would like to further reduce the code
> size and was wondering: Does it make sense to minimize my use of
> "stdio.h" and "printf()" to the minimum code foot-print?
>
> Today, I am using "CLIB" and sized Library options "Small." But I'm
> only using a "%d" format string for char, int and long values. I don't
> need the code overhead for anything else. I couldn't find in the
> documentation anything that said only the needed routines from the
> library will be in the final load image (or did I miss that section?)
>
> What tools or mechanisms exist in the IAR / ex430-F2013 to further
> minimize the terminal output library routine foot-print?
>
> Is there a good description of the most primative routines that
> operate the USB debugger's terminal I/O?
>
> My original design was going to use the LED to flash ASCII output into
> a photodetector that was suitably biased on the Rx line of an RS-2323
> port. Crude, I knew it would absolutely minimize the output code
> foot-print. But I'm getting a little lazy in my old age and the
> terminal output on the USB adapter works nicely too.
>
> Comments? Thoughts?

Hi Bob!

The IO system in CLib stands on the primitive function "putchar", the
idea is that you can replace that function with your own if, say, you
would like to transmit your characters using a serial connection or
using smoke signals.

To comunicate with the actual Terminal I/O windows you can use the
__putchar function. The default implementation of putchar is to directly
call __putchar.

Hence, if you plan to write your own micro-printf then all you need to
do is to call "putchar". If you have the full version of our tools that
contains the library source code, you can see how the current printf is
implemented in the files "printf.c" and "frmwri.c".
Note that we have two different libraries, CLib and DLib, that use
different underlying primitives. For DLib we must provide a larger
number of primitives, and they also allows you to send more than one
byte at a time which is useful if the overhead is high. In DLib you
should *NOT* replace "putchar", instead you should replace __write. See
the DLib documentation for details.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer. Start a New Thread

Thank you Anders,

--- In m..., Anders Lindgren
wrote:
>
> Robert J. Wilson wrote:
> > I have four terminal output lines that I'm using with my ez430-F2013
> > system to report the data. But I would like to further reduce the code
> > size and was wondering:
. . .

You have fully answered my question:

>
> The IO system in CLib stands on the primitive function "putchar", the
> idea is that you can replace that function with your own if, say, you
> would like to transmit your characters using a serial connection or
> using smoke signals.
>
> To comunicate with the actual Terminal I/O windows you can use the
> __putchar function. The default implementation of putchar is to
directly
> call __putchar. . . .

This is what I needed to know. On the report side, time is not
important. I was concerned there was an 'open' function needed to
initialize the terminal interface but it sounds like none is needed.

I'm testing an improved run-length encoding mechanism that should
significantly reduce FLASH data storage. Compiler optimization has
worked well but the link map suggests the memory foot-print can be
significantly reduced using a __putchar in a customized print routine.
I'll run the experiment and report the results.

I appreciate your help. BTW, I'm using the eZ430-F2013 package and
I've been impressed with both the part and your software. I would like
to offer one suggestion, a section definition for unused FLASH memory.

Today, I'm using the following to find and size the available FLASH
memory:

#pragma segment="DATA16_C"
#pragma segment="INTVEC"
__segment_end("DATA16_C") // Last byte that must be rounded up
__segment_begin("INTVEC") // First byte of vector table

It would be great if there were a segment called "FREE_FLASH" that
would not be dependant upon there being a "DATA16_C" segment located
after the code.

Thanks again for the help!

Bob Wilson Start a New Thread