Autor Tema: Quien conoce este protocolo serie o similar?  (Leído 3754 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado Lupin

  • PIC12
  • **
  • Mensajes: 81
Re: Quien conoce este protocolo serie o similar?
« Respuesta #15 en: 15 de Marzo de 2007, 19:18:43 »
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.

Deimos

  • Visitante
Re: Quien conoce este protocolo serie o similar?
« Respuesta #16 en: 16 de Marzo de 2007, 05:47:20 »
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

Desconectado Lupin

  • PIC12
  • **
  • Mensajes: 81
Re: Quien conoce este protocolo serie o similar?
« Respuesta #17 en: 16 de Marzo de 2007, 10:18:25 »
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..
Cita de: Lupin
...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.


Deimos

  • Visitante
Re: Quien conoce este protocolo serie o similar?
« Respuesta #18 en: 16 de Marzo de 2007, 10:26:52 »
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!!!!!

Desconectado Lupin

  • PIC12
  • **
  • Mensajes: 81
Re: Quien conoce este protocolo serie o similar?
« Respuesta #19 en: 16 de Marzo de 2007, 17:50:33 »
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