Hello,
Device/Board:
LPC54102 EVK (OM13077)
SDK:
lpc5410x_xpresso54102_keil_iar_v3.04.000 >> periph_spi_sm_int (example project)
My goal is to have SPI0 and SPI1 running simultaneously using the periph_spi_sm_int sdk example project. The reason for using this version of the SDK is because legacy code I am working with assumes the usage of these SPI drivers.
I’ve modified the periph_spi_sm_int project so both SPI0 and SPI1 are configured as masters. Again, I want to have both SPIs running simultaneously. What I mean by this is after I initiate the first SPI0 transfer I immediately initiate the SPI1 transfer. In the main loop, I use the Chip_SPIM_Xfer non-blocking function to initiate the SPI0 transfer. In the next line, I initiate the transfer for SPI1. This should in theory have both SPI transfers running simultaneously with SPI0 having a small head start. See spi_sm_int.c line 380.
From my understanding the Chip_SPIM_Xfer function is non-blocking. This would mean that two SPI peripherals should be able to transfer data simultaneously. I'm probing the SPI0 and SPI1 clock lines with an Oscope and I don't see these clocks active simultaneously.
As an experiment I did the same thing with the latest SDK spi_interrupt_b2b_transfer. I configured both SPI0 and SPI1 as masters and had them run back-to-back transfers . In this case, I did see both SPI peripherals active simultaneously.
Question:
Is there a way to get both SPIs to run simultaneously using the periph_spi_sm_int example project?
Thanks,
Ricardo
Hello Alice,
I tried importing the newer SPI driver code, namely the fsl_spi.c and fsl_spi.h files into my project which is using the older SDK libraries. There seems to be a lot of file dependencies from SDK versions. I start including files that are required to support fsl_spi.c and things get messy fast. I need to include too many files I don't see this being feasible. If you think this is feasible could you please provide the changes that are required to make this possible? Importing fsl_spi.c from the latest SDK into lpc5410x_xpresso54102_keil_iar_v3.04.000 version of the SDK.
Instead of trying to import the latest version of the SPI driver into my project perhaps we could make the older spi code non-blocking. Is there a way we could modify the older SDK spim_54102.c file to make the spi code non-blocking. Looking at the driver code it seems that the Chip_SPIM_XferHandler in spim_54102.c is blocking in the the while loop.
Hello @rhsalced
Thank you for your question.
I compared the code between the SDK and LPCopen. It seems that in the SDK driver, there is a piece of code to set the SPI state:
/* Set the SPI state to busy */
handle->state = kStatus_SPI_Busy;
You could try adding this to the LPCopen driver.
If it still doesn't work, try sending only 1 byte.
If all else fails, you can port the SDK SPI driver into your code.
BR
Alice
I'm unsure of where to add that in the LPC driver code. I do see there is a xfer->state = SPIM_XFER_STATE_BUSY; statement in the Chip_SPIM_Xferhandler function which is called from the Chip_SPIM_Xfer function. Seems like that is already in there.
I tried transfering one byte, didn't have any luck there.
The legacy code that I am working with depends on the older lpc sdk. For example, it is using older I2C driver code along with other things so I'm not sure if I could update the SPI driver and expect it to work. From my understanding you can't mismatch drivers versions. For instance, use older I2C driver, and new SPI driver in the same code base. Or is this not the right assumption?
Hello @rhsalced
Thank you for your reply.
I understand that you don't want to port the whole project to the SDK at this stage. After evaluation, in order to both retain the Lpcopen framework and achieve the simultaneous operation of SPI0 and SPI1, it is recommended that you manually port the SPI driver to LPCopen. If you meet any problems during the porting process, feel free to contact us at any time.
BR
Alice
Hello Alice,
I tried importing the newer SPI driver code, namely the fsl_spi.c and fsl_spi.h files into my project which is using the older SDK libraries. There seems to be a lot of file dependencies from SDK versions. I start including files that are required to support fsl_spi.c and things get messy fast. I need to include too many files I don't see this being feasible. If you think this is feasible could you please provide the changes that are required to make this possible? Importing fsl_spi.c from the latest SDK into lpc5410x_xpresso54102_keil_iar_v3.04.000 version of the SDK.
Instead of trying to import the latest version of the SPI driver into my project perhaps we could make the older spi code non-blocking. Is there a way we could modify the older SDK spim_54102.c file to make the spi code non-blocking. Looking at the driver code it seems that the Chip_SPIM_XferHandler in spim_54102.c is blocking in the the while loop.