Problema de velocidad RPi GPIO en bare metal

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

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

De la página 106 de la hoja de datos del periférico BCM que proporcionó

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

Esto es en el contexto de configurar el periférico GPIO para generar el reloj periférico directamente sin alternar el software.

Diría que es razonable esperar que incluso si los relojes están configurados correctamente y la CPU funciona a la velocidad máxima, no puede esperar que un GPIO cambie más rápido que esto debido a limitaciones de hardware.

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

Cómo proceder

Parece que si su objetivo es conducir GPIO tan rápido como lo necesita, para fines de reloj, debe usar estos pines de salida de reloj incorporados 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, según 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 el reloj del sistema, el enrutamiento del reloj y los PLL de manera adecuada.

Una vez que haya identificado ese desacuerdo, puede modificar su código de arranque básico para configurar los PLL y ver si se puede hacer que un cambio controlado por software se ejecute tan rápido como la salida del reloj controlada por hardware y continuar desde allí.

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

Acabo de encontrar esta pregunta en una publicación cruzada.
El problema principal que no se discute en todos los comentarios anteriores es la velocidad del autobús.. El procesador puede funcionar a 3 GHz, pero los buses del chip no. El bus del lado ARM es mucho más lento que 3GHz. El bus hacia el GPIO es aún más lento, funcionando a la velocidad de la GPU. Agregue a eso el tiempo perdido por 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 respuesta del bus. En la infraestructura del bus, se necesitan varios ciclos de reloj para llevar la señal de un lado del bus al otro (pero permite que haya múltiples transacciones en el bus al mismo tiempo).