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

Stop listening after starting SoftwareSerial #101

Merged
merged 1 commit into from
Jan 18, 2020

Conversation

sjasonsmith
Copy link
Contributor

Some platforms such as LPC176x call listen() inside their begin() function. This is done due to precedent from the original AVR implementation.

This causes problems for single-pin half-duplex, because it causes the pin mode to switch to input after each write command, even if the TMC will not send a response. This can leave the line in an indeterminate state, preventing the TMC from recognizing the start bit of the next command.

To resolve this, we can call stopListening() immediately after calling begin(). This prevents the automatic transition to input after the write completes.

Captures of Z and E drivers on an SKR 1.3, prior to the change. This issue only impacts only the last driver, because only one SoftwareSerial instance can listen at a time. These are the first interactions with the drivers after power-on.

image

Same capture with this change:

image

@sjasonsmith
Copy link
Contributor Author

@gloomyandy and I have been discussing the SoftwareSerial implementation that led to me creating this change.

I am continuing to look further into some issues regarding half-duplex SoftwareSerial, but this change is likely to remain needed either way.

@sjasonsmith
Copy link
Contributor Author

While this makes the images look better, I've not been able to reproduce any communication issues with my own SKR 1.3, even when I have added pull-down resistors so that "indeterminate" state is all the way down at 1.2 volts.

I'm going to close this for now, until we gather more information to understand why this would fix issues for some people, yet be impossible to reproduce for me.

@sjasonsmith sjasonsmith reopened this Jan 17, 2020
@sjasonsmith
Copy link
Contributor Author

I am reopening this PR because I have now had two SKR 1.4 users report it has solved issues for them. The SKR 1.4 uses single pin serial, so there are a lot more users potentially exposed to this now.

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

Successfully merging this pull request may close these issues.

2 participants