2018-02-22 03:12 AM
Hello.,
I am working on STM32F7 Micro controller , In that I need SPI interface with more then 16 bit data size . As per SPI device requirement the SPI Chip select needs to be active low for more then 16 bit data size. Presently I am operating CS pin by using GPIO pin. But in this case I can't use DMA .
Is there any possible ways to get more then 16 bit data size.?
I have attached the SPI bus cycle requirement of the device.
#armc7 #spi #stm32f72018-02-22 08:44 AM
Not sure why DMA would preclude you from using CS as a GPIO pin. The point of DMA for a 34-bit sequence seems questionable.
34 isn't divisible into units the the SPI uses. You could drive the GPIO via a pattern buffer, using DMA+TIM to drive outputs.
Are you reading back data here? What are the speed requirements here?
2018-02-23 11:14 PM
Hello Clive.,.,
I have more then 8 SPI interfaced devices , so if I use GPIO line as CS it takes more time to access each devices (including GPIO oscillation time ), that's why to avoid this and to increase the access speed I should have to use SPI_NSS , So is there any possible ways to get SPI data size as more then 16bit .
2018-02-24 08:07 AM
The STM32 SPI implementation historically has been a bit brain-damaged, for it to drive SPI_NSS automatically you have to disable the SPI at the end of a transaction, it is not particularly 'automatic' in a sense that most peripherals need it to be.
If your device (unspecified) is tolerant of clocks/data beyond 34-bits (also a brain-damage choice) you could send a multiple of 8-bits (say 40-bits).
The other alternative is to make a more custom CPLD/FPGA and attach that as an FSMC/FMC peripheral that can generate more specialized patterns.
With the DMA pattern buffer to GPIO you can drive up to 16 pins at once. If you used a common CS and CLK for the SPI devices you could blast 8-bit wide data (1 bit to each device) with 10 pins.
If you have GPIO oscillation issues consider dropping the slew-rate to some more appropriate pin speed vs trace length setting.