Hi folks,
I'm wondering if anyone is running into the following problem with
rcc_periph_reset_pulse().
In my application there is a possibility for spurious clock pulses.
To remedy this, I was issuing a rcc_periph_reset_pulse() before setting
up SPI again for each receive only data frame.
However, it seems that the function as it is now does not properly reset
the SPI on STM32F103.
Using the workaround below solves the issue.
The loop count 10 below is arbitrary but I believe it needs to be at
least >1 to work reliably.
I did not find anything in the ST data sheets about the required width
of pulse.
I might be missing some other way to reset the SPI to let the receiver
recover from extra or missing pulses.
However, the behavior in itself is interesting enough to mention.
Cheers,
Tom
/* Loop based busywait (accuracy = 3 cycles). */
INLINE void hw_busywait(uint32_t nb_loops) {
__asm__("1: subs %0, %0, #1 \n" // 1 cycle
" bne 1b \n" // 2 if taken, 1 otherwise
:
: "r"(nb_loops)
: );
}
/* Peripheral reset */
#define _RCC_REG(i) MMIO32(RCC_BASE + ((i) >> 5))
#define _RCC_BIT(i) (1 << ((i) & 0x1f))
INLINE void hw_rcc_periph_reset_pulse(enum rcc_periph_rst rst) {
_RCC_REG(rst) |= _RCC_BIT(rst);
hw_busywait(10);
_RCC_REG(rst) &= ~_RCC_BIT(rst);
}
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
