Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] MCUmgr support #2545

Open
1 task done
raiden00pl opened this issue Sep 1, 2024 · 3 comments
Open
1 task done

[FEATURE] MCUmgr support #2545

raiden00pl opened this issue Sep 1, 2024 · 3 comments
Labels
Type: Enhancement New feature or request

Comments

@raiden00pl
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Hi, does anyone have mcumgr ported on NuttX?

If not, I think it's a project worth porting, as it would provide a tool for managing remote devices and, most importantly, DFU over the Simple Management Protocol (e.g., over BLE). An out-of-the-box tool for managing remote devices is something I feel is missing in NuttX.

If no one has implemented this yet, I might look into it one day. However, I have a few concerns about this task.

Describe the solution you'd like

Currently there are 2 implementations of mcumgr:

  1. The original project from Mynwet - https://github.com/apache/mynewt-mcumgr/
  2. Zephyr version, developed in parallel - https://github.com/zephyrproject-rtos/zephyr/tree/main/subsys/mgmt/mcumgr
    Initially, Zephyr used the Mynewt version directly, but they decided to incorporate
    the code directly into Zephyr. Details can be found here:

Currently Zephyr version has more functionalities (such as mcumgr client and additional
management commands).

So my questions are:

  1. Which code should we port: the Mynewt version or the Zephyr version ?
    Both have Apache licenses, so the license is not an issue. Zephyr has more
    functionalities, but the porting requires more effort.

  2. Should we adopt an approach similar to Zephyr, where we maintain our own version of the
    code, or should we clone active project ?
    If we choose the second approach (git clone), the Zephyr version is probably out of
    the question - cloning the entire Zephyr project is a bad idea.

    Keeping its entire code in our repo could offer benefits, such as implementing NuttX-specific commands,
    transports and optimizations. All the arguments from the discussion in Zephyr issue above also apply here.

Describe alternatives you've considered

No response

Verification

  • I have verified before submitting the report.
@raiden00pl raiden00pl added the Type: Enhancement New feature or request label Sep 1, 2024
@raiden00pl
Copy link
Contributor Author

It looks like mynewt-mcumgr uses custom tinycbor implementation: https://github.com/apache/mynewt-core/tree/master/encoding/tinycbor
and it can't be used with https://github.com/intel/tinycbor supported by Nuttx-apps.
In that case a port without major changes to mcumgr is not possible anyway, so git clone mynewt-mcumgr approach is out.

@xiaoxiang781216
Copy link
Contributor

It looks like mynewt-mcumgr uses custom tinycbor implementation: https://github.com/apache/mynewt-core/tree/master/encoding/tinycbor and it can't be used with https://github.com/intel/tinycbor supported by Nuttx-apps. In that case a port without major changes to mcumgr is not possible anyway, so git clone mynewt-mcumgr approach is out.

Should we upstream the change to mynewt-mcumgr?

@raiden00pl
Copy link
Contributor Author

Should we upstream the change to mynewt-mcumgr?

PR from mynewt to tinycbor is here intel/tinycbor#83 since 2017, so there is no chance that it will be merged.
There is also no chance that mynewt will go back to using the old tinycbor API.

After getting to know both implementations better, I came to the conclusion that the only option is custom NuttX implementation of mcumgr based on Zephyr and zcbor. But it is also the most expensive solution.

An alternative option is to use mynewt-mcumgr and copy tinycbor from mynewt to apps, but this results in two incompatible tinycbor implementations in the apps - which is a worse solution in my opinion.

To sum up - there is no easy way to port mcumgr and the whole task is rather big :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants