#define DSPI_DUMMY_DATA (0x00U) /*!< Dummy data used for Tx if there is no txData. */
Target
K64F
Steps to reproduce
Run SD card block read/write test with SD driver version : sd-driver-0.1.0-mbed-os-5.5.1
@geky @c1728p9
I would use 0xFF as default value, also used by SPI async transfers, we could use that value - SPI_FILL_WORD by default. This would also be used if we extend API by being able to set this fill world, that was already discussed earlier that it would be nice to have.
cc @mmahadevan108
Please fix ASAP to an mbed OS 5.5.x patch release.
@0xc0170 - We can use same API "spi.dummy" as mentioned in PR #4744 for async transfers as well. At present changes are done just for "spi_master_block_write" HAL API, I would prefer changes in async transfer as new pull request.
Internally IOTMORF-1080
cc @mmahadevan108
@deepikabhavnani
There is a new API available in the MCUXpresso SPI driver to set the dummy data.
void DSPI_SetDummyData(SPI_Type *base, uint8_t dummyData)
I will update the DSPI driver. Could you please update the K64F SPI driver to use this API as part of PR #4744
@mmahadevan108 - I believe DSPI_MasterTransferBlocking() API in block write will boost the performance right? Is it applicable to just K64F or other K series targets as well?
If change is required for all kinetis devices, I would prefer new PR. I will just need list of devices and support for all of them to have consistent behavior.
I will create a separate PR to update the Kinetis SPI drivers to include an API to update the DUMMY_DATA variable.
However I am not clear where this API should be invoked from inside mbed.
@mmahadevan108 : After you add API to DSPI driver, I can update mbed-os code in same PR. If that is fine for you.
PR for updating K64F DSPI driver is https://github.com/ARMmbed/mbed-os/pull/4805
I will work to update the other Kinetis platforms separately.