DSPI Driver Usage for Kinetis processors (FRDM-K64F)

[jmueckl]

I am looking for an up to date application note similar to the one titled "KSDK SPI Master-Slave with FRDM-K64F" which is a few years old.  The example code in this app note is different from the code I have studied in the latest SDK Examples.  While this app note is a good place to start, I'm not understanding some of the concepts that have been introduced into the SDK examples.  Please provide any documentation or software forum information that might help me fill in the gaps. 

[FelipeGarcia]

Hi,

Please check the MCUXpresso SDK API Reference Manual. Where you can find all the API descriptions and functionality of our SDK.

MCUXpresso SDK API Reference Manual: DSPI: Serial Peripheral Interface Driver

Hope it helps!

Best regards,

Felipe

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored. Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

------------------------------------------------------------------------------ 

[jmueckl]

I have seen this document, but it doesn't provide the information I need to address the following issue.

I want to read and write one or two bytes of SPI data at a time to my single slave device, the MAX31865. I was expecting to be able to use SPI0 on the FRDM-K64F and to connect it directly to the MAX slave.  But I don't see an SDK DSPI example that I can use for that case. 

Example FRDMK64F_dspi_interrupt requires two SPI instances (SPI0 & SPI1), and to connect the pins of SPI0 to SPI1.  What advantage does using two SPI instances have over that of one, assuming that it works?  I'm not sure that I even need an interrupt driven protocol. Speed is not that much a concern.

[FelipeGarcia]

Hi,

dspi_interrupt example enables two instances of DSPI so the user can interconnect master and slave within the same board, this is done for demonstration purposes only. Please see the following description from the readme file of this example.

In this example , one dspi instance used as DSPI master and another dspi instance used as DSPI slave in the same board. This example does not use the transactional API in DSPI driver. It's a demonstration that how to use the interrupt in KSDK driver.

You can absolutely use this example as base for your project, you can leave only master enabled and comment out slave initialization to communicate with your device as wished.

Best regards,

Felipe

[jmueckl]

Wouldn't I also need to remove the slave instance portion of the IRQ_Handler as well?

After my last post, I found the SDK example frdmk64f_dspi_interrupt_b2b_master.  It would allow me to connect the slave board directly to the master board without a second instance.  What are the advantages and disadvantages between these two techniques?  It would be great if NXP could write an app note on these kinds of issues.

[FelipeGarcia]

Hi,

Yes, if you do not need the slave instance you can remove all the slave related code.

The difference between dspi_interrupt and dspi_interrupt_b2b_master is that the first one enables two instances to communicate master-slave within the same board and B2B example needs two boards, one used as master and another one used as slave.

Best regards,

Felipe

[jmueckl]

I have seen this document, but it doesn't provide the information I need to address the following issue.

I want to read and write one or two bytes of SPI data at a time to my single slave device, the MAX31865. I was expecting to be able to use SPI0 on the FRDM-K64F and to connect it directly to the MAX slave.  But I don't see an SDK DSPI example that I can use for that case. 

Example FRDMK64F_dspi_interrupt requires two SPI instances (SPI0 & SPI1), and to connect the pins of SPI0 to SPI1.  What advantage does using two SPI instances have over that of one, assuming that it works?  I'm not sure that I even need an interrupt driven protocol. Speed is not that much a concern.