Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers/cc110x: Fix SPI communication on STM32F4 boards #9230

Closed
wants to merge 2 commits into from

Conversation

maribu
Copy link
Member

@maribu maribu commented May 29, 2018

This PR implements the first variant of how to fix issue #9225. Please follow the discussion in the issue before merging, as there is an alternative way to fix the issue.

@aabadie
Copy link
Contributor

aabadie commented May 29, 2018

I think I prefer this solution over variant 2, it's less intrusive.

@@ -53,6 +53,10 @@ void cc110x_cs(cc110x_t *dev)
/* Switch MISO/GDO1 to GPIO input mode */
#ifndef GPIO_READS_SPI_PINS
gpio_init(dev->params.gdo1, GPIO_IN);
#endif
#ifdef CC110X_PARAM_GDO1_AF
/* Reconfigure MISO/GDO1 to be used as regulare GPIO */
Copy link
Contributor

Choose a reason for hiding this comment

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

s/regulare/regular/ ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done :-)

The GDO1/MISO needs to be used as GPIO input in `cc110x_cs()`. On some boards,
a call to `gpio_init_af()` is required. This commit allows to `#define`
`CC110X_PARAM_GDO1_AF` to enable both the call to `gpio_init_af()` and set the
value to pass to `gpio_int_af()`. If `CC110X_PARAM_GDO1_AF` is not defined in
`board.h`, the behaviour remains unchanged.
This fixes communication issues with the CC1101 transceiver, as the board can
now determine reliably when the transceiver is ready.
@maribu
Copy link
Member Author

maribu commented May 29, 2018

I think I prefer this solution over variant 2, it's less intrusive.

This is true. But on the other hand a user of gpio_init() easily expects the GPIO to be usable as a GPIO after that call no matter how the pin was configured before. So similar issues could occur elsewhere.

@maribu maribu mentioned this pull request May 29, 2018
@vincent-d
Copy link
Member

I personally prefer #9231. Even though this might be debatable, I agree with @maribu that gpio_init() should leave the GPIO usable as-is as a GPIO.

And this PR look more a workaround and uses stm32 specific code where it should be no cpu-specific code (gpio_init_af is cpu-specific).

@maribu
Copy link
Member Author

maribu commented May 29, 2018

In any case it seems to be good idea to add a warning to the documentation of gpio_init(): Either that a call to gpio_init_af() depending on CPU and prior pin usage might be required as well, or that gpio_init() undos any previous gpio_init_af() calls on the same pin on STM32 CPUs.

@maribu
Copy link
Member Author

maribu commented May 30, 2018

This does not solve the problem :-(

@maribu maribu closed this Jun 4, 2018
@maribu maribu deleted the cc110x-fix-variant1 branch June 17, 2018 13:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants