What is the current status on adding machine.PWM? I am gated because this isn't complete and am thinking about going to a different board.
Hi @michaelm0929,
Yes, it’s possible to use PWM on the GIGA R1 WiFi with MicroPython. However, it works a bit differently compared to typical MicroPython boards. You need to use the Timer class in combination with the Pin class from the pyb module instead of directly relying on machine.PWM.
Here’s an example code snippet to help you get started:
from pyb import Pin, Timer
# Configure the built-in LED pin (A13 is DAC1, capable of PWM)
led = Pin('A13') # Replace with your desired PWM-capable pin
# Initialize a timer for PWM
timer = Timer(2, freq=1000) # Timer 2 at 1 kHz
# Create a PWM channel on the timer (channel 1)
channel = timer.channel(1, Timer.PWM, pin=led)
# Function to change the PWM duty cycle
def set_brightness(percent):
if 0 <= percent <= 100:
channel.pulse_width_percent(percent)
print(f"LED brightness set to {percent}%")
else:
print("The percentage must be between 0 and 100.")
# Example: vary the duty cycle from 0% to 100% in 25% steps
for duty in range(0, 101, 25):
set_brightness(duty)
pyb.delay(1000) # Wait 1 second before changing the duty cycle
You can adjust the pin to any other PWM-capable pin besides A13 by referencing the correct pin mapping.
For your convenience, here’s a link to a tutorial that provides a detailed pin map for MicroPython on the GIGA R1 WiFi.
Please test this solution and let me know if it works for your case or if you need additional help!
Best,
Thanks, I'll give it a try.
The docs say, "All channels share the same underlying timer, which means that they share the same timer clock." Yet we pass in a timer. Is that an override of the default behavior or an implementation nuance? Any other differences from machine.PWM?
Is there any downside to implementing PWM in this fashion other than tying up a timer? If I use timer.channel(), that appears to tightly couple the pin to the channel. I assume no other pins could then be coupled as well (i.e., 1 to 1).
What else am I missing about implementation here?
Hi @michaelm0929,
Great to hear you're trying it out!
- Timer Implementation: The statement means multiple PWM channels can use the same timer. By choosing a specific timer, you’re configuring it to your needs. It’s not overriding default behavior, just specifying which timer to use.
- Downsides of Using a Timer for PWM: Using a timer for PWM means you can’t use it for something else at the same time. Each channel is linked to one pin, creating a 1-to-1 mapping.
- Other Implementation Details:
- The PWM signal’s resolution and frequency depend on the timer settings.
- Be mindful of interrupts and callbacks that might affect the timer.
- Track your timers and pins to avoid conflicts in larger projects.
Feel free to ask if you have more questions!
Best regards,
I'm currently writing a MicroPython class to manage a UART servo bus (SC15 servos), but when I was last playing with configuring PWM behavior I had shifted to testing on the Nano ESP32 (yes, different uP implementation) and was leveraging its onboard RGB LED as a visual indicator of code behavior. What I noticed and seemed to confirm in the MicroPython's C++ source code was that the machine.PWM class would look for a corresponding timer based on the frequency passed in the constructor and, if one existed, it would then attach to that timer. This resulted in the LED going to white because all of the PWM instances fired on the timer. Offsetting the frequency by one Hz would grab a different timer and result in the fading colors I was attempting.
I'll circle back to that after I've finished my bus class. ![]()