Comunicacion entre Micropics

Todo cuanto tiene que ver con la obtención, almacenamiento y proceso de la información digital, sus aplicaciones y el software y hardware utilizado.
Mensaje
Autor
Avatar de Usuario
fusion
Mensajes: 4573
Registrado: Lun Feb 20, 2006 1:12 pm
País: Madrid
Ciudad: Alcobendas
Ubicación: Madrid

Comunicacion entre Micropics

#1 Mensaje por fusion »

Tengo que comunicar dos microprocesadores de microchip en el mismo PCB. ¿Cual es el más sencillo de usar?, ahora uso el can bus pero no quisiera usar el receptor de este. He usado anteriormente el RS232, pero ignoro si el SPI va bien o es mejor algún otro

Avatar de Usuario
heli
Mensajes: 1946
Registrado: Mié Sep 06, 2006 7:28 am
País: España
Ciudad: Alcalá de Henares
Ubicación: Alcala de Henares (Madrid, España)
Contactar:

Re: Comunicacion entre Micropics

#2 Mensaje por heli »

Depende de lo que se tengan que contar entre sí los micros... CAN para inter circuit comunications es matar moscas a cañonazos, esta diseñado para lo contrario: para sacar las comunicaciones de las placas y llevarlas lejos.

Para muchos datos lo mejor RS232, pero tienes que escribir tu protocolo basado en mensajes para que se entiendan sin errores... Los micros modernos pueden comunicar a >1Mbit/s y dentro de la misma placa no habrá problemas. El RS232 es bidireccional, cualquiera puede iniciar la comunicación...

Para datos binarios, mensajes de sincronización o palabras sueltas (comandos, parámetros de 8/16 bytes) etc mejor usar I2c o SPI que estan basados en registros. Inventas un mapa de registros cada uno con una utilidad y listo. Con estos tienes que tener un MASTER y varios SLAVE, solo el master inicia las comunicaciones y escribe o lee...

Yo he usado I2C para comunicar varios PIC, un master y varios slaves identicos pero con distintas direcciones. Los slaves recibian una trama por IR y la almacenaban en los registros del 1 al 8 para que el master la leyera. Si escribias en un slave en los registros 9, 10, 11 es información iba a unos LED RGB que controlaba cada slave... simple.

Elo I2C es lento, para mucha velocidad mejor SPI.
¡No es imposible, lo que pasa es que no sabes como hacerlo!
Aka: no es difícil si sabes como.
http://heli.xbot.es

Avatar de Usuario
fusion
Mensajes: 4573
Registrado: Lun Feb 20, 2006 1:12 pm
País: Madrid
Ciudad: Alcobendas
Ubicación: Madrid

Re: Comunicacion entre Micropics

#3 Mensaje por fusion »

El RS232 creo que también se puede usar para escribir en un LCD (creo), lo cual me valdría para ver que pasa dentro, o no sé si es mejor para eso el SPI, o I2C. Mi idea es mandar comandos cortos de un nivel analógico y digitales y quizá leer telemetrias.
¿cual sería el más fácil de programar?

Si uso el mismo modelo de chip vendría bien. Imagino para programarlos se puede usar el mismo conector con un switch manual para cambiar de uno a otro ¿no?

Avatar de Usuario
heli
Mensajes: 1946
Registrado: Mié Sep 06, 2006 7:28 am
País: España
Ciudad: Alcalá de Henares
Ubicación: Alcala de Henares (Madrid, España)
Contactar:

Re: Comunicacion entre Micropics

#4 Mensaje por heli »

El RS232 creo que también se puede usar para escribir en un LCD (creo)
En general NO. No hay LCD con RS232, aunque hay módulos que incluyen un micro que sí tiene RS232. Los LCD suelen conectarse en paralelo con 14 ó 18 hilos, aunque venden versiones comerciales con un IC para controlarlos por I2C (muy común). Los TFT y OLED suelen comuicarse por SPI, aunque también existen versiones en paralelo por muchos hilos (cuando necesitas una velocidad de refresco alta, vídeo...).
¿cual sería el más fácil de programar?
La comunicación o sincronización entre micros no suele necesitar de mucho código, el RS232 es lo más largo porque tienes que desarrollar un protocolo (o reciclar alguno ya escrito). Con I2C y SPI es más sencillo porque te limitas a escribir bytes en registros con direcciones fijas...
Mi idea es mandar comandos cortos de un nivel analógico y digitales y quizá leer telemetrias.
Según la velocidad de actualización que necesites usa SPI o I2C.
Imagino para programarlos se puede usar el mismo conector
Para programarlos por RS232 tienen que tener "bootloader serial", entonces sí que puedes usar el conector RS232 con un switch. Pero lo más normal es que se programen por JTAG o por ICSP.
¡No es imposible, lo que pasa es que no sabes como hacerlo!
Aka: no es difícil si sabes como.
http://heli.xbot.es

Avatar de Usuario
fusion
Mensajes: 4573
Registrado: Lun Feb 20, 2006 1:12 pm
País: Madrid
Ciudad: Alcobendas
Ubicación: Madrid

Re: Comunicacion entre Micropics

#5 Mensaje por fusion »

Con I2C y SPI es más sencillo porque te limitas a escribir bytes en registros con direcciones fijas...
¿Desde un micro escribo en una dirección de otro micro o en una dirección del spi?,

Es que es genial, el que lee no se tiene que preocupar de las comunicaciones, solo lee el último dato :), (creo recordar así funciona el mod bus sobre 485)

Avatar de Usuario
fusion
Mensajes: 4573
Registrado: Lun Feb 20, 2006 1:12 pm
País: Madrid
Ciudad: Alcobendas
Ubicación: Madrid

Re: Comunicacion entre Micropics

#6 Mensaje por fusion »

Al final me han recomendado el I2C, pues con solo 2 cables y tierra comunicas todos los micros, pues el SPI además necesitaría un hilo por receotor y no veas lo mal que sienta quitar uan pata del micro.

¿Hay algún conector paralelo chulo de 3 pines?, aunque lo ideal es pinchar en un back panel donde esté la alimentación

Avatar de Usuario
baldo
Mensajes: 1514
Registrado: Vie Dic 23, 2005 7:54 pm
País: españa
Ciudad: coruña y madrid
Ubicación: Galicia
Contactar:

Re: Comunicacion entre Micropics

#7 Mensaje por baldo »

fusion escribió:¿Desde un micro escribo en una dirección de otro micro o en una dirección del spi?,
heli se referia a que escribes el byte en un registro del maestro, y te olvisas, lo recibe el esclavo.

los problemas del SPI:

1º la decodificacion es "fuera de banda". significa que si eres maestro y quieres hablar con un esclavo, antes tiene que activarlo por la patilla chip select, un lio. a no ser que hagas un protocolo con la direccion del esclavo, y que solo este se de por aludido y hable. pero para hablar con uno, despiertas a todos, otro lio.

2º para recibir tiene que mandarle reloj al esclavo. este tendria que mandar en el paquete la longitud. tiene que darle a "la manivela". otro lio.

3º el esclavo no puede hablar cuando quiera/pueda, necesita de la manivela. por supuesto que los esclavos no pueden hablar cuando quieran, pero imposible tipo "muevete a tal sitio, y avisa cuando llegaste", habria que preguntarle siempre si llego.

de los 3 serie, USART, SPI, y I2C, casi me quedo con una modificacion del USART, la de usar un unico cable, que usan todos, convierte la usart en half duplex ( o hablas o escuchas), pero esto suele ser asi siempre incluso con cables especifiocs, usando el truco del diodo, o un ampli de colector abierto. por supuesto que el que habla se oye a si mismo.
esto tendria alguno de los problemas vistos: decodifi en banda por dierccion de esclavo, despertar a todos,,, pero no manivela, y hablan cuando pueden / quieren.

hay unos driver,,, con dos salidas balanceadas,,, ¿heli, estas ahi?, ¿que opinas de esto?

este asunto me interesa, a ver si nuestro experto nos aclara.

Avatar de Usuario
heli
Mensajes: 1946
Registrado: Mié Sep 06, 2006 7:28 am
País: España
Ciudad: Alcalá de Henares
Ubicación: Alcala de Henares (Madrid, España)
Contactar:

Re: Comunicacion entre Micropics

#8 Mensaje por heli »

los problemas del SPI:
El SPI no es tan complicado de usar.
La pega que tienen tanto el SPI como el I2C es que son buses master-slave. Solo uno puede ser el master e iniciar las comunicaciones, enviar el clock etc.
Para bus multi-master tienes el CAN, pero ese sí es más complicado de usar.

La opción de usar el RS232 es siempre interesante, pero exige bastante más inteligencia en los chips para gestionar los datos.
Aunque el RS232 es un sistema simétrico punto a punto puede hacerse multipunto multimaster simplemente añadiendo unos diodos y unas resistencias y uniendo todos los TX y RX en un solo hilo. Pero hay que desarrollar un protocolo a medida para gestionar las comunicaciones y sobre todo para evitar las colisiones si dos master deciden comunicar a la vez. Estas soluciones son solo para comunicaciones intermicro dentro de una placa o de un rack, no valen para campo.

Yo lo he usado (con niveles TTL) con un master y 6 esclavos con i8051, pero la solución "profesional" es usar transceivers RS485 (half duplex) o RS422 (full duplex). Así tengo un bus sobre cable telefónico con un master PC y 9 tarjetas con i8051 funcionando desde hace más 25 años.
En mi caso es master (PC) slave (tarjetas). El protocolo de comunicación tiene unos mensajes de polling cada 3 segundos con 3 reintentos y timeout si no hay respuesta, para preguntar a los slaves si tienen algo que contar. También contempla mensajes de comando para enviar información a los slaves. Todo muy robusto, la integridad de los mensajes es mediante CRC8 y la recepción de los mensajes debe ser confirmado con ACK.
Si necesitáis ejemplos de código y esquemas pego aquí algo. He usado I2C, SPI y RS232/RS485/RS422 con distintos protocolos y cableados, con el CAN no tengo experiencia.
¡No es imposible, lo que pasa es que no sabes como hacerlo!
Aka: no es difícil si sabes como.
http://heli.xbot.es

Avatar de Usuario
fusion
Mensajes: 4573
Registrado: Lun Feb 20, 2006 1:12 pm
País: Madrid
Ciudad: Alcobendas
Ubicación: Madrid

Re: Comunicacion entre Micropics

#9 Mensaje por fusion »

El can es fácil de usar una vez que has logrado configurarlo y vale sirve para trasmitir comandos o telemetrías de 4 words de 16 bits.
Lo suyo es escribir en determinados registros del slave y que éste lea ahí como hace el modbus, aunque el modbus no me gusta mucho pues hay que poner otro chip que haga la conversión.
El escribir en un registro permite leer en él cuando quieras sin tener que mirar si han habido interrupciones

Avatar de Usuario
heli
Mensajes: 1946
Registrado: Mié Sep 06, 2006 7:28 am
País: España
Ciudad: Alcalá de Henares
Ubicación: Alcala de Henares (Madrid, España)
Contactar:

Re: Comunicacion entre Micropics

#10 Mensaje por heli »

aunque el modbus no me gusta mucho pues hay que poner otro chip que haga la conversión
Mi entender...
El Modbus RTU es un protoloco que no define la capa física, se puede mandar por RS232, RS485, niveles TTL... Trabaja sobre comunicaciones serie asíncronas. Hay una versión que trabaja sobre TCP/IP. No veo donde hay que convertir nada, solo hay que implementar el protocolo en el micro.
Hay muchas librerías open source para ello, ni siquiera hay que escribirlo por uno mismo: https://www.arduino.cc/en/ArduinoModbus/ArduinoModbus
El escribir en un registro permite leer en él cuando quieras sin tener que mirar si han habido interrupciones
Tampoco entender.
No se mira si ha habido interrupciones sino todo lo contrario, las interrupciones interrumpen y se ejecuta el código correspondiente para la gestión del evento.
Lo contrario es el polling, donde sí es necesario estar mirando periódicamente los registros a ver si hay novedades.

El CAN necesita un periférico específico, en CAN controller, que puede estar embebido en el micro o ser externo. Y hay que aprender a usarlo, igual que el resto de periféricos I2C, SPI, UART...
El Can controller y yo todavía no nos conocemos, pero me llevo muy bien con los otros tres periféricos.
¡No es imposible, lo que pasa es que no sabes como hacerlo!
Aka: no es difícil si sabes como.
http://heli.xbot.es

Responder

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 0 invitados