> 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

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

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

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

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

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

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

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

Hi Clifford, Paul,

> Sorry, but you're confused with the ability to store a char into a
> long. sprintf has no way to know that the *pointer* passed is to an

No, I wasn't.
I referred to a (char *) (I enclosed w/ parentheses to indicate I meant a char * ).
But I meant that you can store the contents of a char * into _any_ (writeable) address, including
samples or IOW &samples[0]. (of course, if it's been typecasted !! Hmm)
But I indeed overlooked that the prototype of the function is (should be) there, and
that a char* and long* are incompatible pointer types. Sorry.

But then again, I'd never declare a long array to store an ASCII string :-)
Perhaps it's harder to imagine what happens when something's done _wrong_ instead of right,
rather than the other way around, so to say, dunno.

Best Regards,
Kris

-----Original Message-----
From: m... [mailto:m...] On Behalf Of Clifford Heath
Sent: Saturday, 25 November 2006 6:03 PM
To: m...
Subject: Re: [msp430] Re: Printf 'long' format specifications

Microbit wrote:
> Why should the compiler alarm ?
> I don't see any reason, storing a (char*) into an array of longs is not illegal. (w/ ISO AFAIK)
> The opposite is against ISO, when the dest object is too small.

Sorry, but you're confused with the ability to store a char into a
long. sprintf has no way to know that the *pointer* passed is to an
array of objects of sizeof(long), so it assumes it has a valid char*,
and stores the resultant string as ASCII bytes packed 4 to each long,
in a sequence that's defined by the machine's endian-ness. Which is
almost certainly what lewis is seeing in the simulator, but he can't
see the ASCII values because they're packed 4 to a long.

Oh, and it *is* illegal to pass a long* where a char* is expected,
unless you provide a cast and know how to predict the result.

> But, indeed, storing an ASCII string into an array of longs is pure waste,

That's not what happens here. lewis' code might generate 12 bytes
including the NUL ("-2147483648"), which will use 3 of the longs he
passed, not 12. But if you include stdio.h, it won't compile without
warnings.

Clifford Heath.

Yahoo! Groups Links Start a New Thread

Clifford,

> lewis wrote:
> > I tried the following code
> > unsigned long samples[20];
> > long lTest ;
> > lTest = 1001;
> > i = sprintf(samples,"%ld",lTest);
> > I ran the code using teh simulator but i get an incorrect result in
> > the output buffer.
>
> The output buffer should be char[20], not unsigned long[20].
>
> I'm a bit alarmed that the compiler didn't prevent you from
> compiling it - please read the manual and find out how to:

It used to raise errors on assigning incompatible pointer types (long * and
char * are incompatible) but we have to compile so many broken legacy
programs that, by customer demand, it was reduced to a warning with an
option to treat warnings as errors.

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