Skip to content

Available yield #545

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

Closed
wants to merge 4 commits into from
Closed

Available yield #545

wants to merge 4 commits into from

Conversation

Makuna
Copy link
Collaborator

@Makuna Makuna commented Jul 12, 2015

#540

NOTE: There is bleed over in the changes from a previous pull request, don't know how to clean that out other than revert it on my branch; BUT I DO NOT WANT TO REVERT THOSE CHANGES if they get merged in.

@igrr
Copy link
Member

igrr commented Jul 12, 2015

Since there isn't a way to handle this yield issue in one single place, i would propose to reduce the amount of code duplication by refactoring this as follows.

  • Introduce a global function, e.g. maybe_yield():
void maybe_yield() {
  if (micros() - esp_micros_at_task_start() > 10000) {
    yield();
  }
}
  • Update available methods to use it instead of esp_micros_at_task_start (which was a quick and dirty hack on my side):
bool isAvailable = ... ; // depending on the class
if (!isAvailable) {
  maybe_yield();
  isAvailable = ...; // perhaps update isAvailable, depending on the class?
}
return isAvailable;

@igrr
Copy link
Member

igrr commented Jul 12, 2015

Also i would like to merge your fixes in 4d3ef20. Would you mind if I rebase that change directly right now and then we go with a clean pull related to isAvailable?

@Makuna
Copy link
Collaborator Author

Makuna commented Jul 13, 2015

Go ahead and take the other, I will refactor this stuff and put out a new pull

@Makuna
Copy link
Collaborator Author

Makuna commented Jul 13, 2015

Note that #534 already contains the changes you want, just merge that.

@Links2004
Copy link
Collaborator

will the yield brake the code if i call it for example in the Ticker or the IO interrupt handler?

@igrr
Copy link
Member

igrr commented Jul 13, 2015

That's right, yield is non-reentrant, so calling it from Ticker or GPIO interrupt will cause an exception.
Doing while(!Serial.available()){} from an interrupt is not good either, but i think it would be good not to yield on the first invocation of available(). That was the rationale behind the existing code — so that you could call available() at least once from system context.

@Links2004
Copy link
Collaborator

yes while(!Serial.available()){} is a bad idea,
but a simple int i = Serial.available(); need to work otherwise we get more problems again.

@igrr
Copy link
Member

igrr commented Jul 13, 2015

My suggestion here is to yield only if available() was called more than once with zero result.
This way we can still read all available data from both sketch and system contexts, and handle the case of while(!available()); loop.

@Makuna Makuna mentioned this pull request Jul 13, 2015
@Makuna
Copy link
Collaborator Author

Makuna commented Jul 13, 2015

this is replaced by #551

@Makuna Makuna closed this Jul 13, 2015
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.

3 participants