On Sat, Aug 6, 2011 at 2:30 AM, Jim Smith wrote:

> Peter, I appreciate your input, and have, for various reasons, debated
> whether to respond to your comments. I don't really need to explain my
> reasons why, but decided I would have a go at it.

Certainly valid reasons there, and no need to argue.

Although I am a hobbyist and the cost of additional
speed/ram/rom/power is a complete non-issue, I generally try to keep
things as "tight" as possible so long as I don't sacrifice development
time or code readability. On some of the MCUs I am playing with,
printf() takes up half of all available codespace!

-p.
Start a New Thread

Al and Paul, you are both correct. Perhaps I was not as precise as I should
have
been in my response. I sent that out at 2:30 AM, after working all day, and
most
of the night! My mind was probably pretty fuzzy by then. My wife is out of
town
for a couple of days, and one of my partners is on a business trip, the
other is
on vacation. So, I can get a lot of work done at the office, and then at
home!

Although I did not state this, I am not using floating point for
the higher precision data values. Where possible, I use sprintf to compose
complete data strings, which may have more than one data value, for
transmission,
upon request, to a host (Data Acquisition System) over a SDI-12 serial link.
http://www.sdi-12.org/sdi-12/SDI-12_version1_3%20January%2012%202009.pdf.

I use a separate RS-232 link to a terminal (most times, a Laptop), mainly
for
menu-driven input of setup parameters. This link may also be used for a
continuous display of some of the data and calculations provided. A good
site
checkout and troubleshooting tool, but some customers use this to collect
data.

This is a 2nd generation of this sensor. The first used an 8051 variant, and
the
Keil Compiler. I only had to write a custom putchar() routine to link
printf(),
puts(), etc. to the UART. Early development for this 2nd generation using
the
MSP430 was done using the IAR Compiler. I used a custom __write(), which
used
MyLowLevelPutchar(), to link printf() (and such) to the UART. I had problems

trying to do the same when I moved to the TI CCS Compiler. That is when I
came
here for help.

Thanks to all, your help is appreciated.

Jim Smith

-----Original Message-----
From: m... [mailto:m...] On Behalf Of
Paul Curtis
Sent: Saturday, August 06, 2011 5:07 AM
To: m...
Subject: Re: [msp430] Speaking of printf...

It's worse than that.

1.654321

That is 7 significant figures. float can't deliver that. You'd need 64-bit
doubles to read and print correctly without loss. Even then it's an
approximation.

If you want six decimal places accurately, or seven significant figures, use
scaled integers.only sensible choice for many things.

-- Paul.
On 6 Aug 2011, at 07:59, Onestone wrote:

> You state that you require "accuracy to the 6th decimal place" and yet
> you then say that this is a reason to revert to C's internal floating
> point routines. This would seem to be contradictory, since floating
> point is not able to maintain this sort of accuracy in all cases. If you
> genuinely need 6th decimal place accuracy then integer maths is going to
> achieve this better than C can.
>
> Al
>

Start a New Thread

It's worse than that.

1.654321

That is 7 significant figures. float can't deliver that. You'd need 64-bit doubles to read and print correctly without loss. Even then it's an approximation.

If you want six decimal places accurately, or seven significant figures, use scaled integersonly sensible choice for many things.

-- Paul.
On 6 Aug 2011, at 07:59, Onestone wrote:

> You state that you require "accuracy to the 6th decimal place" and yet
> you then say that this is a reason to revert to C's internal floating
> point routines. This would seem to be contradictory, since floating
> point is not able to maintain this sort of accuracy in all cases. If you
> genuinely need 6th decimal place accuracy then integer maths is going to
> achieve this better than C can.
>
> Al
>
> On 6/08/2011 4:00 PM, Jim Smith wrote:
>> Peter, I appreciate your input, and have, for various reasons, debated
>> whether to respond to your comments. I don't really need to explain my
>> reasons why, but decided I would have a go at it.
>>
>>
>>
>> There are some rather sophisticated data processing algorithms (customer
>> developed, with source provided in C) involved in the system that I am
>> working on, requiring accuracy to the 6th decimal place. Most of the data
>> output is to 3 decimal places, but it varies from integer values to 6
>> decimal places. The customer wants to see "1.654321" as output data, rather
>> than "1654321" that must then be divided by 1,000,000.
>>
>>
>>
>> I agree that what is needed in the way of data I/O could be done entirely
>> with binary to decimal (and vice-versa) conversion routines. In the past, I
>> have done this in assembler on several different embedded systems. We are
>> not, however, hurting for code size, execution speed, or RAM size. So, it is
>> just simply easier and more convenient to use C's built-in floating point
>> for keyboard setup parameter input, and for internal calculations, then use
>> printf to output the data in the customer-specified format. SDI-12 is just a
>> means of delivery of data over a particular serial protocol.
>>
>>
>>
>> Sometimes, we can do things the way we would personally choose. In this
>> business, most of the time I'm operating as a "loner" (as in alone), and not
>> many people understand, or care, about how I do things, so I have freedom to
>> handle it my way. There is a certain satisfaction in that, but then no one
>> can see or appreciate the really "spectacular" methods you come up with
>> (your creativity!). There are other times that it is better to "not rock the
>> boat/just go with the flow" and give the customer what he wants, the way he
>> wants it! You end up with a happy customer, and a happy customer usually
>> means more business!
>>
>>
>>
>> Jim Smith
>>
>>
>>
>> From: m... [mailto:m...] On Behalf Of
>> Peter Johansson
>> Sent: Friday, August 05, 2011 1:15 PM
>> To: m...
>> Subject: Re: [msp430] Re: Speaking of printf...
>>
>>
>>
>>
>>
>> I started a new thread because I wasn't entirely sure whether you were
>> using printf for debugging or something else. ;-)
>>
>> I just took a quick look at the SDI-12 protocol and I see absolutely
>> no reason why you would need or want printf. An isolated SDI-12
>> library would need nothing more than binary->decimal conversion
>> routines.
>>
>> -p.
>>
>> On Fri, Aug 5, 2011 at 12:55 PM, Jim >> > wrote:
>>> Oops! I did a no-no, I searched for "SDI-12", got a link to a wiki, and
>> posted it without trying the link. Turns out there is not, and apparently,
>> never was, a wiki by this name. What I should have posted is:
>> http://www.sdi-12.org/.
>>> Sorry about that,
>>> Jim Smith
>>>
>>> --- In m... , "Jim"
>> wrote:
>>>> I like your idea, but I don't have the freedom to try that
>>>> approach. I must send data over a well-defined serial link
>>>> and protocol. See http://en.wikipedia.org/wiki/SDI-12.
>>>>
>>>> --- In m... , Peter
>> Johansson wrote:
>>>>> While reading the printf thread I got to wondering...
>>>>>
>>>>> I generally recommend against printf for debugging for non uC
>>>>> programming, but I am finding less of a case against it in the uC
>>>>> world.
>>>>>
>>>>> So, if you are going to use printf this way, rather than do the data
>>>>> formatting on the micro, why not spit the formatting string and the
>>>>> raw data over the serial connection, and whip up a simple app on the
>>>>> PC side to do the formatting? This should dramatically reduce
>>>>> codespace requirements on the uC and require far fewer cycles.
>>>>>
>>>>> Has anyone tried this?
>>>>>
>>>>> -p.
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Start a New Thread

You state that you require "accuracy to the 6th decimal place" and yet
you then say that this is a reason to revert to C's internal floating
point routines. This would seem to be contradictory, since floating
point is not able to maintain this sort of accuracy in all cases. If you
genuinely need 6th decimal place accuracy then integer maths is going to
achieve this better than C can.

Al

On 6/08/2011 4:00 PM, Jim Smith wrote:
> Peter, I appreciate your input, and have, for various reasons, debated
> whether to respond to your comments. I don't really need to explain my
> reasons why, but decided I would have a go at it.
>
> There are some rather sophisticated data processing algorithms (customer
> developed, with source provided in C) involved in the system that I am
> working on, requiring accuracy to the 6th decimal place. Most of the data
> output is to 3 decimal places, but it varies from integer values to 6
> decimal places. The customer wants to see "1.654321" as output data, rather
> than "1654321" that must then be divided by 1,000,000.
>
> I agree that what is needed in the way of data I/O could be done entirely
> with binary to decimal (and vice-versa) conversion routines. In the past, I
> have done this in assembler on several different embedded systems. We are
> not, however, hurting for code size, execution speed, or RAM size. So, it is
> just simply easier and more convenient to use C's built-in floating point
> for keyboard setup parameter input, and for internal calculations, then use
> printf to output the data in the customer-specified format. SDI-12 is just a
> means of delivery of data over a particular serial protocol.
>
> Sometimes, we can do things the way we would personally choose. In this
> business, most of the time I'm operating as a "loner" (as in alone), and not
> many people understand, or care, about how I do things, so I have freedom to
> handle it my way. There is a certain satisfaction in that, but then no one
> can see or appreciate the really "spectacular" methods you come up with
> (your creativity!). There are other times that it is better to "not rock the
> boat/just go with the flow" and give the customer what he wants, the way he
> wants it! You end up with a happy customer, and a happy customer usually
> means more business!
>
> Jim Smith
>
> From: m... [mailto:m...] On Behalf Of
> Peter Johansson
> Sent: Friday, August 05, 2011 1:15 PM
> To: m...
> Subject: Re: [msp430] Re: Speaking of printf...
>
> I started a new thread because I wasn't entirely sure whether you were
> using printf for debugging or something else. ;-)
>
> I just took a quick look at the SDI-12 protocol and I see absolutely
> no reason why you would need or want printf. An isolated SDI-12
> library would need nothing more than binary->decimal conversion
> routines.
>
> -p.
>
> On Fri, Aug 5, 2011 at 12:55 PM, Jim > > wrote:
>> Oops! I did a no-no, I searched for "SDI-12", got a link to a wiki, and
> posted it without trying the link. Turns out there is not, and apparently,
> never was, a wiki by this name. What I should have posted is:
> http://www.sdi-12.org/.
>> Sorry about that,
>> Jim Smith
>>
>> --- In m... , "Jim"
> wrote:
>>> I like your idea, but I don't have the freedom to try that
>>> approach. I must send data over a well-defined serial link
>>> and protocol. See http://en.wikipedia.org/wiki/SDI-12.
>>>
>>> --- In m... , Peter
> Johansson wrote:
>>>> While reading the printf thread I got to wondering...
>>>>
>>>> I generally recommend against printf for debugging for non uC
>>>> programming, but I am finding less of a case against it in the uC
>>>> world.
>>>>
>>>> So, if you are going to use printf this way, rather than do the data
>>>> formatting on the micro, why not spit the formatting string and the
>>>> raw data over the serial connection, and whip up a simple app on the
>>>> PC side to do the formatting? This should dramatically reduce
>>>> codespace requirements on the uC and require far fewer cycles.
>>>>
>>>> Has anyone tried this?
>>>>
>>>> -p.
>>>>
>>
>> Start a New Thread

Peter, I appreciate your input, and have, for various reasons, debated
whether to respond to your comments. I don't really need to explain my
reasons why, but decided I would have a go at it.

There are some rather sophisticated data processing algorithms (customer
developed, with source provided in C) involved in the system that I am
working on, requiring accuracy to the 6th decimal place. Most of the data
output is to 3 decimal places, but it varies from integer values to 6
decimal places. The customer wants to see "1.654321" as output data, rather
than "1654321" that must then be divided by 1,000,000.

I agree that what is needed in the way of data I/O could be done entirely
with binary to decimal (and vice-versa) conversion routines. In the past, I
have done this in assembler on several different embedded systems. We are
not, however, hurting for code size, execution speed, or RAM size. So, it is
just simply easier and more convenient to use C's built-in floating point
for keyboard setup parameter input, and for internal calculations, then use
printf to output the data in the customer-specified format. SDI-12 is just a
means of delivery of data over a particular serial protocol.

Sometimes, we can do things the way we would personally choose. In this
business, most of the time I'm operating as a "loner" (as in alone), and not
many people understand, or care, about how I do things, so I have freedom to
handle it my way. There is a certain satisfaction in that, but then no one
can see or appreciate the really "spectacular" methods you come up with
(your creativity!). There are other times that it is better to "not rock the
boat/just go with the flow" and give the customer what he wants, the way he
wants it! You end up with a happy customer, and a happy customer usually
means more business!

Jim Smith

From: m... [mailto:m...] On Behalf Of
Peter Johansson
Sent: Friday, August 05, 2011 1:15 PM
To: m...
Subject: Re: [msp430] Re: Speaking of printf...

I started a new thread because I wasn't entirely sure whether you were
using printf for debugging or something else. ;-)

I just took a quick look at the SDI-12 protocol and I see absolutely
no reason why you would need or want printf. An isolated SDI-12
library would need nothing more than binary->decimal conversion
routines.

-p.

On Fri, Aug 5, 2011 at 12:55 PM, Jim > wrote:
> Oops! I did a no-no, I searched for "SDI-12", got a link to a wiki, and
posted it without trying the link. Turns out there is not, and apparently,
never was, a wiki by this name. What I should have posted is:
http://www.sdi-12.org/. Sorry about that,
> Jim Smith
>
> --- In m... , "Jim"
wrote:
>>
>> I like your idea, but I don't have the freedom to try that
>> approach. I must send data over a well-defined serial link
>> and protocol. See http://en.wikipedia.org/wiki/SDI-12.
>>
>> --- In m... , Peter
Johansson wrote:
>> >
>> > While reading the printf thread I got to wondering...
>> >
>> > I generally recommend against printf for debugging for non uC
>> > programming, but I am finding less of a case against it in the uC
>> > world.
>> >
>> > So, if you are going to use printf this way, rather than do the data
>> > formatting on the micro, why not spit the formatting string and the
>> > raw data over the serial connection, and whip up a simple app on the
>> > PC side to do the formatting? This should dramatically reduce
>> > codespace requirements on the uC and require far fewer cycles.
>> >
>> > Has anyone tried this?
>> >
>> > -p.
>> >
>>
>
>
> Start a New Thread

I started a new thread because I wasn't entirely sure whether you were
using printf for debugging or something else. ;-)

I just took a quick look at the SDI-12 protocol and I see absolutely
no reason why you would need or want printf. An isolated SDI-12
library would need nothing more than binary->decimal conversion
routines.

-p.
On Fri, Aug 5, 2011 at 12:55 PM, Jim wrote:
> Oops! I did a no-no, I searched for "SDI-12", got a link to a wiki, and posted it without trying the link. Turns out there is not, and apparently, never was, a wiki by this name. What I should have posted is: http://www.sdi-12.org/.
>
> Sorry about that,
> Jim Smith
>
> --- In m..., "Jim" wrote:
>>
>> I like your idea, but I don't have the freedom to try that
>> approach. I must send data over a well-defined serial link
>> and protocol. See http://en.wikipedia.org/wiki/SDI-12.
>>
>> --- In m..., Peter Johansson wrote:
>> >
>> > While reading the printf thread I got to wondering...
>> >
>> > I generally recommend against printf for debugging for non uC
>> > programming, but I am finding less of a case against it in the uC
>> > world.
>> >
>> > So, if you are going to use printf this way, rather than do the data
>> > formatting on the micro, why not spit the formatting string and the
>> > raw data over the serial connection, and whip up a simple app on the
>> > PC side to do the formatting? This should dramatically reduce
>> > codespace requirements on the uC and require far fewer cycles.
>> >
>> > Has anyone tried this?
>> >
>> > -p.
>> >
>>
> Start a New Thread

Oops! I did a no-no, I searched for "SDI-12", got a link to a wiki, and posted it without trying the link. Turns out there is not, and apparently, never was, a wiki by this name. What I should have posted is: http://www.sdi-12.org/.

Sorry about that,
Jim Smith

--- In m..., "Jim" wrote:
>
> I like your idea, but I don't have the freedom to try that
> approach. I must send data over a well-defined serial link
> and protocol. See http://en.wikipedia.org/wiki/SDI-12.
>
> --- In m..., Peter Johansson wrote:
> >
> > While reading the printf thread I got to wondering...
> >
> > I generally recommend against printf for debugging for non uC
> > programming, but I am finding less of a case against it in the uC
> > world.
> >
> > So, if you are going to use printf this way, rather than do the data
> > formatting on the micro, why not spit the formatting string and the
> > raw data over the serial connection, and whip up a simple app on the
> > PC side to do the formatting? This should dramatically reduce
> > codespace requirements on the uC and require far fewer cycles.
> >
> > Has anyone tried this?
> >
> > -p.
>

Start a New Thread

I like your idea, but I don't have the freedom to try that
approach. I must send data over a well-defined serial link
and protocol. See http://en.wikipedia.org/wiki/SDI-12.

--- In m..., Peter Johansson wrote:
>
> While reading the printf thread I got to wondering...
>
> I generally recommend against printf for debugging for non uC
> programming, but I am finding less of a case against it in the uC
> world.
>
> So, if you are going to use printf this way, rather than do the data
> formatting on the micro, why not spit the formatting string and the
> raw data over the serial connection, and whip up a simple app on the
> PC side to do the formatting? This should dramatically reduce
> codespace requirements on the uC and require far fewer cycles.
>
> Has anyone tried this?
>
> -p.
>

Start a New Thread

While reading the printf thread I got to wondering...

I generally recommend against printf for debugging for non uC
programming, but I am finding less of a case against it in the uC
world.

So, if you are going to use printf this way, rather than do the data
formatting on the micro, why not spit the formatting string and the
raw data over the serial connection, and whip up a simple app on the
PC side to do the formatting? This should dramatically reduce
codespace requirements on the uC and require far fewer cycles.

Has anyone tried this?

-p.
Start a New Thread