Interrupcion RTCC y distintos Cristales.

[migsantiago]

Hola

Te adjunto un programa que calcula los valores que hay que cargarle al PIC según el cristal que pongas.

http://www.4shared.com/file/42847804/cf551413/PIC_TMR0.html

[Nocturno]

Oléeeeeeeeee, por fin alguien que es capaz de escribir algo técnico con un lenguaje que da gusto leer.
Está muy bien el artículo, paisano, no envidia en nada al de Conket, porque te aseguro que es mucho más fácil y ameno de leer el tuyo.
Aunque si me permites un pequeño consejo. En la fórmula que te posteé al principio, olvidé incluir el Preescaler, y acabo de acordarme leyendo el artículo de Conket:


Realmente creo que añadiendo esto tu artículo quedaría supercompleto, y disculpa mi olvido inicial.

P.D.: Ese germen del que hablabas podría alimentarse con algunas cervecitas, ahora en las vacaciones sería un buen momento.

[RedPic]

1º Será tenido en cuenta para una posterior y pronta modificación del artículo. Aunque creo que ya se apunta en el mismo tomando en cuenta el Preescaler tras haber calculado el ciclo a pelo. Aunque si lo integramos en la fórmula es mas claro, sencillo y directo aún. Ok.

2º No solo acepto el embite sino que lo hago extensivo a los sevillanos y asimilados que deseen brindar por la Picmanía. Radon es tb de servalavari, y Cucaracha de muy cerca, de la tierra de mis agüelos: Huelva provincia marinera y serrana ...

3º Desde el día 23 hasta el día 2 estoy de vacacio legis por lo que cualquier día, menos los extrictamente familiares, me biene bién. Ya te pasaré por privado mis telefonillos pa quedar.

Asi da gusto, que con el 68HC11 me la chupé yo solo con tos los manuales en pitinglish y con menos ejemplos que el prospecto d"un chupe.

[RedPic]

Mas acerca de todo este tema:

Me encanta confirmar prácticamente lo que teóricamente hemos descrito. He terminado la versión 1.0 del CronoPic ... cuenta segundos y minutos y los saco por los 4 siete segmentos de mi placa de desarrollo ...

Lo he puesto en marcha y he realizado el experimento que describo un poco mas arriba en este mismo hilo, consistente en poner un cronometro en paralelo, y tras un cierto tiempo, comprobar las diferencias entre ambos. Cuanto más tiempo pase entre el inicio y el final de la comparación mas preciso será la medida del error cometido por el PIC. Podemos comprobar empiricamente la duración de un segundo-pic comparado con un segundo-cronómetro.

Lo he dejado exactamente 10 minutos contados por el PIC, o sea 600 segundos. En este lapso de tiempo mi cronómetro manual ha contado 9 minutos y 50 segundos, por lo que el PIC me adelanta 10 segundos en 600.

Esto significa que 10/600 = 0.01666 es aproximadamente el adelanto del PIC por cada segundo que cuenta.

Como resulta que yo cuento 15 interrupciones RTCC completas cada vez que incremento el número de segundos transcurridos tenemos por lo tanto que 0.1666 / 15 = 0.00111 es aproximadamente el adelanto del PIC por cada interrupción RTCC que salta.

Esto es aproximadamente 1 milisegundo por interrupción.

Un cristal de 4 Mhz sirve el ciclo de reloj de este PIC y en mi programa le he activado el Preescaler 256 por lo que según el cálculo me debe saltar una interrupción cada 66.6 milisegundos. Como cuento 15 de ellas para completar un segundo tengo que mi segundo-pic vale exactamente 66.6 * 15 = 999 milisegundos ...

Voilá, ahí está el milisegundo de adelanto. Mi segundo-pic consta de solo 999 milisegundos en vez de los mil como tienen los segundos-segundos como Dios manda.

Conclusión: Por cálculo a mi Interrupción le falta 1 milisegundo. Por experimento a mi Interrupción le falta 1 milisegundo. Ambos métodos coinciden y se verifican el uno al otro.

Ahora solo queda corregirlo ... y lo voy ha hacer con el método pic-bisiesto ... cada un cierto número de interrupciones RTCC voy a contar 14 de ellas en vez las 15 oficiales. Casa segundo-pic no será perfecto pero muchos de ellos si.

Lo dicho, me encanta.

(Y ahora a publicaaaaar)

 

[Nocturno]

Estupendo análisis el que hicísteis ahí, Pocher.
De todas formas, hay una idea propuesta por Radón, que parece muy lógica a la vez que simple.
Está en este hilo:
http://miarroba.com/foros/ver.php?foroid=46840&temaid=4579639

y se trata de, literalmente:
Ahora bien para hacer 1 seg plantee ponerle un divisor al timer de 64, y cargarlo con 131 (125 ticks) y que chequeara 125 entradas:

64 * 125 * 125 = 1000000 de ciclos, a 4Mhz (1u/S instrucción) dan el segundo exacto.

En todos los intentos de cronómetro que he visto, nos empeñamos en llevar el prescaler a 256, pero si lo ponemos en 64 como sugiere Radón, la cuenta sale exacta. Habría que probarlo.

[pocher]

Vaya, es cierto, con el Preescaler a 64 sale el segundo clavado.

[pocher]

Faltaba algo ... por fín me he acordado. Aún consiguiendo el segundo exacto, bien con un determinado cristal, bien como dice Radón con un Preescaler de 64 y cargando con 131 (fosc=4Mhz) no hay forma de conseguir que no retrase si se utiliza la interrupción.

La solución comprobada que yo encontré es detectar la subida del bit TOIF al desbordarse el TMR0 pero en el while no en la interrupción de esa forma no "se gasta tiempo" al entrar en la interrupción (ni tan siquiera valdría precargar el TMR nada más entrar en la interrupción como dice Radon en el otro post).

Voy a hacer esta aclaración también en el otro post.

Un saludo

[pocher]

Otra cosa, hace tanto tiempo que no me acordaba.

No se debe de emplear la instrucción de recarga set_timer0() ya que se emplea tiempo en ella. Esto dá al traste con el desarrollo de Radon en el que se recargaba el TMR0 con 131.

Resumiendo tres cosas:

- No usar interrupción

- Usar un cristal que consiga no hacer recargas del TMR

- Detectar en el programa principal el desbordamiento del TMR mediante el bit T0IF

Un saludo

[RedPic]

y se trata de, literalmente:

Ahora bien para hacer 1 seg plantee ponerle un divisor al timer de 64, y cargarlo con 131 (125 ticks) y que chequeara 125 entradas:

64 * 125 * 125 = 1000000 de ciclos, a 4Mhz (1u/S instrucción) dan el segundo exacto.

En todos los intentos de cronómetro que he visto, nos empeñamos en llevar el prescaler a 256, pero si lo ponemos en 64 como sugiere Radón, la cuenta sale exacta. Habría que probarlo.

¡Bien por Radon, por Pocher y por Nocturno por rescatarla!

Utilizando los dos métodos en conjunto, el uso del preescaler y valor inicial de Radon y la detección en main() directamente del bit-flag de desborde, pasando de usar RTCC, de Pocher tenemos una señal clara y precisa de nuestro segundo-pic. Nos evitamos todo el fárrago de contadores, incremetos y comparaciones dentro de RTCC.

Me gusta.