I'm seeing big gaps (5 us) between each byte in the transmission. What's the cause and how do I fix it?
Here's my init and transfer function, I'm using the latest CMSIS LPCOpen code. I pretty much lifted this from the example. I'm controlling the CS manually.
void int(void) { SPI_CFGSETUP_T spiSetup; SPIM_DELAY_CONFIG_T masterDelay; /* Initialize SPI controller */ Chip_SPI_Init(EVE_SPI); /* Call to initialize first SPI controller for mode0, master mode, MSB first */ Chip_SPI_Enable(EVE_SPI); spiSetup.master = 1; spiSetup.lsbFirst = 0; spiSetup.mode = SPI_CLOCK_MODE0; Chip_SPI_ConfigureSPI(EVE_SPI, &spiSetup); /* Setup master controller SSELx for active low select */ Chip_SPI_SetCSPolLow(EVE_SPI, EVE_SSEL); /* Setup master clock rate, but start off slow. */ Chip_SPIM_SetClockRate(EVE_SPI, 1000000); /* Setup master delay (all chip selects) */ masterDelay.PreDelay = 0x00; masterDelay.PostDelay = 0x00; masterDelay.FrameDelay = 0x00; // This can be as low as zero, but set to two to making debugging easier w/ a scope. masterDelay.TransferDelay = 0x01; // The minimum is 1. Chip_SPIM_DelayConfig(EVE_SPI, &masterDelay); } /* Setup master transfer callbacks in the transfer descriptor */ spiMasterXfer.eventCB = NULL;
static void spi_transfer(uint8_t *data, size_t size)
{
/* Set up master transfer block */
spiMasterXfer.txData = data; /* set master transmit pointer */
spiMasterXfer.txCount = size; /* set master transmit frame count */
spiMasterXfer.rxData = data; /* set master receive pointer */
spiMasterXfer.rxCount = size; /* set master receive frame count */
spiMasterXfer.dataWidth = 8;
spiMasterXfer.sselNum = 0; /* set SPI select */
spiMasterXfer.txIndex = 0; /* clear the transmit buffer index */
spiMasterXfer.rxIndex = 0; /* clear the receive buffer index */
spiMasterXfer.option = 0;
Chip_SPIM_XferBlocking(EVE_SPI, &spiMasterXfer);
}
Solved! Go to Solution.
Hi Chris,
Yes, you are right.
If you call another SPI frame, a lot of functions will be called again, so the big gap between the two frames(not between bytes in the same frame) is long, the SPI code is really a little redundancy, so if you very care about the execution time, I think you can simplify the SPI function, you can design it by yourself, don't use too many function calls.
If you don't want to receive the the SPI data, I think you can delete the receive code, it will save the code execution time.
Wish it helps you!
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
I made these changes:
Using Chip_SPIM_XferFIFO() instead of interrupts and changing optimization to -Os, brought the byte time to 1 us. (a 5x speed increase!) So, I realize that almost all the gap I saw was related to the the driver's overhead and function calls.
These times are acceptable, and I'll be implementing a DMA driver for large data transfers.
I think Chip_SPIM_XferFIFO() has a bug or two.
When I pass in rxCount = 0, and rxData = NULL, the driver gets stuck on this line:
while (SPI_FIFOSTAT_RXLVL(Chip_SPI_GetFIFOStatus(pSPI)) < xfer->rxCount);
If I pass in an rxData buffer and rxCount < txCount, I get a buffer overrrun.
Hi Chris,
Yes, you are right.
If you call another SPI frame, a lot of functions will be called again, so the big gap between the two frames(not between bytes in the same frame) is long, the SPI code is really a little redundancy, so if you very care about the execution time, I think you can simplify the SPI function, you can design it by yourself, don't use too many function calls.
If you don't want to receive the the SPI data, I think you can delete the receive code, it will save the code execution time.
Wish it helps you!
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
I checked by switching to IRQ based operation, no change. I tried other clock speeds, 12 MHz is the fastest, but setting it to 5 MHz gives me a true 5 MHz clock speed. Most everything else is working OK, including the USB MSC demo.
Hi Chris,
Please give me the sample code package name, I will help you to test, and check it on my side when I have time.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Kerry, did you get that code package I emailed? I still have this problem, but haven't spent any time on it.
Hi Chris,
Sorry for my later reply, I have got your code.
I have test the periph_spi_sm_poll project, this is the SPI bus:
The time is just 640 ns between bytes, it's not long.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Here's what I see. D0 is the clock - which each little burst is one byte. D1 is data, D3 is CS.
D6 is a debug pin set inside Chip_SPIM_XferHandler(), which shows that during the seven byte sequence it never exits that ISR and is just running as fast as it can.
This doesn't make much sense - each loop to process a byte is taking 5 us. Should the CPU be able to process it faster than that? I set the clkout to the main clock - it's 94 MHz.
Hmm. What is the clock frequency on that capture?
Hi Chris Pflieger,
The SPI clock baudrate is 4Mhz.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
MCPXpresso v10.0.0.2
LPC54113J256
How would I know what LPCopen version I'm using? I downloaded it within the current year...
Is it possible this is a clock issue? I'm trying to get to 30 MHz, Chip_SPIM_SetClockRate(SPI, 25); but it tops out at 12 MHz.
I pulled the code from "periph_spi_sm_poll" into my project.
Hi Chris,
Please tell me where you download the code.
You can give me the code package name, eg:
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
I believe I have either the latest – 3.01 or 3.00c.
Hi Chris,
Please tell me the LPC chip part number, and the what the lpcopen reversion you are using, also tell me your test project, I will check it on my side.
Waiting for your reply!
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------