Problema de velocidad RPi GPIO en el metal desnudo

El culpable principal es una combinación de limitaciones de hardware / periféricos y la configuración del reloj. Si bien no he tenido que trabajar con BCM Baremetal específicamente, estos son problemas comunes de los proyectos de baremetal en cualquier arquitectura compleja.

Como una sugerencia sobre las limitaciones de los controladores de salida GPIO, puede ver que cuando está cableado como salida de reloj de hardware, la frecuencia máxima de salida es de 125MHz

De la página 106 de la Hoja de Datos Periféricos de BCM que proporcionó

  

Frecuencia de funcionamiento :   La frecuencia máxima de funcionamiento de los relojes de uso general es de ~ 125 MHz a 1.2 V, pero   esto se reducirá si los pines GPIO están muy cargados o tienen una carga capacitiva.

Esto se encuentra en el contexto de la configuración del periférico GPIO para emitir el reloj periférico directamente sin alternar el software.

Yo diría que es razonable esperar que incluso si los relojes están configurados correctamente y la CPU se ejecuta a una velocidad máxima, no puede esperar que un GPIO alterne más rápido que esto debido a las limitaciones de hardware.

También porque el dispositivo periférico puede bloquear el comando de su software a tiempo, no significa que los transistores de controlador de salida físicos, que son grandes y robustos, con una gran cantidad de carga inherente, puedan cambiar tan rápido como su código pueda ejecutarse. Si está realizando pruebas, es imperativo que se utilice un osciloscopio con suficiente ancho de banda analógico y sondas de alta calidad, ya que también está cambiando su resultado con el sistema de medición. Un analizador lógico puede no ser suficiente, una velocidad de giro lenta no es identificable con las entradas con umbral.

Cómo proceder

Parece que si tu objetivo es conducir GPIO tan rápido como lo necesites, para propósitos de reloj, deberías usar estos pines integrados de salida de reloj del periférico. Estos se configuran a través de registros

CM_GP0CTL CM_GP0DIV (repita para las salidas de reloj gp 1 y 2)

Luego, dependiendo de los resultados de esto, identificará la frecuencia de conmutación máxima para su sistema de hardware teniendo en cuenta la carga máxima de GPIO y el VDD de su circuito PIO.

Si la salida del reloj es más lenta de lo esperado para la configuración de su divisor nominal, esto indicaría que no ha configurado correctamente el reloj del sistema, el enrutamiento del reloj y los PLL.

Una vez que haya identificado ese desacuerdo, puede modificar su código de arranque directo para configurar los PLL y ver si se puede realizar una conmutación controlada por software para que se ejecute tan rápido como la salida de reloj controlada por hardware y vaya desde allí.

Es posible que existan factores contribuyentes adicionales en las caché de instrucciones y datos, que requieren la configuración del software, si no puede alinear el software alternando con el límite de hardware a través de PLL solo, ese sería el próximo lugar donde buscaría.

Acabo de encontrar esta pregunta desde una publicación cruzada.
El problema principal que no se trata en todos los comentarios anteriores es la velocidad del bus . El procesador puede estar funcionando a 3GHz pero los buses en el chip no lo están. El bus en el lado ARM es mucho más lento que 3GHz. El bus hacia el GPIO es incluso más lento, corriendo a la velocidad de la GPU. Agregue a eso el tiempo perdido para el cruce del dominio del reloj y el hecho de que los buses son un recurso compartido entre los núcleos ARM y la GPU. Además, el chip utiliza el sistema AXI que tiene un reconocimiento de escritura, por lo que el procesador puede esperar a que llegue el reconocimiento de escritura, que es el doble de la velocidad de giro del bus. En la infraestructura del bus, se requieren varios ciclos de reloj para obtener la señal de un lado del bus al otro (pero permite que se realicen múltiples transacciones en el bus al mismo tiempo).