SPI and DMA and LTC2600

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SPI and DMA and LTC2600

901 Views
pietrodicastri
Senior Contributor II

Good morning

I have the XTWR-ADCDAC-LTC. I need to book the LTC2600 for all of the channel at very fast rate.

It would be nice to get the DMA work without any polling or interrupt for updating in burst all of the DAC channels.

It seems impossible to do.

The DAC requires transfer of three or four bytes each one framed by the CS for every channel.

The SPI wants to transfer no more than 2 bytes. The DMA has the option to frame with the CS every transfer or the full

datalength. I don't see how to frame three or four bytes still the transfer continuing without any uC intervention.

The best solution I see is to transfer in chunk of three or four bytes with the CS continuously enabled, than in the DMA callback restart a new transfer with the next frame, all of this eight times for every tick of processing. 

In the end there is not so much to get from the DMA respect to the interrupt driven SPI, considering the KSDK function DSPI_MasterTransferEDMA(...) is not so light.

Maybe there is a way to bypass the limitations of the KSDK with some modifications in the initialization code.

I would like to get suggestion on the subject...

Thank You

Pietro

Tags (1)
0 Kudos
3 Replies

668 Views
pietrodicastri
Senior Contributor II

Nobody is liking this observation.

The question here is serious. The processor I have is fast but the DSPI_MasterTransferEDMA(...) takes about 10 uS.

The DAC and ADC on the expansion board are meant for fast update, up to the 100 KHz. If the DMA scan need to be reactivated with a call to DSPI_MasterTransferEDMA(...)  the uC will stuck there just for restarting the DMA scan.

The structure of the DMA service as is provided in current KSDK is not suitable for such situation, that I think is commonly happening. 

I worked terribly to bypass the problem. I initialized manually the DMA registers to provide a continuous scanning without any reinitialization, and now the processor is just free. 

I suggest to add the support for manual filling of an array of PUSHR  variables, then feeding the DMA source address with the array. 

Pietro

0 Kudos

669 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Pietro:

Could you please let us know your KSDK version and board? Does your project work as expected now?

Thanks

Regards

Daniel

0 Kudos

669 Views
pietrodicastri
Senior Contributor II

Thank You for attention

The KSDK is the 2.e, the directory name is SDK_2.3.0_MKV58F1M0xxx24.

I have a working solution I got initializing the DMA by hand, without using the DMA object.

The limit of the solution offered by the KDSK is that evey transfer needs to recall the DSPI_MasterTransferEDMA(...) reinitializing the registers with the same values. For repeating service it is too much expensive.

There is no way with actual SDK to recycle the previous settings. And the call costs 10uSecs. 

Additionally most of the time the DMA is used endlessly, so the bit of auto stop need to be disabled and the SLAST and DLAST simply roll back.

This approach is the one that is the most used, at least the way I see for my applications. And for this usage no support is provided, the DSPI_MasterTransferEDMA(...) enables the auto stop bit or rely on the scatter gather. 

Now the application is working so I have an optimal solution reading all of the ADC and writing all of the DAC outputs without any uC intervention.

I prepared an array of PUSHR and I feed in this way the DMA transfer, that automathically cycles the transfer values.

It is important in my opinion to provide this approach in SDK.

For now I am happy with what I have,,

Thank You

Pietro

0 Kudos