Uart based user interface: Shell?, McuMgr?

[sheldon_b]

I have a device that needs to do the following:

1. Communicate with a program running on a computer.
2. Send sensor data over UART when polled by the host computer.
3. Accept commands from a host computer (update setting, turn on led ...etc.)
4. Perform a DFU when the host computer has a firmware available.

I have read a lot of different forum posts that have "work arounds" for custom protocols for delivering data while also supporting MCUMGR . I suppose a custom protocol isn't strictly necessary in my use case (but I did start this way). I am mostly interested in the Nordic/Zephyr best practice for accomplishing the three objectives above. It seems like MCUMGR can coexist with the shell, but I'm not sure if a shell is appropriate for talking with other programs (its more for a user terminal). Any suggestions on the high level design here?

I am using NCS 2.3.0 and currently working on an NRF52840 (although I will most likely reuse the agreed upon paradigm on other SOC's like the NRF9160 and NRF53). 

[Menon]

Hello,

I think with the overlay configuration I pointed out, the MCUGR will not take full control of the interface. But I haven't tested this here; for that, I need some more time. But I recommend you give it a try, like what is mentioned here.

Kind Regards,

Abhijith

[sheldon_b]

I ultimately decided the overhead and complexity of running MCUMGR wasn't worth the trouble. I used the following approach:

• Using the app event manager, I created an event and module for a console. This console uses a UART (but could very easily be USB or BLE) to communicate with a HOST using a message-response exchange protocol. I could have gone a few different directions with the transport, but ultimately decided to use line delimited JSON strings (This part is less important because the transport was abstracted away from the console and can be changed to anything).
• For firmware updates, the host sends a series of JSON strings that are ack'd by the console module.
  • A DFU start message
  • A sequence of DFU file fragments
  • A DFU end message.
• The console used the dfu_target api from <dfu/dfu_target.h>

I then wrote a host side library that allowed me to communicate with the client. While it was a little more work upfront (honestly not too bad), I have a good understanding of how the protocol works and I don't have manage another dependency.