fix: use atomic DTR/RTS reset on unix for CH340/UART bridges#37
Merged
deadprogram merged 1 commit intotinygo-org:mainfrom Apr 24, 2026
Merged
fix: use atomic DTR/RTS reset on unix for CH340/UART bridges#37deadprogram merged 1 commit intotinygo-org:mainfrom
deadprogram merged 1 commit intotinygo-org:mainfrom
Conversation
go.bug.st/serial issues SetDTR and SetRTS as separate ioctls, which on macOS with the CH340 VCP driver can drop or reorder the transitions and leave the chip unable to enter download mode. esptool.py addresses this with UnixTightReset, which uses a single TIOCMSET ioctl to change both modem lines atomically. - add setDTRandRTS helper that prefers atomic TIOCMSET on darwin/linux and falls back to separate ioctls elsewhere - add unixTightReset matching esptool.py's sequence and delay constants (default 50ms, extra 550ms) - on darwin/linux, ResetDefault now cycles unixTightReset/classicReset across attempts like esptool.py's default-reset list; other platforms keep the prior behavior - on darwin/linux, ResetAuto now also includes unixTightReset in its dispatch cycle (unixTightReset, classicReset, USB-JTAG, unixTightReset extra delay, no-reset) so CH340 devices sync correctly under the default reset mode; non-unix platforms retain the prior 3-strategy cycle
Member
|
Tested on Ubuntu and working as expected. Thanks for the fix @jgangemi now merging. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
go.bug.st/serial issues SetDTR and SetRTS as separate ioctls, which on
macOS with the CH340 VCP driver can drop or reorder the transitions and
leave the chip unable to enter download mode. esptool.py addresses this
with UnixTightReset, which uses a single TIOCMSET ioctl to change both
modem lines atomically.
and falls back to separate ioctls elsewhere
(default 50ms, extra 550ms)
across attempts like esptool.py's default-reset list; other platforms
keep the prior behavior
dispatch cycle (unixTightReset, classicReset, USB-JTAG, unixTightReset
extra delay, no-reset) so CH340 devices sync correctly under the
default reset mode; non-unix platforms retain the prior 3-strategy
cycle