Tutorial completo de salidas PWM en Raspberry Pi 5

Inicio » Windows » Tutorial completo de salidas PWM en Raspberry Pi 5

La Raspberry Pi 5 ha dado un salto importante en potencia y en posibilidades de control de hardware, y uno de los puntos clave para proyectos de electrónica, robótica y automatización es el uso de sus salidas PWM para gobernar LEDs, servomotores y motores de corriente continua. Si vienes de modelos anteriores de Raspberry o de placas como Arduino, verás que aquí el enfoque es un poco distinto, sobre todo por cómo se configuran los pines y los overlays del sistema.

En este artículo vamos a ver con calma cómo funciona el PWM en la Pi 5, qué diferencias hay entre PWM por hardware y PWM por software, cómo activar correctamente los canales desde /boot/firmware/config.txt usando dtoverlay=pwm y cómo manejarlos desde Python con librerías como pigpio, gpiozero o utilidades basadas en sysfs. De paso, resolveremos algunas dudas típicas que suelen aparecer (por qué no se enciende un LED, problemas con los canales, errores de configuración, etc.).

Qué es el PWM y por qué es tan útil en Raspberry Pi 5

Cuando hablamos de PWM (Pulse Width Modulation) nos referimos a una técnica que permite generar una señal digital que, vista desde fuera, se comporta como una señal “pseudoanalógica” variando su ciclo de trabajo. En lugar de cambiar el voltaje de salida, lo que se ajusta es el tiempo que la señal pasa en nivel alto (ON) frente al tiempo que pasa en nivel bajo (OFF) dentro de un ciclo completo.

En la práctica, muchos dispositivos interpretan esa señal PWM como si fuera analógica: un LED variará su brillo, un motor de DC cambiará su velocidad en función del porcentaje de tiempo en alto, y un servo interpretará ciertos rangos de ancho de pulso para fijar su posición. Es decir, no estamos sacando un voltaje variable real, pero el efecto sobre la carga es muy similar en la mayoría de aplicaciones comunes.

La Raspberry Pi 5 sigue este esquema: sus GPIO trabajan a nivel digital, pero gracias al PWM podemos controlar intensidad, velocidad y posición sin necesidad de un DAC externo en muchos escenarios. Eso sí, conviene distinguir bien entre PWM por hardware, que ofrece precisión y estabilidad, y PWM por software, más flexible pero dependiente de la carga de la CPU.

Un detalle importante es que, cuando regulas el ciclo de trabajo (duty cycle), lo que ajustas realmente es la proporción de tiempo activo dentro del periodo total. Por ejemplo, un PWM al 50 % estará la mitad del ciclo en alto y la otra mitad en bajo, y un PWM al 10 % apenas tendrá pulsos cortos. Esta proporción es lo que, por ejemplo, un servo de tipo feedback usará para codificar una señal de retorno basada en tHigh/tCycle, relacionando directamente ese cociente con una posición angular.

Salidas PWM de hardware en Raspberry Pi 5

La Pi 5 dispone de un conjunto de pines capaces de ofrecer PWM por hardware, gestionados por el chip RP1. En concreto, destacan GPIO18 y GPIO19 como salidas PWM de hardware muy utilizadas (asociadas a PWM0 canales 0 y 1 respectivamente), adecuadas cuando necesitas una señal precisa y estable, por ejemplo, para controlar servos estándar, motores de precisión, o cuando tu sistema va a estar bastante cargado de procesos.

Estos pines no salen ya “preparados” para PWM; necesitan que les asignes la función alternativa correcta. En el caso de GPIO18, se suele usar el modo ALT3 para asociarlo al canal PWM0_CH0. Así, a nivel de software podrás usar una librería como pigpio para generar señales de, por ejemplo, 8 kHz con un duty cycle del 50 % durante varios segundos sin que la carga de la CPU afecte en exceso al resultado.

Un ejemplo típico es conectar un LED (con su correspondiente resistencia en serie) entre GPIO18 y GND y variar el ciclo de trabajo para ajustar el brillo. Con la Pi 5 resulta especialmente interesante usar PWM de hardware en proyectos de control intensivo, donde un PWM por software podría sufrir jitter o variaciones si el sistema operativo está ocupado con otras tareas.

Además, el subsistema PWM del RP1 se expone también a través de interfaces como sysfs (/sys/class/pwm) y, de forma más detallada, mediante /sys/kernel/debug/pwm. Estas rutas te permiten inspeccionar qué canales están activos, sus periodos, ciclos de trabajo y estado (habilitado o no), lo cual es fundamental a la hora de depurar por qué un determinado pin no está sacando la señal que esperas.

Configuración de funciones de pin y overlays de PWM

Para que esos pines comiencen a comportarse como salidas PWM de hardware en la Raspberry Pi 5, hay que pasar por un proceso de configuración mediante overlays del dispositivo. La forma recomendada es editar el archivo /boot/firmware/config.txt y usar la directiva dtoverlay=pwm atribuyendo pines concretos a un canal PWM.

Antes de tocar nada, es muy útil inspeccionar qué funciones alternas soporta un determinado GPIO. Para ello, existe la herramienta pinctrl, que permite listar las funciones asociadas al multiplexor de pines. Un comando típico sería:

pinctrl funcs 18

Ejecutando, por ejemplo, sudo pinctrl funcs 18 verás las funciones posibles de GPIO18 y, entre ellas, la función correspondiente a PWM0. Así te aseguras de que ese pin puede usarse realmente para PWM de hardware y qué modo alternativo hay que configurar si lo gestionas a bajo nivel.

El siguiente paso es editar el archivo de configuración de arranque. Un ejemplo muy común para activar PWM en varios pines simultáneamente sería añadir líneas como estas a /boot/firmware/config.txt:

dtoverlay=pwm,pin=12,func=3
dtoverlay=pwm,pin=13,func=3

La documentación indica que un solo dtoverlay=pwm puede gestionar múltiples pines si se especifican adecuadamente, y cada uno obtendrá su asignación de canal PWM a través del sistema de overlays. No obstante, en la práctica y especialmente con la Pi 5, se ha observado que a menudo es más estable y más fácil de depurar usar entradas dtoverlay=pwm separadas por pin, en lugar de overlays combinados tipo pwm-2chan que pueden no ser compatibles con el RP1.

Después de modificar config.txt, hay que reiniciar la Pi para que el overlay se cargue. Al volver a arrancar, deberías poder comprobar la presencia de los canales PWM en sysfs y validar que el sistema ha expuesto correctamente los chips de PWM y sus salidas asociadas.

Verificación de canales PWM desde el sistema

Una vez que tienes configurado el overlay de PWM, lo primero es confirmar que el sistema ve los canales. En Linux, los dispositivos PWM suelen aparecer en /sys/class/pwm. En la Pi 5, podrás encontrar algo como /sys/class/pwm/pwmchip0/ (y en algunos casos más chips, dependiendo de la configuración).

Para ver qué hay dentro, puedes ejecutar:

ls /sys/class/pwm/pwmchip0/

Si todo está bien, deberían mostrarse entradas como pwm0 y pwm1 correspondientes a los distintos canales disponibles en ese chip. Si no aparecen, lo más probable es que el overlay no se haya cargado correctamente o que el pin no esté asignado al PWM que crees.

Para un diagnóstico más detallado, el archivo /sys/kernel/debug/pwm ofrece una visión de bajo nivel de todos los controladores PWM. Ejecutando:

sudo cat /sys/kernel/debug/pwm

verás listados del estilo pwm-0 (sysfs): requested enabled period: … duty: … polarity: normal, que indican si un canal está solicitado, habilitado, su periodo en nanosegundos y el ciclo de trabajo configurado. Esto es muy útil si tu código supuestamente está cambiando el duty cycle pero no observas ningún efecto en el pin: podrás confirmar si el kernel realmente ha aceptado y aplicado esos valores.

Otro punto de verificación es leer el valor de enable en la ruta del canal PWM, por ejemplo:

cat /sys/class/pwm/pwmchip0/pwm0/enable

Si devuelve 1, el canal está activo; si devuelve 0, está desactivado. Esto te permite saber si tu programa está habilitando el PWM o simplemente configurando el periodo y el ciclo sin llegar a encender el canal. En escenarios de depuración, muchos usuarios han descubierto así que el PWM estaba correctamente configurado pero no se llegaba a habilitar, o incluso que el canal usado (por ejemplo, pwm_channel=0) no correspondía al que realmente estaba cableado al GPIO que utilizaban.

Control de PWM en Raspberry Pi 5 con Python y pigpio

Para proyectos en Python, la combinación de Raspberry Pi 5 y la librería pigpio está muy bien valorada porque facilita el uso de PWM por hardware y ofrece buena precisión. Aunque RPi.GPIO cuenta con una funcionalidad de PWM, el soporte para la Pi 5 es limitado en versiones actuales, así que se suele recomendar pigpio o librerías que se apoyen en él.

Primero hay que instalar y habilitar el demonio pigpio:

sudo apt install pigpio
sudo systemctl enable pigpio

Una vez instalado, en tu script Python puedes hacer algo como esto para generar un PWM de 8 kHz con un ciclo de trabajo del 50 % en el GPIO18, usando el canal PWM0 CH0:

import pigpio
import time

pi = pigpio.pi()
if not pi.connected:
    exit(1)

pi.set_mode(18, pigpio.ALT3)
pi.hardware_PWM(18, 8000, 500000)
time.sleep(10)
pi.set_PWM_dutycycle(18, 0)
pi.stop()

La llamada a pi.hardware_PWM(18, 8000, 500000) fija una frecuencia de 8000 Hz y un duty cycle del 50 %, porque el parámetro de duty en pigpio se expresa en una escala de 0 a 1 000 000 (en este caso, 500 000 equivale a un 50 %). Antes de ello, pi.set_mode(18, pigpio.ALT3) configura el GPIO18 en la función alternativa que lo asocia al canal PWM de hardware adecuado.

Esta aproximación con pigpio resulta ideal para tareas donde necesitas una frecuencia relativamente alta y un duty cycle estable, como control de motores DC con drivers externos o atenuación suave de LEDs sin que parpadeen al cambiar de intensidad. Además, la propia API de pigpio permite combinar PWM de hardware y PWM por software en otros pines dentro del mismo proyecto.

Si únicamente quieres un PWM sencillo para, por ejemplo, un LED, sin grandes exigencias de precisión, puedes optar por una alternativa basada en PWM por software usando la librería gpiozero. Un ejemplo sería:

from gpiozero import PWMLED
from signal import pause

led = PWMLED(18)
led.value = 0.5
pause()

En este caso, cualquier pin GPIO sirve en principio para PWM por software, y gpiozero se encarga de generar la señal. No es tan robusto frente a cargas pesadas o timings muy estrictos, pero para atenuar LEDs o controlar servos de forma sencilla suele funcionar de maravilla y con código muy limpio.

Uso de PWM software vs hardware: cuándo elegir cada uno

La gran cuestión práctica es cuándo tiene sentido complicarse un poco más con overlays, modos alternativos y librerías de bajo nivel, y cuándo basta con un PWM por software más directo y flexible. La respuesta se reduce, básicamente, a las necesidades de precisión, estabilidad y número de canales PWM que tu proyecto requiera.

El PWM de hardware es la opción preferida cuando vas a controlar dispositivos sensibles a variaciones de tiempo, como ciertos servos de precisión, motores que funcionan a frecuencias relativamente altas, o cuando el sistema operativo va a estar bajo carga intensa y no quieres que los pequeños retardos en el scheduler afecten a la señal. Además, si necesitas frecuencias concretas y duty cycles muy estables, el PWM por hardware es claramente superior.

En cambio, la generación de PWM por software (bit-bang) se defiende muy bien en aplicaciones no críticas: atenuación de LEDs decorativos, control simple de velocidad de un motor donde no te importa un poco de variación, o servo­motores que no exigen una precisión brutal de temporización. La ventaja del PWM por software es que puedes usar prácticamente cualquier GPIO y no dependes tanto de la configuración del RP1 ni de los overlays.

En el contexto de la Raspberry Pi 5, muchos usuarios han optado por un enfoque mixto: usar salidas PWM de hardware para los elementos clave del robot o sistema (por ejemplo, dos motores principales o servos de dirección) y PWM por software para LEDs de estado o elementos accesorios. Así se mantiene el control preciso donde importa y se simplifica el resto del diseño.

La elección también dependerá del número de canales PWM que necesitas. El hardware ofrece un número limitado de salidas, mientras que por software puedes multiplexar muchos más, a costa de la carga de la CPU y la precisión. Por eso, si tu montaje incluye varios servos con encoders y sensores, quizá tenga sentido reservar los canales de hardware para las partes más críticas del lazo de control y dejar el resto al PWM por software.

Ejemplo práctico: problemas comunes al usar librerías de PWM en Pi 5

Un caso muy ilustrativo es el de un usuario que intentaba usar el PWM de hardware de la Raspberry Pi 5 para controlar un LED en el GPIO18 siguiendo dos tutoriales basados en rpi-hardware-pwm y syspwm. El enfoque consistía en editar /boot/firmware/config.txt, activar el PWM, y después lanzar un pequeño script de prueba, pero el LED nunca llegaba a encenderse, pese a que desde el sistema parecía que el canal PWM sí estaba activo.

En el primer intento, con el paquete rpi_hardware_pwm, el código tenía esta forma:

from rpi_hardware_pwm import HardwarePWM
from time import sleep

pwm = HardwarePWM(pwm_channel=0, hz=333, chip=2)
pwm.start(100)
sleep(2)
pwm.stop()

También se probó con chip=0. En la terminal se podía ver que el sistema cambiaba correctamente el duty cycle y que el canal aparecía como “requested enabled” en /sys/kernel/debug/pwm. Ejecutar cat /sys/class/pwm/pwmchip0/pwm0/enable devolvía 1 mientras el script corría y 0 al terminar, indicando que el PWM se activaba y desactivaba según lo esperado.

En el segundo tutorial, usando un pequeño módulo llamado syspwm.py, el patrón era similar:

from syspwm import SysPWM
import atexit

pwm = SysPWM(0)
pwm.set_frequency(333)
pwm.set_duty_cycle(2)
atexit.register(pwm.disable)
pwm.enable()
sleep(5)

También en este caso se observaban cambios en sysfs y en /sys/kernel/debug/pwm pero el LED seguía sin reaccionar. Al final, el problema estaba en algo mucho más sutil: el canal PWM seleccionado no correspondía realmente al GPIO que se estaba utilizando, o el chip de PWM usado (chip=2) no era el adecuado para ese pin concreto en la Pi 5.

La solución llegó al ajustar el parámetro a pwm_channel=2 en la llamada a HardwarePWM. Al hacerlo, todo empezó a funcionar como se esperaba; el LED reaccionó y se pudo controlar el brillo. Esto muestra lo delicado que puede ser el mapeo entre número de chip, canal y GPIO físico en la Raspberry Pi 5, especialmente cuando usas librerías que asumen una numeración derivada de cómo expone el kernel los chips PWM.

Medición y uso de señales PWM de retroalimentación en servos con encoder

Cuando entras en el terreno de la robótica con servos que incluyen encoder interno, la cosa se pone más interesante. Un ejemplo popular es el Parallax Feedback 360, un servo continuo que no solo acepta una señal PWM de entrada para girar, sino que además ofrece una salida de retroalimentación basada en PWM para indicar su posición relativa.

En este tipo de servo, la entrada PWM suele ir a una frecuencia fija (en el caso mencionado, unos 910 Hz) con un duty cycle que varía dentro de un rango amplio, por ejemplo, del 2,7 % al 97,1 %, para controlar la velocidad y dirección de giro. A su vez, la señal de retroalimentación se codifica midiendo el cociente tHigh/tCycle, es decir, cuánto dura el pulso en alto dentro del periodo total, lo que se corresponde con el ángulo de una vuelta completa en sentido horario.

Para medir esa retroalimentación en una Raspberry Pi 5, tienes varias opciones. La más directa es usar una librería con capacidad de capturar tiempos de subida y bajada de la señal con buena resolución, como pigpio, y calcular el duty cycle efectivo de la señal de feedback. La idea sería registrar los instantes de transición de la señal de entrada (subida y bajada), calcular el periodo y el tiempo en alto, y a partir de ahí obtener el valor de tHigh/tCycle.

Otra opción, si quieres aislar la medición del resto del sistema, es usar un pequeño microcontrolador dedicado (tipo Arduino o similar) para medir la señal de feedback y comunicar a la Pi 5 la posición ya procesada por puerto serie o I2C. Pero si decides hacerlo directamente en la Raspberry, es crucial que tu código maneje interrupciones o callbacks precisos, y no se limite a leer valores de estado con retardos, porque podrías perder precisión o muestreos.

En cualquier caso, al trabajar con servos de este tipo, conviene revisar bien la hoja de datos para conocer el rango exacto de duty cycles que representan una vuelta completa, el sentido de giro asociado a cada extremo del rango y la frecuencia exacta de la señal, ya que pequeñas variaciones pueden generar resultados inconsistentes. La Raspberry Pi 5, con sus capacidades mejoradas y librerías como pigpio, ofrece herramientas suficientes para manejar tanto la señal de control como la de retroalimentación con un nivel de detalle más que aceptable.

Lista de comprobación y diagnóstico de problemas típicos de PWM

Trabajar con PWM en Raspberry Pi 5 implica combinar configuración de hardware, overlays, librerías de usuario y, por supuesto, el cableado físico. Es normal encontrarse con comportamientos raros al principio, así que tener una pequeña lista de comprobación viene muy bien para no volverse loco. A continuación se recogen síntomas habituales, posibles diagnósticos y formas de resolverlos.

Si te encuentras con un error de comando relacionado con gpio inválido o una sintaxis extraña en config.txt, puede que estés usando parámetros heredados de guías antiguas. En la Pi 5 se recomienda evitar parámetros como gpio= en config.txt para configurar funciones especiales y, en su lugar, usar dtoverlay=pwm u otros overlays específicos. El primer paso ante un error de configuración es simplificar el archivo de arranque, eliminar directivas dudosas y partir de ejemplos conocidos que funcionen.

Otro problema frecuente es que nunca aparezca PWM1 (o cierto chip PWM) en /sys/class/pwm, pese a que has añadido un overlay tipo pwm-2chan. En el contexto del RP1 de Raspberry Pi 5, algunos overlays multicanal no son compatibles, por lo que la solución pasa por definir overlays individuales por pin mediante dtoverlay=pwm,pin=… en lugar de overlays combinados. Volver a arrancar tras el cambio y volver a listar los contenidos de /sys/class/pwm te permitirá comprobar si ahora se exponen los canales esperados.

Si no aparecen entradas en /sys/class/pwm en absoluto, lo más probable es que el overlay no se haya cargado. En ese caso, es útil ejecutar:

sudo dtoverlay -l

para listar los overlays del árbol de dispositivos actualmente cargados. Si no ves tu overlay de PWM, revisa de nuevo /boot/firmware/config.txt y asegúrate de que la sintaxis es correcta, que no hay comentarios mal cerrados ni parámetros conflictivos. En casos puntuales, puedes intentar cargar el overlay manualmente con sudo dtoverlay pwm para ver si genera errores inmediatos que te den pistas.

La ausencia de señal en el osciloscopio o en un analizador lógico, incluso cuando el sistema indica que el canal PWM está habilitado, suele deberse a que la función de pin no está correctamente configurada como PWM. Herramientas como raspi-gpio get permiten volcar el estado actual de los GPIO y ver qué función alternativa tienen asignada. Si tu pin sigue apareciendo como salida estándar o entrada, deberás cambiarlo explícitamente a la función alternativa correspondiente al PWM, ya sea mediante pigpio, pinctrl u otra utilidad.

Por último, si tu código parece correcto pero el dispositivo no responde, no olvides repasar el cableado físico (resistencias, masa común, alimentación, etc.) y, si puedes, usar un osciloscopio o analizador lógico para confirmar que efectivamente hay una onda cuadrada limpia a la frecuencia configurada y con el duty cycle que has establecido en el software. Esto te evita perseguir errores de configuración cuando, en realidad, el problema está en un cable suelto o una referencia de tierra mal conectada.

Con todo lo anterior, la Raspberry Pi 5 se convierte en una plataforma muy potente para proyectos que necesiten un control fino mediante PWM, desde la simple regulación del brillo de un LED hasta robótica con servos con feedback y automatización industrial básica. Comprendiendo bien la diferencia entre PWM de hardware y software, utilizando overlays correctamente y apoyándote en herramientas de verificación como sysfs, debugfs y utilidades tipo raspi-gpio o dtoverlay, es relativamente sencillo conseguir salidas estables y fiables que no se vean comprometidas por la carga del sistema o por errores de configuración del RP1.