Reto Conseguido: Red de Pics mediante Rs232

[Manunet]

Hola a todos, quisiera compartir con vosotros un reto que llevaba mucho tiempo detrás de el.
Os explico, a mi siempre me han gustado los sistemas modulares, mas sencillos de configurar y de mantener y hace poco tiempo me prospuse hacer un "invento" el cual lleva 4 partes, la primera parte y principal con un 16f877a y las tres restantes con unos 16f627a.

El funcionamiento es sencillo, cada 16f627a trabaja a su ritmo, si ocurre algo informa al 877a en cualquier momento y el 877a se puede comunicar con cualquier 627a tambien en cualquier momento.

Las pegas, que utilizo 3 pines, dos de datos y uno de estado de linea, cuando alguno quiere transmitir primero comprueba el estado de esa linea, si está en Low la pone en Hi y transmite, el receptor, mediante una ID sabe que le estan hablando a el y responde a las solucitudes, cuando se termina la transmision, el transmisor vuelve a poner la linea en Low.

Por ahora lo tengo todo mediante botones, de manera manual, voy a ver si consigo hacerlo de forma automatica para que funcione el pin LineState.

Ahora mismo, el 877a tiene tres botones y tres leds, a grosso modo, en simulacion, sin resistencias ni nada, luego ya le pondré todo lo que le hace falta y probaré.
Bueno, si le das a Btn1 del 877a, se enciende el led de un 627a, si le das a Btn2 se enciende el de otro 627a y con Btn3 pasa lo mismo, ahora, lo mejor de todo es que cada 627a tiene un boton, si le pulsas, pues en el 877a se enciende el Led correspondiente.
Por ahora solo transmite un byte, veremos con tramas mas largas...

os adjunto foto



Se me olvidaba.. jeje.. por ahora solo hay comunicación desde los 627a hacia el 877a o del 877a hacia los 627a, mas adelante veré de que todos "vean" a todos en armonía.

Lo buene que tiene este metodo es que de esta manera puedes conectar tantos pics como quieras.

 

[locodelafonola]

hola..amigo........ interesante el proyecto...pero el esquema no se nota nada .....y al agrandarlo pierde definicion ......y se ve borroso

 

[Meta]

Hola:

¿Con qué lenguaje lo hiciste?

Buen trabajo.

 

[miguelus]

Buenas tardes

esa forma de comunicarse suena a Bus I2C o algo muy parecido
Sal U2

 

[Manunet]

Buenas tardes

esa forma de comunicarse suena a Bus I2C o algo muy parecido
Sal U2

Si, la verdad es que es muy parecido, el hilo LineState, que así lo he llamado correspondería al pin CS del protocolo I2c.
Con las prisas no he podido explicarme bien, os explico:

Me he fijado en el protocolo Can-Bus, I2c y SPI, entonces quería crear algo sencillo y facil de implementar para mis proyectos, pero el resultado siempre era el mismo, me faltan pines o espacio de memoria en los pics para tantas funciones, asi que decidí hacerlo modular, cada modulo desempeñaría un trabajo a su ritmo, todos con un fin en comun designado por el pic Maestro, que en este caso es el 877a, como los modulos comandados por los 627a son sólo para recolectar información y realizar calibraciones necesitaba algo para que el 877a pudiera comunicarse con los 627a en cualquier momento que el usuario solicitase información, tambien quería que en el caso de ocurrir algo en algun módulo, el 627a encargado de esa funcion informaría al 877a tomando las decisiones oportunas, pero claro, tantos datos hay que guardarlos en alguna memoria, y por eso no quería usar el I2c, ya que lo quiero exclusivamente para comunicarse con las memorias EEPROM.

Así que me puse a investigar y conseguí esta configuración capaz de satisfacer todas mis necesidades.

El firm está escrito con el Pic Simulator Ide, que aunque para ciertas cosas está muy limitado siempre me las puedo arreglar para conseguir lo que quiero.

Mañana os subo el esquema en Proteus y los HEX de cada pic.

saludos

 

[Manunet]

Lo prometido es deuda, aqui teneis un .RAR con el DSN en proteus y los HEX de los 4 pics, para hacerlo funcionar simplemente apretar los botones y listo, una vez enciende y la segunda apaga los led.

No hace falta decir que es una simulación de una investigación y que por supuesto faltan varios componentes, como resistencias, diodos, etc... para conseguir un correcto funcionamiento en la protoboard.

Si os fijais los datos se transmiten por los pines TX y RX de cada pic mediante RS232, ahora, para que veaís que realmente es rs232 y no I2c o SPI, daros cuenta que el unico pic que tiene I2c y SPI es el 877a, los 627a sólo tienen rs232, o TTL para ser más exactos.

saludos

Se me olvidaba.. jeje.. vaya cabeza la mia.. hay un conector llamado linea, este es comun a los 4 pics, en esta simulación no lo uso ya que estaba investigando, pero mas adelante lo utilizaré para que antes de transmitir se compruebe esa linea por si hay alguna transmision en curso.

 

[Meta]

Muy bueno.

Rx y Tx lo entiendo. ¿Lo de LÍNEA para que es exactamente?

Saludo.

 

[Manunet]

El conector Linea lo he puesto para idear un metodo para que dos pics no transmitan a la vez, por ejemplo, el 877a pide info a un 627a y en ese momento en otro 627a ocurre algo que debe informar al 877a, claro, como los otros dos están "hablando" si se mete un tercero pues la conversación se pierde, así que cuando la linea está en HI solo transmite el 877a y uno de los 627a, cuando vuelve a LOW cualquiera puede establecer una transmision.

Pero en esta simulacion no se utiliza, ya que la simulacion no es automatica, para realizar cualquier cosa es necesario apretar algun boton con lo cual nunca va a haber colision de datos. Mas adelante utilizaré ese conector para establecer un protocolo de "espera"

 

[Manunet]

Bueno, he seguido con el tema y tengo algunos problemas, si pngo al 877 a transmitir sin parar una secuancia para que cada 627 encienda un led e intento transmitir desde un 627 para que el 877 encienda un led el 877 no se entera... jo!, voy a rediseñar el ciruito para intentar utilizar el conector LINEA para conectarlo al RB0 de cada pic y así utilizar la interrupcion de RB0 cuando el estado de LINEA sea LOW, así, cuando alguno transmita esa linea la pone a HIGH despues de comprobar que esté en LOW, una vez transmitidos los datos esperaré unos milisegundos para ponerla otra vez a LOW, me temo que vá a ser un quebradero de cabeza ya que todos los pines RB0 deberán de estar como INPUT e ir cambiando a OUTPUT y volver a INPUT segun sea necesario...
Por otra parte voy a intentar rediseñarlo para que todos puedan hablar con todos, de esa manera se podría intercalar un "modem" TTL<->Rs232 para intercalar un pc y que éste pueda enviar y recivir de todos los pics en la red.

En menudo berenjenal me he metido.. jaja..

saludos!

 

[Meta]

En menudo berenjenal me he metido.. jaja..

Jajajajajajjja, ya te darás cuenta que eres una persona resolutiva, que los errores forman parte del aprendizaje, no ahy que amargarse, ajjajaja.

Si el PIC16F877 no escucha o te mete la gran ignorada del año, ahí está el problema.

¿Qué ocurre?
El PIC maestro no escucha.

¿Qué hacer?
Detectar el problema para ser escuchado.

¿Cómo lo resulevo?
Haciendo ruido. Tocándole los registros hasta el fondo, probar, probar y probar hasta saber donde le duele.

Por cierto. Buen trabajo.

 

[Manunet]

Gracias Meta!, tu apoyo me anima. jeje.. bueno, lo que he descubierto con el osciloscopio del Isis es que las tramas que manda el 627 las envia cuando el 877 está enviando, entonces necesito hacer saber al resto que hay un pic transmitiendo y que no se puede transmitir hasta que LINEA vuelva a LOW, el único problema que veo por ahora es que si dos pic's ejecutan las instrucciones exactamente al mismo momento se pueden poner a transmitir a la vez, pero mas o menos pienso que poniendole un retardo distinto a cada uno antes de poner LINEA a high podría solucionar el problema.

Por ahora voy a reescribir todo el código desde cero y cuando pruebe pues, como suelo decir, iré "matando ratas".. jajaj hasta que dé con la tecla.

saludos



Añado:
El 877 si que escucha, si aprieta algun boton de algun 627 si que enciende el led el 877, pero el problema es cuando al 877 lo meto en un bucle para que transmita sin parar... ahí es cuando pasa de mi... jo!.. no me quiere.. ains...

 

[Meta]

El 877 si que escucha, si aprieta algun boton de algun 627 si que enciende el led el 877, pero el problema es cuando al 877 lo meto en un bucle para que transmita sin parar... ahí es cuando pasa de mi... jo!.. no me quiere.. ains...

Vaya, el 877 escucha pero no oye.

El tema de hablarse entre varios a la vez de un mismo grupo es un problema de comunicación, tanto el habla sin escuchar, que el que escucha mira como le hablan al mismo tiempo, luego él habla sin los demás que no escuche, ahí está el problema. Por si acaso haya una moto fuera y estás hablando y escuchando, con el ruido que hace mejor cierra la ventana, digo, pon condensadores de 100 nF en paralelo de la alimentación de cada PIC.

Hasta eso puede evitar futuros ruidos o alborotos más de lo que imaginas.

Cuando un 877 poco escuchador y mucho hablador, solo que hable cuando tiene que hablar a alguien. Ese alguien no responderá hasta que 877 acabe la conversación, los demás esclavos no deben hacer ni un solo ruido ni interrumpir. Solo se hablan uno a la vez, no al mismo tiempo para poder entenderse. Cuando un esclavo habla, los demás a callar, incluido 877.

Cuando quiera hablar un esclavo, hablará siempre y cuando los demás estén callados para escuchar mejor.

¿Se entiende el concepto?

Ánimos y adelante.

 

[Manunet]

exacto, el justo eso, por eso el conector LINEA, ese pin será el indicador de que todos a callar y ponerse a escuchar que voy a hablar.. jej... el que vaya a hablar comprobará la linea, si está en high callará y esperará, pero si está en low la pondrá en high y hablará, despues la pondrá en low, callará y se pondrá a escuchar... jeje.. si, ese es justo el concepto, ahora falta llevarlo a la práctica.

El tema de ruidos y motos por ahora no me preocupa, ya que es una simulación hasta que construya completamente el protocolo, luego, en la protoboard y con ayuda de un osciloscopio veremos las "carreras de la MotoGp" e hiremos poniendo "silenciadores".

Creo que a mas de uno le valdrá este protocolo ya que he visto por ahí muchos hilos de gente que quiere conectar muchos pic's entre si, y si consigo hacer el protocolo full-duplex ya sería la leche... jaj.. pero no creo, debería de estudiar aún más el protocolo Can-Bus que sólo usa dos hilos a ver como está construido.

Mañana seguiré peleandome, hoy ya se ha hecho tarde.

Saludos a todos y os mantendré informados.

 

[Meta]

Lo has pillado

Por ahí se empieza.

Protocolo para conectar condos hilos varios dispositivos está bien el I2C, el SPI es más rápido pero cada dispositivo que pongas, requiere un pin extra al microcontrolador maestro..El CAN bus se usa para cohes, casi nadie lo usa y está obsoleto. Eso si, hay posibilidad.

Saludo.

 

[Manunet]

Errr.. si, esa idea la tenía clara desde el principio, de hecho todavía me cuesta creer que hay gente que vé "Salvame" y se entera de todas las conversaciones que tienen todos al mismo tiempo.. jaja.. menudo gallinero!!.. jaja.. lo que estoy investigando es el protocolo de comunicación, que como bien dices el i2c está bien, pero tiene sus limitaciones, el SPI es más rápido pero como bien dices, necesitas un pin por cada esclavo por el tema de CS, de hecho, el SPI no permite la comunicacion de un esclavo al maestro a no ser que el maestro haya empezado la conversación con lo cual, si tienes varios pic's conectados recolectando información deberás de hacer una "rueda" preguntando a cada uno por las novedades, el protocolo que estoy investigando permite, por ahora, comunicar el maestro con cualquier esclavo en cualquier momento y cualquier esclavo con el maestro tambien en cualquier momento, lo que intento por ahora es establecer una red descentralizada de igual a igual, al estilo can-bus, utilzando parte de la tecnología del SPI, por el pin CS, y utilizando tambien el i2c porque cada pic tendrá una ID única en la red, vamos, lo que se dice un "mezclote" de los 3 protocolos, por ahora la "batidora" está en marcha, veremos lo que sale y si se puede digerir.. jejej..

saludos!

 

[ByAxel]

Hola.
Si vas solo con el RS232 está el detalle que su bus no es bidireccional, es decir que siempre debe haber un maestro y un esclavo.
Un modo es el llamado multimaestro, aquí también está el detalle que entre maestros no se pueden comunicar, para tal caso haciendo uso del RS232 y copiando al I2C (el bus de datos es bidireccional) se arregla con un truquillo entre hardware (ver imagen)...en la práctica funciona en algunos metros y software (ver adjunto) que está en C del CCS pero puedes leer los comentarios para entender.

El ejemplo es un solo programa que trabaja como esclavo o maestro, cuando es maestro un LED en RA0 se activa y envia un comando que hace que el resto de PICs enciendan un LED del color respectivo al comando.

El original es un tanto más complejo pero esa es la idea, puedes mejorar ya que falta incluir el pin CS de verificación, los IDs de cada uno, etc...
Ánimo.
Saludos.

 

[Meta]

Buenas:

Para comunicar varios dispositivos que yo sepa es RS-485. A lo mejor hay otras cosas. I2C está limitado en algunas cosas. Comprueba hasta donde llega sus limitaciones, donde llega la limitación del proyecto y sobre todo de uno mismo.

Saludo.

 

[Manunet]

Hola ByAxel, muchisimas gracias por la info, es muy interesante, ese ejemplo lo estudiaré a fondo, creo que se podría hacer algo interesante con el y conseguir algo.

Por ahora en el proyecto que tengo en mente, los 627 serán recolectores de información, por ejemplo, uno se dedicará a mantener una temperatura, podrá calentar o enfríar según el caso, otro controlará una balanza con varios sensores de peso Sen-10245 y así sucesivamente, imaginaros todo eso controlado por un solo pic.. uf... demasiado trabajo, entonces, en el caso del 627 dedicado a la temperatura, en el caso de que se exceda de la tolerancia, deberá informar al 877 y éste tomará las medidas oportunas, ya que la variación de temperatura afectaría a otras cosas, con esto quiero decir que cada esclavo hará una función específica, en el caso del de la tamperatura sólo calentaría, enfriaría o mantendría la temperatura que el 877 le haya dicho y en el caso de que por cualquier cosa no pudiera llevar a cabo la tarea informará al 877. Con lo cual, en este proyecto no es necesario la comunicación esclavo a esclavo, pero ya que estoy investigando un protocolo sería bueno llegar hasta el final y conseguir algo que pudiera utilizar en un futuro que fuera necesaria la comunicación esclavo a esclavo.

salu2



Estooooo.. una cosa ByAxel, veo que la resistencia que mantiene la linea en High protege tambien al pin de TX cuando está en LOW, ahora, el problema que veo es que el mismo pic que transmite, pongamos una serie de bytes, entrará en interrupción de RX nada más haber mandado el primer byte, supongo que desactivando temporalmente la interrupcion de rx antes de enviar datos y reactivandola justo despues podría solventar el problema, peeeero... jeje, siempre hay un pero, que según el osciloscopio del simulador el buffer de tx sigue transmitiendo aún cuando el pic pasa a ejecutar el siguiente comando, entonces habría que hacer una pausa de unos Ms antes de reactivar la interrupcion, todo esto lo digo de cabeza, habría que probarlo en la proto y con el osciloscopio a ver por donde sale.

 

[ByAxel]

Exacto, así mismo funciona el ejemplo... (hace eco de todo lo que envia), pero como el PIC sabe que es el Maestro en ese momento no hace caso (ver código, variable iMaster)... si vez el código en la parte donde trabaja con los pulsadores se ve un delay luego de putc(1); (envia el 1).

Adicional:
- El eco se puede usar para segurar que el dato/s enviado/s esten completos, así el PIC sabe que el resto de PICs también los han recivido para luego soltar el PIN de verificación (modo esclavo y espera respuesta por ejemplo).
- Se sabe que el buffer por hardware del USART tiene 2 posiciones, cuando el PIC es maestro y recive datos por eco puede limpiar ese buffer con tan solo leer 1 o 2 veces. También se puede verificar los flags o bits de error de USART y reiniciar el mismo para que siga trabajando normalmente.

 

[vrainom]

Saludos Manunet. Me identifico contigo en que me gusta hacer las cosas por mi propios medios aunque ya exista una solución nada más para ver de qué soy capaz .

Por cierto, en tu protocolo podrías utilizar el método del protocolo CAN que utiliza colector abierto para la señal (como en el diagrama de ByAxel) y se asegura que la línea este alta antes de comenzar a transmitir primero su dirección, si dos dispositivos comienzan a transmitir al mismo tiempo el que tenga la dirección más baja tiene preponderancia. Esto se resuelve analizando la línea cuando en la dirección de mi dispositivo existe un 1 pero en la línea detecto un 0, lo que significa que otro dispositivo con una dirección más baja también está transmitiendo y entonces mi dispositivo deja de transmitir y comienza a escuchar.