Issues with multiple mode QSPI devices using mfc52223 and spi_pol_mcf5xxx_qspi.c

[drkhes]

I have encountered a weakness in the bsp architecture when using multiple kinds of modes in spi devices. The basic issue is this, in the initialization for spi devices in init_spi.c one passes in clock phase and polarity through the MCF5XXX_QSPI_INIT_STRUCT structure. If you have two devices with different phase/polarity, the you must reset the mode with an ioctl before each read/write ioctl. One must do this because the last phase/polarity set is what is used, not what a specfic device is configured with. This also is true of baud rate if my code reading is correct. In addition, it would be nice if the FRAMESIZE was added to the MCF5XXX_QSPI_INIT_STRUCT so that it could be stored and used.  

An application in theory could in one task could set the phase/polarity, be swapped out, have another task set phase/polarity, be swapped out, then have the first task swap back in and send its data with the incorrect settings. Even without the task switching issues, it is combersome to have to always set the phase/polarity before each read/write operation.

I have modified my spi_pol_mcf5xxx_qspi.c function _mcf5xxx_qspi_polled_tx_rx() to explicitly call the ioctl to set mode and baud IO_IOCTL_SPI_SET_MODE and IO_IOCTL_SPI_SET_BAUD before transmitting.

Around line 668 I added

if ( SPI_OK != _mcf5xxx_qspi_polled_ioctl( io_info_ptr, IO_IOCTL_SPI_SET_MODE, &io_info_ptr->INIT.CLOCK_POL_PHASE, 0 ) )
        return 0;
if ( SPI_OK != _mcf5xxx_qspi_polled_ioctl( io_info_ptr, IO_IOCTL_SPI_SET_BAUD, &io_info_ptr->INIT.BAUD_RATE, 0 ) )
        return 0;

If the FRAMESIZE was stored, I would set it here also.

Donald

M8R-jw5952 at mailinator dot com

[PetrM]

This is the reason why the spi driver cannot be opened multiple times simultaneously (in several tasks).

It is low level driver, it should be used in one (spi communication) task only and this task should manage multiple connections/protocols/stacks for the other tasks.

The initialization structure contains just default settings, in multiple device mode it's practically useless. But you're right, it may be extended by other parameters.

Your modification is specific for your use case, the driver should stay universal - as you wrote, you can call the right IOCTL command anytime you want.

PetrM

[drkhes]

Well that is just unacceptable. It can be better. I have already re-written the low level driver to support multiple types of spi devices. I don't believe it is yet task safe, but it will be when I am done.

This is not the correct way to represent a device as you have attempted to in this mqx/bsp environment. If you want to design the abstraction between the application and device with file handles, one better be able to use a file handle without regards to other operations in the system.  One must not be limited to using those file handles in a single thread/task because they are all on the same bus and require extra ioctl calls because some other part of the application last used the bus.

This is weak design. Full of holes. My evaluation of this system is not good.