STM8L Temporizador 1 inesperadamente baja frecuencia de desbordamiento

Navega tus respuestas
2

Estoy ejecutando el MCU fuera del oscilador interno de alta velocidad (16MHz, confirmado) y configuré el temporizador 1 para desbordar con la máxima frecuencia de desbordamiento: 

/* No system clock pre-division, overflow upon reaching 0x0001 (starting from 0x0000) */
TIM1_TimeBaseInit(0, TIM1_CounterMode_Up, 0x0001, 0);

Una vez en la rutina de manejo de desbordamiento del temporizador 1, alterno un pin. Por alguna razón, solo estoy obteniendo una onda cuadrada de 32 kHz en ese pin (por lo tanto, la frecuencia de interrupción de 64 kHz).

¿Por qué es tan lento?

El mismo problema también ocurre con otros temporizadores.

Actualización: Ok, entonces ejecuté el temporizador con una configuración razonable. A continuación se muestran los resultados para:

500 cuentas

300cuentas

200 cuentas (inestable como el infierno)

100cuentas

50 cuentas (la frecuencia es igual a 0 cuentas)

    
pregunta andrey g

2 respuestas

2

Ok, entonces la CPU está funcionando a 16MHz. Tiene un valor de "contar hasta" de 1. El contador comienza en 0. Después de 1 marca, el contador estará en 1, por lo que se produce la interrupción y el contador se reinicia.

Segundo tick ingresas el ISR y empiezas a empujar registros a la pila. El contador aumenta a 1, por lo que la interrupción se produce y el contador se restablece.

Tercera marca, todavía está en el ISR desde antes, sigue presionando los registros en la pila, y estará en el futuro previsible. Pero quieres que vuelva a entrar en el ISR y ya estás allí. Así que la interrupción se retrasa.

Cuarto tic. Todavía estás empujando a la pila, el contador aumenta a 1, por lo que la interrupción se dispara. La interrupción ya está en cola, por lo que no ocurre nada. El contador se reinicia a 0.

Finalmente, después de muchos muchos tics e interrupciones perdidas, finaliza el ISR y vuelve al flujo normal del programa. Inmediatamente, el ISR se ejecuta nuevamente debido a la interrupción retrasada de antes, y todo el ciclo comienza de nuevo.

Lo que está tratando de hacer: ejecutar una interrupción cada vez que se active el reloj de la CPU, no es físicamente posible. Las interrupciones toman tiempo para ejecutarse.

No puede desencadenar una interrupción más rápido de lo que tarda en procesarse.

    
respondido por el Majenko
1

Debería probar esto con un número más realista de "contar hasta". Hay tics de reloj asociados con la entrada y salida de interrupciones, y no debe esperar una buena funcionalidad con una interrupción cada pocos tics. Pruébelo con 100 o 200, y háganos saber qué sucede. Todavía no esperaría que el temporizador fuera tan lento como lo es, incluso con tus ajustes, pero deberías crear un caso de prueba realista.

Con los higos actualizados, el período para el conteo de 100 es de aproximadamente 38 microsegundos, por lo que los ticks de 100 conteos son de aproximadamente 19 microsec

(19e-6) / 100 sería la tasa de conteo del reloj, = 19e-8.

1 / 19e-8 = 5.3 MHz

No estoy seguro de a qué velocidad está programada su autobús para ir a

    
respondido por el Scott Seidman

Lea otras preguntas en las etiquetas

FIFO en el módulo ethernet Atmel y la bobina se cierran en una placa: ¿la interferencia es un problema?