search

apache / mynewt-newtmgr

Newt Manager (newtmgr) is the application tool that enables a user to communicate with and manage remote devices running the Mynewt OS
https://mynewt.apache.org/
Apache License 2.0
35 stars 77 forks source link

Reduce serial TX delay or make configurable #180

Open sw opened 3 years ago

sw commented 3 years ago

I'm using mcumgr-cli to flash Zephyr application images. The communication is quite slow. Despite using 460800 baud, I only get about 1.9kbyte/s. Maximum throughput would be 45kbyte/s but I understand this is reduced due to base64 encoding overhead etc.

There seems to be a delay of ~20ms between each fragment. I believe that many targets can process the data faster.

image (RX/TX as seen from the target)

With no Go experience, looking into the code, I suspect this is the culprit?

https://github.com/apache/mynewt-newtmgr/blob/87d51a23a7575b070335ececd0e240092860c24f/nmxact/nmserial/serial_xport.go#L276-L279

Could you reduce this or make it configurable?

Maybe set it to a low value in the beginning and increase it if there are timeouts due to the target not responding.

mkiiskila commented 3 years ago

If speed is an issue, this might be better: https://github.com/mkiiskila/mynewt_serial_uploader

On 20. Jan 2021, at 11.46, Stephan Walter notifications@github.com wrote:

I'm using mcumgr-cli to flash Zephyr application images. The communication is quite slow.

There seems to be a delay of ~20ms between each fragment. I believe that many targets can process the data faster.

https://user-images.githubusercontent.com/4478/105156649-68bec500-5b0c-11eb-8b05-fef3bc9c1372.png (RX/TX as seen from the target)

With no Go experience, looking into the code, I suspect this is the culprit?

https://github.com/apache/mynewt-newtmgr/blob/87d51a23a7575b070335ececd0e240092860c24f/nmxact/nmserial/serial_xport.go#L279 https://github.com/apache/mynewt-newtmgr/blob/87d51a23a7575b070335ececd0e240092860c24f/nmxact/nmserial/serial_xport.go#L279 Could you reduce this or make it configurable?

Maybe set it to a low value in the beginning and increase it if there are timeouts due to the target not responding.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apache/mynewt-newtmgr/issues/180, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARG35RRT2FLRFOLAVBUQDLS22Q6XANCNFSM4WKMUQ2Q.

mniestroj commented 3 years ago

Even though there are other tools allowing to do the same as this project, I share @sw idea that this 20ms time would be good to be configurable or handled smarter. Note that 20ms timeout is good enough for some subset of platforms. When working with https://github.com/zephyrproject-rtos/zephyr/pull/27023 it seemed that 10ms was a problem for Zephyr+nRF52 before mentioned PR was merged. So assuming that somebody was using 2x slower platform, it is very likely that 20ms was not long enough. So changing this hardcoded 20ms to something configurable (either by user, or calculated in runtime) makes a lot of sense, either to improve speed of fast platforms, or make it reliably work with slower platforms!