Process ADC data, moved by DMA, using CMSIS DSP: what's the right way?

Building upon goodwin's answer, I'd like to suggest a complete loop:

void Twos2Dec_Remapp(const uint32_t *twosBuff, float32_t *decBuff, uint32_t buffLength)
{
     register uint32_t       i;
     register float          *d;
     register const uint32_t *s;

     s = (int32_t *) &twosBuff[buffLength];
     d = &decBuff[buffLength];
     i = -buffLength;  /* convert length to negative index for speed */
     do
     {
          d[i] = (s[i] & 0xfff) - 2048;  /* most likely, this is the correct calculation */
     }
     while(++i);
}

I believe the above would produce the optimal binary code (by 'hinting' the compiler how).

The most expensive part is to convert to a float! In fact, I think it's a very bad idea using floats if you don't have hardware floats.

Imagine that for each float operation, a huge block of code is executed. Each line of code usually takes 1 or 2 clock cycles (unless we're speaking about dividing), so if you can, use fixed point.

Converting to a 16:16 fixed point is real easy; you just need to change the type 'float *' to 'int32_t *' and the shift operations to ...

          d[i] = (s[[i] << 20) >> 4);

-Because fixed point is just an "integer part" and a "fractional part". The integer part is the same as your integer value, the fractional part is 0.

So in hexadecimal, a 16:16 fixed point would lookk like this:

0xiiiipppp

-Also make sure that your destination buffer is not in the SRAM section, which the DMA is using, in order to avoid disturbing the DMA.

The larger the DMA buffer is, the larger the 'propagation delay' will be (eg. time between input and output)

If your data is output in real-time, you will want a small DMA buffer.

But if the DMA buffer is very small, the CPU will spend a lot of time executing non-essential code (such as entering/leaving subroutines, instead of actually working on the data).

-So you'll need to find the right balance and when you've found a size that juuust works, give it a little more room; 40% extra is often a good choice. I would not recommend less than 10% extra.

Building upon goodwin's answer, I'd like to suggest a complete loop:

void Twos2Dec_Remapp(const uint32_t *twosBuff, float32_t *decBuff, uint32_t buffLength)
{
     register uint32_t       i;
     register float          *d;
     register const uint32_t *s;

     s = (int32_t *) &twosBuff[buffLength];
     d = &decBuff[buffLength];
     i = -buffLength;  /* convert length to negative index for speed */
     do
     {
          d[i] = (s[i] & 0xfff) - 2048;  /* most likely, this is the correct calculation */
     }
     while(++i);
}

I believe the above would produce the optimal binary code (by 'hinting' the compiler how).

The most expensive part is to convert to a float! In fact, I think it's a very bad idea using floats if you don't have hardware floats.

Imagine that for each float operation, a huge block of code is executed. Each line of code usually takes 1 or 2 clock cycles (unless we're speaking about dividing), so if you can, use fixed point.

Converting to a 16:16 fixed point is real easy; you just need to change the type 'float *' to 'int32_t *' and the shift operations to ...

          d[i] = (s[[i] << 20) >> 4);

-Because fixed point is just an "integer part" and a "fractional part". The integer part is the same as your integer value, the fractional part is 0.

So in hexadecimal, a 16:16 fixed point would lookk like this:

0xiiiipppp

-Also make sure that your destination buffer is not in the SRAM section, which the DMA is using, in order to avoid disturbing the DMA.

The larger the DMA buffer is, the larger the 'propagation delay' will be (eg. time between input and output)

If your data is output in real-time, you will want a small DMA buffer.

But if the DMA buffer is very small, the CPU will spend a lot of time executing non-essential code (such as entering/leaving subroutines, instead of actually working on the data).

-So you'll need to find the right balance and when you've found a size that juuust works, give it a little more room; 40% extra is often a good choice. I would not recommend less than 10% extra.

Indeed, the optimization that goodwin mentioned will improve performance dramatically!

The problem with floating point and Interrupt Service Routines (ISR) is that if you use a floating point register in the ISR, it will need to be saved before it's used and restored before the interrupt is ended.

-This is because if you're using floating point registers anywhere in the other parts of your program, the values would be messed up randomly if the registers are changed by the interrupt.

However... If you're using floating point only in the interrupt, you won't have any problems.

[Note: sometimes it would be worth it to use hardware floating point in ISR and software floating point at task-time; eg. if you're only using software floating point for printing out values once per second, that would be the optimal solution. Mixing software and hardware floating point is an advanced topic, however and is not recommended the first 3 days of your life as a programmer].