Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow upload over USB on cygwin to pixracer #12053

Open
RaphZufferey opened this issue May 21, 2019 · 12 comments
Open

Slow upload over USB on cygwin to pixracer #12053

RaphZufferey opened this issue May 21, 2019 · 12 comments
Assignees
Labels

Comments

@RaphZufferey
Copy link

RaphZufferey commented May 21, 2019

Describe the bug
Upload speed to pixracer is very slow.

To Reproduce
Steps to reproduce the behavior:

  1. Cygwin on Windows 10
  2. Pixracer connected via USB, COM port setup as 2 and baudrate 115200 or 57600
  3. upload with "make px4_fmu-v4 upload"

Expected behavior
Upload in 30s, speed that I usually get on Ubuntu build

Log Files and Screenshots
image

Additional context
Bug #10429 still happens irregularly, about 1/3 of trials to upload. Just hangs on "non-standard ... USB connection"

@MaEtUgR
Copy link
Member

MaEtUgR commented May 22, 2019

I can reproduce with two times the exact same setup and firmware (latest master).
Windows 10 Cygwin toolchain:
pixracer_upload
Ubuntu 18.04 VM on Windows:
pixracer_flash_ubuntu
Sorry but I have no idea why that could be. @julianoes @davids5 any pointers for me to look into?
Maybe it's again the windowed mode that kicks in, I can check that.

@davids5
Copy link
Member

davids5 commented May 22, 2019

@MaEtUgR - even though it says ttyS3 am I correct to assume this is all USB?

The display says windows mode is false.

Here is a quick test - set the baud rate to the highest rate supported rate on Cygwin and see if it changes the time.

This may be the original issue the OS time quanta per packet delay that I was seeing originally.

@MaEtUgR
Copy link
Member

MaEtUgR commented Jun 7, 2019

@davids5 Yes, it's USB serial devices which are COM ports on Windows and these COM ports get mapped to /dev/ttyS# in Cygwin for posix compliance. Let me check your suggested test.

@MaEtUgR
Copy link
Member

MaEtUgR commented Jun 7, 2019

@david5 I checked and either I change the wrong thing or it doesn't make any difference when I change the bootloader baudrate. I checked the args.baud_bootloader on line https://github.com/PX4/Firmware/blob/be02ad3514213af7e1febd0377835eb00d063495/Tools/px_uploader.py#L815 and it makes no difference. When I change baud_flightstack it doesn't reboot anymore which is to be expected and means I'm not at the wrong spot.

What's also interesting is: on fmu-v5 I don't see that much of a difference in flashing time between
Cygwin (Windows):
windows
Ubuntu 18.04 (VM on Windows):
linux

@MaEtUgR
Copy link
Member

MaEtUgR commented Jun 7, 2019

On the pixracer I now also have a normal upload time using Windows Cygwin...:
windows_pixracer

Did something change on master?
@RaphZufferey Does the problem persist for you?

@RaphZufferey
Copy link
Author

I don't have a pixracer on hand right now, will try as soon as possible! Do you also get normal compiling speeds? It takes about 4-5 minutes to clean build the code for me.
Thanks a lot for all the help.

@davids5
Copy link
Member

davids5 commented Jun 7, 2019

@MaEtUgR - how is Cygwin updated? Could this be related to and issue with Python on Cygwin that got fixed?

@MaEtUgR
Copy link
Member

MaEtUgR commented Jun 12, 2019

@davids5 The toolchain can locally be updated. The version deployed in the installer is updated by generating a new installer through CI. It fetches the latest Cygwin packages here: https://github.com/PX4/windows-toolchain/blob/master/appveyor.yml#L21 But Cygwin is rather conservative and stable (vs bleeding edge). At least I didn't update the toolchain recently.

@stale
Copy link

stale bot commented Sep 10, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@julianoes
Copy link
Contributor

@MaEtUgR so this is fixed?

@stale stale bot removed the Admin: Wont fix label Sep 20, 2019
@MaEtUgR
Copy link
Member

MaEtUgR commented Oct 21, 2019

I don't think so but since I consider it a minor problem I'm not planning to look into this very soon.

@stale
Copy link

stale bot commented Jan 19, 2020

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

@stale stale bot added the stale label Jan 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants