Add API to set the SPI_USR_DUMMY_IDLE bit in the SPI_USER_REG (IDFGH-12205)

[sfzhi]

Is your feature request related to a problem?

In some cases it is useful to suppress SPI clock during the dummy phase of a transaction. The SPI hardware supports that, but ESP-IDF does not seem to have an easy way to use that functionality.

Describe the solution you'd like.

Add a new flag named SPI_DEVICE_DUMMY_IDLE to driver/spi_master.h and make sure it is used to set the SPI_USR_DUMMY_IDLE bit in the SPI_USER_REG of ESP32 when setting up an SPI device transaction.

Describe alternatives you've considered.

It is possible to set user.usr_dummy_idle in spi_dev_t directly by installing a pre-transaction callback, but that is cumbersome and inconsistent with how other transaction properties are applied.

Additional context.

No response

[wanckl]

@sfzhi Hi~ Thank you for report, but may I know your case why you need this DUMMY_IDLE, generally if without clock output, slave side don't know what happen with master side.

Or another way you can simply configure cmd+addr phases and data as 2 independent transactions. it just a bit slower than DUMMY_IDLE way.

will be very helpful if you can have a description on your cases! waiting for your reply~

[sfzhi]

Many PIC16 microcontrollers (and possibly others) have programming interface (intentionally) compatible with SPI. For example: PIC16(L)F153XX Memory Programming Specification (pdf). They require a delay before the data phase, which is easily implemented with dummy cycles without clock.

Of course, there are multiple ways to achieve the same result, but why jump through hoops when the hardware is capable of doing exactly what is needed?

[wanckl]

@sfzhi Great application,

Then is every transaction with this device (PIC16) need this DUMMY_IDLE?
Or for example do you need switch on/off DUMMY_IDLE for different transactions of this device?
It will decide this is a device or transaction level flag

[sfzhi]

As far as I know, the delay is always required. Besides, it would be harmless to have it even when it's not needed. So I think a device-level flag would be sufficient.