Publicado por: RedPic en 08 de Diciembre de 2005, 13:23:00
La Interrupción RTCC salta cada vez que Timer0 pasa de FF a 00. Salta cada n micro/mili segundos. Usando el Preescaler 1:2, 1:4, 1:8 ... 1:256 podemos enlentecerla si ese es nuestro gusto. Hasta ahí llego.
Mas, pero, sin embargo imagino que depende del ciclo de reloj que nos brinda nuestro cristal oscilador. He encontrado una tabla de los tiempos que tarda RTCC en dispararse para un cristal de 4 Mhz y parece que es real. Tengo un cajón
de cristales distintos pero el único de 4 Mhz lo tengo montado en una placa en uso, así que he cogido uno de 6 Mhz y lo he montado en mi placa de desarrollo.Los delays van bien porque, imagino, el CCS hace los cálculos necesarios para dejar pasar los micro o mili segundos que le digo que espere .... sin embargo el Timer0, y los demás timeres, se desborda cada tantos n/u/m segundos y con el cristal de 6 Mhz no tengo ni idea de qué lapso de tiempo estoy hablando.
¿Tenéis, amables Picmaniacos, alguna fórmula de cálculo del tiempo empleado en hacer su recorrido el Timer0 en función del cristal?
Publicado por: Nocturno en 09 de Diciembre de 2005, 00:34:00
Para calcular el valor que has de cargar al timer para que tarde en desbordar un determinado tiempo es:
256 - (tiempo / (4/FOSC) )
El tiempo (el delay del timer) , es en segundos y FOSC en hercios.
Por ejemplo, tendrías que cargar para 20 micro segundos de delay a 6mhz:
256 - (0.000020 / (4/6000000) ) = 226
Publicado por: RedPic en 09 de Diciembre de 2005, 06:27:00
Luego ...
Para un recorrido completo del Timer0, de 00 a FF, el valor a poner debería ser 0 y entonces la formula quedaría:
256 - ( Time / (4/FOSC)) = 0
y despejando Time:
Time = (256 * 4) / FOSC
Para un FOSC de 6.000.000 Hz tendríamos un Time de 1.706666e-4 o sea 171 microsegundos en darle una vuelta completa a la manivela sin reductora, perdon, sin preescaler.
¿Cierto? ¿Confirmado? ¿Es ello así? ¿He visto la luz?
Publicado por: Nocturno en 09 de Diciembre de 2005, 10:23:00
Por cierto, he visto tu güeb, mejor dicho, tus güebs. Me ha sorprendido mucho ver cuánto lo has currado. Enhorabuena.
Publicado por: RedPic en 09 de Diciembre de 2005, 10:30:00
Por cierto ... con esto de la formulilla pos ya tengo mas chicha pa picmanía by yo mismo. El siguiente que tire del google pa peguntá por ciclos de relós puede ahorrarse unos cuantos quebraderos de cabeza.
Pos eso. Un saludo fraternal.
Publicado por: RaDoN en 09 de Diciembre de 2005, 10:48:00
Supongo que depende de los leds, r1 y r2 estaran entre 150 y 330 ohm, supongamos el mejor de los casos 330 ohm, cuando la pata del pic este en alta impedancia (como entrada) esto quiere decir que sin hacer nada, incluso con el pic "dormido", existe un consumo de (suponiendo Vdd= 5V), unos 7mA, que se puede disparar hasta 20mA en el caso de las de 150.
Supongo que debe haber mejores soluciones sin necesidad de ese consumo...
Aparte hay algo en el esquema que no me acaba de convencer
Edito: en su dia vi una forma de hacerlo, que aparecio por aquí y era algo como:
R1 y R2 rondaban los 300 ohm y R3 1k, no lo he probado pero supongo que funciona
P.D.: estupendo trabajo tu página
Publicado por: RedPic en 09 de Diciembre de 2005, 13:09:00
Este esquema de conexión proviene de la AN234 Hardware Techniques for PICmicro Microcontrollers de Microchip. Aún no lo he usado pero como es simplísimo voy a ver si puedo probarlo este mismo fin de semana.
Si quieres podemos abrir otro hilo con este tema en el foro general "Todo en ..." que parece mas adecuado a estos temas
P.D. Acabo de encontrar otro Cristal de 4 Mhz y otro de 8 Mhz así que voy a seguir calculando y probando tiempos ... a ver si me aclaro definitivamente.
El asunto es que el osciloscopio de mi trabajo está desaparecido en combate y hasta que no lo devuelvan no podré comprobar empiricamente si lo calculado es cierto o no deja de ser una paja mental teórico falaz. 
Publicado por: Nocturno en 09 de Diciembre de 2005, 13:16:00
1.- Pones el dedo en la salida y cuentas los calambres.
2.- Pones un led y los cuentas con la mirada, aunque tiene el inconveniente de que no puedes pestañear.
3.- Haces un frecuencímetro con otro pic. Hay uno ya hecho en los ejemplos de CCS.
Publicado por: RaDoN en 09 de Diciembre de 2005, 13:19:00
Publicado por: RedPic en 09 de Diciembre de 2005, 13:38:00
Voy a utilizar uno de los corolarios de la Ley de Murphy que dice que si un sistema tiene un error este será acumulativo hasta desvirtuar su propia naturaleza.
Me explico, si puedo: Voy a contar segundos mostrandolos en el los cuatro 7 segmentos de la placa. Reseteo el micro para que empiece a mostrar segundos y arranco un cronometro (o lo hago justo al empezar una hora en punto) y cuando pasen exactamente 3600 segundos, una hora después, lo comparo con el cronometro para ver que diferencia hay.
Si me sobran o faltan segundos sólo tengo que dividir la sobra o falta por 3600 para ver cuanto atraso o adelanto en 1 segundo y como tengo el número de interrupciones que lanzo para contar un segundo entonces divido el adelanto o atraso por segundo entre este número de interrupciones y así puedo calcular bastante exactamente cuanto tarda realmente cada una de ellas.
Mi error de apreciación solo está en el primer y el último segundo, el error del PIC se acumula uno tras otro hasta 3600 veces, en el caso de comprobarlo durante una sola hora, por lo que mi error es irrelevante comparado con el suyo. (Incluso puedo calcular cual es el error máximo que puedo cometer y cuanto "pesa" en el experimento)
Como tengo 4 dígitos en los displays puedo hacer la prueba hasta de 9999 segundos o, para hacerlo más facil, de hasta 2.5 horas que són 9000 segundos, que es muy fácil de controlar y que solo te obliga a lanzar el asunto y volver a mirar con un poco de atención dos horas y media despues.
Ea, ahí quea eso.
Publicado por: RaDoN en 09 de Diciembre de 2005, 16:09:00
Publicado por: RedPic en 10 de Diciembre de 2005, 07:56:00
Con lo aprendido en este hilo de mensajes acabo de montar un pequeño artículo que me gustaría que revisaseis para sacarle las meteduras de pata, errores, incongruencias, deslices, fallos, yerros, inconsistencias ....
Los Cristales y El Tiempo
Publicado por: RaDoN en 10 de Diciembre de 2005, 08:47:00
http://www.conket.com/modules.php?name=Sections&op=viewarticle&artid=31
Publicado por: RedPic en 10 de Diciembre de 2005, 08:56:00
Y tan buena pinta, joé ... que mas chafao la moral.
. El artículo que has mandado es como el mío pero a lo bestia. Si me llego a enterar antes de que existe: o no escribo el mío o lo copio tó completo y en paz ... ... pero claro, no puedo caer en la soberbia de creerme que estoy inventando algo, ya no soy tan joven como para permitirme el lujo de engañarme creyendo que lo que descubro lo está descubriendo la humanidad conmigo
Y sin embargo me siento feliz.
Publicado por: RaDoN en 10 de Diciembre de 2005, 09:23:00
. Creo que tu trabajo se puede convertir en un referente para los que comienzan en esto, sigue así
Publicado por: migsantiago en 10 de Diciembre de 2005, 09:58:00
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
Publicado por: Nocturno en 10 de Diciembre de 2005, 11:04:00
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.
Publicado por: RedPic en 10 de Diciembre de 2005, 14:59:00
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.
Publicado por: RedPic en 10 de Diciembre de 2005, 16:48:00
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)
Publicado por: Nocturno en 11 de Diciembre de 2005, 00:57:00
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.
Publicado por: pocher en 11 de Diciembre de 2005, 01:41:00
Publicado por: pocher en 11 de Diciembre de 2005, 03:00:00
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
Publicado por: pocher en 11 de Diciembre de 2005, 04:22:00
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
Publicado por: RedPic en 11 de Diciembre de 2005, 04:34:00
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.