Skip to content

BlueNRG-MS: Use non Arduino Uno pin names #14829

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.

Sign up for GitHub

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

BlueNRG-MS: Use non Arduino Uno pin names #14829

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions connectivity/drivers/ble/FEATURE_BLE/COMPONENT_BlueNRG_MS/mbed_lib.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,20 +1,20 @@
{
"name": "bluenrg_ms",
"config": {
"SPI_MOSI": "ARDUINO_UNO_SPI_MOSI",
"SPI_MISO": "ARDUINO_UNO_SPI_MISO",
"SPI_nCS": "ARDUINO_UNO_A1",
"SPI_RESET": "ARDUINO_UNO_D7",
"SPI_IRQ": "ARDUINO_UNO_A0",
"SPI_SCK": "ARDUINO_UNO_D3",
"SPI_MOSI": "D11",
Copy link
Contributor

Choose a reason for hiding this comment

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

Good point, hardcoding this to D11, how to overwrite it as this is acomponent to be used by other targets. It was chosen to be usable with arduino uno. A question is, shouldn't this be a specific config and available to be overriden by a target?

"SPI_MOSI": "MBED_CONF_BLUENRG_MOSI", etc ?

Copy link
Contributor Author

@LDong-Arm LDong-Arm Jun 24, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

This mbed_lib.json is the very place to generate MBED_CONF_..., so we shouldn't reference MBED_CONF_... in mbed_lib.json. The field target_overrides is the exact place for overriding pins per target.

In my opinion, providing defaults still makes sense. This is convenient for targets supporting a common form factor (e.g. ARDUINO_UNO) so they don't need any overrides.

"SPI_MISO": "D12",
"SPI_nCS": "A1",
"SPI_RESET": "D7",
"SPI_IRQ": "A0",
"SPI_SCK": "D3",
"valid-public-bd-address": {
"help": "Read the BD public address at startup",
"value": false
}
},
"target_overrides": {
"K64F": {
"SPI_SCK": "ARDUINO_UNO_SPI_SCK"
"SPI_SCK": "D13"
},
"DISCO_L475VG_IOT01A": {
"SPI_MOSI": "PC_12",
Expand Down