Skip to content
This repository has been archived by the owner on Dec 19, 2018. It is now read-only.

Fix SPI blocking problem #1

Conversation

austinglaser
Copy link
Contributor

The SPI peripheral's receive FIFO threshold was too high -- it expected two bytes, but only one was transferred before blocking. I've fixed that issue.

Going forward, stm32f30x-hal is a better reference than the f103 for the SPI peripheral on the f0x2 devices.

See the commit messages for more detailed explanations.

PB2 does not have any SPI1 alternate functions. However, PB3 has
SPI1_SCK as it's alternate function 0. This uses PB3 correctly.

Fixes 98227f2 ("Added SPI code and an APA102C example")

Signed-off-by: Austin Glaser <austin.glaser@gmail.com>
The SPI peripheral on the STM32F0x2 has a configurable FIFO threshold
(it can be either 8 or 16 bit, with the FIFO capacity being 32 bits).
This threshold is controlled by the `FRXTH` bit in the `CR2` register
(reference manual, pp 804).

When using the default blocking implementation, the driver will write
and the read bytes alternately. When the FIFO threshold is too high, the
`RXNE` bit is not set after the first word -- and the driver blocks
indefinitely.

The presence of the FIFO suggests the possibility of a more efficient,
non-default blocking implementation, which uses the FIFO to help pack
transfers together more tightly and hence achieve a higher throughput.

Fixes 98227f2 ("Added SPI code and an APA102C example")
Signed-off-by: Austin Glaser <austin.glaser@gmail.com>
Copy link
Owner

@therealprof therealprof left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I'll need to verify with the hardware that the nb::WouldBlock doesn't cause a problem for me anymore.

@therealprof therealprof merged commit 5869c5d into therealprof:features/half-assed-spi Mar 21, 2018
@austinglaser
Copy link
Contributor Author

Looks good. I'll need to verify with the hardware that the nb::WouldBlock doesn't cause a problem for me anymore.

I should hope so!

I've got some more improvements to this particular driver I'm contemplating, including a non-default blocking implementation. Would you be open to merging another pull request some time in the next couple weeks?

@therealprof
Copy link
Owner

Absolutely, keep 'em coming!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants