Does a task "own" the SPI interface?

[davepfaltzgraff]

The background is that I'm writing code for the FRDM-K22F under KDS with KSDK and MQX. I used the example found in C:\Freescale\KSDK_1.2.0\rtos\mqx\mqx\examples\dspi\build\kds and wrote a task that initializes the SPI1 interface. By itself, the code works as expected.

However, I have another task that attempts to write to the SPI interface, it always returns the busy status (error code 4). While the original task seems to be able to write anything, I have tried various combinations in the second task and always get the same result.

This leads me to ask: Is the SPI interface "owned" by the task that initializes it? This would make sense in that it would appear busy to all other tasks, but I am not sure of the inner workings of MQX.

If this is the case, what is the easiest (laziest) way to share the interface? In this design, the SPI interface is used to output two bytes to a set of shift registers that drive the LEDs on a front panel. It is output only from the processor.

Thanks

[davepfaltzgraff · Accepted solution]

I really hate solving my own problems! But, oh well,...

It does not appear that the SPI interface is "owned" as I implied. However, the structures defining the interface must be permanent in memory. In my code, the structures were locally defined by the init routine and thus on the local stack. Once the initialization routine exited, that memory was freed up for other uses.

My moving the declaration for:

dspi_master_user_config_t userConfig;

dspi_device_t spiDevice;

dspi_master_state_t dspiMasterState;

outside the scope of the initialization routine, they become fixed in memory and now the interface works as desired. (Note: Unless explicitly declared static, they will have global scope which may or may not be desirable. This depends on your coding style.)

In the example mentioned in the original post, these were defined at the top level of the task and thus remained in the task's stack area. So, any routine running under this task would have access to the variables. However, tasks running with a different stack would not.

[soledad]

Hello David,

Thanks for your input, I'm sure that this information will be useful to other users.

Regards

Soledad