LPC43xx SGPIO Configuration -- Why not use GPDMA ?

LPC43xx SGPIO Configuration

The LPC43xx SGPIO peripheral is used to move samples between USB and the ADC/DAC chip (MAX5864).

The SGPIO is a peripheral that has a bunch of 32-bit shift registers.

These shift registers can be configured to act as a parallel interface of different widths.

For HackRF, we configure the SGPIO to transfer eight bits at a time.

The SGPIO interface can also accept an external clock, which we use to synchronize transfers with the sample clock.

In the current HackRF design, there is a CPLD which manages the interface between the MAX5864 and the SGPIO interface.

There are four SGPIO signals that control the SGPIO data transfer:

• Clock: Determines when a value on the SGPIO data bus is transferred.
• Direction: Determines whether the MAX5864 DA (ADC) data is driven onto the SGPIO lines,
  or if the SGPIO lines drive the data bus with data for the MAX5864 DD (DAC) signals.
• Data Valid: Indicates a sample on the SGPIO data bus is valid data.
• Transfer Enable: Allows SGPIO to synchronize with the I/Q data stream.
  The MAX5864 produces/consumes two values (quadrature/complex value) per sample period -- an I value and a Q value.
  These two values are multiplexed on the SGPIO lines. This signal suspends data valid until the I value should be transferred.

Frequently Asked Questions

Why not use GPDMA to transfer samples through SGPIO?

It would be great if we could, as that would free up lots of processor time.

Unfortunately, the GPDMA scheme in the LPC43xx does not seem to support

peripheral-to-memory and memory-to-peripheral transfers with the SGPIO peripheral.

You might observe that the SGPIO peripheral can generate requests from SGPIO14 and SGPIO15,

using an arbitrary bit pattern in the slice shift register.

The pattern in the slice determines the request interval.

That's a good start.

However, how do you specify which SGPIO shadow registers are read/written at each request,

and in which order those registers are transferred with memory?

It turns out you can't.

In fact, it appears that an SGPIO request doesn't cause any transfer at all, if your source or destination is "peripheral".

Instead, the SGPIO request is intended to perform a memory-to-memory transfer synchronized with SGPIO.

But you're on your own as far as getting data to/from the SGPIO shadow registers.

I believe this is why the SGPIO camera example in the user manual describes an SGPIO interrupt doing the SGPIO shadow register transfer,

and the GPDMA doing moves from one block of RAM to another.

Perhaps if we transfer only one SGPIO shadow register, using memory-to-memory?

Then we don't have to worry about the order of SGPIO registers, or which ones need to be transferred.

It turns out that when you switch over to memory-to-memory transfers, you lose peripheral request generation.

So the GPDMA will transfer as fast as possible -- far faster than words are produced/consumed by SGPIO.

I'd really love to be wrong about all this, but all my testing has indicated there's no workable solution

to using GPDMA that's any better than using SGPIO interrupts to transfer samples.

If you want some sample GPDMA code to experiment with, please contact Jared (sharebrained on freenode #hackrf).