SPI Slave config on KL03

[Raffaele]

Hi,

is there a basic configuration to set up an SPI slave interface on the KL03?
I am able to configure an SPI master, what do I need to change for a slave?

Thanks

[mark]

Hi

See chapter 6 of https://www.utasker.com/docs/uTasker/uTasker_I2C.pdf

Regards

Mark

[Raffaele]

thanks Mark.

The guide is for I2C, but I guess I can do something similar for SPI.
Please correct me if I am wrong: I need to create a TABLE with SPI parameters, buffers, callback etc. Open the connection (fnOpen) that returns the PortID. And I need to define my callback to manage the received data.

I was expecting that part of this, such as the SPI_TABLE struct and the callback were already implemented or that I could use something similar to the SPI master config

Code: [Select]

INITIALISE_SPI_SD_INTERFACE()  POWER_UP(4, SIM_SCGC4_SPI0); \
_CONFIG_PERIPHERAL(B, 0, PB_0_SPI0_SCK); \
_CONFIG_PERIPHERAL(A, 7, (PA_7_SPI0_MOSI | PORT_SRE_FAST | PORT_DSE_HIGH)); \
_CONFIG_PERIPHERAL(A, 6, (PA_6_SPI0_MISO | PORT_PS_UP_ENABLE)); \
_CONFIG_DRIVE_PORT_OUTPUT_VALUE(A, SPI_CS1_0, SPI_CS1_0, (PORT_SRE_FAST | PORT_DSE_HIGH));\
SPI0_C1 = (SPI_C1_CPHA | SPI_C1_CPOL | SPI_C1_MSTR | SPI_C1_SPE); \
SPI0_BR = (SPI_BR_SPPR_PRE_4 | SPI_BR_SPR_DIV_2); \
(void)SPI0_S; (void)SPI0_D;

[mark]

Hi

My mistake - I don't know why I read I2C...?

If you are using the professional version there was an interrupt driven SPI driver added in 2018.

This is however not in the open source version at the moment.

There are two ways to work with the SPI - either the way that the SPI drivers do it - quite low level blocking (as you know from the init code you showed) or by reading/writing via a queued interface (a bit like UART). The difficulty in slave mode is however than one doesn't know when the master will be doing transfers and so interrupt driven is generally more suitable.

I have attached the files that are missing from the OS version at the moment, which allows the second method. It has been used for DSPI SPI types and prepared for SPI and LPSPI but I don't remember whether it has been used/completely verified. In any case it should give a decent starting point in the worst case.

driver.h includes the updated SPI parameter struct that is passed when opening the interface

// SPI table structure used to configure an SPI interface
//
typedef struct stSPITABLE {
    unsigned char  ucSpeed;                                              // SPI speed (set fixed defines) - 0 for slave
    QUEUE_DIMENSIONS Rx_tx_sizes;                                        // the desired rx and tx queue sizes
    UTASK_TASK     Task_to_wake;                                         // default task to wake when receive message available
    QUEUE_HANDLE   Channel;                                              // physical channel number 1,2,3...
    unsigned char  Config;                                               // mode details
    unsigned char  ucWordWidth;
    unsigned char  ucChipSelect;
} SPITABLE;

and possibly some new flags too (to use as reference and probably not replace).

SPI_drv.c is the generic interface which handles the open, read, write [it is located in the uTasker directory and needs to be added to a project]
kinetis_SPI.h is the low level driver (it must be included in kinetis.c using

#if defined SPI_INTERFACE
/* =================================================================== */
/*                            SPI Interface                            */
/* =================================================================== */
    #include "kinetis_SPI.h"                                             // include SPI hardware driver code
#endif

and SPI_INTERFACE define needs to be enabled for the operation to be made available.

I don't find any documentation prepared for this driver but it is very similar to the UART interface whereby the SPI slave's owner task is woken whenever it receives data from a master and the task can then read the data from its input buffer. The slave can also write data to its output buffer which are subsequently read by a master when it sends/receives.

Tell me if this helps you come further.

Regards

Mark

[Raffaele]

Thank you Mark.

The structure is similar to what I thought, so this is very helpful. I worked with UART, as you might remember from my other posts, so this makes makes sense to me. I'll try it