DK-TM4C129X: Estimating uDMA processing time for a scatter gather transfer

Unpacking using scatter/gather will not be very efficient. Since the number of samples is dynamic, you spend the CPU time setting up the task list. Then for every 3 bytes you transfer, you have an additional 3 cycles of uDMA memory to peripheral transfers to load the next task.

Have you considered using Peripheral Scatter-Gather to copy from the SSI to separate memory arrays for each channel? That way, the transfer and unpack happens while the SSI is receiving the next data.

Hi Bob,

the setup only happens once at start sampling time when I know which channels are required so the setup overhead is pretty much irrelevant. CPU overhead per sample block is in a couple of interrupt handlers:

void UnpackSamples()
   {
   // Interrupt handler for SSI1 uDMA following DMA transfer.
   SetRGBLed(BLULed | GRNLed);

   // Debugging
   ++*sSampleTxBuffer;

   // Clean up after SSI1 transfer
   SSIDMADisable(SSI1_BASE, SSI_DMA_TX | SSI_DMA_RX);
   SSI1_ICR_R = SSI1_RIS_R; // Clear the pending interrupts

   // Reset DMA interrupts to allow next transfer to happen
   SSI1_DMACTL_R &= ~(SSI_DMA_TX | SSI_DMA_RX);

   // Release the ADC chip select
   *(GPIO_PORTB_AHB_DATA_BITS_R + ADC_CS_BIT) = ADC_CS_BIT;

   // Kick off the sample unpack and commit processing
   uDMAChannelScatterGatherSet(UDMA_CHANNEL_SW, 8, sSampleXferTable, 0);
   NVIC_EN1_R |= 1 << (44 - 32); // Enable the uDMA SW interrupt
   UDMA_ENASET_R |= 1 << UDMA_CHANNEL_SW;
   UDMA_SWREQ_R = 1 << UDMA_CHANNEL_SW;
   SetRGBLed(GRNLed);
   }


void CommitSamples()
   {
   SetRGBLed(BLULed);
   NVIC_UNPEND1_R = 1 << (44 - 32); // Clear pending uDMA SW interrupt
   NVIC_DIS1_R = 1 << (44 - 32); // and disable it

   int32_t *to = gSampleBuffer->mBuffer[gSampleBuffer->mNextIn].mChanSamples;
   int32_t *from = sSamplesUnpackBuffer;

   *to++ = (*from++ << 14) & 0xFFFFC000;
   *to++ = (*from++ << 12) & 0xFFFFC000;
   *to++ = (*from++ << 10) & 0xFFFFC000;
   *to++ = (*from++ <<  8) & 0xFFFFC000;
   *to++ = (*from++ << 14) & 0xFFFFC000;
   *to++ = (*from++ << 12) & 0xFFFFC000;
   *to++ = (*from++ << 10) & 0xFFFFC000;
   *to   = (*from   <<  8) & 0xFFFFC000;

   // Commit the new sample to the sample buffer
   if (++gSampleBuffer->mNextIn >= kSampleBufferSize)
      gSampleBuffer->mNextIn = 0;

   if (gSampleBuffer->mNextOut == gSampleBuffer->mNextIn)
      // There's been a buffer overflow. Drop the oldest sample.
      if (    gSampleBuffer->mNextOut == gSampleBuffer->mNextIn
         && ++gSampleBuffer->mNextOut >= kSampleBufferSize
         )
         gSampleBuffer->mNextOut = 0;

   SetRGBLed(LEDSOff);
   }

which run in about 1.5 us each with local optimization for speed tuned on.

The killer for this whole task is that the ADC (ADS8598S - 8 channel 18 bit SAR) generates a packed stream of 8 x 18 bits giving a 144 bit block (9 x 16 bit words) with the 18 bit sample words barber polled through the block. SSI works with word sizes ranging from 4 to 16 bits so doesn't natively handle the 18 bit samples from the ADC. I can get around that by transferring 9 x 16 bit words and manually handling the SPI enable line for the ADC, but then I have the unpacking problem.

Hmm, I could set the SSI up to use 9 bit words. I still have to do some post processing to combine the two 9 bit values for each sample into an appropriately aligned 32 value, but I'm doing most of that work already and it's pretty fast.

I'll let you know how I get on. It may take a few days to get back to that task though - it's been put aside while I work on other things.

Using 9 bit SSI transfers instead of 16 bit gets me from about 16 us per sample down to about 8 us.

There is some variability in either the uDMA processing time or in the interrupt latency at the end of the uDMA transfer. Most of the time I see about 0.6 us from the end of the SPI transfer to the start of interrupt processing for the end of transfer interrupt. Every 1 ms or 0.7 ms (the period alternates!) I see 3 - 4 us interrupt latency. Any idea what that may be? I'd guess USB SOF if it were a regular 1 ms, but it isn't.

The amount of CPU activity on the RAM bus and the peripheral bus will affect the time to do the uDMA transfers. The CPU always has priority. The time to respond to an interrupt request varies depending on the number of cycles the current instruct takes to execute even if no other interrupts are being processed. However, the alternating nature of this delay implies it is application related.