EmbeddedRelated.com
Forums
Memfault Beyond the Launch

converting float to ascii w/o printf

Started by Ron Blancarte March 27, 2007
On Sun, 01 Apr 2007 18:00:07 -0400, CBFalconer <cbfalconer@yahoo.com>
wrote:

>Grant Edwards wrote: >> On 2007-04-01, Anton Erasmus <nobody@spam.prevent.net> wrote: >> >... snip ... >>> >>> Doing a robust floating point implimentation that handles all >>> the exceptions properly is non-trivial. Typical 8-bit >>> implimentations takes short cuts. >> >> I've been using floating point on 8-bit platforms for 15 years, >> and I've got no complaints. > >I think Anton is including omission of detection and propagation of >INF and NAN as "short cuts". The other approach is to trap those >operations at occurance.
While in-band signalling of special conditions is useful in some cases, when there are a limited number of special cases, however, with more complex situations, when the signal is processed at various stages, getting any meaningful information through the whole chain is quite hard. However, when using out-of-band signalling, i.e. there is a status field is attached to the actual value. This status field can express much more situations, such as sensor open/short circuit, out of range etc. For instance, in the Profibus PA fieldbus, each signal is represented by 5 bytes, four bytes for the actual floating point value and one byte for the actual status ("quality") of the signal. So if you are planning to use a floating point value with the sole purpose of using in-band signalling with NAN, +INF and -INF, it might make more sense to use a 16 or 24 bit integer value field and an 8 bit status field, which has the same or smaller memory footprint than the 32 bit float. On an 8 bitter, less memory access is required to check for the status byte than trying to determine, if the float is a very large value, INF or NAN, requiring testing up to 4 bytes. This is significant, since the exception conditions should be checked every time before using the value. Paul
Anton Erasmus wrote:
> A pity that none of the main stream languages has support for fixed point.
Ada supports fixed point. I consider it a "main stream language", but some perhaps don't... -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
On Fri, 30 Mar 2007 09:28:38 -0600 (while OU was sucking), Not Really
Me wrote:
> >"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
I didn't get it (or my spam filters got to it first). Try sending it to ron dot blancarte at benchtree dot net. That is my work address and would be where I was looking for this solution. -R
On Mon, 02 Apr 2007 13:29:31 +0300, Niklas Holsti
<niklas.holsti@nospam.please> wrote:

>Anton Erasmus wrote: >> A pity that none of the main stream languages has support for fixed point. > >Ada supports fixed point. I consider it a "main stream language", but >some perhaps don't...
So do COBOL and PL/1, but are these main stream languages in the embedded world ;-). Paul
On Mon, 02 Apr 2007 13:29:31 +0300, Niklas Holsti
<niklas.holsti@nospam.please> wrote:

>Anton Erasmus wrote: >> A pity that none of the main stream languages has support for fixed point. > >Ada supports fixed point. I consider it a "main stream language", but >some perhaps don't...
As far as I am aware there is no main stream language available for from small 8-bit micros up to 64 bit processors that has support for fixed point. This is true whether one considers Ada a main stream language or not. C , and maybe Forth is probably the only languages which is supported across the full range of micros. Regards Anton Erasmus
In article <pub5135u3ht8o5i56brfu83rq5vu5n5phb@4ax.com>, Anton Erasmus <nobody@spam.prevent.net> writes:
> > As far as I am aware there is no main stream language available for > from small 8-bit micros up to 64 bit processors that has support for > fixed point. This is true whether one considers Ada a main stream > language or not. C , and maybe Forth is probably the only languages > which is supported across the full range of micros. >
Ada is now available on the AVR. What I don't know, because I don't use the AVR, is if Ada's fixed point packages are also available on the AVR. See http://avr-ada.sourceforge.net for further details if you are interested. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world

Memfault Beyond the Launch