Replace cmsis implementation

[embeddedteam103]

Description

As I mentioned in previous threads, we have rolled our own implementation of cmsis-os by wrapping the closed source threadx rtos (and we use more then the public API of threadx then this can't be open source).

We do this by removing the rtos directory (using .mbedignore) and replacing a bunch of files instead.
We want to do this in an official way - have configuration files that define what CMSIS implementation to use.

We are willing to develop the configuration and the tool that controls it.
Therefore I want the design to be discussed here before we start the implementation.
The steps are as follows:

1. Iron clad the files that the cmsis implementation need to provide (make it part of the API).
2. Define a configuration that determines where to find these files.
3. Add defaults to RTX
4. Develop tool that turns these configuration into actual build instructions.
5. Add that functionality to mbed-cli

Am I missing some steps?

As for the details:
Right now the way mbed finds the cmsis typedefs is in the following files in the rtos\TARGET_CORTEX directory (these are the files we have overridden in our fork):

• mbed_rtx_conf.h
• mbed_rtos_storage.h
• mbed_rtos1_types.h
• mbed_rtx_handlers.c

Everything else depends on RTX due to deficiencies in cmsis that should be solved (#9119, #9125, discussion in #6534).

After the day these are solved, there is no use of rtx inside mbed other then these files that define the CMSIS implementation customization (unless this list is not exhaustive).
I want to standardize the API provided by these files as the customization mechanism for the RTOS (after renames of the files).

We really really want such a customization tool and hope for a guiding hand from the mbed team.

I think the following questions (at the minimum) should be answered before starting an implementation:

1. Is there a fundamental reason to NOT enforce the CMSIS API inside mbed?
2. How do custom OS provide the API needed? This is more then a mere json file.
3. How uniform the customization should be related to the custom targets interface? Note these are very similar - they both include json file (custom_targets.json) and header/source files (the pinout and peripheral mapping, and changes to the HAL implementation if needed).
4. Should this configuration API be part of mbed or cmsis?
5. Do we enforce certain configuration params on every cmsis os?

For the last one, I think the answer should be NO - in our impl there are completely different configuration params - and this is due to the design decisions of the OS implementation.
If we decide it should be no, then we need to allow custom customization params - what API should this be in?

I hope this kick-starts discussion and we can move forward soon.

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-336

[embeddedteam103]

I want to understand if such a path forward is in line with you.
Because if you don't want to allow an official replacement of RTX as part of the toolchain, then we won't develop a general-purpose tool - The point of doing that is to be part of the mbed toolchain (otherwise we can use our own internal python hacks).
So I want to understand the following first - Will you be interested in such a tool (or at least a standardization of customization points of the CMSIS implementation)?

[bmcdonnell-ionx]

Potentially relevant:
#5700

[0xc0170]

To provide at least some answers but not definite ones

Is there a fundamental reason to NOT enforce the CMSIS API inside mbed?

We would like to use CMSIS API only without any custom edits - enables us to use vanilla CMSIS.

How do custom OS provide the API needed? This is more then a mere json file.

Ideally we would not need anything custom.

We want to do this in an official way - have configuration files that define what CMSIS implementation to use.

As soon as we use vanilla CMSIS, then this configuration comes to the table - how to enable different cmsis rtos implementation ? To be defined - this might be a good candidate for mbed-cli tool.

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.