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

Turn off IRQ on stopWaveform after Tone timeout #7232

Closed
wants to merge 3 commits into from

Conversation

earlephilhower
Copy link
Collaborator

Fix #7230 (until 3.0 when this whole code will probably change).

Before, a timed out pin would clear its bit in waveformEnabled. The
logic in stopWaveform. If only one tone was running and timed out,
stopWaveform would check the enabled bitmask and see nothing active
and immediately return w/o cancelling the IRQ. So, the IRQ would be
called every 1/100th of a second and return immediately when no work to
be done was detected.

Remove the check and always send in a waveformToDisable bit. It's
save to disable an already disabled pin, so no logical consequences will
occur, and the final IRQ disable will be executed when appropriate.

Fix esp8266#7230 (until 3.0 when this whole code will probably change).

Before, a timed out pin would clear its bit in `waveformEnabled`.  The
logic in `stopWaveform`.  If only one tone was running and timed out,
`stopWaveform` would check the `enabled` bitmask and see nothing active
and immediately return w/o cancelling the IRQ.  So, the IRQ would be
called every 1/100th of a second and return immediately when no work to
be done was detected.

Remove the check and always send in a `waveformToDisable` bit.  It's
save to disable an already disabled pin, so no logical consequences will
occur, and the final IRQ disable will be executed when appropriate.
@dok-net
Copy link
Contributor

dok-net commented Apr 20, 2020

@earlephilhower Off the top of my head, your fix isn't right, if you'd just cherry-pick mine from PR#7022 it will be correct?

@earlephilhower
Copy link
Collaborator Author

@dok-net I'm looking at your commit bb3ee99 . I think we're both fine here.

It's doing the same thing, but this small PR sends in the waveformToDisable even if it was already off. This is safe to do, as that flag is just removed from the waveform (a no-op in this case). It does waste up to 10us, but stopping waveforms isn't a timing critical operation.

In your PR it's also possible to have a race condition where the bit is cleared in wvfEnabled just after the main code does its check and you'd still send in the disable request. It's no biggie and safe on both versions...

Copy link
Collaborator

@devyte devyte left a comment

Choose a reason for hiding this comment

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

Looks ok from my pov

@earlephilhower
Copy link
Collaborator Author

Closing

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.

stopWaveform() doesn't deinit the timer if waveform had limited runtime
4 participants