Comunicar varios PIC

[rodstar]

Hola, este es mi primer thread. (Espero estar publicando éste en la sección correcta) El tema es el siguiente: Necesito algún consejo acerca de mi situación: Desde mi PC quiero controlar 4 motores simultáneamente. Mi diseño es tener 5 pic's, que son un PIC18F4550 como interfaz USB con el PC y al mismo tiempo coordinador entre los otros 4 PIC's (PIC18F2431) los cuales cada uno controlará su respectivo motor. Mi duda es respecto a bajo cual conección comunico los 4 pic's (de motores) al pic coordinador. Mi sospecha es conectarlos en cadena, pero lo que no sé es cuál conección si SPI, I2C, UART, o quién sabe que cosa. Eso es estimados espero alguien me dé una luz al respecto. PD: El objetivo es que en la medida que yo desde mi aplicación en windows haga mover lo motores, recibir de vuelta a mi misma aplicación de windows el feedback de la posición, dirección y velocidad real actual resultante de cada motor (por eso los PIC's con decodificación de sensor de cuadratura [el hermoso QEI]). La lógica y el software no tengo problema, mi duda es solamente acerca de cual protocolo de comunicación entre los PIC's usar, y de paso, saber si mi diseño en cadena es correcto.) ADJUNTO IMAGEN DE LO EXPUESTO, gracias

[Nocturno]

Por I2C te resultará muy sencillo comunicarlos y colgarlos todos del mismo bus, lo que facilitará el cableado.
¿Necesariamente tienes que dedicar un PIC para cada motor?, ¿has visto que hay PICs con varios módulos de control de motores en el mismo encapsulado?.
Lo del módulo QEI es muy cómodo, pero también puedes hacerlo mediante interrupción externa y evitarás consumir otro PIC sólo por el hecho de necesitar otro módulo QEI.

[pibe]

I2c tiene la ventaja que solo necesitas 2 cables para colgar cada micro. Pero la pega es que el envío / recepción de datos y direccionamiento debes hacerlo por software.
El SPI tiene la ventaja que no necesitas casi nada de software para ponerlo en marcha y direccionar cada pic por el CS (chip select) pero la pega es que son 3 cables en común y un CS por cada pic.

Yo particularmente prefiero (aunque me cueste 5 pines más del micro como en tu caso) usar el SPI por hardware. Además de su confiabilidad y facilidad a la hora de poner en marcha la velocidad de transferencias de datos es mucho más elevada que en I2C.

Una tontería, que supongo que será un error conceptivo: El 18f4550 controlaría a todos los pics, y no sólo al primero como lo muestra tu GIF.

[Nocturno]

¿Por software?, si usas el módulo I2C del PIC el tratamiento se hace por hardware.
Tanto es así que en los esclavos sólo defines su dirección I2C y te levanta una interrupción con cada byte recibido.

Yo también aconsejo SPI para altas velocidades, pero para el control de motores irá de sobra con un I2C o incluso un RS232.

[pibe]

Si, es verdad lo que dices. El I2c tiene módulo hardware como asi también el SPI e incluso comparten algunos registros. El tema es que debes tratar el ack y ya debes tener un poco más de control por software que con el SPI. Al menos y por lo que he experimentado el I2c me ha costado lo suyo hacerlo funcionar, en cuanto yo con el SPI me siento como pez en aguay me ha funcionado sin más y con total confiabilidad.
Claro que para gustos...

[MLO__]

Hola.

Otro factor importante es la longitud del bus. Si es mayor de 2 metros toca pensar en un RS485.

[rodrigo_control2009]

Estoy adaptando un codigo para la escritura y lectura de dato de 1 bit  a  float en microcontroladores esclavos,  pero  me  presenta  problemas a la  hora  de compilar .

No  reconoce rutinas de lectura  o escritura  del driver que escribi (esclavos_i2c.c).

Como  no  se  mucho  de programación , y como dije  es una adaptaión  de  otro  código una  mezcla de  ext_eeprom.c  y 24256.c .
La  verdad  no entiendo  muy bien la instruccion
#ifndef ESCLAVOS_I2C_UTILITIES
#define ESCLAVOS_I2C_UTILITIES
la inclui  pensando q esto  me  ayudaría a  evitar  codigo  repetido  pero  no  m  ayuda  mucho  creo, sin embargo  si  las  deshabilito  aun persite  el problema

Desde  ya  muchas  gracias

Adjunto el código  y  algunas rezñas  del  problema
Desde  ya  muchas  gracias.

[rodrigo_control2009]

Hola  hice  una orrecion a driver  esclavos_i2c.c   declare  las  funciones  basicas  al  principio del  driver  y  se  soluciono Pero sigo con peroblemas  En isis lo  simulo  se  ve  actividad  i2c  pero  no  se  logra la comunicacion on un esclavo  q le  cargue  ex_slave.c   

Sigo  haciendo pruebas 

[rodrigo_control2009]

Hola  he hecho  alguna s mejoras  y  lo  simulo  en isis  y  veo actividad i2c  pero  tngo  dudas  y  hay algunos  problemas .
Tngo un maestro  18f4550  con dos esclavos. En el maestro tngo rutinas rtos, usb, i2c, el usb reponde bien a la HMI  la actividad  i2c  presenta  errores.
Al escribir en los dos esclavos en el 1E(un 16F877A) se ve el dato 0x86  q segun entiendo es el  maestro diciendo TRANSMISION TERMINADA Y RECONOCIDA pero  al hcer lo  mismo  sobre el  2E(18F2550) no  ocurre  lo  mismo. Lo curioso  es q en ambos  esclavos  tengo  la misma  rutina  de atencion #int_ssp  q esta  en  ex_slave.c  y ambos escriben o lee sobre un buffer[50] .

Adjunto algunas  imagenes para  ver si detectan algo  desde ya  muchas gracias 

[rodstar]

I2c tiene la ventaja que solo necesitas 2 cables para colgar cada micro. Pero la pega es que el envío / recepción de datos y direccionamiento debes hacerlo por software.
El SPI tiene la ventaja que no necesitas casi nada de software para ponerlo en marcha y direccionar cada pic por el CS (chip select) pero la pega es que son 3 cables en común y un CS por cada pic.

Yo particularmente prefiero (aunque me cueste 5 pines más del micro como en tu caso) usar el SPI por hardware. Además de su confiabilidad y facilidad a la hora de poner en marcha la velocidad de transferencias de datos es mucho más elevada que en I2C.

Una tontería, que supongo que será un error conceptivo: El 18f4550 controlaría a todos los pics, y no sólo al primero como lo muestra tu GIF.

Tiempo después investigué, y apenas supe que se podían conectar cada uno directo al master por SPI cambié el diseño, siendo lo ideal cada PIC esclavo (los PIC18F2431) directo al coordinador (PIC18F4550), lo cual resulta menos sucio a nivel de flujo, con SPI, aunque mas lento que I2C... pero soporta mayor distancia. Por suerte el ..4550 tiene pines de sobra.

Recién ahora me voy a meter al código, pues he estado en otros asuntos.

[jonathanPIC888]

Yo estoy haciendo el mismo proyecto que vos y ya escribí una librería de control para motores PAP mediante I2C usando como esclavo I2C un PIC16F88 y como master un PIC18F2550. El programa de controla para la PC lo estoy haciendo en VB.net 2008 y para el PIC estoy programando en C de CCS.

En el principio del hilo a que te referías con el QEI ?? , es algún tipo de enconder ??

[rodstar]

Yo estoy haciendo el mismo proyecto que vos y ya escribí una librería de control para motores PAP mediante I2C usando como esclavo I2C un PIC16F88 y como master un PIC18F2550. El programa de controla para la PC lo estoy haciendo en VB.net 2008 y para el PIC estoy programando en C de CCS.

En el principio del hilo a que te referías con el QEI ?? , es algún tipo de enconder ??

Hola, QEI se refiere a Quadrature Encoder Interface, que te permiten conectar un sensor mecanico que emite pulsos y con ellos puedes obtener la dirección, posición y velocidad del motor respectivo. El modulo QEI en la familia de PIC's del PIC18F2431 (y algunas otras familias dedicadas a control de motor) es el DECODER de un sensor ENCODER.- Espero ser claro