Need advise on SPI CS line control

[mbutura]

I have the an chip, the LoRa SX1301 that has a mode called burst mode, this allows the SPI host to read and write to several addresses as the SPI slave auto-increments the addresses internally. This avoids explicitly sending the address in subsequent transactions. The only requirement is that the CS line be held low throughout. An example write from SPI master with CS held low throughout:

<[7]READ/WRITE BIT><[6:0]ADDRESS><7:0 ADDRESS DATA><7:0 (ADDRESS+1) DATA><7:0(ADDRESS+2)><CONTINUES...>

I have implemented the data transfer but the CS line keeps toggling between transactions therefore I need a way to manually control the hardware CS line(if possible) in a way that allows me to adhere to the above. Any advise on how I could do this is appreciated.

I am currently going through the driver code but I post this here in order to cover more ground quickly. Thank you.

[loboris]

You can configure spi_master not to use CS, just set spics_io_num=-1

Code: Select all

    spi_device_interface_config_t devcfg={
        .clock_speed_hz=10*1000*1000,           //Clock out at 10 MHz
        .mode=0,                                //SPI mode 0
        .spics_io_num=-1,                       //CS pin
        .queue_size=7,                          //We want to be able to queue 7 transactions at a time
        .pre_cb=lcd_spi_pre_transfer_callback,  //Specify pre-transfer callback to handle D/C line
    };

Then you can activate CS gpio before the first transaction, and deactivate it after the last.

[ESP_krzychb]

I have implemented the data transfer but the CS line keeps toggling between transactions therefore I need a way to manually control the hardware CS line(if possible) in a way that allows me to adhere to the above. Any advise on how I could do this is appreciated.

Hi mbutura,

I believe I had a similar use case and the solution was to use standard functionality of the spi master API. Maybe this is your case as well.

To prevent the CS line toggling and receive multiple data from a salve able to auto increment addresses, you need to specify '.rxlength' equal to the total number of bits expected to receive.

Example code - https://github.com/krzychb/esp-lis35de/ ... 5de.c#L223
Example waveform with CS line held low throughout - https://github.com/krzychb/esp-lis35de# ... ransaction

[mbutura]

Hi all,

Thank you very much for your suggestions. For a bit of background info for anyone in future refferring to this. I previously would have the data and commands in a single buffer. with the command phase and address phase of the specific transaction unset.

I therefore can see that there are two solutions in the fore here:

1. Use the hardware CS and specify the lengths(Rx or Tx). I think this is a very good solution since I need the hardware CS in order to provide strict timing requirements on the bus. Since the max payload is smaller than the max allowed on the bus for DMA per transaction(4096). This will suffice. I just have to split my message into the various transaction phases and set the cmd/addr field in the transaction.

2. Use a software controlled CS pin. This is an even simpler solution if the cmd, address and data is in a single buffer. The only thing that would vary is timings based on the software load.

Thank you all for the help.

[ESP_Sprite]

FWIW, on initialization of the SPI bus, you can specify the maximum amount of bytes for DMA transfers in max_transfer_sz in the struct you pass to spi_bus_initialize. This way, you can raise the 4094-byte limit you encountered.

[mbutura]

FWIW, on initialization of the SPI bus, you can specify the maximum amount of bytes for DMA transfers in max_transfer_sz in the struct you pass to spi_bus_initialize. This way, you can raise the 4094-byte limit you encountered.

Thanks for this Sprite.

[ESP_krzychb]

In this example I am setting .max_transfer_sz = 4736 and it works out-of box / without any additional code. I really like this driver