Fix CY8CPROTO_062_4343W baremetal build

[hugueskamba]

Summary of changes

Make a Mbed library with Cypress WHD files so it is automatically excluded when building with the bare metal profile. Create another Mbed library to group network files that use WHD so they can also be excluded from the bare metal profile.

Impact of changes

It is now possible to build the CY8CPROTO_062_4343W target with the baremetal profile.
i.e It is now possible to build mbed-os-example-blinky-baremetal with $ mbed compile -t <TOOLCHAIN> -m CY8CPROTO_062_4343W

Migration actions required

Documentation

---

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)
[] Tests / results supplied as part of this PR

---

Reviewers

@evedon @bulislaw

---

[vmedcy]

It is not valid to add Mbed-specific macros to cy_network_buffer.c and cybsp_wifi.c, this is common code shared across multiple ecosystems:

https://github.com/cypresssemiconductorco/wifi-mw-core/blob/master/lwip-whd-port/cy_network_buffer.c

https://github.com/cypresssemiconductorco/amazon-freertos/blob/master/vendors/cypress/psoc6/common/cy_network_buffer.c

[hugueskamba]

The problem is that both modules pull in WHD which depends on RTOS functionality. RTOS is not present with the bare metal profile. Adding the mbed_lib.json file allows all files in targets/TARGET_Cypress/TARGET_PSOC6/COMPONENT_WHD to not be included for the bare metal profile.

The alternative was to add #if MBED_CONF_RTOS_PRESENT to all the files in the targets directory that are dependent on RTOS functionality as I have shown here. I opted for the present PR as there are less file changes.

[hugueskamba]

I have made changes to address the comment here.

[vmedcy]

Why is this needed? https://github.com/ARMmbed/mbed-os/tree/master/targets/TARGET_Cypress/TARGET_PSOC6/psoc6csp/abstraction/rtos/source/COMPONENT_RTX is included by targets.json (https://github.com/ARMmbed/mbed-os/blob/d78e009/targets/targets.json#L13425)

[hugueskamba]

The baremetal configuration does not have an RTOS. This Mbed library file has been added to make all files in targets/TARGET_Cypress/TARGET_PSOC6/psoc6csp/abstraction/rtos part of a new library called cy_pscoc6csp_rtos. With this, I am able to to exclude all files in this directory when building with the bare metal profile.

The alternative was to add #if MBED_CONF_RTOS_PRESENT to all the files in that directory that are dependent on RTOS functionality as I have shown here.

Although the target supports all kinds of functionalities (specified in targets/targets/json) not all functionalities are available when building with the bare metal profile.

[ciarmcom]

@hugueskamba, thank you for your changes.
@maclobdell @bulislaw @evedon @ARMmbed/mbed-os-maintainers please review.

[hugueskamba]

This force-push removes the changes made to Cypress files (in response to this comment). Instead the files that are dependent on RTOS are moved and used to create a new library that is automatically excluded when building with the bare metal profile.

[0xc0170]

To summarize - baremetal ignores whd, rtos and common network component and building full Mbed OS will include them, correct? This is important detail - we should cover this in our design guide (I dont recall seeing it there, is it there?).

@ARMmbed/team-cypress Please review

[hugueskamba]

To summarize - baremetal ignores whd, rtos and common network component and building full Mbed OS will include them, correct?

Yes. The PR CI tests should demonstrate that building with full Mbed OS works fine.

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

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

[maclobdell]

@ARMmbed/team-cypress please review. this should be gated by your approval.

[kyle-cypress]

I'm not too familiar with the bare metal profile and it's not clear from https://os.mbed.com/docs/mbed-os/v5.15/reference/mbed-os-bare-metal.html how you can change the components, macros etc when building under that profile. But I'm assuming that there is some fairly flexible mechanism given that Cypress-specific macro values and library names have been proposed in this PR.
Based on that premise, I believe that the undesired code can be disabled almost entirely using pre-existing mechanisms (the change in mbed_overrides.c is still required):

1. Remove the components WHD and RTX
2. Remove the CYBSP_WIFI_CAPABLE macro (it is currently defined in targets.json)

[hugueskamba]

I'm not too familiar with the bare metal profile and it's not clear from https://os.mbed.com/docs/mbed-os/v5.15/reference/mbed-os-bare-metal.html how you can change the components, macros etc when building under that profile. But I'm assuming that there is some fairly flexible mechanism given that Cypress-specific macro values and library names have been proposed in this PR.
Based on that premise, I believe that the undesired code can be disabled almost entirely using pre-existing mechanisms (the change in mbed_overrides.c is still required):

1. Remove the components WHD and RTX
2. Remove the CYBSP_WIFI_CAPABLE macro (it is currently defined in targets.json)

@kyle-cypress,
Thank you for your input.
Please note that the intent is to exclude it ONLY for the baremetal profile.
Your proposed solution above will also remove the components for non baremetal builds (with full Mbed OS) which is not what we want to do.

[kyle-cypress]

I'm not too familiar with the bare metal profile and it's not clear from https://os.mbed.com/docs/mbed-os/v5.15/reference/mbed-os-bare-metal.html how you can change the components, macros etc when building under that profile. But I'm assuming that there is some fairly flexible mechanism given that Cypress-specific macro values and library names have been proposed in this PR.
Based on that premise, I believe that the undesired code can be disabled almost entirely using pre-existing mechanisms (the change in mbed_overrides.c is still required):

1. Remove the components WHD and RTX
2. Remove the CYBSP_WIFI_CAPABLE macro (it is currently defined in targets.json)

@kyle-cypress,
Thank you for your input.
Please note that the intent is to exclude it ONLY for the baremetal profile.
Your proposed solution above will also remove the components for non baremetal builds (with full Mbed OS) which is not what we want to do.

@hugueskamba
To clarify, my suggestion is to remove those components and macro ONLY when building for the baremetal profile. Given the previous proposals (e.g. relying on a new macro MBED_CONF_CY_PSCOC6_WHD_PRESENT) I am assuming that you have a mechanism for customizing the app configuration for baremetal (is there somewhere I can read about this?)

[hugueskamba]

I'm not too familiar with the bare metal profile and it's not clear from https://os.mbed.com/docs/mbed-os/v5.15/reference/mbed-os-bare-metal.html how you can change the components, macros etc when building under that profile. But I'm assuming that there is some fairly flexible mechanism given that Cypress-specific macro values and library names have been proposed in this PR.
Based on that premise, I believe that the undesired code can be disabled almost entirely using pre-existing mechanisms (the change in mbed_overrides.c is still required):

1. Remove the components WHD and RTX
2. Remove the CYBSP_WIFI_CAPABLE macro (it is currently defined in targets.json)

@kyle-cypress,
Thank you for your input.
Please note that the intent is to exclude it ONLY for the baremetal profile.
Your proposed solution above will also remove the components for non baremetal builds (with full Mbed OS) which is not what we want to do.

@hugueskamba
To clarify, my suggestion is to remove those components and macro ONLY when building for the baremetal profile. Given the previous proposals (e.g. relying on a new macro MBED_CONF_CY_PSCOC6_WHD_PRESENT) I am assuming that you have a mechanism for customizing the app configuration for baremetal (is there somewhere I can read about this?)

The way the baremetal profile is built is by only selecting what it needs (as opposed to removing what it does not need). This is done by using the "requires" attribute to select only what is needed in the baremetal profile configuration file.

The macro MBED_CONF_CY_PSOC6_WHD_PRESENT is automatically generated by the addition of the mbed_lib.json and can be used if needed for a pre-processor condition. However, the simple fact of adding mbed_lib.json makes the files within that directory part of a new library (called cy_psoc6_whd) and the library is not included by the baremetal profile configuration file. Since the files in the new library are not included in the build the problem is solved.

I am assuming that you have a mechanism for customizing the app configuration for baremetal (is there somewhere I can read about this?)

https://os.mbed.com/docs/mbed-os/v5.15/reference/configuration.html

[vmedcy]

Hello @hugueskamba,

I have just reviewed https://github.com/ARMmbed/mbed-os-example-blinky-baremetal/blob/master/mbed_app.json and now understand the application-defined "requires": ["bare-metal"] overrides the default list of included libraries. This effectively means that any customers that already have mbed_app.json with custom "requires:" in their mbed_app.json will get sudden change in behavior (WHD, common/network and abstraction-rtos excluded from build). Of course, such change in behavior is acceptable in new major Mbed OS version.

I understand the goal to get the mbed-os-example-blinky-baremetal app working out-of-box for PSoC 6 targets - this is very good goal. Alternative would be to add custom target_overrides for PSoC 6 targets to exclude COMPONENT_WHD and COMPONENT_RTX - but this doesn't solve issue with common/network. Hence I approve this PR. @kyle-cypress do you see any issues?