Compartir oscilador entre 2 PIC's

[Ardogan]

Bueno, la pregunta es la del título precisamente: ¿alguien probó compartir un oscilador entre dos PIC's?.

El oscilador es integrado SG531P. En un proyecto tengo que usar dos pics pero no quiero poner dos osciladores por separado, más aún, compartiendo el oscilador (supongo) la sincronía entre PIC's estaría asegurada.

La otra variante sería conectar el oscilador a 1 PIC, y usar una salida PWM de éste como entrada de reloj externa del otro PIC.

¿Qué opinan?, tal vez sería mejor la última opción ¿no?.

Saludos, y aprovecho para desearles a toda la gente del foro un feliz año nuevo y navidad. O no, si es que profesan una religión no cristiana y/o usan otros calendarios. Sea como fuere, va un brindis virtual con toda la muchachada del foro. Salud!

(Más vale tarde que nunca)

 

[pepechip]

Hola
hace poco estube pensando lo mismo que tu, aunque no lo he provado te dare mi modesta opinion.
pienso que lo mejor seria que a los 2 pic les llegara la misma frecuencia de reloj, de esta forma los tendras sincronizados, pero hay un pequeño problema y es que a la hora de conectar la tension de alimentacion o de provocarle un reset, no se si estos empezaran a funcionar en el mismo instante, asi que deveras de probar esto. Si no arrancan los dos micros a la vez, puedes mandar al primero a dormir y en el segundo empleas un pin para despertarlo.

La otra opcion de generar la señal de reloj con uno para mandarsela al otro, no me parece muy buena, ¿supongo que ese micro tendra otras cosas mas importantes que hacer?.

No se a que frecuencia quieres hacer trabajar a los micros, pero tienes otra opcion. seria hacer trabajar al primero utilizando una red RC o bien con el SG531P, y la salida osc2 de este la aplicas al pin osc1 del otro. De este modo tambien van sincronizados, aunque uno correra 4 veces mas rapido que el otro.

Este tema me interesa bastante, si pudieras postear aqui tu experiencia seria de gran utilidad

saludos

 

[lelguea]

Los pics, pueden tener una fuente externa de reloj, es decir compartir un mismo generador de pulsos.

Lo de sincronizar lo veo poco ultil, pues cada Pic, divide la frecuencia entre 4, por lo que cada pic, podria estar en otra parte del "ciclo" interno.

Saludos

 

[f_point]

En mi experiencia personal he notado que algunos montajes con múltiples PIC tienden a usar el mismo oscilador de cristal para 2 microcontroladores.

La solucion implementada es relativamente simple:
- Un PIC es el responsable directo de manejar el oscilador de cristal, es decir, se le conecta el cristal como es habitual con sus correspondientes capacitores.
- El segundo PIC "escucha" por asi decirlo, al oscilador de cristal del primero. Para ello, se conecta la entrada "OSC1/CLKI" del segundo a la salida "OSC2/CLKO" del primero. Hay que tener MUCHO cuidado de no hacerlo al reves, o corremos el peligro de averiar los driver de los osciladores de ambos PIC. Además, no hace falta agregar capacitores adicionales (de hecho no hay que hacerlo).

Habria que tener otros cuidados adicionales aparte de la conexión, como:
- Los fuses de configuración del oscilador de cristal tienen que ser los mismos (Si un PIC usa oscilador HS, el otro también deberá usar HS).
- Ambos PIC deberían tener encendido el fuse PWRTEN para provocar que ambos se esperen un tiempo extra antes de arrancar (varios milisegundos), para que ambos esperen a que el oscilador de cristal del primer PIC se estabilice antes de ejecutar código.

Y tal como lo menciona lelguea, no hay garantía de que ambos PIC se sincronicen perfectamente porque podrían quedar desfasados por más de algun ciclo Q (hay 4 ciclos Q por instrucción, por lo que la probabilidad de quedar desfasados es del 75% si eso es producto del puro azar).

Ademas, la ejecución de código paralelamente entre PIC requiere de un gran esfuerzo de planeación por parte del desarrollador, es mejor sincronizarse a través de los periféricos de comunicación que los PICs ya poseen (tal como el módulo USART o el MSSP) y así evitar andar contando ciclos de reloj.

Si la sincronía perfecta es una prioridad, entonces sugiero resetear simultáneamente ambos PIC para ese propósito (el RESET forzaría la sincronización de los ciclos Q), además seria bueno usar un oscilador separado de ambos PIC en ese caso.

Espero mis observaciones sirvan de ayuda.

Saludos.

 

[Ardogan]

Gracias por las respuestas gente.
No sabia que se podía compartir oscilador de la forma que menciona f_point,

La solucion implementada es relativamente simple:
- Un PIC es el responsable directo de manejar el oscilador de cristal, es decir, se le conecta el cristal como es habitual con sus correspondientes capacitores.
- El segundo PIC "escucha" por asi decirlo, al oscilador de cristal del primero. Para ello, se conecta la entrada "OSC1/CLKI" del segundo a la salida "OSC2/CLKO" del primero. Hay que tener MUCHO cuidado de no hacerlo al reves, o corremos el peligro de averiar los driver de los osciladores de ambos PIC. Además, no hace falta agregar capacitores adicionales (de hecho no hay que hacerlo).

no parece ser complicado....

En cuanto a la sincronía, tienen razón, me interesaba que ambos PIC's tengan una base de tiempo común para medir el tiempo en que se producen ciertos eventos (fallas de periféricos externos a los PIC's más que nada, y algún que otro fin de carrera).
Con respecto a eso voy a implementar una base de tiempo única en el PIC más rápido, y cuando el más lento detecte algún evento activa una salida que iría a una entrada de interrupción del que tiene la base de tiempo.

Esto lo voy a estar implementando en un plazo de dos semanas, cuando tenga algo funcionando se los haré saber.

Gracias y hasta luego

 

[El nombre]

Solucionado.


Ahora va la chorrada mia de turno.
¿Que tiene que ver la frecuencia de oscilacion con el funcionamiento de los microcontroladores?

Pos eso. tienen el mismo reloj y pueden hacer lo que les de la gana sin mas. al igual que sincronizarse sin mas, al igual que cada uno puede o no resetear (lo del fuse si es correctisimo)

Lo importante es ejecutar un programa que no dependa de esas chorradas. es decir: que funcionen como si llevasen cristal independiente. Eso garantiza un funcionamiento de calidad.

 

[pepechip]

hola.
el Nombre dijo:

Lo importante es ejecutar un programa que no dependa de esas chorradas. es decir: que funcionen como si llevasen cristal independiente. Eso garantiza un funcionamiento de calidad.

Eso seria lo ideal, aunque dpendiendo de la complejidad del circuito se puede dar el caso que que se tengan que sincronizar

 

[El nombre]

La sincronizacion nunca depende del la señal de reloj. por eso puedes conectar un 48Mhz con un 4Mhz sin problemas.

No depende de la complejidad depende del uso. Si intentas pasar un bit no hace falta un gran programa. Si quieres pasar x Bytes tampoco.

 

[f_point]

La sincronizacion nunca depende del la señal de reloj. por eso puedes conectar un 48Mhz con un 4Mhz sin problemas.

No depende de la complejidad depende del uso. Si intentas pasar un bit no hace falta un gran programa. Si quieres pasar x Bytes tampoco.

Tratandose de comunicar los MCUs, yo optaria por comunicarlos entre si via SPI. Este modulo es perfecto para estas tareas, pues el clock lo pone un PIC y el otro solo recibe el clock como una entrada, sincronizandose automaticamente al primero. Plus tenemos que cuando mueves un byte, este se envia y recibe al mismo tiempo en los dos extremos, gracias a que el bus es bidireccional.

Esta alternativa proporcionada por el modulo (M)SSP es perfecta para comunicarlos. No se diga si usamos I2C.

Saludos.

 

[pepechip]

La solucion implementada es relativamente simple:
- Un PIC es el responsable directo de manejar el oscilador de cristal, es decir, se le conecta el cristal como es habitual con sus correspondientes capacitores.
- El segundo PIC "escucha" por asi decirlo, al oscilador de cristal del primero. Para ello, se conecta la entrada "OSC1/CLKI" del segundo a la salida "OSC2/CLKO" del primero. Hay que tener MUCHO cuidado de no hacerlo al reves, o corremos el peligro de averiar los driver de los osciladores de ambos PIC. Además, no hace falta agregar capacitores adicionales (de hecho no hay que hacerlo).

He llevado a la practica esta configuracion, aunque en un principio configure el microcontrolador esclavo como oscilador exterior EC_OSC y viendo que no funcionaba observe que la salida OSC2 no es una señal con niveles TTL, sino una señal senoidal inferior a 1v, por lo cual volvi a configurar los fuses del microcontrolador esclavo y lo puse en XT_OSC, de modo que ahora este pic si me trabajaba. Pero mis intenciones eran conectar 12 pic 12f629 a un mismo cristal, y al conectarlos todos me dejaron de actuar, asi que tras ir levantando microcontroladores observe que solamente podian funcionar un pic principal + 2 esclavos.
Pero es mas el programa que realice en los 2 pic esclavos consistia en un led que parpadeaba con una cadencia de 1seg, sin embargo cada pic prendia el Led a frecuencias diferentes, por lo que llegue a la conclusion de que 2 PIC NO PUEDEN COMPARTIR EL MISMO CRISTAL OSCILADOR.

Conclusiones: Un pic trabajando con cristal no se puede utilizar como salida el pin OSC2, ya que el nivel de tension que entrega es muy devil, y si la inyectamos en otro pic por el pin OSC1 no siempre que la tension señoidal alcance su valor de pico sera suficiente conmo para que sea interpretado por un 1 logico.

un saludo

 

[El nombre]

Pues discrepo un poco.
Es imposible que la señal generada por el cristal a 4 megas sea de 5V.
Si miramos el esquema interno se ve el funcionamiento. En ningun caso se llega a los 5V. La forma de onda del oscilador es senoidal, naturalmente. Ya se explico el motivo en otro post.
Nunca he conectado tantos micros juntos pero si aplicas una señal a uno este saca señal. si continuas conectandolos en cascada no pierdes señal.
Saludos

 

[pepechip]

No recuerdo la tension que medi en el terminar OSC2, pero yo juraria que nisiquiera llegaba a 1Voltio.
Cuando utilizamos un micro con un cristal, hay que configurarlo mediante XT_OSC, y con ese fuse el pin OSC2 no actua a modo de salida. En el caso de utilizarla para otro micro no funcionan a la misma frecuencia, ya que hay ciclos que no son detectados por su reducido nivel de tension.