• State Accepted Answer
  • Locked Locked
  • Replies 44 replies
  • Subscribers 350 subscribers
  • Views 104828 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Andrea Bettati

Hi to you all,
I've a firmware running on a NXP LPCLink2 (LPC4370: 204 Mhz Cortex M4 MCU) board which basically does this:

  • Fills the ADC FIFO @40msps.
  • Copies the data into memory using the built-in DMA Controller and 2 linked buffers.
  • Processes one buffer while the other is being filled.

My problem is that my code is too slow, and every now and then and overwrite occurs.

Using the DMA I'm saving the ADC data, which I get in Twos complement format (Offset binary is also available), in a uint32_t buffer and try to prepare them for the CMSIS DSP function by converting the buffer into float32_t: here's where the overwrite occurs. It's worth saying that I'm currently using Floating point Software, not hardware.


The CMSIS library also accepts fractional formats like q31_t, q15_t and so on, and since I don't strictly need floating point maths I could even use these formats if that could save me precious time.
It feels like I'm missing something important about this step, that's no surprise since this is my first project on a complex MCU, any help/hint/advise would be highly appreciated and would help me in my thesis.

I'll leave here the link for the (more datailed) question I asked in the NXP forums, just in case: LPC4370: ADCHS, GPDMA and CMSIS DSP | NXP Community .

Thanks in advance!

Parents
  • 0

    Line 19, 20, 36 and 37 looks very wrong to me.

    To me, it seems you're doing the same job twice.

    Eg. after 8 iterations, the values you've already sign-extended, will be sign-extended again.

    I could be wrong, but I better mention it; are you sure that they're doing what you want ?

    (I would remove them completely)

    About the 'prefetch' on branches (P):

    Prefetch only happens when necessary. It's not really something you're in control of (especially not when using C code).

    -But it may be 3 the first time the branch jumps back in the loop and then 1 from that point on.

    If an interrupt happens while you're inside the loop, P might become 3 again.

    But as you see, this is something that's rare, so I think you can assume the value 1.

    RAM usage looks great. There's plenty for placing code in SRAM in a section that does not collide with the DMA.

    As far as I can tell, the DMA buffer is somewhere in RamLoc128.

    That means you can pick any of the other ram locations (I'd suggest one of the AHB sections) for the code.

    Now, I just don't know which address RamLoc128 is.

    (I particularly like that NXP measure 0 Bytes in GB).

Reply
  • 0

    Line 19, 20, 36 and 37 looks very wrong to me.

    To me, it seems you're doing the same job twice.

    Eg. after 8 iterations, the values you've already sign-extended, will be sign-extended again.

    I could be wrong, but I better mention it; are you sure that they're doing what you want ?

    (I would remove them completely)

    About the 'prefetch' on branches (P):

    Prefetch only happens when necessary. It's not really something you're in control of (especially not when using C code).

    -But it may be 3 the first time the branch jumps back in the loop and then 1 from that point on.

    If an interrupt happens while you're inside the loop, P might become 3 again.

    But as you see, this is something that's rare, so I think you can assume the value 1.

    RAM usage looks great. There's plenty for placing code in SRAM in a section that does not collide with the DMA.

    As far as I can tell, the DMA buffer is somewhere in RamLoc128.

    That means you can pick any of the other ram locations (I'd suggest one of the AHB sections) for the code.

    Now, I just don't know which address RamLoc128 is.

    (I particularly like that NXP measure 0 Bytes in GB).

Children
No data