In Regards to spi_master ; Raising DEV_NUM_MAX (IDFGH-11042)

[dmglogowskiOS]

Answers checklist.

• [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

We use an ESP-32-S3-WROOM-2 Module. We currently use idf version v4.4-rc1-22-gbb02481e41 however we are planning to migrate to version 5.1.1 ASAP.

This is an issue already encountered in https://github.com/espressif/esp-idf/issues/3527 , however the information in that Issue is not satisfactory to us and as stated in that issue we are opening a new one, as that issue is already marked as closed.

We require usage of up to 10 different SPI Devices on Bus 2 in the current iteration of our Project and possibly more in the future. However we are encountering the hard limit of 6 SPI Devices as set in spi_common_internal.h as DEV_NUM_MAX. We do not use CS Pins through the ESP-32 directly and provide a hardware CS Generator.

Meaning we already use -1 as the Chip Select Pin for Devices on that bus. For example: spi_device_interface_config_t deviceConfig; deviceConfig.command_bits = 8; deviceConfig.address_bits = 8; deviceConfig.dummy_bits = 0; deviceConfig.mode = 0; deviceConfig.cs_ena_pretrans = 0; deviceConfig.cs_ena_posttrans = 0; deviceConfig.clock_speed_hz = MCP_CLOCK; deviceConfig.input_delay_ns = 0; deviceConfig.spics_io_num = -1; deviceConfig.flags = 0; deviceConfig.pre_cb = NULL; deviceConfig.post_cb = NULL; deviceConfig.duty_cycle_pos = 128;

We would like to know: a) Why is this hard limit in place? b) Is raising it a larger ordeal? c) How is the (supposed) limit of SPI 3 set to 3 CS Lines? d) If we were to raise it ourselves, what are, if any, issues that might arise out of that? e) Did we misunderstand the API provided by the SPI Master Driver and usage of a Software CS?

[wanckl]

@dmglogowskiOS emmmm,,,Hello: it is right that SPI bus can mount many device, and control them by CS line, one CS line connect to one device or sensor, and you should't select more than one device at same time. the device abstract in IDF is same.

while the DEV_NUM_MAX 6 for GPSPI2 and 3 for GPSPI3 in IDF, is the peripheral hardware limitation, you configure 6 CS lines which connect to 6 devices to peripheral, the hardware will also control according CS line to contact the device when you start a transaction, you don't need to select the CS line by software. so we should let't refer to hardware condition.

But if you use additional CS generator, and set CS_PIN in device config to -1, IDF will don't know which device you are contact every time, exclude your self. and IDF also don't know what the different between so many devices but with CS_PIN are all -1.

However, I don't know how your CS generator works, but there is a way like this:

1. add only one device with CS set to `-1`
2. select one device by your CS generator
3. start a polling transaction using `spi_device_polling_transmit()`
4. transaction done, disable CS generator

It required all your devices in same SPI mode and clock freq, and can use only polling transaction. I think this way can help you! you can contact as many devices as your CS generator support!

[dmglogowskiOS]

@wanckl Thank you for the reply.

We created our own wrapping library for the spi_master driver, which handles the CS Generator, so while IDF won't be fully aware of the actual CS used, it is well controlled. Also the architecture of the CS Generator prevents any potential of multiple devices being addressed simultaneously (Although it currently isn't, yet, threadsafe but that is an issue on our radar).

Our various device types use different clock frequencies and modes, some of our devices require usage of the command/address bits whilst others don't.

What we did find is, that in our use case simply raising DEV_NUM_MAX to, for example, 32 does not cause any issues, however we dislike that solution, because it is hard to standardise without creating a fork for our own variant of idf.

However we will discuss implementing your proposed solution internally.

[wanckl]

@dmglogowskiOS great,

but FYI, although you can use software CS to break 6 or 3 hardware limitation, but there also a software limitation in the spi_bus_lock which used by SPI master driver, this one limit you can add 10 devices at maximum, in theory.

[dmglogowskiOS]

Considering that we were able to raise DEV_NUM_MAX to 32 and that we were able to communicate with 19 devices on SPI2, I do not think that there is any real software limitation caused by spi_bus_lock, I wasn't able to find any code relating to spi_bus_lock that would cause a limit of 10 devices either.

I would love to know more about how that could impact the SPI Master driver, but I doubt that there would be any actually significant impact.