Skip to content
This repository has been archived by the owner on Jan 10, 2022. It is now read-only.

Write up-to-date comments about waitForDisconnect() #34

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

IvanSanchez
Copy link
Contributor

The changes in #33 (inadvertently) left some old comments which are no longer true (i.e. the waitForDisconnect() function no longer times out after 5 sec). This just gets those comments up to date.

@IvanSanchez IvanSanchez requested review from mrodem and bencefr June 18, 2018 09:21
// 64-bit win. Previous implementations ( < v0.2.5) had workarounds,
// but those workarounds created problems on a specific USB XHCI root hub
// on win7 64-bit.
// The current implementation **assumes** that the DFU target will reset
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am under the impression that the current implementation does not assume the reset, it does close() regardless, correct me if I'm wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it does. If the DFU target doesn't reset itself, the function will still return a fulfilled promise. Maybe it's a matter of wording?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it is, since DFU is expected to reset in any case, we don't force reset it, and the serialport close is another layer. Maybe if the wording indicates that this function is called when we expect that the target is/has reset... then we close the corresponding serialport.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants