-
-
Notifications
You must be signed in to change notification settings - Fork 87
Calls to digitalWrite() don't work after a previous analogWrite() #58
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
Comments
@technoblogy
looks like analogWrite does something to mess with pinMode. Tested on a Minima. |
Thanks, but my point is that calling |
I agree thats why I added it to make it painfully clear. |
Others may see this differently but this is acceptable behaviour to me. This use case of using the same pin both as digital output and as PWM output within the same sketch is one that's unlikely to occur outside of your experimental setup (in the real world ™️). If you insist on doing it than one call to |
The reason I see it as unacceptable is that I have code (a more complicated version of the example at #58 (comment)) that works on all other Arduino compatible boards, but fails in a non-obvious way on the Uno R4 Minima and Uno R4 WiFi. |
I really hate the "cluttering" of digitalWrite() with checks for whether an analogWrite() is in effect, whether the pin is in INPUT mode (and therefore should have a pullup enabled) (which the R4 code also doesn't do) and so on. Some of this is painful preservation of AVR behavior, and some is just things that ought to be the programmer's responsibility. OTOH, other boards have implemented this behavior, so it is a backward incompatibility. |
That's my position too. It needlessly adds extra state and I can already see people bike-shedding about performance. To top it off, switching back and forth between PWM and digital output is simply not a sensible use case scenario in the real world ™️ . A PWM of 0 is |
I don't have a strong opinion, on if pinMode call should be needed here or not. But this issue was linked to in a thread I started, so decided to take a look. It reminded me of a recent thread up on the PJRC forum: https://forum.pjrc.com/threads/73248-Teensy-4-1-PWM-pulsing-output-with-values-0-and-256 Where the PWM code does not give you the same effects for 0 and 256 (8 bit mode) as setting the pin High or Low. Instead it might still give a very small pulse or gap. Which is why some then explicitly set the pin High or Low. But this could cause problems for some devices that rely on a consistent timing of the pulses, of when the next pulse should start. But I have seen more than once where sketches do intermix using PWM and digital mode. |
New methods and flags + API refactoring
New methods and flags + API refactoring Former-commit-id: 97c3091
Once you've generated PWM on a pin with
analogWrite()
, a subsequentdigitalWrite()
doesn't work.Here is a sequence of calls and the resulting voltage on the pin (on core 0.8.7), compared to the same sequence on an original Arduino Uno R3:
pinMode(3, OUTPUT)
digitalWrite(3, HIGH)
analogWrite(3, 200)
digitalWrite(3, LOW)
digitalWrite(3, HIGH)
The R3 behaviour is what I'd expect.
Here's a visual demonstration of the problem. This program first blinks the builtin LED, and then pulsates it smoothly on and off:
The call to
blink()
only works the first time aroundloop()
.The same problem occurs on the Uno R4 WiFi.
Note: Originally posted on the Early Access Program forum, but still an issue.
The text was updated successfully, but these errors were encountered: