Can I use the GPIO for pulse width modulation (PWM)?
Can I use the GPIO as a pulse-width modulation output?
If so, how would I go about doing it and how many concurrent, distinct PWM outputs can I have?
You probably need to specify which model you're using. They are all slightly different.
As suggested by Alex Chamberlain, the WiringPi library appears to support both hardware PWM output on one or two GPIO pins depending on model, and software PWM on any of the other GPIO pins. Meanwhile the RPIO.PWM library does PWM by DMA on any GPIO pin. Effectively this is a halfway house between hardware and software PWM, providing a 1 µs timing resolution compared to 100 µs with WiringPi's Software PWM.
Which of these is suitable for your applications depends on how many PWM outputs you need and what performance you want out of those outputs.
If your application is tolerant of low-timing resolution and high jitter then you could use a software or DMA assisted timing loop. If you want higher precision / lower jitter PWM then you may need hardware assistance.
When might software PWM be suitable?
If you want to flash a bunch of LEDs with different human visible cadences (10's of hertz) with soft real-time response requirements then the software loop could handle as many PWM's as you have GPIO pins.
When might hardware PWM be suitable?
If you want to control a servo motor with hard real-time response requirements then you will need to use hardware PWM. Even then you may have problems ensuring a real-time response for the servo loop which ties encoder input to PWM output.
A stable servo loop need to read encoders at a regular rate (low jitter), write out revised PWM output values at a regular rate and the latency between these should be fixed (low jitter overall). If you can't do this, then you will have to undertune (soft tune) your motor to prevent it becoming unstable under load. This is hard to do with a multi-tasking operating system without low-level support.
What if I need more hardware PWM outputs?
If you need to run more servo loops than you have hardware PWM outputs, then you are probably going to need to offload them to another device to ensure hard real-time performance, relegating your Raspberry Pi to being a soft real-time supervisor.
One option, would be something like the Adafruit 16-Channel 12-bit PWM/Servo Driver - I²C interface - PCA9685 which would allow you to control 16 PWM outputs with just a few pins of GPIO for the I²C bus. For an example of its use, check out the I²C 16 Channel PWM/Servo Breakout - Working post on the Raspberry Pi forums.
@gideon - Yes, the motor power amplifiers that I have used have all taken PWM as their input.
FYI, the RPI library (http://pythonhosted.org/RPIO/pwm_py.html) seem to have a much better resolution (1us) compared to WiringPi with 100us resolution
@MarkBooth - No probs. The library is really well written and can be used as drop-in replacement for RPi.GPIO which is very handy if you started a project with the latter and later realised PWM signals were needed...
Yes, there is one hardware PWM output on the Raspberry Pi, connected to P1-12 (GPIO18). Further, PWM outputs could be added using an I²C or SPI interface; some people have had success with this (forum post).
You can use the WiringPi library to control the PWM pin; you could look at the code to avoid including the entire library.
The Raspberry Pi is not suitable for any serious software PWM as Linux is not a real-time operating system.
Question, what is the definition or an example of serious software PWM? And what are "real time operating systems" and is there ever any chance of getting one on a Pi
@AnthonyBlake Well, you can probably control the brightness of a light using software PWM, but I suspect a motor will stall. There's no need to do software PWM though, hardware is simpler and more effective. Real time operating systems will be better explained by Google; they guarentee certain things about how long and often software is run.
@AnthonyBlake A "Real-Time OS" (RTOS) is an operating system that gives you a guarantee on the upper time limit of execution. Like saying to the program "Yes, you will have some execution time in 33ms (give or take 2ms tolerance) to flip that GPIO pin bit to give your step motor a signal in the exact time window when he needs it. And you can rely on that!" There's a RT Linux out there. Don't know if it's been ported to the RPi (yet).
Sorry Alex, I didn't intentionally steal another part of your answer, but I've just noticed that we came to the same forum post via different routes.
Recent Pis have two hardware PWM channels. In addition hardware timed PWM pulses may be independently generated on all the GPIO connected to the 40 pin expansion header.
In practice this means there are two highly accurate PWM channels and all the other GPIOs may have Arduino style PWM (800 Hz, 0 off - 255 fully on).
Nice answer! How can I use those two HW PWMs? I need to control 2 servos, I know you say servoblaster and pigpio are OK for that, but I just wonder about the HW PWM, because I can not find anything about them... are there some docs for it out there? I have an RPi 2 V1.1 for tests.
Ok, thanks. Is the servo control via the gpioServo() function reliable under heavy CPU load too or do I need to use the HW PWM then? I need to process computer vision stack so all my CPU cores will be under decent load... What are the gpioHardwarePWM freq and duty values for the common 50 Hz 1-2ms servo standard?
Heavy CPU load shouldn't make a difference. Heavy network load can make a difference to gpioServo especially if sampling at 1MHz rather than the default 200kHz. The frequency is 50 (Hz), the range of duty cycles will be 0 - 1000000 (mapped to the true underlying value of 0 - 5000000). 1 ms is 1 ms in 20 ms so a dutycycle of 5% so 50000, 1.5ms->7.5%->75000, 2ms->10%->100000.
Can you post the references for this info please. I mean, where are the documents showing the 2 HW driven GPIOs on the Rpi3, for example?
Page 102 of BCM2835 ARM Peripherals shows the various modes that the GPIO can be assigned. Look on-line for which GPIO are led out to the various Pi model expansion headers.
Thanks @joan , I had a look at that, but I'm trying to find the max frequency for the PWM, which should be well above the 125 MHz as shown in that document. Someone mentioned 750 MHz somewhere in a transmitter thread... In addition the headers may not be up-to-date since no datasheet has been released, and nobody has confirmed equivalence to BCM2835.
@user1147688 I suggest you get someone to show you how to set a PWM frequency of 750 MHz then. Let someone enlighten us all.
I agree its too good to be true. So it's probably a typo and should be 750 **kHz**. However, I don't see it completely impossible to be 2-4 times of 125 MHz either.
@user1147688 PLLD (500MHz) is used as the core PWM clock. Because of the way "it" works the PWM core frequency is 250 MHz. To be able to switch on and off (pretty essential for PWM) the maximum is 125 MHz. You could double the figures by using PLLC (1000 MHz) but that PLL varies with the core clock speed.
Hi @joan, I 've seen your post. The "*using PLLC (1000 MHz) but that PLL varies with the core clock speed*" is exactly what I want to know! How so? Where in the kernel sources is this?
Not quite a real-time OS, but RISC OS for Raspberry Pi is cooperative multitasking, so you can easily run an application that has 100% CPU so you can manage your timings much better. Just don't expect to do anything else but your own code.
I read somewhere that there is a hardware limit as to the switching frequency of an output pin, too. I think it was around 20 MHz. So don't expect to be able to pull of 300 MHz PWM or anything of that sort, even with 100% CPU usage.
@PeterMortensen: Well I don't know how radio transmitters and such generate their signals, but some might do it with PWM. PiFM does that at 100 MHz. That seems to contradict my comment though, so I wonder if maybe the pin can still be commanded at that frequency, but it's just that the pin capacitance attenuates such signals, so that a 100 MHz square-wave might actually oscillate from e.g. (1.0 V, 2.3 V) instead of the full (0 V, 3.3 V) range.
I have found this library (pi-blaster) which claims to be "extremely efficient: does not use the CPU and gives very stable pulses."
I've not tested it yet, but will update as soon as I do (probably today)
I've been trying this but so far no luck. So far as I can tell it doesn't actually switch the hardware?