Openthread application in both FTD (JOINER enabled) and RCP mode

[Mavioux]

Hello everyone!

I am trying to make an ESP32 application by combining the examples of ot_cli and ot_rcp. I want to compile a firmware where the device can operate both as a JOINER and in RCP mode. Of course the application will never be in both states, but I want to compile with the possibility of using both these states and dynamically on runtime choose which version to initialize.

I noticed that when I enable these configuration options simultaneously the firmware cannot be compiled:

CONFIG_OPENTHREAD_RADIO=y
CONFIG_OPENTHREAD_JOINER=y

FTD mode works fine if I have this enabled:

CONFIG_OPENTHREAD_RADIO=n
CONFIG_OPENTHREAD_JOINER=y

and RCP mode seems to compile fine if I have this enabled:

CONFIG_OPENTHREAD_RADIO=y
CONFIG_OPENTHREAD_JOINER=n

I noticed this line of code inside idf/components/openthread/private_include/openthread-core-esp32x-radio-config.h

#if CONFIG_OPENTHREAD_JOINER
#error "Joiner shouldn't be enabled for RCP"
#endif

It looks to me like the esp32 openthread library was not intended to allow compilation for both RCP and JOINER mode.

I also noticed that even if I suppress the error above and enable both RADIO and JOINER

CONFIG_OPENTHREAD_RADIO=y
CONFIG_OPENTHREAD_JOINER=y

the CMakeLists.txt in the openthread component (idf/components/openthread/CMakeLists.txt) handles these configurations as mutually exclusive, thus not allowing compilation for both without manually changing this file (and thus diverging from the espressif idf branch)

My question is if there is any reason that it is not allowed to compile for both these modes. Of course I understand why I cannot use both these modes simultaneously, I just want to allow compiling for both and choose on runtime which one to initialize. Is there a limitation on that based on the way the openthread library works? Can I just modify the CMake files myself and to compile succesfully or is there a reason that I cannot do that?

Has anyone ever encountered this scenario in the past, I am curious to hear how you solved this.

[abtink]

@Mavioux , let me provide some guidance regarding the OpenThread core and its integration into different projects.

The OpenThread core itself provides various high-level configuration options, in particular FTD, MTD, or Radio, which correspond respectively to different library outputs: libopenthread-ftd.a, libopenthread-mtd.a, and libopenthread-radio.a.

These libraries can then be integrated into other projects to build a full firmware image or executable.

Generally, a complete firmware image consists of at least three components:

• A selected libopenthread-* library.
• A platform library, providing the otPlat* APIs for the OpenThread stack to use (e.g., radio, timer, settings).
• An application layer library, which is the code that controls the Thread stack using OpenThread APIs.
  • The OpenThread repository itself provides two example application implementations: the CLI (Command Line Interface, mirroring OT APIs) and the NCP (providing a Spinel interface through a serial or SPI bus to communicate with an external host).

To construct an RCP firmware, the libopenthread-radio.a library is used along with the NCP application layer and a vendor-specific platform library.

To construct a full FTD/MTD firmware or executable, the libopenthread-ftd.a or libopenthread-mtd.a library is used along with the CLI or NCP application layer and a platform layer implementation (this can be the POSIX platform provided in the OpenThread repository, which works with any RCP, or a vendor-specific platform implementation).

Your idea of having a single firmware that can act as either an RCP or a full FTD stack with a CLI (and be selectable at run-time) is not compatible with the current architecture.

To be clear, making such a combination is technically feasible, but it would require some architectural changes and additional development work. If you are interested in such a configuration, perhaps you could implement it and contribute it back to OpenThread.

[Mavioux]

@abtink Thank you very much for the response.

Your idea of having a single firmware that can act as either an RCP or a full FTD stack with a CLI (and be selectable at run-time) is not compatible with the current architecture.

If I only want an FTD stack without a CLI (I do not need a CLI in my application) does it change things, or is the limitation still the same?

I assume the limitation is still there, I just wanted to make sure.

[abtink]

It follows same rules.

[Mavioux]

If I were to try to go through the architectural changes what should I change? A hint to the general direction would be appreciated.

I assume I shall not touch the precompiled libraries. Should I make some changes on the platform library and the way I include the precompiled libraries? Do I also need to change the NCP application layer?

Any help is appreciated.

[abtink]

I don't expect this to be a small or quick change. I can provide some hints but cannot guide you fully on this.

The question I would raise is the usefulness of having a single binary firmware that can then be configured at run-time to perform entirely different functions (e.g., act as an RCP or a full FTD/MTD stack). These are fundamentally different models, and I would personally advise having separate and distinct binary firmware targeted for each use case.

---

I assume I shall not touch the precompiled libraries.

Probably will need to. Regarding the OpenThread core, I suggest getting familar with the OPENTHREAD_CONFIG_LINK_RAW_ENABLE feature. This feature can be enabled on an FTD/MTD build to provide low-level, raw-link (radio-link) APIs that are similar to what an RCP build (libopenthread-radio.a) provides.

Should I make some changes on the platform library and the way I include the precompiled libraries?

Probably. It depends on whether you want the exact same platform API implementations or not. If you want the exact same behavior, then probably no changes are needed.

Do I also need to change the NCP application layer?

Probably, yes. This would require getting familiar with both the RCP and NCP Spinel interfaces and understand where and how they match or differ.

---

A key additional challenge will be implementing a run-time way (API) to configure the device, i.e. need to design a mechanism to convey to the device (e.g., upon boot) that it should start operating as an RCP or as an FTD/MTD. I would expect this to be a vendor/product-specific mechanism that would add to the overall complexity of the firmware.

[Mavioux]

Thank you for your response and input. I have decided that it is indeed simpler to create two different binaries to achieve this functionality and not try to change the architecture for now.