Go Down

Topic: [SOLUCIONADO] Reemplazar millis por defecto (Read 3438 times) previous topic - next topic

Lucario448

Jan 04, 2017, 08:19 pm Last Edit: Jan 14, 2017, 03:21 am by Lucario448 Reason: Dar por concluido este hilo.
Hola a todos. Cómo el título dice, quiero reemplazar la implementación por defecto de millis, por una más precisa (que utiliza el timer1); así que mis dudas son las siguientes:

  • ¿Se puede deshabilitar la interrupción que millis necesita?
  • ¿Es posible redefinir una función sin necesidad de modificar los archivos fuente usados por la IDE?
  • ¿Podría realizar dichos cambios con solo incluir una librería?


La última pregunta es un poco más "técnica", así que ojalá alguien sepa respondérmela:
¿Necesito reiniciar "manualmente" el contador del timer1 cada vez que ocurre una interrupción por comparación de valores?


Agredezco cualquier respuesta... :)

Alfaville

Hola Lucario448

Ahí van algunos datos básicos:
... ¿Se puede deshabilitar la interrupción que millis necesita?
Sí, se puede, pero eso deja fuera de servicio a ,millis(), micros() y delay():
¿Es posible redefinir una función sin necesidad de modificar los archivos fuente usados por la IDE?
Desde un punto de vista teórico, sí. Desde un punto de vista práctico, no.
¿Podría realizar dichos cambios con solo incluir una librería?
Si creas una nueva funcion, mi_millis() por ejemplo, y la extiendes a mis_micros() y a mi_delay(), y la empaquetas en una libreria mis_tiempos.cpp, entonces sí que sería posible pero no sería compatible con lo que hay.
La última pregunta es un poco más "técnica", así que ojalá alguien sepa respondérmela:
¿Necesito reiniciar "manualmente" el contador del timer1 cada vez que ocurre una interrupción por comparación de valores?

Agredezco cualquier respuesta... :)
No es indispensable. Segun el modo de funcionamiento que utilizaras para el timer1 (es el que usarias, supongo), podria resetearse el contador en espera de volver a alcanzar la cuenta deseada.
Por cierto, hasta donde yo conozco la funciones de tiempo estandar (millis, micros y delay), son precisas hasta donde la programacion lo permite, y usan un timer para la cuenta de los tiempos.

Naturalmente esto se basa en lo que sé y no está libre de errores.
Estamos aprendiendo.

surbyte

Quieres mejor la precisión de millis() y porque no usas micros()?

noter

Intuyo que lo que quiere es crear una función millis más exacta y "natural".

Tal y como viene definido millis por defecto, para un reloj de 16 Mhz utiliza un prescaler de 64, con lo que cada conteo del timer equivale a 4 microsegundos. Por tanto la resolución de micros es esa. En cuanto al conteo de millis, se incrementa cada desbordamiento, es decir cada 4*256 = 1024 microsegundos, con lo que de tanto en tanto se suman dos milisegundos, en lugar de uno, a la cuenta de millis.

Tal vez lo que desea implementar Lucario sea, por ejemplo, un prescaler de 8, con lo que cada conteo equivaldría a medio microsegundo, e interrupción/reseteo cada 2000 conteos, con lo que se incrementaría millis exactamente cada milisegundo.

En cuanto a lo de redefinir millis, micros y delay, me temo que no es posible directamente. La solución que más podría acercarse, si es que funciona, sería una que mencionan, y no como respuesta principal, aquí.

Consistiría básicamente en copiar al directorio del proyecto la librería o librerías que contienen las funciones que deseamos modificar, y modificarlas dentro de nuestro proyecto (en otro lugar he leído que deben estar en una subcarpeta libraries del proyecto). De esta forma las modificaciones sólo afectarían a nuestro proyecto. Si alguien lo prueba sería interesante que exponga sus resultados.

Respecto a lo de reiniciar el timer1 al alcanzarse el valor de comparación, creo que sí es posible (modo CTC). Lo que no estoy totalmente seguro es de si el valor de comparación que debes poner es N o N-1 (2000 o 1999 en el ejemplo propuesto antes).

Alfaville

#4
Jan 05, 2017, 03:09 am Last Edit: Jan 05, 2017, 03:18 am by Alfaville
No queria entrar a tanto detalle, pero bueno si se necesita mas informacion ver aqui:  explicacion de millis.
Para que cada uno pueda plantearse si la precision que da la funcion estandar le vale o no.

Efectivamente, el timer1 se resetea a un valor programado, si usas los modos NORMAL y CTC, pero si deseas resetear a 0, puedes considerar tambien los modos FAST PWM y PWM Phase Correct.

Por cierto, creo que seria N = 1999 y el siguiente clock lo pondria a cero (0 a 1999 son 2000 cuentas)).
@Lucario un factor a considerar si sigues adelante en tu idea es la sobrecarga que supone un tiempo demasiado corto entre interrupciones.

Para un cronometro podria ser buena idea, pero en general tambien usamosSerial, I2C, PWM y mas cosas todas juntas, y queremos que vaya todo fluido.
Quizás por eso los padres fundadores han buscado un equilibrio global, a fin de cuentas para la hora usamos modulos externos, y los milisegundos los usamos siempre en modo relativo ... millis()-tiempo ...

Lucario448

Quieres mejor la precisión de millis() y porque no usas micros()?
  • micros tiene el bendito overflow cada 71 minutos. Es buena la idea pero si el Arduino no opera por más de una hora continua.
  • Analizándolo bien, realmente no tenía pensado redefinir micros; desencadenar interrupciones que cuenten microsegundos con exactitud... imposible con 16 MHz.


A menos de que una interrupción de 974 hz no interfiera fuertemente con una de 1 KHz (de ahí un millis más "exacto y natural"); entonces no sería necesario deshabilitarla. Caso contrario, quedará como una opción para una librería (porque he notado que realmente paralizaría a micros).




Tal vez lo que desea implementar Lucario sea, por ejemplo, un prescaler de 8, con lo que cada conteo equivaldría a medio microsegundo, e interrupción/reseteo cada 2000 conteos, con lo que se incrementaría millis exactamente cada milisegundo.
Lo dices en timer1? Porque en timer0 o 2; está más complicado lidiar con no sub-múltiplos de 2000 (256).

Pero entiendo tu punto, 8 ciclos de reloj son exactamente 500 ns, entonces cada dos cuentas timer, hay un microsegundo (si tan solo se pudiera hacer el incremento completamente paralelo a una variable de la memoria RAM).
Yo tenía en mente hacerlo con el prescaler en 1, así el incremento tiene que ocurrir cada 15999 (16000) ciclos; o podría restarle los que se tarda en "moverse" del código principal a la ISR, que aparentemente (según Nick Gammon aquí, sección "How long does it take to execute an ISR?"), son 23 si no es interrupción externa.

Respecto a la redefinición... si no es algo que pueda hacer con un #include, entonces creo que bastará con deshabilitar la interrupción del overflow del timer0 (si el usuario así lo quisiera).



Para un cronometro podria ser buena idea, pero en general tambien usamosSerial, I2C, PWM y mas cosas todas juntas, y queremos que vaya todo fluido.
Quizás por eso los padres fundadores han buscado un equilibrio global, a fin de cuentas para la hora usamos modulos externos, y los milisegundos los usamos siempre en modo relativo ... millis()-tiempo ...
Otro motivo más para no redefinir millis.

Leyendo el artículo del link que posteaste, me di cuenta que el contador de millis tiene lo que en el calendario gregoriano (con el que prácticamente todo el mundo vive, el de los 365 días) viene siendo el año bisiesto; esa unidad de más que se suma con el fin de compensar la desviación que provocan las cifras decimales. Vamos, para nadie es un secreto que el movimiento de traslación de la Tierra no dura exactamente 365 días; sino hasta el "29 de febrero" se podría usar como una indirecta de "nunca".

Si entonces millis tiene su razón de ser, entonces mejor dejarlo así; a menos de que se pueda cambiar con un #include <libreria.h>.



PD: creo que ya tengo claro que el modo CTC automáticamente reinicia el contador cuando viene la interrupción, pero ahora mi duda es: ¿Sigue contando aún dentro de una ISR, y aún si todas las interrupciones estuvieran deshabilitadas?

Yo supongo que sí, ya que los timers son piezas de hardware y no de software; que únicamente son contadores de pulsos (reloj interno o externo). No sé que piensan ustedes...

Alfaville

PD: creo que ya tengo claro que el modo CTC automáticamente reinicia el contador cuando viene la interrupción, pero ahora mi duda es: ¿Sigue contando aún dentro de una ISR, y aún si todas las interrupciones estuvieran deshabilitadas?

Yo supongo que sí, ya que los timers son piezas de hardware y no de software; que únicamente son contadores de pulsos (reloj interno o externo). No sé que piensan ustedes...
Efectivamente no te equivocas.
El timer sigue contando y si (aunque no es el caso) genera una interrupcion, no se podrá atender hasta no retornar de la ISR.
Y aunque nuestro timer no va a generar una interrupcion porque precisamente estamos atendiendo la que acaba de generar, si fuese necesario poriamos habilitar las interrupciones dentro de la ISR con un sei() y sí que seriamos interrumpidos.
Esta tecnica es fuente de muchos problemas potenciales, y debe evitarse salvo extrema necesidad.

Creo que la idea de hacerte una funcion personal para medida "exacta" de tiempos sería mejor que complicarte parcheando librerias.
Por eso en mi primer post te hablé de "mis_tiempos.cpp" y demás.

noter

#7
Jan 05, 2017, 01:07 pm Last Edit: Jan 05, 2017, 01:07 pm by noter
Bueno.
Me parece que más que solucionar algo concreto, lo que estamos haciendo todos es más bien teorizar, elucubrar, etc., cosa que no me parece mal, sino sumamente constructiva, aunque el lector que entre en este hilo sin un conocimiento un poco avanzado puede caer en la locura. :)
Así que una vez realizado el aviso, pongo algunos flecos más ;).

Creo que esto es sabido por Alfaville, y no sé si también por Lucario, pero de la lectura del último post podría deducirse que micros también genera una interrupción, lo que sería una locura, pues con 16 Mhz sería imposible atender una interrupción de 1 Mhz; y lo sería doblemente pretender que se ejecutara cada medio microsegundo. La única interrupción que se atiende es la de desbordamiento cada 1024 us, en la que se incrementa en uno (o dos) la cuenta de millis(). Esto quiere decir que, efectivamente, hay una variable "paralela" en memoria RAM. No así con micros(), que consulta el timer0 y realiza el cálculo sólo cuando es llamado.

De esta forma, el teórico millis y micros propuesto que, como decía Lucario, debería realizarse sobre timer1; incrementaría directamente millis sin correcciones, y podría proporcionar un cálculo de micros más preciso. Podríamos decir: ¿Por qué los padres de Arduino no implementaron millis así? Pues supongo que por aprovechar mejor los recursos disponibles y no comprometer el único timer de 16bit de muchos micros. También porque este cálculo tan chulo está muy bien para un reloj de 16 Mhz, pero se nos vendrá abajo con otras frecuencias. En las librerías del core se toma en cuenta la frecuencia definida para ajustar el incremento de millis y el cómputo de micros.

Ya metidos en harina, creo que para quien haya llegado hasta aquí puede ser interesante ver la implementación en el core de las tres funciones descritas; así que me tomo la libertad de ponerlas con algún comentario añadido.


noter

#8
Jan 05, 2017, 01:28 pm Last Edit: Jan 05, 2017, 01:50 pm by noter
Esta sería la definición de la ISR para desbordamiento del timer0. Vemos que hay tres variables afectadas llamadas timer0_millis, que sería la variable que contiene propiamente los millis, y timer0_fract, que acumula la fracción que se produce en cada desbordamiento (el 24 de los 1024 microsegundos para 16 Mhz). Cuando la fracción acumulada supera FRACT_MAX, vemos que se incrementa el milisegundo adicional. Por último, también se incrementa la variable timer0_overflow_count que, como su nombre indica, lleva la cuenta del número de desbordamientos, que será parte del cálculo de micros().

Code: [Select]

#if defined(__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)
ISR(TIM0_OVF_vect)
#else
ISR(TIMER0_OVF_vect)
#endif
{
// copy these to local variables so they can be stored in registers
// (volatile variables must be read from memory on every access)
unsigned long m = timer0_millis;
unsigned char f = timer0_fract;

m += MILLIS_INC;
f += FRACT_INC;
if (f >= FRACT_MAX) {
f -= FRACT_MAX;
m += 1;
}

timer0_fract = f;
timer0_millis = m;
timer0_overflow_count++;
}


El código de la función millis, vemos que básicamente consulta la variable timer0_millis, con la precaución de deshabilitar interrupciones para evitar que en medio de la lectura se produzca una actualización de dicha variable y nos de un resultado incongruente.
Code: [Select]
unsigned long millis()
{
unsigned long m;
uint8_t oldSREG = SREG;

// disable interrupts while we read timer0_millis or we might get an
// inconsistent value (e.g. in the middle of a write to timer0_millis)
cli();
m = timer0_millis;
SREG = oldSREG;

return m;
}


En la función micros, vemos que se hace el cálculo con el número de desbordamientos(m) y el valor actual del timer0 (t):

Code: [Select]

unsigned long micros() {
unsigned long m;
uint8_t oldSREG = SREG, t;

cli();
m = timer0_overflow_count;
#if defined(TCNT0)
t = TCNT0;
#elif defined(TCNT0L)
t = TCNT0L;
#else
#error TIMER 0 not defined
#endif

#ifdef TIFR0
if ((TIFR0 & _BV(TOV0)) && (t < 255))
m++;
#else
if ((TIFR & _BV(TOV0)) && (t < 255))
m++;
#endif

SREG = oldSREG;

return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());
}

Alfaville

Si señor, así funciona.
Los recien llegados que pueden caer en un estado de "locura" pasajera ante estos post, pueden ambientarse aquí: enlace a explicaciones sobre millis  que aunque ya lo posteé, ha quedado semioculto entre los últimos post.
Y llegados a este punto, y a falta de saber si el moderador considera que deberiamos abrir un nuevo hilo en otra sección, creo que debemos preguntar a Lucario ¿ quieres realmente hacer estas funciones de tiempos ?.
Si la respuesta es sí, aquí estamos por si en algo podemos facilitarte la tarea.

Lucario448

pues con 16 Mhz sería imposible atender una interrupción de 1 Mhz; y lo sería doblemente pretender que se ejecutara cada medio microsegundo.
A eso me refería:
desencadenar interrupciones que cuenten microsegundos con exactitud... imposible con 16 MHz.
La única interrupción que se atiende es la de desbordamiento cada 1024 us, en la que se incrementa en uno (o dos) la cuenta de millis(). Esto quiere decir que, efectivamente, hay una variable "paralela" en memoria RAM.
Bueno... yo hablaba de que ambos incrementos ocurrieran en el mismo ciclo de reloj (cuenta de timer con variable en RAM); pero creo que no es el caso.


De esta forma, el teórico millis y micros propuesto que, como decía Lucario, debería realizarse sobre timer1; incrementaría directamente millis sin correcciones, y podría proporcionar un cálculo de micros más preciso.
O al menos deshabilitar sólo el millis original; digo, que la interrupción únicamente incremente el "overflow count".
Con 16 MHz pedir más resolución en el conteo de microsegundos (ir de 3 en 3 o menos) veo que es demasiado pedir.


También porque este cálculo tan chulo está muy bien para un reloj de 16 Mhz, pero se nos vendrá abajo con otras frecuencias. En las librerías del core se toma en cuenta la frecuencia definida para ajustar el incremento de millis y el cómputo de micros.
De hecho, lo debo tomar en cuenta en una versión mejorada de mi librería. La frecuencia del reloj también me altera el valor del OCR para intentar mantener un constante 1 KHz.


Y llegados a este punto, y a falta de saber si el moderador considera que deberiamos abrir un nuevo hilo en otra sección
Lo dices por la discución/lección de timers en AVR?.
Al menos a mi no me incomoda siempre y cuando el desvirtuado no sea tan extremo; y no haya intercambio de insultos/groserías.


creo que debemos preguntar a Lucario ¿ quieres realmente hacer estas funciones de tiempos ?
Y por qué no? Como todo, tiene sus pros y sus contras.
Como decía Alfaville, sería útil para cronómetros, pero para ciertos proyectos más bien es un dolor de cabeza. Es más, admito que tengo tres librerías que no van a ser compatibles con mi implementación de millis: Servo, TMRpcm (a menos que se configure para timer2) y TimerOne. Hasta incluso se vería alterado al hacer analogWrite a cual sea el pin que está asociado al OCR1A (si no me equivoco creo que es el 10 "Arduino" en ATmega328P).

Muy posiblemente tenga que encapsularlo en una clase, porque necesito que la variable que lleva los milisegundos no pueda ser accesada desde afuera.


PD: quizá esta pregunta también este fuera de tema, pero aquí va: ¿qué tan nocivo es para el microcontrolador hacerle "overclocking"?
Sé que quizá desatiempe los tres tipos de comunicación serial (USART, I2C Y SPI) y por supuesto que hasta los mismos timers. Y que genera más calor, requiere mayor voltaje, bla bla bla.
Mi pregunta es si (como todo microprocesador), practicarle "overclocking" a un pobre ATmega328P a la larga lo puede matar.

surbyte

Yo para algo como lo que plantea Lucario simplemente me voy al Atmel Studio y programo el AVR y me olvide del C  Arduino style. Y asunto terminado. 
Facilmente genero una interrupción con timerX en 10kHz o 100khz.
El resto es lo mismo si usar Arduino, estilo COMO ANTES o como ha dicho Alfaville que trabaja !!



Lucario448

Yo para algo como lo que plantea Lucario simplemente me voy al Atmel Studio y programo el AVR y me olvide del C  Arduino style. Y asunto terminado.
Si lo dices porque me estoy yendo muy "adentro", pues... tiene sentido.

Alfaville



... Lo dices por la discución/lección de timers en AVR?.
Al menos a mi no me incomoda siempre y cuando el desvirtuado no sea tan extremo; y no haya intercambio de insultos/groserías.

No, para nada.
Considero que estamos en terreno cortés, no de discusión.
¿ Insultos ?, ¿ groserias ?. Dios no lo permita.
Lo decía porque el tema dá para mucho y ahonda en las partes intimas del Auduino (librerias del core), y puede parecer demasiado técnico para el tópico elegido.
Vamos que cae mas en el campo de un tuto.

Sobre el tema del overclock, el ATmega 328P admite hasta 20 MHz que, por cierto, es una frecuencia mas agradecida a la hora de encontrar divisores para obtener mili / micro segundos.

Por otro lado los calculos internos usan la constante F_CPU
Code: [Select]
#define clockCyclesPerMicrosecond() ( F_CPU / 1000000L )
#define clockCyclesToMicroseconds(a) ( (a) / clockCyclesPerMicrosecond() )
#define microsecondsToClockCycles(a) ( (a) * clockCyclesPerMicrosecond() )
por lo que pese al cambio de frecuencia, se pueden recalcular los tiempos.
Es un tema a considerar mas despacio.

noter

Como ejercicio teórico no está mal, pero los beneficios prácticos creo que no serán notables respecto al uso de millis/micros implementado en el core. Como se ha dicho, la precisión de millis es de +-1ms, y la precisión de micros de +-4us- Teóricamente esta precisión se mantiene tanto si queremos medir un tiempo breve como uno largo. Creo que para la mayoría de aplicaciones es más que suficiente, y para las que necesiten un temporizado más fino (generador de frecuencias, medir anchura de un pulso, etc) es preferible programar específicamente un timer, bien directamente, bien con apoyo de alguna librería.
No obstante, si alguien se quiere embarcar en la aventura, se intentará ayudar ;).

Go Up