He estado usando microcontroladores ARM de NXP en productos comerciales con gran éxito durante los últimos 2 años.
En la mayoría de mis proyectos, no uso el PLL para aumentar la frecuencia del oscilador porque nunca encontré que fuera necesario (nunca sentí que la frecuencia del reloj fuera un problema) y porque el PLL aumenta ligeramente el consumo de energía.
Sin embargo, no sé cómo puedo medir qué frecuencia de reloj es suficiente para alimentar mi código. Estoy atascado con esta pregunta en mi cabeza porque, como sabrá, cuanto más rápido sea el reloj que use, más energía terminará consumiendo. Dado que en estos días los equipos portátiles con baterías limitadas son comunes, este es un tema importante.
La pregunta principal aquí es ¿cómo puedo saber si la frecuencia de reloj actual es suficiente para mi código?
En esta pregunta digo "detención o retrasos" porque asumo que si la frecuencia de mi reloj no es suficiente, el primer síntoma que ocurrirá es un tiempo de respuesta lento debido a rutinas que consumen mucho tiempo.
Casi en mis proyectos utilizo un sistema de máquina de estado que tiene una OnIdle()función que se llama cuando el sistema no tiene ningún evento para procesar, por lo que puede poner la MCU en un modo de bajo consumo. Estaba pensando en medir cuánto tiempo permanece el sistema en esta función y registrar marcas de agua mínimas y máximas de esta medida para tener números reales sobre si el reloj actual del sistema es o no suficiente.
¿Alguien tiene sugerencias para esto?
En caso de que sea difícil o imposible estimar la frecuencia requerida teóricamente (basado en cálculos y el conocimiento de la microarquitectura) o basado en la experiencia (código similar en una máquina similar), se puede tomar el enfoque empírico. Una técnica común para escribir una aplicación integrada en tiempo real es hacer que el bucle principal tenga una duración fija. Entonces su ciclo principal se verá así:
while (true)
{
doStuff();
waitSync();
}
waitSyncaquí es impulsado por algún tipo de interrupción del temporizador. Al agregar un indicador como la salida del pin GPIO como este:
while (true)
{
gpioOn();
doStuff();
gpioOff();
waitSync();
}
y al colocar una sonda de alcance en ese GPIO, obtendrá un buen tren de pulsos, cuyo ciclo de trabajo indicará el porcentaje del tiempo de la CPU, cuando en realidad está "haciendo cosas".
Estás pensando en esto al revés. La pregunta no es "¿cómo puedo saber si mi código que se ejecuta con su reloj actual es suficiente?" , es "¿cómo diseño mi código para saber si se está ejecutando correctamente?
Los microcontroladores son algo opacos. Son una plataforma difícil de depurar. Debe desarrollar el hábito de dividir el código en fragmentos comprobables, utilizando técnicas como la alternancia de bits para probar cada fragmento y luego probar todo el sistema. Construir las pruebas debe convertirse en parte de su proceso de pensamiento y comienza antes de escribir cualquier código.
Hay diferentes formas de quedarse sin tiempo con el código del microcontrolador. Es posible que se quede sin ancho de banda total, en cuyo caso definitivamente debe cambiar algo (mejores algoritmos, mayor frecuencia de reloj, tal vez una mejor arquitectura).
Antes de que eso suceda, es posible que obtenga efectos más sutiles, como fluctuaciones excesivas en las rutinas de servicio de interrupción o el servicio de eventos de baja prioridad, como la interfaz de usuario.
Por lo general, es deseable tener un poco de margen en el ancho de banda total: quedarse sin velocidad (o memoria) no es muy divertido a menos que tenga una ruta de actualización clara (como aumentar la velocidad del reloj o colocar un micro más costoso que es compatible hacia arriba).
Puede perfilar el código en simulación o alternando un pin GPIO como sugiere Eugene, sin embargo, tenga en cuenta que en micros como el ARM, el GPIO está desacoplado del micronúcleo por un bus relativamente lento, por lo que el perfilado debe realizarse en intervalos de tiempo relativamente grandes. .
También debe mirar las especificaciones (y tal vez probar) para ver cuáles son las ventajas y desventajas con la velocidad del reloj y los numerosos modos de funcionamiento típicos del micro. Si solo está inactivo en los bucles de espera y no realiza ningún control de potencia, parte de la corriente de suministro será proporcional a la frecuencia (en un primer orden). Sin embargo, si se despierta, hace algunas cosas y luego se va a dormir, el efecto de una frecuencia de reloj más alta puede no ser tan significativo (incluso podría ser una mejora), ya que el ciclo de trabajo será menor y tal vez algunos periféricos pueden ser poner en un modo de baja potencia durante más tiempo a la frecuencia de reloj más alta.
Wouter van Ooijen
Welgriv