Calculating with real numbers without FPU

[0xdeadbeef]

fixepoint needs saturating math
made in software or in hardware

Using saturation or not has nothing to do with fixed point arithmetic. Just because the numerical range of float types is higher compared to integer types (at the expense of gaps in the range) doesn't mean that they can't underflow (become subnormal) or overflow (infinity). The main difference is that you can detect an underflow/overflow in float after it happened. In a realtime system, that is of limited use though as you usually need a result that can be processed instead of just displaying an error message.
Besides, you can always avoid overflow for multiplications by using numbers normalized to one. Pretty much standard in DSPs and digital filters.

this, plus a fine-tuning of the algorithm.

Crappy implementation with floats will lead to numerical nonsense just as with fixed point integers or whatever.

[SiliconWizard]

Crappy implementation with floats will lead to numerical nonsense just as with fixed point integers or whatever.

True. At least with fixed point, you're less tempted to think your calculations will magically work in all cases. Floating point can be deceitful.

[ali_asadzadeh]

Just wanna catch the topic in here

[legacy]

The meaning of "tuning" is that you enable the overflow/underflow circuit (or you use kind of software check) in order to verify that your numerical conditioning actually works. In my experiences, this happened with matrix computation when matrices were "bad conditioned".

Yes, it would have worked bad even with floating point, but with a fixed-point, it can go even worse: during the engineering step, you need to check how good/bad the data conditioning goes, and having these checks is a good practical feature.

---

Being numerically tolerant.

In avionics, we use dedicated video-core systems to provide navigation information to the pilot through a visual helmet that integrates a special LCD as well as we use radio-core systems to provide useful information through a kind of headphone integrated into the helmet.

Both these systems implement saturation arithmetic for video and audio decoding, so as to avoid visual and sound defects.

[legacy]

a special case is "fractional"

Q(1,N-1): 1 bit for the sign, N-1 bits for the fractional part.
as a reference, it's used by Microchip in the DSPic line.

[langwadt]

Besides, you can always avoid overflow for multiplications by using numbers normalized to one. Pretty much standard in DSPs and digital filters.

almost, -1.0*-1.0 won't fit in a Q1.xx

[apis]

Sorry for nitpicking but FPUs don't calculate with real numbers either. Computers only do numerical computations with rational numbers (or something similar). So just use the fact that 1.071 = 1071/1000 or 1071 * 10^-3 (or something equivalent in base 2).

[brucehoult]

By using soft floating point. It comes standard with every C library. There is one downside: you will need more flash and the speed will be slower. If your application can tolerate that, then you are fine and I wouldn't bother with using fixed point math. If you use an ARM microcontroller it is likely fast enough to use floating point in realtime scenarios as well. I'd try first to see if you get the required performance using soft floating point and only optimise if the performance isn't good enough.

Even on a 16 MHz AVR, the Arduino soft floating point library takes around 10 us for a single precision floating point add, subtract, or multiply. So you can do around 100 FP operations in a millisecond. That's plenty fast enough for a lot of realtime control systems, and avoids problems with getting unexpected overflow in a fixed point calculation.

[ali_asadzadeh]

would somebody clarify things here for me, suppose we have 16Bit ADC and we need to do some DSP on it, how should we convert the ADC values to Q format, do the calculations and convert back the results to integers or floats.

Suppose that we want to do FFT

I have tested it with ARM CMSIS DSP with the Q format I would most times get wrong results when the ADC values are low, so I would mostly use the Float version, which I simply put the ADC values directly to float version and do the calculations, the point in here is how to do it fixed point so it can be done on M0 with lower CPU clock.

[T3sl4co1l]

Consider that the 16-bit ADC values come in as 0.16 format, relative to VREF.  (Or 1.15 if signed.)

The numbers inside the computer need not have any units at all.  Preferably, they're just more arbitrary data to pass around!  You should only ever need one unit conversion step, when outputting the value to display or other* DAC.

*That is, a DAC that's separate from the ADC and its VREF, in which case they probably won't exactly match.

Nothing matters for DSP or FFT, as long as the gain is unity, and you don't cause overflow in intermediate steps (and, you provide enough fractional bits as needed for certain purposes -- integrators with very long time constants, or high order IIR filters, for example -- in which case the extra bits can be local to those sections, and truncated or rounded off elsewhere).

On an M0, 8.24 format is probably as effortlessly good, and easy, as you'd need for most purposes?  In other words, take the ADC sample, put it in a (u)int32_t, << 8, math it, then >> 8 when you're done.

Incidentally, the added bits can be meaningful.  For example, when accumulating values (such as a in "boxcar" FIR filter), you need ceil(Lg(N)) extra bits to hold N samples added together.  Assuming uniform, independent quantization noise, we expect to gain about half as many bits in real measurement accuracy.  For N = 256 say, we need 8 additional bits, and 4 of them are meaningful (effectively expanding a 16 bit ADC to 20 bits accuracy).

(Or if subtractive dithering is used, nearly all 8 added bits are meaningful!)

Note that uniform and independent quantization noise is not a good bet, when considering the DNL and INL of real ADCs.  You'll get more resolution this way, but not necessarily more accuracy.  Ideally, you'd calibrate such a system, and introduce a conversion table or piecewise or polynomial correction curve to get real numbers out.  This is... heroic effort compared to the $5 to buy a "24-bit" ADC (which might only be 20 bits real accuracy, but there you have it, eh?), so it's not often used.  Just FYI, know your errors and statistics.

Tim

[ali_asadzadeh]

Thanks Tim for the help in here.

[techman-001]

If we have a microcontroller which does not have an FPU. How would we calculate:

• 1.713 * 0.0514
• 1.713 + 0.0514

Thanks.

With Mecrisp-Stellaris Forth, we would do it this way on a STM32F051 32 bit CortexM0 with no FPU:

1,713 0,0514 f* 8 f.n
0,08804819  ok.

1,713 0,0514 d+ 8 f.n
 1,76439999  ok.