Reduce serial TX delay or make configurable

[sw]

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.

(RX/TX as seen from the target)

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

mynewt-newtmgr/nmxact/nmserial/serial_xport.go

Lines 276 to 279 in 87d51a2

	/* slower platforms take some time to process each segment
	* and have very small receive buffers. Give them a bit of
	* time here */
	time.Sleep(20 * time.Millisecond)

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]

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 ***@***.***> 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 <#180>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARG35RRT2FLRFOLAVBUQDLS22Q6XANCNFSM4WKMUQ2Q>.

[mniestroj]

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 zephyrproject-rtos/zephyr#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!