¿Importancia de ARM SysTick Timer frente a otros temporizadores?

Vengo de MCU de 8 bits y he usado un temporizador del sistema para generar una interrupción periódica que parece ser la motivación detrás del temporizador Cortex M SysTick.

¿Hay algún tipo de importancia arquitectónica en el uso del temporizador SysTick en comparación con cualquier otro temporizador en las MCU de Cortex M?

¿Es solo una cuestión de preferencia de codificación que los programadores hayan usado el temporizador SysTick como el temporizador principal cada pocos ms?

El manual de referencia de 800 páginas es bastante silencioso en SysTick, aparte de cómo aplica post/prescalars.

Veo que es una interrupción predeterminada de alta prioridad, por lo que es el camino de menor resistencia para el sistema. Pero la prioridad de interrupción es configurable.

(El origen de esta pregunta es que estoy usando STM32CubeMX para generar una plantilla de proyecto, y cuando va a agregar FreeRTOS, Cube genera una advertencia de que FreeRTOS debe usar un temporizador separado de SysTick... lo que me hace preguntarme si hay ¿Algo más en juego aquí? Acabo de suponer que usarías el SysTick porque así es "cómo se hacen las cosas"...).

SysTick es un temporizador estándar definido por ARM. Mientras que los demás son periféricos específicos de las MCU y no forman parte del núcleo.
¿Tiene mejor latencia que un temporizador periférico? Debido a que es estándar para cada Cortex M, ¿la motivación es más que la portabilidad del código?
Supongo que la diferencia de latencia es insignificante. Es una parte de la definición central. Diría que un núcleo en su mínimo debería tener un conjunto mínimo de HW para poder ejecutar un mínimo de SW. Sin temporizadores en absoluto no será posible.
Y creo que esto siempre está diseñado con un sistema operativo en mente. Entonces, uno puede tener un kernel portátil algo universal y solo tener "controladores" para el hardware variable.
@ Leroy105 En otras palabras, debe comprender que ARM es una empresa (¿vendida hace un año?) Que NO fabrica CPU, sino que ofrece propiedad intelectual (máscaras y/o fuente sintetizable) a quienes fabricarán directamente dichos dispositivos. o negociarlo para la fabricación. Se quedan fuera de la competencia allí. Quienes compren la IP de ARM agregarán sus propios periféricos para diferenciarse de los demás. SysTick es parte de ARM CORE IP. Así que todos los fabricantes de ARM lo tienen. Sin embargo, no todos los ARM tienen algo más. Esto hace que SysTick sea único. ¿Tener sentido?
Sí, eso tiene sentido. Me asusté con el error de FreeRTOS del asunto del cubo. Supuse que FreeRTOS sería registrado por SysTick. Tal vez lo sea, y el error realmente signifique otra cosa. Estoy transfiriendo un código para aprender un RTOS y familiarizarme con Cortex M. El producto real seguirá siendo un 8051.
Creo firmemente que FreeRTOS está cronometrado por SysTick
@Jonk: sí, entiendo totalmente ese final. No me di cuenta de que era una unidad funcional central definida de cada Cortex M. Solo veo un temporizador de 24 bits, que usa cada ejemplo de novato y comienzas a preguntarte si hay algún poder mágico o algo relacionado con este temporizador...
@ Leroy105 Si estuviera escribiendo un sistema operativo (y lo hago con frecuencia), entonces haría un juicio sobre SysTick en función de lo que estoy tratando de lograr. Si no quisiera admitir el uso de varios temporizadores, pero quisiera "codificar" un temporizador con el que pudiera contar, entonces usaría SysTick. Pero si quisiera proporcionar "configurabilidad", entonces permitiría que quien esté compilando el sistema operativo especifique uno para usar, permitiéndole usar temporizadores específicos del proveedor en su tiempo libre.
Uno de estos días, voy a tener que poner mi O/S en libertad, por así decirlo. Está diseñado para permitir todo tipo de opciones de configuración que ni siquiera FreeRTOS ofrece y es compatible con chips extremadamente pequeños que casi no tienen RAM (permitiendo que algunos de los datos constantes por proceso se mantengan en flash). Las prioridades son compatibles, Por ejemplo. Pero si conoce la cantidad de procesos reales en tiempo de compilación y puede especificar sus prioridades, no hay razón para que esos valores no puedan estar en flash. Lo lanzaré si alguna vez tengo tiempo para documentarlo mejor, de todos modos.
@jonk OT: ¿Es un proyecto comercial/propietario? ¿O personal/código abierto?
@EugeneSh. Es el mío que comencé a desarrollar alrededor de 1990, cuando las CPU de 32 bits no se encontraban a menudo en dispositivos integrados. Como resultado, tuve que aislar cuidadosamente todas y cada una de las piezas. Incluso puede configurar si desea o no listas individuales o doblemente enlazadas (RAM frente a compensación de velocidad de inserción/eliminación) simplemente usando un #define para seleccionar en qué dirección desea ir. Admite solo cooperativa o prioridad (aunque la prioridad tiene implicaciones para las bibliotecas), etc. Todo es configurable hasta el nivel de byte. Lo tengo pero no me siento dueño de él.
@EugeneSh. FreeRTOS a menudo es sincronizado por SysTick, pero no siempre. Estoy trabajando en una aplicación de bajo consumo en la que SysTick se apaga en algunos estados, por lo que uno de los otros temporizadores cronometra FreeRTOS.
@brhans ¿Es una funcionalidad lista para usar o tuvo que extender el kernel?
@EugeneSh. Puede leer una pequeña descripción general en Descripción general, escrita en 2008 .
@jonk Genial, gracias. Aunque no tan pequeño :)
@EugeneSh. También lo encontrará "parcialmente editado". Es solo algo que comencé a escribir, pensando que podría lanzarlo entonces. Entonces el trabajo intervino y detuve el esfuerzo. (Verá "notas personales" en su interior, por ejemplo, que necesitan más discusión y expansión). En parte, esto se expandió mucho durante mi trabajo en instrumentos médicos donde no podía comprar, ni usar, un O/ comercial. S ya que estos eran dispositivos críticos que requerían prueba de ejercicio de CADA LÍNEA DE CÓDIGO.
Totalmente fuera de tema, ¿alguien puede opinar sobre esto? ¿Qué es más eficiente, ejecutar un Cortex M a la frecuencia más baja requerida para la tarea y ponerlo en reposo (suponiendo un apagado periférico óptimo, etc.), o ejecutar Cortex M a la velocidad más alta? y ponerlo a dormir. En mi 8051 encontré más eficiencia en el reloj más lento. PIC velocidades más rápidas. Corteza Sra?
@ Leroy105 Mejor plantéelo como una pregunta diferente, pero defina "eficiente" antes.
Agradezco cualquier información: electronics.stackexchange.com/questions/350595/…
@EugeneSh. Extendido por el proveedor de microcontroladores (SiLabs) como parte de su 'pila'.
@ Leroy105, ¿qué decía la hoja de datos de la pieza? Un cortex-m es solo el núcleo, el brazo no fabrica chips, sino IP, el proveedor de chips compra esa lógica y fabrica un chip en alguna fundición con algún proceso, fuga, etc.

Respuestas (1)

Como se responde en los comentarios.

El SysTick, si está presente, es parte del núcleo ARM, los otros temporizadores son del proveedor del chip. SysTick tiene un evento más directo (piense en interrupción) en el núcleo donde los otros tiempos entran a través de interrupciones, no es que eso importe. Y otros temporizadores tienden a tener más funciones.

Etiquetó Cortex-M, por lo que es probable que sea un microcontrolador, lo que significa que podría estar haciendo baremetal, lo que significa que puede hacer lo que quiera, usted decide qué temporizadores hacen qué. Si toma algunos RTOS u OS ya creados para ese chip, entonces han decidido qué recursos quieren consumir y por qué. Principalmente basado en la opinión en lo que respecta a eso.

El temporizador de sysstick es mucho más fácil y simple de poner en marcha, y no siempre está presente, algunos núcleos no lo tienen como una opción y otros como una opción (para que el proveedor del chip decida en el momento de la compilación), por lo que tiene esa ventaja. , aunque puede haber algunos temporizadores en algunos chips que sean igualmente sencillos.

Los temporizadores de proveedores de chips a veces pueden controlar los pines de E/S o tener alguna participación externa donde el sysstick está AFAIK contenido dentro del núcleo.

¿Importancia de ARM SysTick Timer frente a otros temporizadores?
RespuestasAquíPolítica de privacidad1y, 0v