TODOPIC
FORO TÉCNICO => Foro Técnico => Mensaje iniciado por: Lupin en 13 de Marzo de 2007, 22:56:26
-
Hola,
Hace un tiempo me encontre con la necesidad de intercomunicar distintas placas de equipos que diseñe en distintas epocas y con distintos microcontroladores, claro que estas placas no estaban previstas para dicho fin, la mayoria no tiene ni RS232 y los pines del I2C estan usados para otras funciones.
Lo unico que encontre en comun en todas las placas fue un conector de 4 pines donde tengo +5V,GND y dos pines directo del pic (estos conectores suelo ponerlos para dejar acceso a los pines que me sobran, para futuras aplicaciones).
Por esto es que decidi "embeber" algun tipo de comunicacion serie bidireccional por dos pines, pero despues de ver algunos estandar, no me convencio ninguno por motivos de no querer agregar interrupciones de soft en algunas placas o tener que gastar muchos recursos del pic para atender esta comunicacion.
Aprovechando que no necesito mucha transferencia de datos entre placas, apunte a que la comunicacion pueda ser lo suficientemente versatil para agregarla a todos los pic (diferentes modelos y familias usando las mismas rutinas) y que se pueda iniciar la comunicacion o recibir un dato por "pulling", o desatender el puerto por intervalos largos de tiempo sin perder datos.
En definitiva, arme un sistema de comunicacion con estas caracteristicas que me funciono muy bien y ahora voy a detallarlo con la intencion de que si alguien lo conoce o conoce alguno similar me avise, ya que es muy probable que haya perdido el tiempo haciendo algo que ya existe!!
El tema es asi, los cables necesarios son GND, una linea llamada SCL (para que suene familiar) y otra llamada SDA (tambien muy conocida).
Ambas lineas estan conectadas al positivo por una resistencia de pull-up en una o ambas placas.
En standby SDA y SCL estan en 5V.
Si el Pic_1 quiere enviar un dato, pone en bajo SCL y espera la respuesta del Pic_2.
La respuesta del pic_2 consiste en poner en bajo SDA antes de un tiempo maximo de espera (yo estoy usando 500ms para que pic_2 no tenga que apurarse en contestar y desatender lo que esta haciendo).
La respuesta de pic_2 dura 100uSeg en bajo y despues libera SDA (se pone en alto).
En este momento Pic_1 pone el primer Bit de dato en SDA y 50uSeg despues pone en alto el SCL para que pic_2 lea el valor de SDA.
50uSeg despues pic_1 pone en bajo SCL, pone el bit 2 en SDA y repite el paso anterior.
Despues de pasar 8 bits, SCL queda en alto, por lo tanto si inmediatamente se inicia la comunicacion de un nuevo BYTE, esta es "enganchada" inmediatamente por pic_2.
De esta forma tenemos que la comunicacion puede tardar hasta 500ms para iniciarse, este es un tiempo maximo antes de cancelar, lo normal es que la comunicacion se inicie rapido (depende del tiempo del loop en caso de usar pooling o inmediatamente si se usan interrupciones). A partir del segundo BYTE del paquete enviado, al estar ya enganchados los pic, cada byte tarda 900uSeg, por lo que tenemos mas de 1000 BYTES por segundo que para muchos casos es mas que suficiente.
Todos los tiempos se pueden modificar, logrando velocidades muchisimo mas altas, pero perdiendo flexibilidad en la interaccion con equipos ya diseñados, perdiendo longitud en los cables de interconexion, etc.
(http://www.gratisweb.com/circuito/ima/protocolo_sm.jpg)
Para transmitir desde pic_2 a pic_1 es exactamente igual, pero pic_2 inicia la comunicacion.
Se pueden "colgar" del mismo bus de datos muchos pics simultaneamente.
Vuelvo a repetir, si ya existe algo identico a esto y tiene nombre me gustaria saberlo, por el momento lo sigo llamando "El protocolo SOM".
Saludos y gracias.
-
Pues no me atrevería a asegurar que sea idéntico, pero el SPI se parece bastante.
-
No es un SPI manolo, sino un I2C.
Lupin lo que buscas se llama protocolo I2C y el foro está plagado de hilos con respecto al tema. Usa el buscador y verás que es un tema que hemos tratado en infinidad de ocasiones.
El I2C utiliza dos cables y tramas para determinar el nodo. El SPI usa 4 cables y utiliza chip selects para elegir a que nodo comunica.
Salu2!!!!
-
En realidad sería una mezcla, porque el I2C incorpora la dirección del destinatario en la comunicación.
-
En realidad sería una mezcla, porque el I2C incorpora la dirección del destinatario en la comunicación.
Parte de razon tienes, ya que la comunicacion es tipo P2P, pero el bus en sí está hecho por dos cables, que se llamas igual que en I2C, el SDA serial data y el SCL serial clock. Es decir, está haciendo un I2C si la parte de la trama que indica dirección o comando de lectura/escritura. Se entiende que hay un master y un slave, como el SPI, es eso lo que quieres decir manolo?
Con este protocolo Lupin dudo que puedas pinchar varios pics al bus, a no ser que quieras que todos reciban lo mismo. Si pretendes discriminar, con el protocolo tal y como lo tienes........ no se puede, ya que en tus tramas no mandas ni direcciones ni comandos, solo datos.
Dews!!!!
-
hola,
Si no me equivoco, en el I2C la comunicacion la inicia y termina un pic sin saber si alguien lo esta "escuchando", solamente comienza con el bit de inicio y termina con el bit de stop, pero nunca espera un ACK para comenzar a transmitir, (supone que los pics conectados al bus son lo suficientemente rapidos para atender la comunicacion).
Con respecto a colgar varios pic del bus, lo que yo hago es mandar esa informacion en el paquete de datos, asi como tambien los controles de error.
Por esto es que siempre mando solo 8 bits, la informacion real se forma al completar la recepcion completa de un paquete de bytes.
Por ahora lo unico que tengo claro es que no es ni I2C ni SPI (a simple vista se parece bastante a cualquiera) pero ni el I2C ni el SPI cumplen con las necesidades que mencione en el primer mensaje (claro esta que el I2C o el SPI son totalmente superiores a este en otros aspectos).
Quiero aclarar que no hay un pic que siempre transmite y otro que siempre recibe, cualquiera que este conectado en el bus puede iniciar una comunicacion en cualquier momento (fijandose que SDA y SCL esten en alto) con cualquier otro.
Saludos y gracias por las opiniones.
-
Hola, y si usas el I2C pero sacándolos por esos dos pines que tienes libre, osea asi como la USART se puede sacar por otros pines que no sean RC6 ni RC7, podrías hacer lo mismo con esos pines, el CCS creo que permite hacer eso. Corregirme si me equivoco,
-
Lupin en i2c no hay bit de start o de stop, sino que es una combinación entre la linea de clock y la de datos. Lo bueno de ese sistema es que con el start avisas a todo el bus, pero siempre es necesaria la señal de ACK para seguir con la comunicacion.
En el i2c puedes mandar solo tramas de 8 bits, y como bien dices, en el nodo de recepcion montas los words tan largos como te sean necesarios, pero, en el i2c las primeras partes de la trama son direccion y palabra de comando, es decir lectura o escritura. Con tu sistema mandas datos pero no sabes a donde van a parar, ni tampoco si el dato es de lectura o escritura, o pertenece a una dirección. Supongo que esto te lo montas con un diccionario interno en el nodo de recepción, pero personalmente no me parece una solución demasiado acertada.
Si es i2c las tramas están incompletas, y si es SPI falta en el cronograma de la linea de chip select para indicarle al nodo que en ese momento se le va a hacer trabajar.
No puedes pinchar en el bus (tal y como lo tienes planteado) más de dos nodos (master y slave), ya que el primero que entre ocupará el bus. En i2c no hay problema ya que la trama la reciben todos los nodos, pero solo responde el que reconozca la dirección de nodo, pero solo uno, no pueden responder varios nodos a la vez. En SPI no puedes tener más de un nodo por bus, ya que la selección se hace a través del CS. Con tu sistema los nodos se estrellarían, ya que todos tendrian el CS activado, y todos se pondrían a mandar datos a través del bus, con lo que colisionan. En un bus SPI, lo normal es tener activo solo un nodo esclavo, y activado por CS. Si quieres poner más elementos en el bus SPI los has de ir multiplexando con sus respectivos CS, pero solo puede haber un esclavo activado.
Renatox
Dentro del Mplab hay unas librerias que empiezan con sw (ej: sw_i2c.h, sw_spi.h, ...) que son precisamente para lo que comentas, para simular un puerto digital I/O con módulo asociado (i2c, spui, usart, etc...). Puedes crear puertos como los mencionados con pines I/O de propósito general. El problema que veo yo aquí, es que como ni es i2c ni spi, es posible que ninguna libreria le acabe de servir. En CCS no sé si tienen estas librerias, es un lenguaje que no practico.
Salu2!!!!
-
Hola Deimos, tengo una duda con el SPI, se pueden manejar varios dispositivos esclavos, desactivando los esclavos que no se usan con el SS o CS, eso impiden que estos esclavos puedan mandar datos por el bus y malograr la comunicación, pero no impide que estos esclavos escuchen la conversación entre el master y el esclavo activo.
Entonces cuando se selecciona otro esclavo, este tiene un dato basura que está en su buffer de recepicón SPI, debido a la escucha de la comunicación anterior, entocnes el primer dato que lee el esclavo no es el primer dato que le envía el master si no un dato incorrecto, esto es cierto..? y si es cierto como solucionarlo.
-
Hola Deimos, tengo una duda con el SPI, se pueden manejar varios dispositivos esclavos, desactivando los esclavos que no se usan con el SS o CS, eso impiden que estos esclavos puedan mandar datos por el bus y malograr la comunicación, pero no impide que estos esclavos escuchen la conversación entre el master y el esclavo activo.
Entonces cuando se selecciona otro esclavo, este tiene un dato basura que está en su buffer de recepicón SPI, debido a la escucha de la comunicación anterior, entocnes el primer dato que lee el esclavo no es el primer dato que le envía el master si no un dato incorrecto, esto es cierto..? y si es cierto como solucionarlo.
Hola Renatox. No es correcto lo que dices, ya que si un nodo tiene el CS desactivado, no almacena ni escucha nada. Para que el nodo se entere que van a trabajar con él ha de ver un flanco en su entrada de chip select (normalmente negada, aunque los hay de selección por positivo). Mientras el CS no sufra un cambio de nivel, el buffer de recepción y el de transmisión (en caso que tenga dos) del nodo se mantiene inalterable. El problema básicamente se da cuando varios esclavos mandan tramas al maestro, entonces si que ha colisión en el bus.
Resumiendo, sin cambio de CS no hay peligro de dato basura, como tu lo has definido.
Espero haberte sido de ayuda.
Dews!!!!!
-
Excelente, gracias.
-
No hay de que.
Dews!!!!!
-
Hola, y si usas el I2C pero sacándolos por esos dos pines que tienes libre, osea asi como la USART se puede sacar por otros pines que no sean RC6 ni RC7, podrías hacer lo mismo con esos pines, el CCS creo que permite hacer eso. Corregirme si me equivoco,
Renatox, el problema mio no es implementar un I2C en pines distintos al que vienen en el pic, mi problema es que la comunicacion I2C no me sirve para lo que comente al abrir este tema.
Igualmente gracias por tu aporte.
-
Lupin en i2c no hay bit de start o de stop, sino que es una combinación entre la linea de clock y la de datos. Lo bueno de ese sistema es que con el start avisas a todo el bus, pero siempre es necesaria la señal de ACK para seguir con la comunicacion.
Ok, yo le llamo "bit de start" al "start condition" y "bit de stop" al "stop condition"
El problema si uso I2C es que mientras estoy enviando la direccion del equipo con el cual me quiero comunicar, lo mas probable es que estos bits se pierdan ya que el modulo que deberia recibirlos todabia no esta listo (minimos recursos usados en la comunicacion, incluso sin interrupciones).
En el i2c puedes mandar solo tramas de 8 bits, y como bien dices, en el nodo de recepcion montas los words tan largos como te sean necesarios, pero, en el i2c las primeras partes de la trama son direccion y palabra de comando, es decir lectura o escritura. Con tu sistema mandas datos pero no sabes a donde van a parar, ni tampoco si el dato es de lectura o escritura, o pertenece a una dirección. Supongo que esto te lo montas con un diccionario interno en el nodo de recepción, pero personalmente no me parece una solución demasiado acertada.
Explique la comunicacion entre dos pics, pero no di ningun detalle de la comunicacion con muchos modulos conectados al mismo bus, por eso la confusion...
Cuando hay varios pics colgados del mismo bus (yo uso 5) uso un ACK mas prolongado para lograr lo siguiente:
Supongamos que el pic_3 quiere mandar un dato al resto..
Pic_3 pone en bajo SCL..
Pic_2 (por ejemplo) es el primero en engancharse y pone en bajo SDA (ACK de pic_2)..
Mientras dura este ACK, el pic_5 (por ejemplo) se engancha a la comunicacion y pone en bajo a SDA (que ya estaba en bajo) extendiendo su duracion..
Despues pic_4 (por ejemplo) hace lo mismo ...
Y finalmente Pic_1 que estaba terminando de resolver algo, ve que SCL esta en bajo.. y se engancha a la comunicacion prolongando SDA en bajo.
Cuando termine el ACK del pic_1 es cuando SDA vuelve al estado alto.. en este momento los 5 pics estan sincronizados esperando los datos de quien inicio la comunicacion.
Cuando se termina de transmitir el Byte completo, el ciclo se repite hasta transmitir todo el paquete.
Al terminarse de transmitir el paquete de bytes, cada pic interpreta la informacion recibida para ignorarla o actuar en concecuencia (si queremos, mas de un pic puede hacerse cargo y actuar segun cierto mensaje recibido).
Si es i2c las tramas están incompletas, y si es SPI falta en el cronograma de la linea de chip select para indicarle al nodo que en ese momento se le va a hacer trabajar.
No puedes pinchar en el bus (tal y como lo tienes planteado) más de dos nodos (master y slave), ya que el primero que entre ocupará el bus. En i2c no hay problema ya que la trama la reciben todos los nodos, pero solo responde el que reconozca la dirección de nodo, pero solo uno, no pueden responder varios nodos a la vez. En SPI no puedes tener más de un nodo por bus, ya que la selección se hace a través del CS. Con tu sistema los nodos se estrellarían, ya que todos tendrian el CS activado, y todos se pondrían a mandar datos a través del bus, con lo que colisionan. En un bus SPI, lo normal es tener activo solo un nodo esclavo, y activado por CS. Si quieres poner más elementos en el bus SPI los has de ir multiplexando con sus respectivos CS, pero solo puede haber un esclavo activado.
Como ya explique no es I2C, no es SPI, no tengo posibilidad de agregar ningun CS (tengo solo 2 cables), no puedo mandar una direccion antes de recibir el ACK.
Renatox
Dentro del Mplab hay unas librerias que empiezan con sw (ej: sw_i2c.h, sw_spi.h, ...) que son precisamente para lo que comentas, para simular un puerto digital I/O con módulo asociado (i2c, spui, usart, etc...). Puedes crear puertos como los mencionados con pines I/O de propósito general. El problema que veo yo aquí, es que como ni es i2c ni spi, es posible que ninguna libreria le acabe de servir. En CCS no sé si tienen estas librerias, es un lenguaje que no practico.
Que no sea ni I2C ni SPI no es el problema, ya que a proposito lo hice diferente para que cumpla con las necesidades del proyecto, mi consulta inicial era si hay algo estandar (que no es el I2C ni tampoco el SPI) que sea casi identico o que cumpla con los requerimientos, para poder usarlo en lugar de este sistema "casero" y (un poco improvisado), aunque los resultados hasta ahora fueron excelentes (y las rutinas muy simples).
En este momento estoy comunicando de esta manera todo un "rejunte" de placas de distintos equipos (modificando minimamente los soft).. un teclado matricial (pic 16f84A), un display LCD (pic 16f873A), una CPU (pic 18f452), una placa de control de 10 reles (pic 16f873A), otra cpu (pic 16f873A) y un transmisor/receptor infrarrojo (pic 12f675)... (ahora que me fijo bien, son 6 modulos no 5 como dije en el ejemplo).
Cuando se me acaben todos estos modulos ya armados, seguramente reducire a este "franskestein" en una sola CPU (con un solo pic), pero por ahora el protocolo SOM me viene salvando.
Sigo escuchando sujerencias, modificaciones, criticas, etc.
saludos
-
Este sistema que utilizas para controlar las colisiones me recuerda mucho al protocolo CAN, pero solo el sistema de colisiones, por lo demás me sigue recordando a I2C o SPI.
Con respecto a lo que dices de usar I2C y que los bits se pierdan...... no veo el porqué se van a perder. Lo que puedes hacer (aunque no lo veo necesario) es enviar una trama con la direccion, y si no recibes nada volver a enviar hasta 5 o 10 veces, si no recibes absolutamente nada entonces dictaminas que el nodo está K.O.
-
Este sistema que utilizas para controlar las colisiones me recuerda mucho al protocolo CAN, pero solo el sistema de colisiones, por lo demás me sigue recordando a I2C o SPI.
El CAN lo conozco solo de nombre (despues voy a ver como funciona). Te recuerda al I2C y al SPI, porque toda transmision de datos serie sincronica tiene similitud con el I2C o con el SPI.
Con respecto a lo que dices de usar I2C y que los bits se pierdan...... no veo el porqué se van a perder. Lo que puedes hacer (aunque no lo veo necesario) es enviar una trama con la direccion, y si no recibes nada volver a enviar hasta 5 o 10 veces, si no recibes absolutamente nada entonces dictaminas que el nodo está K.O.
Los bits se pierden, porque por ejemplo en una de las placas que utilizo, solo puedo atender el puerto cada 300mSeg (en este tiempo ya pasaron los datos de direccion, y todos los demas bits de una I2C). Si implemento una I2C lenta para solucionar esto, los datos se transmiten tan lento que el paquete completo tardaria varios segundos en completarse (y son menos de 100 bytes).
Con este sistema tengo la ventaja de que despues de enviarse el primer byte, el resto del paquete pasa muy rapido, de esta forma se podria decir que el tiempo que tarda el paquete en transmitirse es despreciable respecto del tiempo que tardan los modulos en atender el puerto.
Tratar de iniciar la comunicacion varias veces (5.. 10veces )hasta lograrlo, fue justamente una de las cosas que quise evitar.
Saludos y gracias por las sugerencias.
-
Prueba a realizar la comunicacion por interrupciones entonces, y no por bucles de espera como seguramente lo tienes, por eso se te pierden los bits, porque los estas esperando, en vez que ellos te avisen cuando llegan.
Cada vez que tocas algo te ves obligado a recalcular los tiempos de envios y retocar esos bucles de espera y esos delays. Montes lo que montes de protocolo, te recomiendo que uses interrupciones para la recepcion de datos. Así es muy improbable que se te pierda ningun bit.
Salu2
-
Prueba a realizar la comunicacion por interrupciones entonces, y no por bucles de espera como seguramente lo tienes, por eso se te pierden los bits, porque los estas esperando, en vez que ellos te avisen cuando llegan.
Si, seria lo ideal, pero justamente comence este hilo de la siguiente forma..
...por esto es que decidi "embeber" algun tipo de comunicacion serie bidireccional por dos pines, pero despues de ver algunos estandar, no me convencio ninguno por motivos de no querer agregar interrupciones de soft en algunas placas o tener que gastar muchos recursos del pic para atender esta comunicacion...
Entre las placas que participan de esta comunicacion, hay una que por ejemplo durante 300ms no puede atender nada excepto lo que esta haciendo, por lo que ademas de la interrupcion tendria que agregarle un buffer de algunos bytes donde ir guardando los datos recibidos, y comenzar a hacer esto en las 6 placas con sus 6 programas diferentes es bastante trabajoso. Con esta comunicacion solo "pego" la rutina de enviar_dato y la de recibir_dato y sale andando.
Cada vez que tocas algo te ves obligado a recalcular los tiempos de envios y retocar esos bucles de espera y esos delays...
No debo haber explicado bien como funciona este sistema, porque gracias a la señal de ACK que se recibe antes de iniciar el envio de datos, hace que sea muy flexible y tolere variaciones de tiempo muy grandes (desde 100micro Segundos hasta 500Mili segundos) por eso funciona bien con y sin interrupciones (puedo modificar lo que sea en el programa sin tener que retocar ningun bucle de espera ni delays).
Gracias a lo explicado por ustedes, estoy empezando a concluir en que no existe ningun sistema de comunicacion con estas caracteristicas, posiblemente porque estas caracteristicas solo sean necesarias en casos como este (rejunte de placas) o en programas muy basicos en los que se busca simplicidad.
Saludos.
-
El no querer agregar interrupciones al fuente no es prudente, yo todos los fuentes que hago normalmente en el bucle principal no hacen nada, y el resto lo monto en el vector de interrupciones. No te pide más recursos, sino todo lo contrario. Mientras el micro no reciba interrupcion por dato de recepcion en el buffer, se puede dedicar plenamente a sus tareas. Lo podrias montar por ejemplo, con las entradas INT de las cpus.
Yo lo que si he hecho es conectar varios micros a un bus CAN y no me ha dado problemas ni de colisiones, ni de desincronizaciones ni nada, y todo por interrupciones. Pienso que es posible que te estés complicando bastante, y que con otro protocolo estandar ya lo tendrias solucionado.
Con interrupciones tienes la flexibilidad que quieras, ya que deja de ser un sistema síncrono para ser un sistema eventual, por eventos, estímulos, hitos o como lo quieras llamar.
En fin, porque no cuelgas el fuente para que le echemos un vistazo? Si quieres, claro está.
Dews!!!!!
-
Deimos:
Colgar el codigo seria bastante engorroso, ya que son 6 programas en total, y si sumamos todos.. nos da unas 20K lineas de programa en assembler.
Quiero aclarar que estoy totalmente de acuerdo con tus sugerencias, con el uso de interrupciones, etc. El problema principal radica en dos factores principales:
1- Por lo menos 2 de los 6 soft que tengo que modificar son de hace mas de 8 años, y en esa epoca era un poco mas desprolijo programando (practicamente inentendible y muy poco estructurado) por lo que no queria tener que adentrarme mucho en esos soft y con este sistema solo tenia que pegarle un "call" en el bucle principal, sabiendo que no le afectaria al resto del codigo (mientras no hay comunicacion este sistema retorna el control al programa en 6 microsegundos).
2- Una de las placas (mas nueva) desactiva las interrupciones durante 300miliseg cada 5 segundos, por lo que en esta ya no puedo usar interrupciones para la comunicacion. Si un dato entrase durante esos 300milisegundos entorpeceria la medicion que se realiza en ese tiempo (que es la mayor prioridad del equipo). y si desactivo las interrupciones pierdo el dato (en caso que justo se recibiera).
Lo ideal seria tomarme el tiempo para actualizar todos los soft, agregarle I2C a todos (con interrupciones) y modificar esa medicion (la de 300miliseg) para que pueda aceptar pequeñas interrupciones (esta es la parte mas complicada). Pero casi siempre trabajo contra el reloj y despues de que a este formato de comunicacion serie lo pude "crear" , colocar en todos los pics y probar que funcione bien en menos de un dia, lo empece a usar hasta que se agoten todas las placas a reciclar.
Hice el intento de estandarizarme viendo si habia algo con las mismas caracteristicas, pero parece que no hay, entonces seguro lo voy a seguir usando mientras no solucione los puntos 1 y 2.
Saludos