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

Hi abeta and welcome to the Community!

I've moved your question to ARM Processors where I hope you will get your answer.

This is about the code that you posted in NXP Community.

Your code temporarily converts the negative ADC values to positive (by "manual" two's complementing) and eventually you convert back to negative by multiplying by -1. I suggest that you explore alternate, which can be more efficient, ways of converting from 12-bit signed integer to floating-point format.

A possible way of converting the ADC data from 12-bit signed integer to 32-bit floating-point format is by transforming to 32-bit two's complement code then assigning the result to a floating-point variable (simply let the compiler do the rest of the work).

If the ADC data is in (12-bit) offset binary code it can be converted to 32-bit two's complement format by simply subtracting the offset (in this case the offset is 2048)

    adcBuff[i] - 2048

where adcBuff[] is an array of signed 32-bit integer (int32_t). We then let the compiler convert it into floating-point format by assigning to a floating-point variable. The complete statement would be

    float32Buff[i] = adcBuff[i] - 2048;

where float32Buff[] is an array of 32-bit floating-point (float32_t) data.

If the ADC data is in 12-bit two's complement code it can be converted to 32-bit two's complement format by simply sign-filling bits 12 to 31 (replicating bit 11 into bits 12 to 31). Sign-filling can be done by (logical) shifting the 12-bit ADC data 20 bit positions to the left then performing an arithmetic shift right by 20 bit positions

    (adcBuff[i] << 20) >> 20

Note that there is no test for the state of bit 11. I just can't clearly recall if I previously encountered a compiler which cancels (no corresponding code generated) opposing shifts like this. Including the assignment to a floating-point variable, the complete statement would be

    float32Buff[i] = (adcBuff[i] << 20) >> 20;

If the compiler produces no code for the opposite shifts, you should devise a way to circumvent that or you can resort to alternative methods. An alternate method of converting the ADC data is to transform from 12-bit two's complement to 12-bit offset binary format. The subsequent conversion to 32-bit two's complement can be done as described above for the offset binary format. Two's complement code can be converted to offset binary format by simply complementing the leftmost bit (in this case bit 11)

    adcBuff[i] ^ 0X00000800

The complete conversion statement would be

    float32Buff[i] = (adcBuff[i] ^ 0X00000800) - 2048;

Extremely helpful. What I do need more right now is an insight from a skilled eye to point out what could be possible limitation of my design.
I'm not experienced so I read some chapters on this interesting book: The Definitive Guide to ARM® Cortex®-M3 and Cortex®-M4 Processors, Third Edition: Joseph Yiu: 9780124080829: Amazon.com:…   

Here there are lots of useful information about the cycles needed for each operation and I'll try to do rough calculations about how many of them my code needs.
I hoped I could squeeze things to fit in that 5 cycles boundary (which I was aware of since the beginning), but, as I understand, I might be wrong.
Anyway, I'm planning to follow your advice and, since I'll need to sample impulsive signals, to use the ADCHS in non-continuous mode, using the thresholds I can set and processing data when no info is being sampled. What do you think about it?

Again, thank you very much: as I said I'm developing this alone and for the first time, therefore your help is highly appreciated.

Cheers,

Andrea

Good post goodwin!

goodwin wrote:

    (adcBuff[i] << 20) >> 20

I just can't clearly recall if I previously encountered a compiler which cancels opposing shifts like this.

Such compilers are faulty and would generate incorrect code.

The compiler is free to optimize the code, however, making the code behave incorrectly is not allowed.

An exception: If the resulting value of the shift is unused, then of course the compiler is allowed to remove it completely.

Another exception: If the compiler can 'see' that only the low 12 bits are used anyway, it is free to ignore the line completely (GCC is capable of doing that, as the optimizer is very sophisticated).

I would expect that an optimizing compiler would reduce the above to a single instruction:

... for signed values ...

sbfx rT,rS,0,12

... and for unsigned values ...

ubfx rT,rS,0,12

-I know that GCC is working well, regarding optimizing and code reduction.

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].

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.

I think that's the way to do it but as I stated I am not an expert. Instead I would further suggest that you access LabTool's documentation and open-source software. LabTool is also based on LPC4370/LPC-Link 2 so I hope you find it helpful to your thesis.