BlueNRG-MS: Use non Arduino Uno pin names

[LDong-Arm]

Summary of changes

The Arduino Uno pin aliases in hal/PinNameAliases.h are now guarded by the macro TARGET_FF_ARDUINO_UNO (since 7c333d8) and not globally available anymore. This results in the following error (and similar ones) when building the driver for K64F:

error: 'ARDUINO_UNO_SPI_MOSI' was not declared in this scope

To fix it, replace the aliases with their raw pin names. Now the pins are identical to BlueNRG-2.

Impact of changes

Migration actions required

Documentation

None

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[x] Tests / results supplied as part of this PR

Manual testing: compile mbed-os-example-ble/BLE_Advertising for K64F.

---

Reviewers

@ARMmbed/mbed-os-connectivity

---

[jeromecoutant]

I think you should correct K64F...

@MarceloSalazar

[0xc0170]

Why then BlueNRG2 uses D/A pin names? What is the difference ?

    "name": "bluenrg_2",
    "config": {
        "SPI_MOSI":  "D11",
        "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
        }
    },

The Arduino Uno pin aliases in hal/PinNameAliases.h are now guarded by the macro TARGET_FF_ARDUINO_UNO (since 7c333d8) and not globally available.

Were they available for K64F? I don't see ARDUINO_UNO supported by K64F, only ARDUINO .

[LDong-Arm]

I think you should correct K64F...

@MarceloSalazar

@jeromecoutant Do you mean use Arduino pins by default, and override K64F to not use it? Or enable ARDUINO_UNO for K64F?

@ARMmbed/mbed-os-hal We have two form factors in targets.json - ARDUINO and ARDUINO_UNO. Arduino has the former, thus Uno pins are not available. Are they the same?

[0xc0170]

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 ?

[LDong-Arm]

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.

[LDong-Arm]

Why then BlueNRG2 uses D/A pin names? What is the difference ?

This is a question for @apalmieriGH and @ARMmbed/mbed-os-connectivity who added BlueNRG 2 support.

Were they available for K64F? I don't see ARDUINO_UNO supported by K64F, only ARDUINO .

As per my inline comment, the Uno pins were available (probably by mistake to both ARDUINO_UNO and ARDUINO form factors, before 7c333d8.

[MarceloSalazar]

K64F needs to migrate to the standard Arduino Uno pin names - see docs

ARDUINO is the legacy (deprecated). ARDUINO_UNO is the supported one.

[LDong-Arm]

K64F needs to migrate to the standard Arduino Uno pin names - see docs

ARDUINO is the legacy (deprecated). ARDUINO_UNO is the supported one.

Thanks for clarification. I think the fix would then be migrating K64F to ARDUINO_UNO. Is that easy to do?

I'm closing this PR, but until it's fixed this issue blocks Travis CI of mbed-tools.
Additionally, it would be good to switch to ARDUINO_UNO pins for BlueNRG-2 too.