Is there any plan to improve the non-DMA Driver for the SPI Interfaces or allow DMA and 4-wire to work together? If I need to transfer blocks of data back and forth in 64 byte chunks, it would be tedious. For testing purposes I would like to get a 2k read in once command, as it would let me see if there were any side effects from a sent command sequence. Perhaps a flag to say DMA on Tx or Rcv only, in the interface configuration function.
The Error message:
spi_master: check_trans_valid(808): SPI half duplex mode does not support using DMA with both MOSI and MISO phases.
Implies that there is a way to set up a transaction that is one way. But how to generate that transaction is not described.
Known Issue of DMA and SPI in 4 Wire
-
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: Known Issue of DMA and SPI in 4 Wire
Can you post how you set up that transaction?
-
- Posts: 73
- Joined: Mon Mar 09, 2020 7:36 pm
Re: Known Issue of DMA and SPI in 4 Wire
THE INIT:
THE FUNCTION:
Code: Select all
spi_device_interface_config_t MY_VSPI_IFcfg = { 1, // uint8 command_bits simply T/R:: For a write, set the first bit to 0, and for a read, set this bit to 1.
15, // uint8_t address_bits; /// Default amount of bits in address phase (0-64), used when
//``SPI_TRANS_VARIABLE_ADDR`` is not used, otherwise ignored.
0, // uint8_t dummy_bits; /// Amount of dummy bits to insert between address and data phase
0, // uint8_t mode; /// SPI mode (0-3)
0, // uint8_t duty_cycle_pos; /// Duty cycle of positive clock, in 1/256th increments (128 = 50%/50% duty). Setting
// this to 0 (=not setting it) is equivalent to setting this to 128.
0, // uint8_t cs_ena_pretrans; /// Amount of SPI bit-cycles the cs should be activated before the transmission (0-16).
// This only works on half-duplex transactions.
0, // uint8_t cs_ena_posttrans; /// Amount of SPI bit-cycles the cs should stay active after the transmission (0-16)
.clock_speed_hz=SPI_MASTER_FREQ_8M/2, // 4MHz for now < Clock speed, divisors of 80MHz, in
.input_delay_ns =0, // int input_delay_ns; Maximum data valid time of slave. The time required between SCLK and MISO
.spics_io_num = GPIO_VPIN_CS0, //int spics_io_num; ///< CS GPIO pin for this device, or -1 if not used
.flags = SPI_DEVICE_HALFDUPLEX,// uint32_t flags; ///< Bitwise OR of SPI_DEVICE_* flags, one flag for searching
.queue_size = 4, //int queue_size; Transaction queue size. This sets how many transactions can be queued using
//spi_device_queue_trans but not yet finished using spi_device_get_trans_result) at the same time
.pre_cb = ADI_spi_pre_transfer_callback, // callback pointer transaction_cb_t - empty function
.post_cb = ADI_spi_post_transfer_callback // callback pointer transaction_cb_t - empty function
};
Ret_Val = spi_bus_initialize(My_VSPI, &My_VSPI_cfg , 2 ) ; // using DMA 2 ?
Ret_Val = spi_bus_add_device(My_VSPI, VSPI_Cfg_P, &SpiDevHandle );
DMA_ATTR uint32_t DumpBlock[512];// dump buffer, 2048 bytes
Code: Select all
Spi_StreamRead( const uint16_t Address, uint8_t *Data ,const uint8_t Count )
{ // misc local variable instantiation
spi_transaction_t trans = { // local stack copy of trans structure
0, // ,
1, // command bit to SPI, 1 is MISO I believe
.addr = Address,
0, Count*8, &DummyUserVal, // Total Length, Rcv Bits, &UserVar Tx only at this time and Rx data size
.tx_buffer = (void*) 0L, // Not Used}, // tx then rcv
.rx_buffer = (void*) DumpBlock // Returned Data }
};
// Set the correct command mode, only ctrl_reg has ascending, streaming is always I guess.
Ret_Val |= byte_Spi_Send( CONTROL_REG, ASCENDING4W );// ensure the device is in Ascending 4Wire Mode
Ret_Val |= spi_device_polling_transmit( SpiDevHandle, &trans );
memcpy( Data, DumpBlock, Count); //copy from DMA Block to calling pointer,
// other cleanup and return
}
-
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: Known Issue of DMA and SPI in 4 Wire
First of all, suggest you don't mix named and unnamed initializers. Aside from technical reasons, they make my brain hurt Secondly, your total transaction length is 0, of which (count*8) are rx bits... that does not make sense. (Also, if you don't want to use an user value, just pass NULL.) Also, you send a command value of '1' which will just get ignored as you didn't specify a command length while initializing the device.
-
- Posts: 73
- Joined: Mon Mar 09, 2020 7:36 pm
Re: Known Issue of DMA and SPI in 4 Wire
I seem to see a command bits of one in the spi_device_interface_config_t declaration above. Perhaps there is another bit you think should also be set. It reflects on my Scope as the first bit out being high causing the device to transmit the register associated with the address.
I too thought that the length and receive bits should be coordinated, What my scope showed me was 32 clocks instead of 24, and the driver was reporting the last 8 clockings before the chip select came back up giving me nothing but zeros. With a length of 0 and receive 8, I get 24 clocks and the correct value returned.
I am mixing named and unnamed because your it works, other approaches gave me multiple compiler whines to start with.
You have not addressed the issue which is 4 wire, streaming, and DMA. Perhaps you can post some code which runs a 4 wire interface with a message size larger than 64 bits.
I too thought that the length and receive bits should be coordinated, What my scope showed me was 32 clocks instead of 24, and the driver was reporting the last 8 clockings before the chip select came back up giving me nothing but zeros. With a length of 0 and receive 8, I get 24 clocks and the correct value returned.
I am mixing named and unnamed because your it works, other approaches gave me multiple compiler whines to start with.
You have not addressed the issue which is 4 wire, streaming, and DMA. Perhaps you can post some code which runs a 4 wire interface with a message size larger than 64 bits.
-
- Posts: 73
- Joined: Mon Mar 09, 2020 7:36 pm
Re: Known Issue of DMA and SPI in 4 Wire
Close this issue, workaround identified
Who is online
Users browsing this forum: No registered users and 50 guests