You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by GitBox <gi...@apache.org> on 2021/01/20 09:46:17 UTC
[GitHub] [mynewt-newtmgr] sw opened a new issue #180: Reduce serial TX delay or make configurable
sw opened a new issue #180:
URL: https://github.com/apache/mynewt-newtmgr/issues/180
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.
(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
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.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [mynewt-newtmgr] mkiiskila commented on issue #180: Reduce serial TX delay or make configurable
Posted by GitBox <gi...@apache.org>.
mkiiskila commented on issue #180:
URL: https://github.com/apache/mynewt-newtmgr/issues/180#issuecomment-764436563
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 <no...@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>.
>
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [mynewt-newtmgr] mkiiskila commented on issue #180: Reduce serial TX delay or make configurable
Posted by GitBox <gi...@apache.org>.
mkiiskila commented on issue #180:
URL: https://github.com/apache/mynewt-newtmgr/issues/180#issuecomment-764436563
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 <no...@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>.
>
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [mynewt-newtmgr] mniestroj commented on issue #180: Reduce serial TX delay or make configurable
Posted by GitBox <gi...@apache.org>.
mniestroj commented on issue #180:
URL: https://github.com/apache/mynewt-newtmgr/issues/180#issuecomment-833345167
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!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org