how to merge cdc funcation in ncs sdk project desktop?

[pipixia_1_1]

Hi,nordic team，

im use nrf52840 develop my product with sdk ncs 2.6.the speed of desktop dfu is so slow,and the speed of configurator channel is also slow.i want to transfer my data by cdc .if there is some eexample to show how should i to do?or som document? 

[Einar Thorsrud]

Hi,

Can you elaborate a bit more about the issue? Is the problem that BLE transport is slow and therefore you want a different transport or something else? Specificially what do you use and want to use DFU CDC for Note that the nRF Dekstop application also support DFU in form of serial recovery. See nRF Desktop: Bootloader and Device Firmware Update.

PS: If the issue is with Bluetooth performance, you may want to look at CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP which adjusts BLE buffers etc to incrase BLE throughput.

PSS: File transfer over CDC in nRF Dekstop is deliberately slow but it can be optimized. I will look into how.

[Einar Thorsrud]

Hi,

We have looked at this and have some more to share. Our assumption is that you want quicker data exchange (including update image upload) over the nRF Desktop configuration channel. And we assume you relies on our HID configurator script as host tool. Plase let me know if that is not the case.

Generally the configuration channel design focuses on mitigating negative impact on HID device's performance (because of that the update image is transfered slowly, in small chunks). DFU speed was not considered a priority here because DFU image transfer was meant to happen in the background and be nearly unnoticeable for the end-user. After the complete transfer a device reboot can be triggered to let bootloader start using the newly uploaded image. Also, the configuration channel can be used for HID devices connected either over USB, BLE or even through nRF Desktop dongle (config channel relies on HID feature reprots for DFU image transfer).

If you rely on our hid_configurator script, you could try to shorten poll interval on the host computer side by locally modifying parameters in NrfHidDevice.py file (it should make DFU noticeably faseter, but it could have negative impact on HID device's performance). The following parameters could be updated:

POLL_INTERVAL_DEFAULT = 0.02
POLL_RETRY_COUNT = 200

The poll interval (20 ms by default) could be set e.g. to 0.002 (2 ms). Then poll retry count would need to be increased to prevent failures too (2000
should work fine with the new poll inteval).

[pipixia_1_1]

Thank you for your reply，

        Firstly, upgrading through the hid config channel is indeed too slow for us, but if we use CDC to upgrade, there may be issues with the PC driver environment on the client side, and some customers may encounter installation failures of Nordic CDC drivers.

     Secondly, we have a large amount of private data transmission, such as RGB equivalent; If the communication ability of the hid config channel is really not fast, we can only find a way to improve the speed through CDC.

   I will try to modify the default configuration to see the upgrade effect.

[Einar Thorsrud]

Hi,

Please let me know when you have tested the configuration canges.

PS: May I ask why speed is an issue? Our assumption was that as DFU is done in the background, speed would not be an important factor.

[pipixia_1_1]

Yes, I tested it and after modifying the macro configuration, upgrading the firmware takes about 3 minutes. Because our firmware upgrade is issued to customers, not downloaded from network access servers before upgrading, users will have at least two perceptions when upgrading:
1. Use the upper computer to select the firmware and start upgrading;
2. After the upgrade is completed, a prompt will appear asking the customer if they want to reset and update to the new program;
We have many RGB lights for users to edit, and one light effect can support up to several hundred frames per second. Therefore, the amount of data here is huge, and the slow speed brings a bad experience

[Lorenzo Amicucci]

if timing is critical during the file transfer, one other option is to use SMP protocol and MCUmgr. 
As mentioned in the documentation, the same mouse can support both type of transports ( we do this already now): the same mouse can be updated using config channel when connected to the PC over BLE, but it can updated using the SMP protocol when connected over BLE to the smartphone - nRF Connect for Mobile app. The important thing is that you include MCUboot as bootloader. 

So, you could try to use SMP over BLE also when mouse is connected to the PC. SMP is faster typically. 
However, you need to keep into consideration this:

- here you find the PC libraries that implement the SMP Client 
https://docs.zephyrproject.org/latest/services/device_mgmt/mcumgr.html#tools-libraries
(for mobile phone you can get the libraries from our mobile apps nRF Connect for Mobile and nRF Connect Device Manager - both android and ios)

- in linux, you have more choices, as mcumgr-client works also over BLE.

- in windows, the mcumgr-client will not work over bluetooth, only over USB. So you will need to use either AuTerm or mcumgr-web. Note: these are supported by the community, not released by Nordic, so they may have some bugs not under our control.
Important: such 3rd party PC clients are not able to use Direct-XIP mode. So you will need to disable that feature. That means they only support swap of the images between slots after the reset. This change of slot will also take some time. So, even if you reduce the time in transferring the image, after resetting time, it may take a bit time to swap the images between slot 1 and 0. Overall, it should be less than 3 minutes, and maybe it is ok for you (because you have a prompt that inform customers when to reset the device). 

If you can use USB for file transfer, than there may be other options. Please let us know if you can use USB.