ADC/DAC Conversion to "decimal", best practices....

[jmaja]

Not using floating point is one of the many ill advised dogmas that surround embedded programming.

That was my first thought when I read this thread. When I started using microcontrollers in 2001 I avoided using floating point. I manage to do rather complicated calculations using up to 64 bit integers and carefully taking care not to overflow. Yes it worked and probably even was necessary due to quite small FLASH space.

But likely it was slower compared to floating point. And it's much easier to program with floating point.

I would say in most application speed is not a issue as long as you don't do something stupid. A 8bit MCU can do quite a lot of floating point calculations in a ms.

[SiliconWizard]

Not using floating point is one of the many ill advised dogmas that surround embedded programming.

Not using FP in any context, unless you really need it, is a very reasonable approach actually. It does make even more sense on targets which do not have hardware support for FP, because it's pretty slow then, but speed matters only if uh, it matters. Depending on the target and constraints, speed may not be a factor. But in all cases (not restricted to "embedded"), using FP should be done knowing its limitations. Not just in terms of speed of course. Accuracy and rounding errors.

Using FP because you don't know basic arithmetic is pretty sad and never leads to anything good. People not mastering enough arithmetic to implement basic integer/fixed-point computation should not be allowed to code software for any computational task IMHO. I mean, in a professional context of course. Hobbyist can well do what they want as long as it's fun.

[jpanhalt]

Using FP because you don't know basic arithmetic is pretty sad and never leads to anything good. People not mastering enough arithmetic to implement basic integer/fixed-point computation should not be allowed to code software for any computational task IMHO. I mean, in a professional context of course. Hobbyist can well do what they want as long as it's fun.

I couldn't agree more.  One of the classic problems in my college days (slide rules was all we had) was, "Assume you have a rope that does not stretch and tie it around the Earth.  Then add 6 feet to it.  How high is it above the surface if raised everywhere equally."  Of course, the diameter and circumference of the Earth were give as distractors.  Alert students set the problem up, quickly realized the circumference and diameter don't matter and got the correct answer.  Others didn't.

As I said in my earlier post, you need to understand the math and get it reduced to its simplest form before crunching the numbers.  I only use fixed-point on 8-bit PIC's without much hardware support.  24-bit is a little slower than 16/17-bit, but neither is particularly slow, and 1 part in 100,000 has been good enough for me.  I don't do finance though.

[Kleinstein]

If the resolution is enough depends on the use. When doing a frequency / time thing one may get to the range where the single precison FP is not sufficient. The same can happen with some math problems that are numerically not ideal, like calculating the standard deviation with quite some average value. This example may need around twice the number of bits of the data for an intermediate result if done the straight forward way. 

It depends on the µC, but the speed of FP multiplications tend to be not that bad. Adding / subtracting tends to be a bit slower with FP in many cases. Fixed point math may need additional headrom / extra bits. Chanche are 64 bit integers are slower then 32 bit FP and most C-comperilers don't support 40 or 48 bit integers. The bigger issue with FP is more the memory needed for the FP library. AFAIR for GCC-AVR this was something like 6 kBytes and AFAIK printf would come extra with also quite a bit of memory and also a bit of a slow down. There are extra conversion functions like some ftoa that can be quite a bit smaller. However not all IDEs / libs include all the coversion functions. On the PC there usually is an utoa and itoa for integers, but not so much with µCs and this braught up this whole topic.

[wek]

Using  integer/fixed-point should be done knowing its limitations. Not just in terms of speed of course. Resolution (and its change with operations) and rounding errors. Overflow, underflow, signedness. Implications to loading/storing/addressing. Behaviour in various intricate algorithms (think FFT or DSP). Availability of derived types (e.g. complex) and operations on them on various hardware and compilers. Interactions with third party libraries, and providing libraries for third parties. Interactions with external hardware. Future-proofing. Portability. Documentability.

For the last decade or so I am trying to figure out a simple rule of the thumb to decide what data type to use. And the more I try the more confused I am. I wish it could be as simple as "unless you really need it".

JW

[nctnico]

Not using floating point is one of the many ill advised dogmas that surround embedded programming.

Not using FP in any context, unless you really need it, is a very reasonable approach actually. It does make even more sense on targets which do not have hardware support for FP, because it's pretty slow then, but speed matters only if uh, it matters. Depending on the target and constraints, speed may not be a factor. But in all cases (not restricted to "embedded"), using FP should be done knowing its limitations. Not just in terms of speed of course. Accuracy and rounding errors.

Accuracy and rounding errors affect any kind of computation you do on a computer and should be considered no matter what. So that is not a valid reason not to use floating point.

My point is that using fixed point math is more often than not an unnecessary optimisation leading to convoluted code and use of weird units. Say you are developing a weight scale that has a range of 1000 grams with a resolution of 0.1 gram. Any type that can store 0 to 10000 is enough. Now do you want to use internal units in deci-micrograms, micrograms or kilograms? With floating point you can make the base unit kilograms (straight SI unit) and scale the ADC reading from the strain gauge accordingly. It makes it much easier to maintain such code. In the past couple of years I have converted a couple of projects from fixed point to floating point because it lead to code that is much easier to maintain.

[wek]

range of 1000 grams with a resolution of 0.1 gram
 Now do you want to use internal units in deci-micrograms, micrograms or kilograms?

I see and partially agree (see my post above) with your point; but this particular example makes me to ask: why would you want to use any of these in this particular case? Kilograms vaguely have some justification (as you've said, it's an SI unit, but how is it relevant to the internal representation?) but the other two not - besides both would require an unnecessarily wide type (neither fitting into 24 bits, and the former not fitting even into 32 bits).

JW

[nctnico]

range of 1000 grams with a resolution of 0.1 gram
 Now do you want to use internal units in deci-micrograms, micrograms or kilograms?

I see and partially agree (see my post above) with your point; but this particular example makes me to ask: why would you want to use any of these in this particular case? Kilograms vaguely have some justification (as you've said, it's an SI unit, but how is it relevant to the internal representation?) but the other two not - besides both would require an unnecessarily wide type (neither fitting into 24 bits, and the former not fitting even into 32 bits).

JW

IMHO IF you are going to use fixed point math, then it is nice to use units that can be expressed with SI prefixes like Mega, kilo, micro, nano, etc in order to have at least some anchor towards an SI unit and make code easier to understand. However, that leads to using unnecessary wide types indeed. Hence floating point is a better solution. It takes care of shifting the mantissa automatically for you. So the only thing you really need to worry about are resolution and rounding errors.

[wek]

Milli- (or in some languages, mili-) is an SI prefix, too.

Even deci- is an entirely compliant SI prefix, using decigrams in your case would reduce the required type width to 16-bit (14 in fact).

My real point is, that there's no one size fits all in microcontrollers.

JW

[NorthGuy]

Often you don't need to scale anything. ADC readings not always go to humans, but rather are used in control loop or in calculations, such as FFT. For such uses, ADC readings can be used directly, without scaling. Instead, you scale the coefficients. Or, if you use a table lookup (as you may do when you have non-linearities), you just fill in the table with units which are convenient to you - no scaling is necessary neither.

The need to scale arises mostly when you pass data to/from humans. Then you must use units familiar to the particular human - deci-pounds won't do you any good. But humans are slow, so you have plenty of time for conversion - doesn't need to be very efficient. You probably will have enough time and resources for doubles and printf() if you really love to bloat. But not many users will understand 2E-1 pounds, so you will have to use a fixed decimal point in your display. And for that, you need to figure out how many digits to show and where to put the decimal point anyway.

[wek]

> deci-pounds won't do you any good

Of course not. Nobody in its right mind would use pounds in 21.century.
;-)

Decipounds are absolutely okay to display e.g. on an display with literally fixed decimal point (i.e. where the decimal point is always lit to the left of the rightmost digit).

I still insist that there's no one size fits all, but thanks for bringing up another option to the bunch.

JW

[nctnico]

Milli- (or in some languages, mili-) is an SI prefix, too.

Even deci- is an entirely compliant SI prefix, using decigrams in your case would reduce the required type width to 16-bit (14 in fact).

Why fixate on wanting the smallest size? That is only a concern when you are really tight on memory. Otherwise it is just another unnecessary optimisation with potential pitfalls for the next person working on the code.

[wek]

I never worked on a project, where spending memory generously would bring me any perceivable benefit. OTOH, too often a previously unexpected requirement to keep a log of last 1000 measured value or similar appears. My experience is rather limited, I admit.

> potential pitfalls for the next person working on the code.

There is no inherent pitfall in using *any* type - the "next person" needs to familiarize itself with *whatever* type used, and understand fully its limitations.

I also never came across a case where the "next person" wouldn't completely dismiss the "previous person's" design choices. It's just built into our DNA.

JW

[nctnico]

I never worked on a project, where spending memory generously would bring me any perceivable benefit. OTOH, too often a previously unexpected requirement to keep a log of last 1000 measured value or similar appears. My experience is rather limited, I admit.

> potential pitfalls for the next person working on the code.

There is no inherent pitfall in using *any* type - the "next person" needs to familiarize itself with *whatever* type used, and understand fully its limitations.

I also never came across a case where the "next person" wouldn't completely dismiss the "previous person's" design choices. It's just built into our DNA.

I guess you never came across good software engineers then  IMHO The art of writing good code (*) is that the next person working on your code, doesn't want to throw it away but actually wants to add to it and keep the basic structure 'as is' as much as possible. And the person does add code by such an extend that the next time you work on it, you wonder whether you wrote that code or somebody else did. That is the synergy I like to achieve when working with others to develop software because that is a very efficient way of working. Not forcing anything on anyone but just by setting up a good structure and writing code in clear sentences. I know for a fact that many of the code I have written has stayed in use years after I have left the company (sometimes to my own surprise). People made changes to it as well. And yet I never got questions about how it worked.

* I'm very deliberately avoiding the word software here because that implies functionality which is a different subject.

[Nominal Animal]

As for binary to BCD, I have no clue how those C wizards do it.  In Assembly, there are several ways.  Double Dabble is among the slowest.  Up to 17-bit, there are several polynomial methods on PICList that are quite fast compared to division with 16-bits on 8-bit horse carts.

If you have all relevant powers of ten –– 10, 100 for 8 bits; plus 1000, 10'000 for 16 bits; plus 100'000, 1'000'000, 10'000'000 for 24 bits; plus 100'000'000, 1'000'000'000 for 32 bits –– you can do repeated subtraction, starting at the largest one.  For 16 bits, you do a maximum of 5+9+9+9=32 subtractions (of a 16-bit quantity); for 32 bits, 4+8*9=76 subtractions (of a 32-bit quantity), although you can switch down to 24-bit and 16-bit at specific steps.  So, it isn't fast in the time complexity O() sense, but since each comparison and subtraction tends to be fast and the code compact, it is a viable approach.

When you can treat the value as a fraction (i.e., all bits right of the decimal point), then repeated multiplication by ten ((x<<1)+(x<<3)) is quite efficient.  The problem on 8-bit machines is that for integer values, the most significant decimal digit tends to be difficult to extract.  For example, for 32 bits, you'd use 100'000'000 = 0b00000101'11110101'11100001'00000000 (since it is the largest power of ten that can handle all decimal digits; you'd use the subtraction for the larger one).  You can't just use the most significant byte, because 199'999'999 and 200'000'000 only differ in the least significant 9 bits: each extraction must look at three most significant bytes, so it is quite slow.

For BCD, you can use a variant of the subtraction algorithm, that starts at subtractor 64, and halves it for each subtraction (by shifting it one bit right).  The constants needed are then 100 and 64 for 8-bit; 64, 6'400, 10'000 for 16-bit; 64, 6'400, 640'000, 16'000'000 for 24-bit; 64, 6'400, 640'000, 64'000'000, 3'200'000'000 for 32-bit.  Each decimal digit pair takes 5 steps, so a maximum of 25 steps for 32-bit.  Again, simple and relatively compact (although you do need space for those constants, they can be stored in ROM/Flash; and only the currently used one in RAM), but not the fastest known.

When building decimal number strings, the BCD approach produces pairs of decimal digits, 00..99 inclusive.  If you have 100 bytes of ROM/Flash available for lookup, just store the BCD encoded value; you can also use this to encode any two-digit integer to BCD.  Low nibble then gives the lower decimal digit, and upper nibble the upper decimal digit.
For 16-, 24-, and 32-bit conversions, you then need 100+2*4+2*3+2*2+1=119 bytes of ROM/Flash for the constants.

Since 100=64+32+4, 100*x=(x + x<<3 + x<<4)<<2, you can use the 100-byte BCD table to extract pairs of decimal digits from a fractional binary value by repeated multiplication by 100.  The decimal value (0..99) will be in the overflow byte, so converting it to a pair of digits via the BCD table is fast.

Standard library implementations (newlib, in particular) are not designed or intended to be fast; they are written to be correct.  For example, when converting float or double to a string, if it is within certain bounds, multiplying it by a suitable power of ten (both integral and fractional powers!) depending on the desired format of output, rounding to an integer, and printing the integer value and just inserting the decimal point depending on the power of ten multiplier, is often much, much faster than using printf() or snprintf().  It is only the larger magnitudes (absolute values) whose conversion to decimal/string is problematic, and much of the standard library implementations involves getting those right.  As discussed in another programming thread, I'm working on a solution intended for 32-bit architectures (ARM cores) that has a very limited memory footprint, and it already beats all standard library implementations I've seen, while being exactly correct.  My only problem is how to avoid having to store the larger positive powers of ten, because for double, there are over 300 of them.

[Siwastaja]

Don't use float "just because". Fixed point is trivially easy, but of course for a beginner everything is difficult at first. This is not a reason not to learn to use them.

Even on higher performance CPUs like Cortex-M4 or -M7 using floats in ISR context causes stacking of FP registers which doubles your interrupt latency, this is sometimes important and may be totally unexpected for a first-timer.

Single precision float does not have enough resolution so you could ignore it and assume it's an "ideal" real number. And if you need to think about accuracy and resolution, fixed point is easier. double has enough accuracy for most practical purposes so you can get quite far by ignoring the whole problem. But double is even slower and larger.

Fixed point arithmetics literally throws the whole resolution/accuracy/range thing directly on your face. As you manually deal with it, you are forced to see loss of resolution in intermediate steps etc. For example, when multiplying two 32-bit numbers together, it is obvious you will need a 64-bit intermediate result. With 32-bit floats, every step just loses data for you, silently.

Usually floats are fine, yes, but the claim they are magically very much easier is completely untrue. You get different set of footguns.

You really have to learn to understand both floating and fixed point, no way around it IMHO.

[Nominal Animal]

With fixed point, it is also important to remember you can have either a binary fraction (AKA binary fixed point), or a decimal fraction (AKA decimal fixed point).

In binary fixed point, FixedPoint(1.0) = 2^b, where b is the number of fractional bits.

In decimal fixed point, FixedPoint(1.0) = 10^d, where d is the number of fractional decimal digits.

Many programmers use decimal fixed point without realizing it.  For example, if your variable is in milliVolts, it is also in volts in decimal fixed point with d=3.  To convert it to string, you just convert the integral value to a decimal number as usual (with at least four digits), and just insert the decimal point between the third and fourth least significant decimal digits.

To convert binary fixed point to a string, you handle the integer bits and the fractional bits separately.  The integer bits form the integral part, and can be printed as is (except if you apply rounding, and the fractional part rounds to next integer; then you need to add one to the magnitude).
The fractional part is easiest to convert by multiplying by a suitable power of ten, so that the desired digits are in the integer part, and rounding is based on whatever is left in the fractional part.  (IEEE by default rounds floats to even: so, you only increment the integer part if the fractional part is greater than one half, or when it is exactly one half and the integer part is odd.)

Both have their benefits and downsides, and it pays to carefully consider exactly what you do with the variables.  Converting between decimal and binary fixed point boils down to multiplying by a factor of 2^b/10^d=2^b-d/5^d or 10^d/2^b=5^d/2^b-d, which is usually less work than converting to decimal string in between.

On 8-bit architectures, you can convert an 8-bit fraction to three decimal digits by multiplying by 125 (so you'll have a 15-bit intermediate value to work on), leaving you with 5 fractional bits to determine the rounding, because 1000/256=125/32.  If the five bits are 0b01111 or less, leave it be; if 0b10001 or more, increment the three decimal digits by 1; and if 0b10000, apply your rounding logic.  Trick on architectures without a fast multiplication and only a single-bit shifts and rotations: 125=128-2-1, so you only really need one (wide) shift left and one wide shift right, and two temporary values to compute the result.
For printing, just do repeated multiplications by ten, and extract each digit in descending order of importance from the upper byte (bits 8..11).

[Siwastaja]

Yes:
TLDR:
* decimal fixed point for human consumption (ease of printing, just insert dot character at a fixed point)
* binary fixed point for further computer consumption

[wek]

I also never came across a case where the "next person" wouldn't completely dismiss the "previous person's" design choices. It's just built into our DNA.

I guess you never came across good software engineers then 

That is painfully obvious.

So, what's the agreement on best practices in this thread, exactly?

++

[jmaja]

Single precision float does not have enough resolution so you could ignore it and assume it's an "ideal" real number. And if you need to think about accuracy and resolution, fixed point is easier. double has enough accuracy for most practical purposes so you can get quite far by ignoring the whole problem. But double is even slower and larger.

You really have to learn to understand both floating and fixed point, no way around it IMHO.

Float (32bit) isn't very accurate, but doesn't overflow easily and the accuracy isn't that bad (23 bits or about 7 significant digits in base 10 system) . Depends a lot what you are doing. Floats may have problems with adding and subtracting, when the numbers have different order of magnitude. Thus you need to be careful not to loose the effect of the smaller one. Then again multiplying and dividing is quite safe and not much is lost. Dividing is often faster than with equal accuracy fixed point. And you may need some functions like trigonometric, which only work with floating point in most libraries (sure you can make your own with Taylor series etc.)

I always use double with actual computers. Solves almost all problems with float, but is far from optimal for MCU and some MCU C compilers even downgrade double to 32 bit.

My MCU software have always had some physics involved needing the use of several equations involving multiplying, dividing and more complex mathematical functions between variables, that are unknown while coding. I find it much easier to work with float and never had a problem with that. Even in cases needing very high accuracy and using a 24 bit ADC and a sensor giving 16 bit real resolution I have had no problems with accuracy after doing some calculations with floats.

I wouldn't use float for money or time etc. which are often big numbers with even the small differences important. With most other physical stuff, you can just ignore the small values, since they are not meaningful for the data. E.g. if you are measuring 1 km, you (usually) don't really care about each mm while within a year you may care about each second or even ms.

[SiliconWizard]

So, what's the agreement on best practices in this thread, exactly?

Using one's brain?

[Siwastaja]

Depends a lot what you are doing.

That's exactly my point, with float you don't get that "don't think about it at all" luxury. It almost feels like it, and usually works out, but at some point you hit a case where the accuracy isn't quite enough, when inaccuracies accumulate along the way. With a double, you can pretty much consider it a Matlab-like ideal real number, unless you are doing something super fancy like Nominal Animal's atomic/universe scale physical simulations. You see, I either want to prove the fitness of solution, or when handwaving, I want to leave a lot of margin for error, and float does not have much, think about it, if you had a 30-bit float with 2 bits less accuracy you would start truly hitting those corner cases.

I think this is also why double is the standard floating point type in C and C++, despite the age of the languages; literals like 10.0 are of type double, and math.h library functions like sin() take and return doubles. (And one needs to be careful to explicitly use float when doing float stuff: 10.0f, sinf()...)

[Siwastaja]

So, what's the agreement on best practices in this thread, exactly?

Using one's brain?

No, avoid everything if you have ever seen someone making a mistake with something!

[DavidAlfa]

You don't need floats at all, fixed point can provide quite good precision:
uint32_t mV_x100 = ADC*1000000/4095

ADC=2048 : 500122 (5001.22mV)
ADC=2813 : 686935 (6869.35mV)
ADC=1024 : 250061 (1500.61mV)

You can make some hacks to avoid division (Usually pretty slow), losing some accuracy at microvolt level, but overall giving the same results:
uint32_t mV_x100 = (ADC*1000244)>>12

ADC=2048 : 500122 (5001.22mV)
ADC=2813 : 686935 (6869.35mV)
ADC=1024 : 250061 (1500.61mV)

[jpanhalt]

You don't need floats at all, fixed point can provide quite good precision:

Isn't that like suggesting metric is more precise that imperial?  They provide exactly the same precision if set up comparably.