converting float to ascii w/o printf

On Wed, 28 Mar 2007 10:22:05 PST (while OU was sucking), Everett M.
Greene wrote:
>"Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes:
>> "Thad Smith" <ThadSmith@acm.org> wrote in message 
>> > Wilco Dijkstra wrote:
>> >> "Ron Blancarte" <ron@---TAKETHISOUT---.blancarte.com> wrote in message 
>> >>
>> >>>Clearly, the entered value is being stored correctly and the displayed
>> >>>value, while close, is just slightly off.  So is there a way to do
>> >>>this without this error induced by my multiplications by 10 (and still
>> >>>not using sprintf()?
>> >>
>> >> The correct way of doing this is to only do one normalizing multiply
>> >> or divide by a power of 10, so you only get one roundoff error. Powers
>> >> of 10 are exact in floats up to 10^10, for a wider dynamic range you
>> >> get multiple roundoff errors unless you use more precision. After
>> >> normalization you use integer arithmetic to extract the digits.
>> >
>> > Agreed.
>> >
>> >> My advice would be to use integer-only arithmetic for normalization,
>> >> this way you get less roundoff error over much larger ranges.
>> >
>> > Hmmm, I don't understand the recommendation here.  I would say multiply or divide by the 
>> > proper (exact) power of 10 to get a number in the range -9999999..9999999, add a 
>> > rounding factor (-0.5 or +0.5), convert to a 32-bit integer, convert that to a 7-digit 
>> > character string, then format.
>> 
>> What I mean is that if you do the normalization multiply/divide using
>> integer arithmetic, you get more precision, eg. 32 bits rathern than 24
>> when using float. This gives you larger powers of 10 that can be
>> represented exactly and a more accurate result after normalization
>> (and more control over rounding). Integer arithmetic makes even more
>> sense if you use emulated floating point.
>
>And don't forget to look at the accuracy of the data
>before getting wound around the axle of precision.
>If the source of the data is an 8-bit ADC, for
>instance, no amount of fancy footwork is going to
>get you three decimal place accuracy.  If the
>problem is ill-conditioned, not much of anything
>will help.

What I am doing here is a tool for measurements during drilling
applications.  Data sources are a set of three accelerometers and
three magnetometers.  Conversion is handled via a 12 bit ADC that is
temperature corrected during acquisition.  Generally one acquisition
cycle is about 100 samples a second around 5-10 seconds.

As far as my problem, I ended up giving Thad's solution a shot.  It
ended up working great, better than the multiply/divide by 10
solution.  And while mildly slower than sprintf(), it is more than
workable for this application.

RonB

Ron Blancarte wrote:
> Now, i have googled this some, with not much as far as results, so I
> though I would ask here to see what kind of luck I would have.
> 
> I am using the Analog Devices ADuC831 (8052 ISA) part to do data
> acquisition and transmission.  I have some data that is being held as
> floating point (single precision IEEE 754 format).  Some of this data
> needs to be outputted to serial on request.  This is where my request
> comes in.  Currently I am using sprintf() to format this output into
> my buffer.  HOWEVER, the footprint of this code is making it less than
> desirable to use (over 1100 bytes of code space and nearly 30 bytes of
> memory).  So I am looking to do the output on my own.
> 

For embedded work, the rule here is never use floating point at all if 
it can be avoided. If you know what the range of values and required 
accuracy is, scaled integer arithmetic will be faster and more 
efficient, especially if you can arrange the data to allow shifts, 
rather than multiply and divide. If you need trig functions, then write 
your own using lookup tables, perhaps adding simple interpolation as a 
tradeoff against table size. If you do this, you can define your own 
internal representation and design it for ease of use within the system 
and conversion to human readable / external format.

Floating point on small machines is slow, inefficient, adds complexity 
and rounding errors everywhere it's used and you can usually get better 
control and predictable accuracy using other methods. It's a bit of a 
sledgehammer and if I were your project manager, I would encourage you 
to find a more creative solution :-).

Having said all that, 1100 bytes doesn't sound to bad for a sprintf, 
especially on an 8 bit machine. Still wouldn't use it though...

Chris

ChrisQuayle wrote:


> For embedded work, the rule here is never use floating point at all if 
> it can be avoided.

I strongly disagree. Floating point greatly simplifies the development 
and the support of the program. I also like when the physical parameters 
are represented as the natural values, such as Volts, Amperes, Seconds 
and not in the weird units like 12345*ADC_RESOLUTION/CPU_CLOCK_RATE.

> If you know what the range of values and required 
> accuracy is, scaled integer arithmetic will be faster and more 
> efficient,

Yes. On the 8-bitter, float is somewhat 20 times slower then 16-bit 
integer. It also costs several kilobytes of ROM. However it doesn't 
matter in many practical cases.


> especially if you can arrange the data to allow shifts, 
> rather than multiply and divide. If you need trig functions, then write 
> your own using lookup tables, perhaps adding simple interpolation as a 
> tradeoff against table size.

Yes, you can. But what for?


> If you do this, you can define your own 
> internal representation and design it for ease of use within the system 
> and conversion to human readable / external format.

Reinventing the wheel. Wasted effort.

> Floating point on small machines is slow, inefficient, adds complexity 
> and rounding errors everywhere it's used and you can usually get better 
> control and predictable accuracy using other methods.

When you are using a micro of 16k ROM or more, the floating point 
overhead doesn't really matter. Of course, it does matter on the 
machines with less then 8k.

> It's a bit of a 
> sledgehammer and if I were your project manager, I would encourage you 
> to find a more creative solution :-).

Your job as a manager is get the project done on time, within budget and 
for good. There is no place for religious beliefs and super optimization.


> Having said all that, 1100 bytes doesn't sound to bad for a sprintf, 
> especially on an 8 bit machine. Still wouldn't use it though...

Is there any reasonable argument for not using sprintf?



Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

On 2007-03-29, ChrisQuayle <nospam@devnul.co.uk> wrote:

> For embedded work, the rule here is never use floating point at all if 
> it can be avoided.

I disagree. Doing something in fixed-point instead of floating
point will greatly increase the design work required and make
that work more difficult.  It will cause bugs.  There will be
overlow and wrap-around bugs.

If you've got the code space and the CPU cycles, use floating
point: it's far easier to get the right answer and results in
far fewer bugs.

> If you know what the range of values and required accuracy is,

The problem is that many people _think_ they know.  But they
don't.

> scaled integer arithmetic will be faster and more efficient,
> especially if you can arrange the data to allow shifts, 
> rather than multiply and divide. If you need trig functions,
> then write your own using lookup tables, perhaps adding simple
> interpolation as a tradeoff against table size.

Why not design your own CPU, fab your own chips, and write your
own compiler too? ;)

> If you do this, you can define your own internal
> representation and design it for ease of use within the system
> and conversion to human readable / external format.

That's very difficult to do right.  When I started working in
the instrumentation business 15 years ago, most products were
done in fixed point.  A _lot_ of time was spent trying to get
the scaling and represention right.  And it never was quite
right.  There were always problems in the field with wrap
around and over/underflow in cases that the developers didn't
forsee.

Today, almost all of those projects use floating point.  The
result?  Much faster development time and far fewer bugs.  It
requires a few KB more code space, but code space has gotten
very, very ceap.  The main rub is speed when you're running
with little power at clock speeds <1MHz.

> Floating point on small machines is slow, inefficient,

In may applications it doesn't matter if the calculation takes
50ms or 5ms.  Trading complexity, development time, and bugs
for useless speed is a false economy.

> adds complexity

I find exactly the opposite: trying to do things in fixed point
is far more complex than doing them in floating point.

> and rounding errors everywhere it's used and you can usually
> get better control and predictable accuracy using other
> methods. It's a bit of a sledgehammer and if I were your
> project manager, I would encourage you to find a more creative
> solution :-).

Sounds like you're a big fan of premature optimization to me.

Do it the easy, obvious way first (that usually means floating
point for measurement and control apps).  Only _after_ you've
measured performance and decided it's going to be too slow do
you profile the code and decide if the extra work and bugs of
fixed point is worthwhile.

> Having said all that, 1100 bytes doesn't sound to bad for a
> sprintf, especially on an 8 bit machine. Still wouldn't use it
> though...

-- 
Grant Edwards                   grante             Yow!  All right, you
                                  at               degenerates! I want this
                               visi.com            place evacuated in 20
                                                   seconds!

Vladimir Vassilevsky wrote:
> 
> 
> ChrisQuayle wrote:
> 
> 
>> For embedded work, the rule here is never use floating point at all if 
>> it can be avoided.
> 
> 
> I strongly disagree. Floating point greatly simplifies the development 
> and the support of the program. I also like when the physical parameters 
> are represented as the natural values, such as Volts, Amperes, Seconds 
> and not in the weird units like 12345*ADC_RESOLUTION/CPU_CLOCK_RATE.

One of the main problems with the use of C library floating point is 
that you are then more or less forced to use all the library functions 
that support the internal format. As library implementations vary 
between vendors, so do the bugs, implentation detail and the fact that 
you then have a whole wedge of code in your project whose internals are 
invisible, (do you have the sources ?) cannot easily be verified etc.

For small system embedded work, it's better (IMHO, YMMV etc) to develop 
more efficient libraries over several projects / years. You then have 
fully debugged, efficient, tested code that you have complete control 
over. Such libraries can of course include scaled integer support  and 
are actually surprisingly trivial to write, as are table based trig 
functions.

> 
> When you are using a micro of 16k ROM or more, the floating point 
> overhead doesn't really matter. Of course, it does matter on the 
> machines with less then 8k.

Memory space is often not the problem. Rather, it's cpu throughput 
issues that limit it's use. There's also the knockon effect in terms of 
design constraint, innapropriate standard library data types, conversion 
function overhead etc. For a lot of embedded work, much of the standard 
C library is unusable because of such issues. Example:- recent pat 
tester project, 8051 legacy hardware, qtr vga graphics, loads of text 
and icons, 3 decimal place live readout of current and voltage etc, 
which was unusably slow until we ditched all the C lib floating point 
code. This thread was about 8051 class processors. Arguably different 
for embedded Linux on Arm, but that's not what was being discussed.

>> It's a bit of a sledgehammer and if I were your project manager, I 
>> would encourage you to find a more creative solution :-).
> 
> 
> Your job as a manager is get the project done on time, within budget and 
> for good. There is no place for religious beliefs and super optimization.
> 

Right, get it out the door and stuff the quality, because all we had was 
a hammer and no imagination. Nothing to do with religious belief, 
actually...

Chris

Grant Edwards wrote:

> I disagree. Doing something in fixed-point instead of floating
> point will greatly increase the design work required and make
> that work more difficult.  It will cause bugs.  There will be
> overlow and wrap-around bugs.

Any design worthy of the name should be able to define system limits and 
provide recovery for offlimit values.


> That's very difficult to do right.  When I started working in
> the instrumentation business 15 years ago, most products were
> done in fixed point.  A _lot_ of time was spent trying to get
> the scaling and represention right.  And it never was quite
> right.  There were always problems in the field with wrap
> around and over/underflow in cases that the developers didn't
> forsee.

Poor system design / specification ?.

> 
> Sounds like you're a big fan of premature optimization to me.

Not quite sure what you mean by that, but good design starts at the 
beginning, taking into consideration all software and hardware issues.

> 
> Do it the easy, obvious way first (that usually means floating
> point for measurement and control apps).  Only _after_ you've
> measured performance and decided it's going to be too slow do
> you profile the code and decide if the extra work and bugs of
> fixed point is worthwhile.

Depends on the company culture, product and other issues. Quick hack 
proof of concept code can become the product when business sees it 
working and declares development over. Best to do it right to start 
with. Better product and saves time and money in the end...

Chris

ChrisQuayle wrote:


>>> For embedded work, the rule here is never use floating point at all 
>>> if it can be avoided.

>> Floating point greatly simplifies the development 
>> and the support of the program. I also like when the physical 
>> parameters are represented as the natural values, such as Volts, 
>> Amperes, Seconds and not in the weird units like 
>> 12345*ADC_RESOLUTION/CPU_CLOCK_RATE.

> One of the main problems with the use of C library floating point is 
> that you are then more or less forced to use all the library functions 
> that support the internal format.

I would be really surprised if the internal format is not IEEE-754.
The only major problem that I have encountered with the vendor floating 
point libraries is that in some cases the library is not reentrant. 
There were quite a few small bugs though.


  As library implementations vary
> between vendors, so do the bugs, implentation detail and the fact that 
> you then have a whole wedge of code in your project whose internals are 
> invisible, (do you have the sources ?) cannot easily be verified etc.

The less I have to look under the hood, the better. I don't understand 
the open source philosophy.


> Memory space is often not the problem. Rather, it's cpu throughput 
> issues that limit it's use. There's also the knockon effect in terms of 
> design constraint, innapropriate standard library data types, conversion 
> function overhead etc. For a lot of embedded work, much of the standard 
> C library is unusable because of such issues. Example:- recent pat 
> tester project, 8051 legacy hardware, qtr vga graphics, loads of text 
> and icons, 3 decimal place live readout of current and voltage etc, 
> which was unusably slow until we ditched all the C lib floating point 
> code. This thread was about 8051 class processors.

In many cases, the 8-bit software looks like that:

for(;;)
  {
  Do_Everything();
  }

Instead of trying to do everything in one loop, employ a preemptive 
multitasker. Thus the slow floating point calculation will be spread 
over the time. This avoids the annoying delays for the other processes.


> Arguably different 
> for embedded Linux on Arm, but that's not what was being discussed.

I use the multithreading and the floating point calculations with AVR 
and HC12. Works fine. Of course, the speed critical parts are optimized, 
but they are not too many.


Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> wrote in message 
news:ijTOh.3155$YL5.1609@newssvr29.news.prodigy.net...
>
>
> I would be really surprised if the internal format is not IEEE-754.
> The only major problem that I have encountered with the vendor floating 
> point libraries is that in some cases the library is not reentrant. There 
> were quite a few small bugs though.
>

My favorite was a compiler library that supported the floating point 
functions that we called "sometimes less than" and "maybe greater than". 
This was the finest example of truly fuzzy logic I've come across.

Mark Walsh

On 2007-03-29, ChrisQuayle <nospam@devnul.co.uk> wrote:
> Grant Edwards wrote:
>
>> I disagree. Doing something in fixed-point instead of floating
>> point will greatly increase the design work required and make
>> that work more difficult.  It will cause bugs.  There will be
>> overlow and wrap-around bugs.
>
> Any design worthy of the name should be able to define system
> limits and provide recovery for offlimit values.

Maybe it's just the places I've worked, but in practice that
seems to be rather rare.

>> That's very difficult to do right.  When I started working in
>> the instrumentation business 15 years ago, most products were
>> done in fixed point.  A _lot_ of time was spent trying to get
>> the scaling and represention right.  And it never was quite
>> right.  There were always problems in the field with wrap
>> around and over/underflow in cases that the developers didn't
>> forsee.
>
> Poor system design / specification ?.

Being able to provide a robust working solution when given a
poor system design and specification can be a very good thing. :)

-- 
Grant Edwards                   grante             Yow!  Why was I BORN?
                                  at               
                               visi.com            

"Ron Blancarte" <ron@---TAKETHISOUT---.blancarte.com> wrote in message 
news:c0ui03dctcb8t4s04fmrs65v837jimars1@4ax.com...
> Now, i have googled this some, with not much as far as results, so I
> though I would ask here to see what kind of luck I would have.
>
> I am using the Analog Devices ADuC831 (8052 ISA) part to do data
> acquisition and transmission.  I have some data that is being held as
> floating point (single precision IEEE 754 format).  Some of this data
> needs to be outputted to serial on request.  This is where my request
> comes in.  Currently I am using sprintf() to format this output into
> my buffer.  HOWEVER, the footprint of this code is making it less than
> desirable to use (over 1100 bytes of code space and nearly 30 bytes of
> memory).  So I am looking to do the output on my own.
>
> And to this means, I have succeeded, to an extent.  So far I have
> removed my need for sprintf() in printing HEX format, as well as ints
> and chars.  My problem is with floats.  I have not yet attempted
> standard notation:
> 3.1415926
> But I did write an exponent formula.
> 3.141593E+00
> I even got the rounding.  HOWEVER, this is using simple multiplies and
> divides, by 10, to achieve it's goals.  And this introduces my
> problem.  Since a few of the numbers go out to 6 digits of precision,
> I am having problems with these last digits outputting correctly.  For
> example:
>
> Value entered: 6.791775E-08
> Value displayed: 6.791777E-08
> Hex value on chip:   0x3391DA2E (6.7917753e-8)
>
> Clearly, the entered value is being stored correctly and the displayed
> value, while close, is just slightly off.  So is there a way to do
> this without this error induced by my multiplications by 10 (and still
> not using sprintf()?
>
> RonB
>
>
> --------------------------------------------------
> "It is human nature to take shortcuts in thinking"
> --------------------------------------------------

Ron,

I emailed you some sample code that we wrote for the same problem on another 
member of the ADuC8xx family.  Let me know if you did not receive the direct 
email.

Scott