printf*() is probably the first thing one leared in C.
In my opionion, it should be the last thing one uses
in programming a micro-controller.

--- In m..., "lewis" wrote:
>
> Hi,
> My problem is pretty basic , still am stuck. I am trying to use
> sprintf() to format a long value to the destination string.I tried
> using %d , %l etc but dint get he expected results. I went thru th
> ecrosstudio documentation for printf format specifications but ended
> more confused dan before.
> Please advice
> Thanks in advance.
> Regards,
> Lewis
> Start a New Thread

Quite apart from the pointer/char/long issues, in Crossworks and
other compilers remember that you also have to set the size of the
available printf library support, otherwise even if all your
definitions and usage is correct it still won't print long numbers
correctly. The reason for this is to keep the code size to a minimum
without having the linker do this for you. Couple of examples:

In CrossStudio:
Project->Properties->Print->Print Integer Support->long

In IAR (not so sure about this one, check the help file):
Project->Options->General Options->Library Configuration->Full DLAB
Project->Options->General Options->Library Options->Printf Formatter->blah-blah

Quadravox:
No change required, if I remember correctly

Hugh

At 07:20 PM 11/24/2006, you wrote:
Hi,
My problem is pretty basic , still am stuck. I am trying to use
sprintf() to format a long value to the destination string.I tried
using %d , %l etc but dint get he expected results. I went thru th
ecrosstudio documentation for printf format specifications but ended
more confused dan before.
Please advice
Thanks in advance.
Regards,
Lewis Start a New Thread

old_cow_yellow wrote:
> printf*() is probably the first thing one leared in C.
> In my opionion, it should be the last thing one uses
> in programming a micro-controller.

Well said! In any case, it's a serious weakness of C
that it doesn't provide a type-safe method of passing
variable argument lists, so that things like printf
can check their arguments at runtime. Things like
printf("%s", 23) will produce crashes that the compiler
cannot prevent in the general case. Nevertheless gcc
has special code built-in to recognise calls to things
like printf and make this checking statically; a bit
ad-hoc but useful! Start a New Thread

On 2006-11-25, Clifford Heath wrote:

> Things like printf("%s", 23) will produce crashes that the
> compiler cannot prevent in the general case. Nevertheless gcc
> has special code built-in to recognise calls to things like
> printf and make this checking statically; a bit ad-hoc but
> useful!

Extremely. And you can even tell gcc that a function of yours
accepts "printf" style format/arugments and it'll check
parameters for that function as well.

Don't other compilers check printf arguments?

--
Grant Edwards
g...@visi.com Start a New Thread

Grant Edwards wrote:
> Extremely. And you can even tell gcc that a function of yours
> accepts "printf" style format/arugments and it'll check
> parameters for that function as well.

Yes, but my main reason for doing that is to add features to the
printf formatting; for example I have one that allows parameters to
be substituted *positionally* by saying things like %3$d (convert
the 3rd parameter as an integer); and there's no gcc API that I know
of that easily allows this kind of extension.

The reason for positional substitution is for example when fetching
a format string from a native language message catalog, the order of
parameters might need to be changed, and that's not possible with
raw printf.

> Don't other compilers check printf arguments?

Not in my experience. Start a New Thread

Hi,
Thnx for the replies. The long array buffer was a typo. Even though i
dont think that shud affect the way sprintf works, as all sprintf sees
is a destination buffer. I have also tried enabling printf support for
long . Butof no use.
The only reason i need to convert long values to ascii, is to be able
to send out debug info(which needs long) to the hyper terminal so that
i can quickly visually scan various timing data as recorded by my
application.

If any1 has had success wid formattin long values using sprintf it wud
be of great help if i get a few pointers in the rite direction

Thanks once again

Regards,
Lewis

--- In m..., Clifford Heath wrote:
>
> Grant Edwards wrote:
> > Extremely. And you can even tell gcc that a function of yours
> > accepts "printf" style format/arugments and it'll check
> > parameters for that function as well.
>
> Yes, but my main reason for doing that is to add features to the
> printf formatting; for example I have one that allows parameters to
> be substituted *positionally* by saying things like %3$d (convert
> the 3rd parameter as an integer); and there's no gcc API that I know
> of that easily allows this kind of extension.
>
> The reason for positional substitution is for example when fetching
> a format string from a native language message catalog, the order of
> parameters might need to be changed, and that's not possible with
> raw printf.
>
> > Don't other compilers check printf arguments?
>
> Not in my experience.
> Start a New Thread

Lewis,

> Hi,
> Thnx for the replies. The long array buffer was a typo. Even
> though i dont think that shud affect the way sprintf works,
> as all sprintf sees is a destination buffer.

Oh deary me, no.

> I have also
> tried enabling printf support for long . Butof no use.
> The only reason i need to convert long values to ascii, is to
> be able to send out debug info(which needs long) to the hyper
> terminal so that i can quickly visually scan various timing
> data as recorded by my application.
>
> If any1 has had success wid formattin long values using
> sprintf it wud be of great help if i get a few pointers in
> the rite direction

I suggest you start by looking at the posts presented which are intended to
help. CrossWorks does indeed support long output correctly, and you just
need to take the suggestions offered by myself and others for success. And
I SMS writing style; you'd do much better and present yourself better to
others in this group if you try to write just Plain Ole English as we have
many members whose first language is not SMS and not English.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors Start a New Thread

> Even though I dont think that shud affect the way sprintf works,
> as all sprintf sees is a destination buffer.

Although I probably didn't phrase it right, that's kinda what I was trying to say.
Is the problem on :
- Simulator only ?
- Hardware only ?
- or both ?

Have you tried to see if printf() formats properly (whereas sprintf wouldn't) ?
Else it could also be that your low level I/O func is perhaps broken if you use HyperTerminal.
In that case, check that you indeed have __putchar() properly matching its prototype :
int __putchar (int);

Or are you perhaps running on HW, and running the debug LIB through JTAG ?
In that case you results should display on the debug I/O terminal in CW, not on the PC.

In any case, if you want to use SIM, I find it pays to use a macro for printf and create a new
configuration for SIM and for actual HW.
When you select "simulate", the macro substitutes to debug_printf(), on actual HW it is printf()
Same goes for the whole stdio family.

Good luck &
Best Regards,
Kris

-----Original Message-----
From: m... [mailto:m...] On Behalf Of lewis
Sent: Sunday, 26 November 2006 6:02 PM
To: m...
Subject: [msp430] Re: Printf 'long' format specifications

Hi,
Thnx for the replies. The long array buffer was a typo. Even though i
dont think that shud affect the way sprintf works, as all sprintf sees
is a destination buffer. I have also tried enabling printf support for
long . Butof no use.
The only reason i need to convert long values to ascii, is to be able
to send out debug info(which needs long) to the hyper terminal so that
i can quickly visually scan various timing data as recorded by my
application.

If any1 has had success wid formattin long values using sprintf it wud
be of great help if i get a few pointers in the rite direction

Thanks once again

Regards,
Lewis

--- In m..., Clifford Heath wrote:
>
> Grant Edwards wrote:
> > Extremely. And you can even tell gcc that a function of yours
> > accepts "printf" style format/arugments and it'll check
> > parameters for that function as well.
>
> Yes, but my main reason for doing that is to add features to the
> printf formatting; for example I have one that allows parameters to
> be substituted *positionally* by saying things like %3$d (convert
> the 3rd parameter as an integer); and there's no gcc API that I know
> of that easily allows this kind of extension.
>
> The reason for positional substitution is for example when fetching
> a format string from a native language message catalog, the order of
> parameters might need to be changed, and that's not possible with
> raw printf.
>
> > Don't other compilers check printf arguments?
>
> Not in my experience.
>

Yahoo! Groups Links Start a New Thread