Other Parts Discussed in Thread: OMAP-L138, TMS320C6748
How many bytes does the EDMA3 transfer per REVT/XEVT when talking to the SPI in the OMAP-L138? Four?
Thx,
MikeH
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Other Parts Discussed in Thread: OMAP-L138, TMS320C6748
How many bytes does the EDMA3 transfer per REVT/XEVT when talking to the SPI in the OMAP-L138? Four?
Thx,
MikeH
Mike,
The transfer size of the EDMA3 is provided as a programmable size to suite the needs of the various peripherals that require different transfer sizes. The registers for setting the size should be available in the EDMA3 User's Guide for your specific device.
Drew,
Drew Abuan said:The registers for setting the size should be available in the EDMA3 User's Guide for your specific device.
I agree that they *should be*. But I cannot find them. I have checked SPRUGP9B "TMS320C6748/46/42 and OMAP-L138 Processor Enhanced Direct Memory Access (EDMA3) Controller", sprurm4h "TMS320C674x/OMAP-L1x Processor Serial Peripheral Interface (SPI)", and SPRS586B "OMAP-L138 Low-Power Applications Processor". Can you point out where I can find this information?
Thx,
MikeH
Hi Mike
Yes, currently the EDMA3 user-guide does not have example for all SoC peripheral/modules that can be serviced by EDMA. To answer your question specifically, per event SPI transfer is typically 1 or 2 bytes, this can be done by programming the ACNT=1/2 (byte), BCNT= number of such 1 or 2 byte elements that you need to transfer , CCNT=1 , A sync transfers.
You can also find the spi_edma example as part of the BIOS PSP package, the specific source file would be
pspdrivers_01_xx_yy\packages\ti\pspiom\spi\src\SPI_edma.c
Typically the number of bytes per sync event depends on the module, so for UART it is typically 1 byte (unless you have the FIFO enabled), SPI = 1,2 bytes, McBSP = 1,2,4 bytes etc.
Regards
Mukul
Mukul,
Thanks for taking the time to accurately read and answer my post.......
As you and I discussed here (http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/68363.aspx?PageIndex=2) the McASP XBUF/RBUF does not allow the flexibility of 8 or 16 byte transfers (" Doing 8 or 16 bit transfers does not work well with these ports"). I assume from your suggestion above that the SPI->SPIDATA1 and SPI->SPIBUF do not have this same restriction? Or, are we merely masking the issue by adjusting ACNT & BNCT? If so, ACNT and BCNT will need to be different values for sending to SPIDAT1 and receiving from SPIBUF....?
Thx,
MikeH
MikeH said:I assume from your suggestion above that the SPI->SPIDATA1 and SPI->SPIBUF do not have this same restriction?
No restrictions similar to McASP , just that if you notice that the SPIDATA0/1 , SPIBUF registers , the "data" is lower 16 bit only, the upper bits are either reserved (SPIDAT0) or used for additional commands/control bits (SPIDAT1, SPIBUF), so the ACNT would typically will be 1 or 2 (8bit or 16bit), this will also depend on the SPI device you are interfacing with our device.
So the simplest setting would be ACNT=1/2 , BCNT = Number of such elements, CCNT=1 , A sync transfers, where in EDMA will transfer ACNT bytes every tx/rx sync event.
Let me know if you have additional questions on this.
Regards
Mukul