Using Window Function for RMS

[Red_Micro]

In my attempt to continue learning digital signal processing, and as part of learning other methods of finding RMS, I would like implement the code in this site using a STM32 device. I attached the two files that I'm trying to understand. Looking into that code I have the following questions:

1. Do I really need to use double type variables? This code is implemented using a PsoC device, but I'm trying to implement it in STM32 Cortex M0+ with 12 bit ADC and no FPU. So I think I can use float32 variables, right?

2. The Hann Function is given by

Code: [Select]

Hanning = a0 + a1 * Cos (2*PI*i/N); -N/2 <= i <= N/2. This agrees with Wikipedia: https://en.wikipedia.org/wiki/Window_function#Hann_and_Hamming_windows. But then in the ConfigRMS16 function it says:

Code: [Select]

double Y = a0 + a1 * cos( M_PI * ((double) i) / ((double) (NO_SAMPLES-1)) ); Is M_PI equivalent to 2*PI?

3. Why is the Window scaled to 8 bit? Is a quad buffer needed? Why not double buffer?

4. I have initialized the ADC and DMA in the STM32 and it works ok. But in order to translate this code to STM32 I need to fully understand it, so any other help is appreciated. I understand this approach is good for signals with discontinuities, that's why I want to learn how to use it.

[ejeffrey]

You shouldn't need to use double.  Most non-vector FPUs are double precision internally so it doesn't really help to use less.  If you are using soft floats then single precision is a good idea.

[0xdeadbeef]

He said he uses a Cortex M0+ which by definition has no FPU at all. Only starting with M33 and M4, ARM cores have a FPU. So SW library -> slow.
Besides, most 32bit microcontrollers only have a 32bit FPU. I actually only know one exception (Renesas RH850) where the FPU also supports doubles - this is still slower than 32bit floats on a 32bit CPU of course since it needs two registers to store operands and results and the memory transfers for these take twice as long.
As a side note: people typically use floating point because they are lazy. Most of the times it's a better idea to use fixed point integers. Lots of people using floating don't even know what a subnormal number or (quiet or signaling) NaN is. These should better not use floats.

[Kleinstein]

One would not need floats. In principle one can do it with integers (32 bits are probably OK, no need to go 24 bits).
If the speed is critical and one has enough memory, one could use a table for the hanning function - the cosine function is what really needs time. For the table halve the length (because of symmetry) and 8 bit values should be good enough.  A possible alternative is to use some cordic type calculation of the cosine as an approximation for the window.

Ideally one would not need any buffering of the raw data: one can do the sums in really time, as the ADC values come in and once in the sum there is no need to keep the old values.

[Siwastaja]

Both software single precision and double precision floats are slow, the order of magnitude is the same.

If you have plenty of time and resources and are lazy, use double; because if you are lazy, you likely won't be doing any analysis for accuracy anyway, so the only way to succeed is to really overspecify. Hence double "by default".

If you then see  you are having performance issues (test with doubles first!), go for fixed point. This also forces you to analyse numerical ranges and precision.

After this being said, if you still want to use single precision float, remember to call SP library functions, like sinf, cosf, absf and so on.