Skip to content

add the STM32WL SUGGHZSPI to the SPI library #1803

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

Closed
wants to merge 1 commit into from
Closed

add the STM32WL SUGGHZSPI to the SPI library #1803

wants to merge 1 commit into from

Conversation

majbthrd
Copy link
Contributor

The raison d'être for the STM32WL series is its internal SUBGHZSPI peripheral. SUBGHZSPI may have its own chapter in the Reference Manual separate from other SPI peripherals, but SUBGHZSPI is identical in operation to other SPI peripherals:

#define SUBGHZSPI               ((SPI_TypeDef *) SUBGHZSPI_BASE)

However, despite this, the SPI implementation of Arduino_Core_STM32 does not presently support SUBGHZSPI. This PR tweaks the existing implementation to make this possible.

The Arduino Way (tm) of implementing SPI is to insist that the user provides the pin names of the peripheral. Using a database of all possible peripherals stored as part of the firmware, Arduino then evaluates these at run time to map them back to the peripheral. (Chacun à son goût)

To make that method work with SUBGHZSPI, this PR creates three virtual digital pins: SUBGHZSPI_MOSI, SUBGHZSPI_MISO, and SUBGHZSPI_SCLK. These pins are added to the pin databases for the STM32WL variants.

The only difference between SUBGHZSPI and other SPI peripherals is that its pins are hard-wired to the internal peripheral, rather than using the GPIO Alternate Function multiplexer. This condition is signaled by having the "int function" member of the PinMap struct be negative. Then, .libraries/SrcWrapper/src/stm32/pinmap.c detects this in pin_function() and omits the inappropriate GPIO AF code.

@fpistm
Copy link
Member

fpistm commented Aug 30, 2022

Hi @majbthrd
Thanks for this PR.
We are currently working on LoRa support internally.
As a first feedback of this PR is it change file generated automatically and also add support in the pinmap of "virtual" port and pins. I don't think it is the good way.

@fpistm fpistm added enhancement New feature or request abandoned No more work on this labels Sep 28, 2022
@fpistm
Copy link
Member

fpistm commented Sep 29, 2022

Hi @majbthrd,

I've made a new PR based on your one.
See #1839 so I close this one.

@fpistm fpistm closed this Sep 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abandoned No more work on this enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants