Allow NC pins to be instantiated on Silicon Labs platforms

[stevew817]

Description

Allow gpio objects to be instantiated with NC on Silicon Labs targets. Although this is nowhere defined, it seems to be the de-facto standard to allow this on mbed.

Closes #7862
Closes #10191

Pull request type

[X] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

Release Notes

[ciarmcom]

@stevew817, thank you for your changes.
@ARMmbed/mbed-os-maintainers please review.

[kjbracey]

This goes further than necessary - the gpio objects have to be instantiatable with NC, so we can use gpio_is_connected on them, but the other APIs are not required to work.

If you do want to add code to intercept the "using NC" case, that's fine, if you don't mind the ROM cost, but I'd still prefer the assert was there too - easier to catch invalid uses in non-release builds than silently ignoring.

Think of gpio_t as if it was a smart pointer - by design you're allowed to set them to NULL, but actually avoiding using a NULL is on the head of the user. A smart pointer that silently swallowed and avoided SIGSEGV on use of a NULL would not be being very helpful.

The latest C++ standards are getting quite big on syntactically distinguishing "optional" values from compulsory ones - encoding "non-null" into the types. Conceivably I can see something similar happening in the Mbed OS APIs, but that would be done at the C++ DigitalIn/DigitalOut level. The target APIs should stay with the ability to encode NC in their gpio_t, to save the RAM requirement for a separate "is connected" flag in the C++ level.

I'll make a PR to update gpio_api.h to specify expected NC behaviour.

[0xc0170]

@stevew817 Please review #10489

[stevew817]

@0xc0170 reviewed.

[0xc0170]

@0xc0170 reviewed.

Thanks !

Shouldn't #10489 fix it all or will this PR be needed as well?

[stevew817]

#10489 fixed all targets except for efm32, since there was already a pr for those (this one).
So this and 10489 need to be merged simultaneously.

[kjbracey]

I don't think order of merging matters, unless we have EFM32 systems in CI, in which case this one needs to go first so that #10489's test passes.

No reason this one can't go before/without #10489.

[kjbracey]

BTW, I haven't approved this yet because still waiting for response to my previous comment.

[stevew817]

@kjbracey-arm In response to your question, I don't have an issue with the slightly increased footprint. On a develop profile, the footprint is actually reduced because of the assert removal.

I can update it once more to accommodate your remarks and move back to asserts as per your changes in #10489, if you feel that is required to approve this. Honestly, given the hard breakage that occurred with the SPI change and is already released, I had expected this to be fasttracked into a patch release.

[kjbracey]

I can update it once more to accommodate your remarks and move back to asserts as per your changes in #10489, if you feel that is required to approve this.

There are 4 permutations of the two choices "always check and ignore use of NC?" and "check and assert if NC used?" for the calls that are not valid with NC, and this is the only one of the four I'm not happy with - the one that bothers to have a check but never uses it to report that it saw the programming error.

I don't want target code that makes an active effort to conceal bugs in Mbed OS application/driver code, as it's unhelpful if someone is trying to develop portable code on that target.

The only actual fix required here is one-line removal of the MBED_ASSERT in gpio_init; if you want to also change the other calls in the same PR to put asserts there in lieu, I'm fine with that, just not this option.

[stevew817]

@kjbracey-arm this should do it, right?

[kjbracey]

Thanks! @0xc0170 can you get this in asap, as the other platforms have just had theirs merged?

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts