2016-11-27 02:40 PM
I'm using F3 and L4 processors and have a few spi questions
1) In half-duplex mode, how do you receive a single byte with a master ? two bytes ? It appears from reading that in this case, the SPI clock runs as long as one is in receive mode which begs the question -- how do you reliable stop on a byte boundary ? This sounds like a designed in race condition.2) Can you change the data size while the SPI is enabled (but not in the middle of communicating) ?2016-11-27 03:06 PM
/* In master RX mode the clock is automaticaly generated on the SPI enable.
So to guarantee the clock generation for only one data, the clock must be
disabled after the first bit and before the latest bit */
__HAL_SPI_ENABLE(&SpiHandle);
__asm(''dsb\n'');
__asm(''dsb\n'');
__asm(''dsb\n'');
__asm(''dsb\n'');
__HAL_SPI_DISABLE(&SpiHandle);
You can see what I mean about a race condition. If this is the only way, I have to assume this mode is useless. Suppose I eat the extra pin and loop the Master MOSI back to the master MISO -- then I have to enable/disable the MOSI pin when I want to transmit/receive. Do I do this just by changing the pin mode from Alternative to Input ? Do I need to disable the spi device while I do this ?2016-12-11 04:54 AM
enabling/disabling a peripheral clock should be avoided.
First step would be to short MISO with MOSI and make a FW that disables MOSI (sometime with a serial resistor between the SPI devices). (flip the alternate MODE bit while SPI is not BUSY should work)
If the SPI Slave is another MCU, try a protocol by adding a turnaround dummy byte between write and read timings to transition smoothly between inputs/outputs on both side.
4 wire SPI is more voltage shifting friendly and as such, is my preffered configuration.
Hope this helps!
2017-04-30 05:01 PM
Seb, Geoffrey, is it possible for you to explain to a newbie what those comments and dsp instruction mean?
/* In master RX mode the clock is automaticaly generated on the SPI enable.
So to guarantee the clock generation for only one data, the clock must be
disabled after the first bit and before the latest bit */
I also ran into this in STCube sample code and am confused about what it means and why it's there. Indeed, this forms the inner loop of a multibyte SPI read-- why is a loop being used at all instead of RxXferSize=n?
Thanks!
Allan
2017-04-30 05:08 PM
DSB is a 'fencing' instruction, it ensures the write-buffers clear out to their destination.
2017-04-30 05:13 PM
Clive, thank you. Why are there 4 (or sometimes 2) fencing instructions? Why is the SPI read in the sample code done 1 byte at a time rather than n bytes?
Allan
2017-04-30 06:48 PM
The thread lacks sufficient context for me to be certain, you'd have to ask the geniuses behind the HAL library exactly what their thoughts were.
The architecture is pipelined, with a deferred write buffer, when on a slower APB this can take 4 or more cycles to vacate. My expectation is the DSB tends to stall the pipeline where as a NOP wouldn't, as such it introduces a longer minimum time between the enable and disable.
When enabling APB/AHB peripherals via their RCC register there is an errata/hazard related to accessing peripheral registers immediately after the clock is turned on which can be avoided by making sure the write buffers clear and the peripheral let to clock for a few cycles.
In most cases I'm aware of the SPI Master generates 8 or 16 clocks when a byte or word is written into the data register. The purpose of generating a single clock is not clear to me.
2017-04-30 06:53 PM
Clive, thank you. Why are there 4 (or sometimes2) fencing instructions? Why is the SPI read in the sample code done 1 byte at a time rather than n bytes?
Here, they function just as a delay. I guess there's some time between enabling SPI in some of the 'clock-autogenerate' mode and actually starting that clock.
https://community.st.com/0D50X00009XkaBgSAJ
JW
2017-04-30 07:00 PM
I'm still like WTF?
2017-04-30 07:00 PM
Thanks Clive!
Maybe one of the HAL geniuses will notice the thread and explain!!
Allan