Mis experiencias con el BUS CAN

[MGLSOFT]

Los archivos siguientes:
main.c       -> programa principal
mcp2515_tool (extension C y H)-> definiciones de funciones basicas de acceso al mcp2515 que estan funcionales

No se pueden leer bien con el block de notas, estan llenos de espacios y caracteres raros.

El resto se leen perfectamente, podras limpiar y pasar nuevamente esos tres archivos??

[electrolinux]

Los archivos siguientes:
main.c       -> programa principal
mcp2515_tool (extension C y H)-> definiciones de funciones basicas de acceso al mcp2515 que estan funcionales

No se pueden leer bien con el block de notas, estan llenos de espacios y caracteres raros.

El resto se leen perfectamente, podras limpiar y pasar nuevamente esos tres archivos??

hmmm ok deben ser porque estan en formato Unix y no DOS... si tienes alguna utilidad de conversion lo puedes hacer, de todas formas los modificare y los envio.

Saludos

[electrolinux]

Adjunto nuevamente los archivos en formato DOS. Sorry por el "lapsus"... ni me acorde de ese detalle.

Saludos

[Javicho]

Saludos a todos, quisiera hacerles una consulta: quiero comunicar varios pic's entre si en modo multimaestro, no puedo usar el MCP2515 u otro parecido porque por aqui dificil encontrar esos componentes, podria usar el bus I2C en modo multimaestro o hay otro protocolo que me recomienden?

He usado el I2C pero nunca en modo multimaestro, y recien he leido que su arbitraje funciona practicamente igual que el del bus CAN (gana el bus el que hace prevalecer su "0" frente a otro que envia un "1" en dicho instante). Por ello por ahora apuntaré a usar el I2C ya que con este arbitraje aseguraria que ningún pic se cruce con otro y hasta tal vez implemente el tratamiento de errores que tiene el bus CAN por si algún nodo comeinza a actuar erroneamente y asi no perjudique a los demas.

Quisiera escuchar sus opiniones y sugerencias o si hay otra manera mas practica y eficiente de evitar colisiones en modos multimaestros. Gracias.

Javicho.

[electrolinux]

El codigo del AVR que he enviado esta mannana, al menos me hace algo, que es leer los registros internos del MCP2515 y me los envia por la serial del AVR a un terminal que captura la data por RS232...

La salida es:
Pruebas MCP2515 con AVR
  MCP2515 inicializado
  Reg CNF1 = 0x3
  Reg CNF2 = 0xb8
  Reg CNF3 = 0x5
  Reg CANINTE = 0x3
  Reg RXB0CTRL = 0x60
  Reg RXB1CTRL = 0x60
  Reg BFPCTRL = 0x0
  Reg TXRTSCTRL = 0x38
  Reg CANCTRL = 0x3
  Reg SPI_READ_STATUS = 0x0

Ahora estoy viendo los modos de operacion del MCP2515... bueno al menos algo de avance estoy obteniendo, de a poco.

Respecto del codigo que me enviaste MGLSOFT.. entoy analizandolo y ciertas cosas aun no entiendo, por ejemplo en la funcion can_init() llamam a la funcion can_set_modo(CAN_OP_NORMAL);, la cual no me queda muy claro lo que hace exactamente, ya que lee el registro CANCTRL que lo maneja con una estructura... pero no es muy evidente como manejan los bits de ese registro.

Saludos

[electrolinux]

Saludos a todos, quisiera hacerles una consulta: quiero comunicar varios pic's entre si en modo multimaestro, no puedo usar el MCP2515 u otro parecido porque por aqui dificil encontrar esos componentes, podria usar el bus I2C en modo multimaestro o hay otro protocolo que me recomienden?

Yo en tu lugar usaria RS485 y de seguro que habran los drivers del bus alla... pero esa es la capa fisica, sobre ella puedes montar un protocolo sencillo... pero eso depende de lo que quieras hacer finalmente con la red de uC.

He usado el I2C pero nunca en modo multimaestro, y recien he leido que su arbitraje funciona practicamente igual que el del bus CAN (gana el bus el que hace prevalecer su "0" frente a otro que envia un "1" en dicho instante). Por ello por ahora apuntaré a usar el I2C ya que con este arbitraje aseguraria que ningún pic se cruce con otro y hasta tal vez implemente el tratamiento de errores que tiene el bus CAN por si algún nodo comeinza a actuar erroneamente y asi no perjudique a los demas.

Quisiera escuchar sus opiniones y sugerencias o si hay otra manera mas practica y eficiente de evitar colisiones en modos multimaestros. Gracias.
Javicho.

Implementar a mano lo que hace CAN con el arbitraje y manejo de errores, no lo veo tan trivial... dependiendo de la complejidad de lo que deseas hacer, es EMHO mejor una RS485 y un protocolo simple sobre el BUS.

Saludos

[Javicho]

Con la parte hardware creo que me las podria arreglar o al menos luchar ahi, pero el protocolo es lo que me interesa mas, porque el RS485 es nivel fisico y no apunto a eso, sino mas bien a la filosofia del sistema en si, por ejemplo pensaba mandar tramas fijas de longitud fija y cuando el emisor solo necesite enviar 2 bytes pus rellenaria con mas bytes hasta alcanzar la longitud fija, algo por el estilo se me ocurre ahorita.

La filosofia del tratamiento de errores me parece muy inetersante implementarlo pero como la base es I2C entonces no podria implementarlo al 100% tal vez solo un 40% pero eso hara que mi sistema tenga mayor seguridad en su funcionamiento. Que opinan?

Quisiera saber sobre que otros protocolos podria implementar un sistema multimaestro.

Javicho.

[MGLSOFT]

Saludos a todos, quisiera hacerles una consulta: quiero comunicar varios pic's entre si en modo multimaestro, no puedo usar el MCP2515 u otro parecido porque por aqui dificil encontrar esos componentes, podria usar el bus I2C en modo multimaestro o hay otro protocolo que me recomienden?

He usado el I2C pero nunca en modo multimaestro, y recien he leido que su arbitraje funciona practicamente igual que el del bus CAN (gana el bus el que hace prevalecer su "0" frente a otro que envia un "1" en dicho instante). Por ello por ahora apuntaré a usar el I2C ya que con este arbitraje aseguraria que ningún pic se cruce con otro y hasta tal vez implemente el tratamiento de errores que tiene el bus CAN por si algún nodo comeinza a actuar erroneamente y asi no perjudique a los demas.

Quisiera escuchar sus opiniones y sugerencias o si hay otra manera mas practica y eficiente de evitar colisiones en modos multimaestros. Gracias.

Javicho.

Yo que tu haria mi comunicacion en Modbus RTU y montado sobre red RS485.
Si usas el buscador encontraras temas que tratan ampliamente este protocolo y nos permitirias avanzar con el CAN que es la raiz de este hilo.
Respecto del I2C, no lo recomiendo para salir de una placa a otra, fue desarrollado para comunicar los CI entre si.
El origen del nombre viene de: Inter-Integrated Circuit (Circuitos Inter-Integrados)

Mas info aqui:
I2C

[MGLSOFT]

Ahora estoy viendo los modos de operacion del MCP2515... bueno al menos algo de avance estoy obteniendo, de a poco.

Respecto del codigo que me enviaste MGLSOFT.. entoy analizandolo y ciertas cosas aun no entiendo, por ejemplo en la funcion can_init() llamam a la funcion can_set_modo(CAN_OP_NORMAL);, la cual no me queda muy claro lo que hace exactamente, ya que lee el registro CANCTRL que lo maneja con una estructura... pero no es muy evidente como manejan los bits de ese registro.

Saludos

Si miras en el archivo Can-mcp2510.h veras que enumera los modos de operacion asi:

Código: C

1. enum CAN_OP_MODE {CAN_OP_CONFIG=4, CAN_OP_LISTEN=3, CAN_OP_LOOPBACK=2, CAN_OP_SLEEP=1, CAN_OP_NORMAL=0};

Si lees la hoja de datos del MCP2515, encontraras que existen esos modos de operacion.
Los mas utilizados son el Normal (logicamente, sino no andarian los proyectos) el modo Loopback (permite hacer un envio y recibir lo mismo que envias, para testear tu software, es recomendable ya que alli ya sabes si funciona lo que haces sin tener un sniffer o un Bus armado) y el modo Listen, que aun no entiendo bien para que sirve...

[electrolinux]

Si miras en el archivo Can-mcp2510.h veras que enumera los modos de operacion asi:

Código: C

1. enum CAN_OP_MODE {CAN_OP_CONFIG=4, CAN_OP_LISTEN=3, CAN_OP_LOOPBACK=2, CAN_OP_SLEEP=1, CAN_OP_NORMAL=0};

Si lees la hoja de datos del MCP2515, encontraras que existen esos modos de operacion.
Los mas utilizados son el Normal (logicamente, sino no andarian los proyectos) el modo Loopback (permite hacer un envio y recibir lo mismo que envias, para testear tu software, es recomendable ya que alli ya sabes si funciona lo que haces sin tener un sniffer o un Bus armado) y el modo Listen, que aun no entiendo bien para que sirve...

Ok... ya habia visto lo que me comentas en el registro CANCTRL, pero mas bien apuntaba a la forma de manipular bits de la funcion... realizare una funcion que manipule estos bits, pero no como una estructura, sino algo que se vea un poco mas legible, al menos para mi 

Respecto al modo listen, de acuerdo al datasheet la documentacion dice que es un medio para recivir todos los mensajes, incluso los que tienen error y puede ser usado para aplicaciones de monitoreo de bus o para detectar el baud_rate en situaciones de conexion en caliente.

Saludos

[Javicho]

Gracias por tu respuesta MGLSOFT el I2C fue diseñado mas para comunicar circuitos integrados en un mismo impreso, por otra parte el MODBUS no es multimaestro y disculpen por sacarlos por un rato de su hilo.

Javicho.

[Cryn]

MGLSOFT, disculpa, nose si seria muy descortez de mi parte, busque por el hilo el PCB, para pasarlo directo a una placa, proque si encontre el esquematico de las conexiones y todo, pero para la placa, creo qeu no, nose si lo podrias colocar por aca para ir probando todo

muchas gracias, y no me hagas caso si es que soy muy molestoso

[MGLSOFT]

En realidad no hay mucha ciencia, es una placa de una sola faz, bastante rebuscada porque esta hecha por un Neofito como yo, pero si te sirve, aqui esta...

Placa Entrenador CAN

o aqui en formato comprimido con winrar, a ver si va bien...

Comprimido con Winrar

[electrolinux]

En realidad no hay mucha ciencia, es una placa de una sola faz, bastante rebuscada porque esta hecha por un Neofito como yo, pero si te sirve, aqui esta...

Placa Entrenador CAN

Estimado amigo... el PDF al parecer esta erroneo, no lo pude habrir con Acroread, xpdf y kpdf, da un error de "damaged" o "maltrecho"...   

Saludos

[MGLSOFT]

En realidad no hay mucha ciencia, es una placa de una sola faz, bastante rebuscada porque esta hecha por un Neofito como yo, pero si te sirve, aqui esta...

Placa Entrenador CAN

Estimado amigo... el PDF al parecer esta erroneo, no lo pude habrir con Acroread, xpdf y kpdf, da un error de "damaged" o "maltrecho"...   

Saludos

Prueba ahora, por las dudas tambien lo subi comprimido (lleva CRC adentro) a ver si anda...