franciscocantero1 wrote:
> Hello,
>
> Thanks for the help to my previous post("function allocation").
> Now i have another task to complete, porting code from GCC to IAR.
>
> I have done most of the porting, but i have i difficulties with the
> standard library i/o. In GCC there is a routine "uprintf()" to print
> characters to a file. There is something similar in IAR, i tried to
> build my own, but i didnt get near to achieve the uprintf().
>
> Previously i tried to port the GCC code to CCE, and i had the same issue
> with uprintf. so I went to IAR to try but no luck. Then i start looking
> in the libraries of GCC for "uprintf.c" i found it and i try to recreate
> something similar for IAR. But uprintf.c is calling other routines that
> are not in IAR stdio lib.
>
> Does anyone have done something similar.
> Any give a hint will be appreciated.

Hi Francisco!

"uprintf" seems to be a non-standard thing.

In our DLib library, you could easily implement your own since "printf",
"sprintf", and "fprintf" is implemented on top of a common core.

Each function consists of a pair of files, one which provide the actual
function, and one which provide a small function what emit characters to
some output device. See for example: sprintf.c/xsprout.c and
fprintf.c/xfprout.c.

Of course, this requires that you have a version which include the
library sources.

Alternatively, you could implement "uprintf" in top of "vsprintf" (note
the "v"), temporarily saving the output. (This can be done on all EW
variants, since it doesn't require the library source.)

-- 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

hello,

Unfortunately my version doesn't have the sources.
I tried doing the following;
int uprintf(void (*func)(char c), const char *format, ...)
{
va_list ap;
int nr_of_chars;

va_start(ap, format); /* Variable argument begin */
nr_of_chars = _formatted_write(format, func, (void *) &format, ap);
va_end(ap); /* Variable argument end */
return nr_of_chars; /* According to ANSI */
}

but it doesn't compile

Warning[Pe223]: function "_formatted_write" declared implicitly
C:\Fran\porting\uprintf.c 26
Warning[Pe177]: function "put_c_in_string" was declared but never
referenced C:\Fran\porting\uprintf.c 14
Fatal Error[Pe005]: could not open source file "uprintf.h"
C:\Fran\porting\prog\main.c 55
Thanks
--- In m..., Anders Lindgren
wrote:
>
> franciscocantero1 wrote:
> >
> >
> > Hello,
> >
> > Thanks for the help to my previous post("function allocation").
> > Now i have another task to complete, porting code from GCC to IAR.
> >
> > I have done most of the porting, but i have i difficulties with the
> > standard library i/o. In GCC there is a routine "uprintf()" to print
> > characters to a file. There is something similar in IAR, i tried to
> > build my own, but i didnt get near to achieve the uprintf().
> >
> > Previously i tried to port the GCC code to CCE, and i had the same
issue
> > with uprintf. so I went to IAR to try but no luck. Then i start
looking
> > in the libraries of GCC for "uprintf.c" i found it and i try to
recreate
> > something similar for IAR. But uprintf.c is calling other routines
that
> > are not in IAR stdio lib.
> >
> > Does anyone have done something similar.
> > Any give a hint will be appreciated.
>
> Hi Francisco!
>
> "uprintf" seems to be a non-standard thing.
>
> In our DLib library, you could easily implement your own since
"printf",
> "sprintf", and "fprintf" is implemented on top of a common core.
>
> Each function consists of a pair of files, one which provide the actual
> function, and one which provide a small function what emit
characters to
> some output device. See for example: sprintf.c/xsprout.c and
> fprintf.c/xfprout.c.
>
> Of course, this requires that you have a version which include the
> library sources.
>
> Alternatively, you could implement "uprintf" in top of "vsprintf" (note
> the "v"), temporarily saving the output. (This can be done on all EW
> variants, since it doesn't require the library source.)
>
> -- 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

franciscocantero1 wrote:
> hello,
>
> Unfortunately my version doesn't have the sources.
> I tried doing the following;
> int uprintf(void (*func)(char c), const char *format, ...)
> {
> va_list ap;
> int nr_of_chars;
>
> va_start(ap, format); /* Variable argument begin */
> nr_of_chars = _formatted_write(format, func, (void *) &format, ap);
> va_end(ap); /* Variable argument end */
> return nr_of_chars; /* According to ANSI */
> }
>
> but it doesn't compile
>
> Warning[Pe223]: function "_formatted_write" declared implicitly
> C:\Fran\porting\uprintf.c 26
> Warning[Pe177]: function "put_c_in_string" was declared but never
> referenced C:\Fran\porting\uprintf.c 14
> Fatal Error[Pe005]: could not open source file "uprintf.h"
> C:\Fran\porting\prog\main.c 55

Sorry for picking up an old thread, but the question was still open.

Since you are using "_formatted_write", I assume that you are using the
CLib library. If not, you are barking up the wrong tree.

First, the function pointer you use, "func", is not compatible with the
one used by "_formatted_write". This means that you have to convert it
somehow. Also, you might need to cache some values locally to make this
happend, but you are on the right track.

you should be able to handle those errors/Warnings:

1) Declare the _formatted_write function in your C file. The declaration
is the following:

int _formatted_write(const char *,
void (*)(char, void *),
void *,
va_list);

The third parameter of _formatted_write will be passed to the second
parameter of the called function. You can use it to tunnel information.
2) The "put_c_in_string" warning is caused by leftovers from the
"sprintf" code you used originally.
3) The error that you have no "uprintf.h" header file is easy to fix --
simply create one and include the declaration of uprintf in it.

-- 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

--- In m..., Anders Lindgren
wrote:
>
> franciscocantero1 wrote:
> >
> >
> > hello,
> >
> > Unfortunately my version doesn't have the sources.
> > I tried doing the following;
> > int uprintf(void (*func)(char c), const char *format, ...)
> > {
> > va_list ap;
> > int nr_of_chars;
> >
> > va_start(ap, format); /* Variable argument begin */
> > nr_of_chars = _formatted_write(format, func, (void *) &format, ap);
> > va_end(ap); /* Variable argument end */
> > return nr_of_chars; /* According to ANSI */
> > }
> >
> > but it doesn't compile
> >
> > Warning[Pe223]: function "_formatted_write" declared implicitly
> > C:\Fran\porting\uprintf.c 26
> > Warning[Pe177]: function "put_c_in_string" was declared but never
> > referenced C:\Fran\porting\uprintf.c 14
> > Fatal Error[Pe005]: could not open source file "uprintf.h"
> > C:\Fran\porting\prog\main.c 55
>
> Sorry for picking up an old thread, but the question was still open.
>
> Since you are using "_formatted_write", I assume that you are using the
> CLib library. If not, you are barking up the wrong tree.
>
> First, the function pointer you use, "func", is not compatible with the
> one used by "_formatted_write". This means that you have to convert it
> somehow. Also, you might need to cache some values locally to make this
> happend, but you are on the right track.
>
> you should be able to handle those errors/Warnings:
>
> 1) Declare the _formatted_write function in your C file. The
declaration
> is the following:
>
> int _formatted_write(const char *,
> void (*)(char, void *),
> void *,
> va_list);
>
> The third parameter of _formatted_write will be passed to the second
> parameter of the called function. You can use it to tunnel information.
> 2) The "put_c_in_string" warning is caused by leftovers from the
> "sprintf" code you used originally.
> 3) The error that you have no "uprintf.h" header file is easy to fix --
> simply create one and include the declaration of uprintf in it.
>
> -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are strictly my own and
> not necessarily those of my employer.
>
Hello,
Thanks Anders Lindgren, I got it to work, no errors now, but there is
something that concerns me, the stack is being used, i had 226 bytes
for stack and is used to 98%, is this normal for the sprintf? if so
how could i reduce the stack usage from this functions.
Thanks
Francisco.
Start a New Thread

> Thanks Anders Lindgren, I got it to work, no errors now, but there is
> something that concerns me, the stack is being used, i had 226 bytes
> for stack and is used to 98%, is this normal for the sprintf? if so
> how could i reduce the stack usage from this functions.

Hi Francisco!

In general, it is a bad idea to use "sprintf" etc. for processors with
very limited stack. If possible, try to rewrite the program so it don't
use formatted output at all.

-- 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

Anders, A follow-up question, if you please... If I have the memory
to spare, say on a 4619, won't the stack just expand upwards and I'll
be OK so long as I don't have a stack collision? I suppose I'm
addicted to sprintf...
Thanks,
Mike Raines

--- In m..., Anders Lindgren
wrote:
>
> > Thanks Anders Lindgren, I got it to work, no errors now, but there is
> > something that concerns me, the stack is being used, i had 226 bytes
> > for stack and is used to 98%, is this normal for the sprintf? if so
> > how could i reduce the stack usage from this functions.
>
> Hi Francisco!
>
> In general, it is a bad idea to use "sprintf" etc. for processors with
> very limited stack. If possible, try to rewrite the program so it don't
> use formatted output at all.
>
> -- 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

> Anders, A follow-up question, if you please... If I have the memory
> to spare, say on a 4619, won't the stack just expand upwards and I'll
> be OK so long as I don't have a stack collision? I suppose I'm
> addicted to sprintf...

Hi Mike!

Using sprintf and friends comes with a cost, if you can live with that
then you can, of course, continue using it...

In the printf case, often when you look at a program, it is only used to
print or format very simple items. In those cases it might be easier to
replace them with, say, puts, and in the process freeing up lots of
resources for other things.

The problem often occurs when people port code from a desktop machine to
a microprocessor with little RAM and/or ROM without realizing that
something that is cheap on a desktop can be very expensive on a micro.
For example, I've seen people using "new" extensively in processors with
a few hundred bytes of RAM and being surprised when it doesn't work...

-- 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