TODOPIC

Microcontroladores PIC => * PROYECTOS * => Mensaje iniciado por: MGLSOFT en 07 de Noviembre de 2007, 08:35:00

Título: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 08:35:00
Aqui pondré el indice del Hilo, cumpliendo con un pedido de Aristides Zago.
Gracias Bruno por hacerme el enganche del tema (te perdono la borrada) :D :D :D

Indice
:mrgreen: :mrgreen:
Título: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 08:36:42
Bueno, la idea es abrir este hilo para no complicar el hilo de Ethernet del amigo PICMOUSE.
Esto no quita seguir participando de su hilo apenas mi placa cuente con los elementos para poder realizar las comunicaciones en Ethernet.

Aqui contare mis experiencias con este BUS, poco conocido o mejor dicho, poco tocado aqui en el foro.
Cuento para ello con una placa desarrollo de desarrollo propio, que contiene 4 nodos CAN.
Los nodos se denominan Nodo A, Nodo B, Nodo C y Nodo D respectivamente.

La foto siguiente muestra la placa en cuestión armada.

(http://img129.imageshack.us/img129/6988/mvc640fjr7.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 09:04:04
Los recursos del Nodo A son los siguientes:


Aqui una foto con detalles.

(http://img61.imageshack.us/img61/9155/nodoayg9.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 09:59:03
Los recursos del Nodo B son los siguientes:


Aquí una foto con detalles.


(http://img91.imageshack.us/img91/3562/nodobtb8.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: aitopes en 07 de Noviembre de 2007, 10:30:46
Hola Marcos! Muy buen hilo!
Lo voy a mirar seguido. No he necesitado nunca implementar un bus de este tipo, pero es bueno tener donde recurrir en caso de necesidad.
Buenisima la placa!

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 10:33:10
Gracias Ariel!! :-/
Eso anima a seguir adelante!! :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: luscho en 07 de Noviembre de 2007, 10:50:29
Muy buena idea, mira que ya despertaste mi curiosidad y para enfrentarle como nuevo proyecto, para mas adelante, sigue adelante, me comprometo a ser un asiduo lector del mismo, ya que de este no se nada de nada y si las cosas se me dan talvez a realizarle junto contigo, je,je, si no aplicarle mas adelante… :-) :-)

                                                             saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: aitopes en 07 de Noviembre de 2007, 11:06:00
Marcos, por que usaste una Memoria 93C86 con interfaz SPI en lugar de una I2C tipo 24xxxx?
Pregunto por que siempre elijo las 24xxx y quizas este eqivocado en mi eleccion... :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 11:09:53
Si te fijas bien, el primer nodo usa una memoria I2C 24C256, en el segundo nodo uso una memoria SPI por dos razones:

Por otro lado me conviene aprender a usarlas... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: aitopes en 07 de Noviembre de 2007, 11:21:19
Si te fijas bien, el primer nodo usa una memoria I2C 24C256

¡Se me pasó! :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 12:07:29
Los recursos de los Nodos C y D son los siguientes:


Aquí una foto con detalles.

(http://img124.imageshack.us/img124/5084/nodoscdfl1.jpg) (http://imageshack.us)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Azicuetano en 07 de Noviembre de 2007, 12:30:17
Me gusta, me apunto esto en mi lista de tareas pendientes  :mrgreen:


Un saludo desde Alicante.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: PalitroqueZ en 07 de Noviembre de 2007, 12:37:54
otro lector para lo del CAN!!!  :mrgreen:

Gracias Marcos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 07 de Noviembre de 2007, 14:40:42
Otro hilo que me apunto. Bravo Marcos, you can be the boss with the can bus
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Leon Pic en 07 de Noviembre de 2007, 15:00:36
Yo también me apunto. Veo la placa y se me hace agua la boca.

Bravo Marcos, you can be the boss with the can bus

 :D :D :D :D

Nos vemos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 18:54:18
Alguno sabe como hacer para poner aqui un video y visualizarlo directamente sin que sea redirigido a otra pagina?? :lol:
Quiero mostrar los avances de esa forma, pero sin redirigir a nadie hacia otro lado... :? :?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: aitopes en 07 de Noviembre de 2007, 18:58:13
Hasta donde yo se, el foro esta configurado para impedir eso. Consultalo a BrunoF.

Saludos!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: PalitroqueZ en 07 de Noviembre de 2007, 18:58:57
que va Marcos, el único que lo hizo una vez fué Bruno, al menos no hay una opción por los momentos para llamar a youtube.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 19:03:09
Yo subo el video a Imageshack, pero no encuentro un metodo para mostrarlo directo desde alli... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LABmouse en 07 de Noviembre de 2007, 19:03:50
Amigo!!!!   :P

Te agradezco que lo compartieras con todos, se habla Poco en el Foro, pero en la Industria es Pan de cada dia. De seguro te estaré viendo de cerquita para aprender cada día mas.  :P 

Uff, me gusta, me gusta...

APLAUSOS!!!  :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 19:06:19
Gracias, Maestro Picmouse.. :-/
Es muy bueno recibir ese animo a seguir...
Sabras como subir y mostras un video directo aqui??

Es que asi escribo menos despues de cada experiencia... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Mario en 07 de Noviembre de 2007, 20:22:58
Bueno este tema.

Tengo ganas de meterme (desde ya hace buen tiempo) al CAN. Inclusive tengo µicros con CAN (18F448 y 458) pero al ver tooooooooooooooooodos los registros que se necesitan me desanimé  :D.

Estaré viendo esto de cerca.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Noviembre de 2007, 20:31:12
Realmente es como dices Mario, desanima el hecho de la cantidad de cosas a tener en cuenta para poder configurarlo, pero de afrentas se trata nuestro foro, no?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 08 de Noviembre de 2007, 01:13:40
Marco esta muy bien eso, en mi empresa usamos uno para communtar EBU, con Mesa Yamaha Digital, usamos un DME32, bueno ya hay varios, lastima no estoz ahora en mi trabajo, pero desde alli te dare mas informe del que usamos,me gustaria saber que tipo de software usa para trabajar con ellos, ya estare por aqui dandote la lata, no tengo todas la informacion aqui para hacerte pregunta. :mrgreen:
pero te molestare, lo que me enviaste lo estoy estudiando, pero tu sabe que quiero acabar eso dichoso DMXPACK que por culpa de muchos trabajos no me da tiempo, pero voy piano piano :D
saludo amigo :-/
Título: Mis experiencias con el BUS CAN - La Placa montada!!
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 08:34:04
Bueno, voy a presentarles a mi querida placa montada sobre una caja de una entrenadora que tenía... :mrgreen: :mrgreen:
La otra pobre placa fue a parar a una caja, bien guardada  (aprovecho a decirles a mis coterraneos que si alguien la quiere, podemos negociarla.. , me ponen un privado y lo vemos)..

Aquí las fotos!!

(http://img131.imageshack.us/img131/6725/mvc647fwq5.jpg)

(http://img131.imageshack.us/img131/9269/mvc646fir7.jpg)

(http://img131.imageshack.us/img131/7853/mvc648ftf1.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfh900 en 08 de Noviembre de 2007, 08:38:01
Te ha quedado muy bien la placa y el esquema a colores de tapete también.

Un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 08 de Noviembre de 2007, 08:49:12
Felicidades por la "super" entrenadora MGLSoft.

¿Qué lenguaje de programación piensas utilizar para este proyecto?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 08:51:39
Gracias JFH. :)
Ya hice experiencias con dos de las cosas que me parecían Cucos en este BUS, con buena experiencia.

Uno de los temas que me tenía preocupado era como elegir y setear la configuración de los valores de la velocidad del BUS, ya aprendí como hacerlo, lo explicare en detalle mas adelante.

El otro tema es que pasa cuando cambio de velocidad, que cosas debo tocar, también lo aprendí a Sangre y Fuego, perdí 2 horas de mi tiempo para saber que afecto cuando busco una gran velocidad....


Respecto a la pregunta que alguien hizo sobre que uso para programar, uso el CCS C V3.249 , y utilizo sus librerias modificadas por mí para entender mejor la cosa...
A medida que explique los cambios ire poniendo aquí cuales son y como queda el código... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 08 de Noviembre de 2007, 09:34:58
Marco esta muy bien eso, en mi empresa usamos uno para communtar EBU, con Mesa Yamaha Digital, usamos un DME32, bueno ya hay varios, lastima no estoz ahora en mi trabajo, pero desde alli te dare mas informe del que usamos,me gustaria saber que tipo de software usa para trabajar con ellos, ya estare por aqui dandote la lata, no tengo todas la informacion aqui para hacerte pregunta. :mrgreen:
pero te molestare, lo que me enviaste lo estoy estudiando, pero tu sabe que quiero acabar eso dichoso DMXPACK que por culpa de muchos trabajos no me da tiempo, pero voy piano piano :D
saludo amigo :-/


bien marcos me gustaria que tu le echara una ojeada a esto, porque trabajo muchos con esto. y asi saber si es compartible con tu projectos
http://www.dbaudio.com/es/support/faq/faq/show/index_html?cat=7
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 09:56:51
Hay muchos protocolos montados sobre el BUS CAN.

En la industria los mas conocidos son DeviceNet, CanOpen, y otros mas que no recuerdo.
Por lo que veo en otras ramas tambien usan el BUS CAN para montar un protocolo arriba, pero lo unico que es publico es la definicion del BUS CAN, no el protocolo montado arriba que DEBERIA SER publico...

Si investigas sobre DeviceNet y CanOpen, veras que abren a los desarrolladores que quieran utilizarlo las especificaciones (en algunos casos es pago y en otros te cobran la auditoria de cumplimiento de la especificacion), pero dudo que puedas conseguir el protocolo verdadero de ese BUS que pones en el link, salvo que sea pago...

Para informacion general, los ID del BUS CAN estan grabados en el dispositivo, aqui no se usan direcciones de red...
Por lo tanto para especificar direcciones se debe montar arriba un protocolo adicional, que es lo que hacen estos fabricantes...

Si bien el BUS CAN esta considerado un protocolo en si mismo, es mas a nivel de hardware, por eso lo usan como medio fisico para establecer arriba un protocolo mas amplio.
Aprovechan la genialidad y fortaleza de este noble bus de campo. 8)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 08 de Noviembre de 2007, 10:15:59
Hay muchos protocolos montados sobre el BUS CAN.

En la industria los mas conocidos son DeviceNet, CanOpen, y otros mas que no recuerdo.
Por lo que veo en otras ramas tambien usan el BUS CAN para montar un protocolo arriba, pero lo unico que es publico es la definicion del BUS CAN, no el protocolo montado arriba que DEBERIA SER publico...

Si investigas sobre DeviceNet y CanOpen, veras que abren a los desarrolladores que quieran utilizarlo las especificaciones (en algunos casos es pago y en otros te cobran la auditoria de cumplimiento de la especificacion), pero dudo que puedas conseguir el protocolo verdadero de ese BUS que pones en el link, salvo que sea pago...

Para informacion general, los ID del BUS CAN estan grabados en el dispositivo, aqui no se usan direcciones de red...
Por lo tanto para especificar direcciones se debe montar arriba un protocolo adicional, que es lo que hacen estos fabricantes...

Si bien el BUS CAN esta considerado un protocolo en si mismo, es mas a nivel de hardware, por eso lo usan como medio fisico para establecer arriba un protocolo mas amplio.
Aprovechan la genialidad y fortaleza de este noble bus de campo. 8)
Tiene Razon, porque uso un Tongle que corre con el software, pero voy intentar averiguar con el Hardware y el code, ese que tu vee ahi es CanOpen, asi con el controlamos la Etapa de potencia via ETHERNET, con el controla desde una pc todas las etapa de potencia, es muy interesante, pero dime a ver que programa tu usa para controlar tu CAN?
 :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 10:40:33
En realidad no se porque, pero en la pagina no veo nada... :shock: :(
Título: Re: Mis experiencias con el BUS CAN
Publicado por: elreypic2 en 08 de Noviembre de 2007, 10:59:00
Que tal MGLSOFT,

Yo he trabajado con el bus CAN, hace algun tiempo hice un proyecto relativamente mediano el en cual era una serie de botones y luces, que se utilizaba en una linea de produccion. La cual tenia varias estaciones de trabajo y en cada estacion habia dos botones y una luz. Este proyecto consistia en avisar al supervisor de linea cuando alguno de operadores se quedaba sin materia prima para continuar su trabajo o cuando estaba a punto de quedarse. Asi el operador presionaba un boton, generando una senial de "aviso", por lo que se encendia la luz de la estacion y en el centro de la linea se encendia una luz ambar y una sirena para indicar el tipo de senializacion. De igual manera se el evento se enviaba a traves de un convertidor serial-CAN a una PC la cual generaba un archivo con el evento y en una grafica se mostraba en la PC el tipo de evento que estaba ocurriendo. Asi como este habia un segundo evento el cual detenia la linea de produccion. Un proyecto bastatne intersante y para ello utilice micros PIC16F648A, MCP2515 y el  MCP2551. El firmware fue desarrollado en PIC BASIC PRO. El software fue desarrollado en Visual basic, pero por ser una aplicacion comercial no me es posible compartirlo, pero en cuanto al bus CAN cuenten conmigo. Debo aclarar que yo monte mi propio protocolo sobre el CAN, ya que ulizar algun standar como DeviceNet o CANOpen involucraba mas costo. No tengo experiencia en esos protocolos, pero si en los modulos CAN.
Yo estoy dispuesto a ayudar en lo que pueda.

Saludos.

Elreypic.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 08 de Noviembre de 2007, 11:01:13
En realidad no se porque, pero en la pagina no veo nada... :shock: :(
Lo se :? esa pagina siempre da problema, pero tranquilo buscare la informacion y los llamare :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 11:34:22
Gracias, ElReyPIC !! :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 08 de Noviembre de 2007, 12:20:43
Hola elreypic. ¿Existen funciones públicas para redes CAN en PICBasic PRO?
Título: Mis experiencias con el BUS CAN - Configuración de velocidad
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 13:54:03
Bueno, paso a explicar lo que aprendi acerca de como cambiar en forma correcta la configuracion de velocidades para los componentes del BUS CAN.

Hay herramientas Gratuitas para hacer los calculos de configuracion, la que yo uso se llama Microchip CAN bit timing Calculator, de la firma Intrepid Control Systems, la pueden bajar de su pagina WEB del siguiente link:
http://www.intrepidsupport.com/mbtime.htm (http://www.intrepidsupport.com/mbtime.htm)

Se encontraran con esta ventana:
(http://img91.imageshack.us/img91/502/scr2ff911yy0.png)
Título: Mis experiencias con el BUS CAN - Configuración de velocidad
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 14:44:50
Bueno, veamos como usamos esa herramienta para configurar nuestro BUS CAN.

Elegiremos una velocidad para el BUS de 250 Kbps.
Todos los Nodos van a la misma velocidad !!

El Nodo A tiene un PIC18F4580 y cristal de 10 MHz.
Con estos datos en la mano, abrimos el programa y nos encontramos seleccionando estos valores en su ventana..

(http://img401.imageshack.us/img401/1111/eleccioncanbusoq4.png)

Una vez elegidos los valores le damos al boton de avance y nos encontramos con las opciones que el programa encuentra para nosotros, en este caso dos solamente, que se pueden visualizar en la ventana descolgable...

(http://img250.imageshack.us/img250/9255/eleccioncanbus2pm5.png)

Le damos al boton de avance y nos mostrara las opciones y el grafico de participacion de cada segmento del bit y punto de muestreo, viendo algo asi:

(http://img337.imageshack.us/img337/6954/eleccioncanbus3ee8.png)

Por ultimo, le damos al boton Generate Report y obtendremos este informe detallado de los parametros de configuracion que necesitamos...

(http://img136.imageshack.us/img136/8774/scr5977cfix6.png)
(http://img337.imageshack.us/img337/7796/scr5a2e6dfi2.png)

Y ya tenemos los valores que hay que darle en la configuracion a ese Nodo del BUS !!!

en el proximo vemos como hacer lo mismo al Nodo B.... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: elreypic2 en 08 de Noviembre de 2007, 15:24:07
MGLSOFT, realmente me sorprendes, es herramienta es realmente hermosa. Felicidades, creo que mas bien en lugar de aportar resultare un aprendiz. WOW.

jfmateos2, no existen funciones publicas de CAN para PBP, lo que yo hice fue configurar los resgistros del MCP2515 usando su bus SPI, y asi desarrollar mi propio protocolo.

Saludos.

Elreypic.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 16:42:08
Je..je..
Hoy le comentaba a Picmouse por el chat, que hace un año recopilo información respecto al BUS CAN...
Ya estoy por divorciarme a causa de las carpetas que tengo por todos lados... :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Mario en 08 de Noviembre de 2007, 17:23:59
Hay muchos protocolos montados sobre el BUS CAN.

Si bien el BUS CAN esta considerado un protocolo en si mismo, es mas a nivel de hardware, por eso lo usan como medio fisico para establecer arriba un protocolo mas amplio.
Aprovechan la genialidad y fortaleza de este noble bus de campo. 8)


¿Entonces es algo con el RS485?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 17:26:13
Es MAS que el RS485, porque tiene su propio control de errores y sincronizacion entre nodos, que en otros medios hay que hacerlo a pelo...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: elreypic2 en 08 de Noviembre de 2007, 18:28:14
Asi, es CAN es un nivel fisico completamente diferente al RS-485. Aunque el CAN tambien es diferencial, pero tiene la caracteristica que en el nivel fisico, es imposible que se genere una colision, ya que el nivle logico 0 tiene prioridad con respecto al nivel logico 1. Esto quiere decir que si un nodo esta transmitiendo un 1 logico y otro nodo intenta transmitir al mismo tiempo un 0 logico, en el bus CAN el nivel logico 0 prevalece sobre del 1. Es por eso que el protocolo CAN se le llama protocolo con deteccion de mensajes y no por direcciones, aunque este ultimo tambien puede implementarse.

Yo tenia un manual que motorola publico en su web hace ya algun tiempo, desafortunadamente lo olvide en la compania para la que trabajaba anteriormente. Ahi se explica el funcionamiento del CAN bit a bit, tanto el modo stantdard como el modo extendido. El uso de los filtros para la deteccion de mensajes, etc.

Si mal no recuerdo tambien Microchip tiene algunas notas de aplicacion acerca de esto, las voy a buscar, aunque tal vez nuestro amigo MGLSOFT ya las tiene por ahi entre sus curiosidades.

Saludos.

Elreypic.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Noviembre de 2007, 19:01:37
Ahi se explica el funcionamiento del CAN bit a bit, tanto el modo stantdard como el modo extendido. El uso de los filtros para la deteccion de mensajes, etc.


Sería muy importante contar con esa información, precisamente el uso de las mascaras o filtros es lo que me trae dolores de cabeza, aún no lo entiendo bien...
Agradecería mucho si pudieras aportarlo o decirnos donde encontrarlo.
 :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: elreypic2 en 09 de Noviembre de 2007, 00:38:18
MGLSOFT,

Voy a tratar de contactar a un ex-companiero de trabajo para ver si el me puede escanear el manual que les comento, o al menos que me pase el numero de documento para buscarlo en la red.

Voy a tratar de localizarlo.

Saludos.

Elreypic.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 09 de Noviembre de 2007, 05:16:39
Hola chicos, en la revista Resistor han empezado hace 2 meses un curso sobre CAN en el que se explica con bastante detalle.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LordLafebre en 09 de Noviembre de 2007, 12:37:04
Hola:

Alguien ha probado las instrucciones CAN de Microelectrónica en cualquiera de sus lenguajes?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Noviembre de 2007, 15:35:32
Querras decir MiKroelectronica... :lol:
yo no las probe, estoy trabajando con CCS, y ya tengo mas detalles, que pronto subire aqui... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LordLafebre en 09 de Noviembre de 2007, 17:07:41
Hola:

Eso eso, eso mismo, yo no he probado nada sobre esto, pero he visto que los programas de mikroe soportan ese protocolo.

Mi ignorancia es basta respecto a este tema, así que seguire calladito y leeré los posts que aquí se escriban.  :P

Buena iniciativa la tuya al contarnos tus experiencias Marcos.

Adelante...!  :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: groundman en 09 de Noviembre de 2007, 18:53:21
hola.yo desde hace tiempo tengo interes en esta forma de transmision CAN "area local de controladores" o "controlador de area local"no me acuerdo bien.
y el protocolo que queria aprender era el (KWP2000) ya que es el que tengo mas a mano,"mi coche" :D

y ademas tengo una centralita EDC15 para experimentar.
tambien tengo un terminal de diagnostico que cubre un monton de veiculos,y que la actualizo cada 3 meses.

lo que pasa que aparte del tiempo,no encuentro datos para poder experimentar con este protocolo.
me gustaria empezar por muntar un circuito que en un display me diera informacion como:velocidad,revoluciones,caudal de aire espirado,temperatura motor,tiempo de inyeccion y demas datos relacionados con el avitaculo.como ordenar la subida de los elevalunas,encendido de luces,y muchas mas cosas.

estos datos ,normalmente son exclusivos del fabricante de los veiculos.y solo los fabricantes de terminales de diagnostico acceden a ellos.ya que pagan mucho dinero por estos datos.

a mi se me habia ocurrido diseñar un circuito que puesto en serie con el terminal de diagnostico,grabara estos datos en una eprom o ram y luego ir confrontandolos con los datos que recive el terminal de diagnostico.tengo algunos datos de los cursos de inyeccion electronica y multiplexado.
pero no tengo la informacion exacta para empezar con los experimentos. :(




Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Noviembre de 2007, 19:03:13
No veo forma que implementes una grabacion a tal velocidad, considerando que un bit dura unos pocos microsegundos y las eeprom tardan mas tiempo en grabar que lo que tarda en pasar un chorizo de datos por el BUS... :(

Por eso es que el monitoreo de datos normalmente se hace con software en PC, donde no hay problemas de almacenamiento.
Yo no dispongo de ninguno de los softwares para realizar monitoreo, tengo entendido que todos son pagos y lo que intento aqui es usar software de uso libre...

Si sabes de alguno que no sea pago para poder hablar aqui, te pido me avises y lo buscare para ponerlo, la idea del hilo es ir compartiendo experiencias sobre un tema que es un poco Tabú en el ambiente, porque cada uno tuvo que pelarse la frente para poder acceder a la información y le cuesta soltarla... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: groundman en 09 de Noviembre de 2007, 22:27:21
supongo que habria que diseñar un programa que capturse los datos desde un puerto rapido del pc,y luego ver que programa seria eficaz.
ya que segun en que se programe se relentizaria el proceso de captura de datos.
el ensembler es el mas rapido,pero tambien el mas tedioso.

capturar un dato desde un puerto es facil.pero dirigir ese dato a la memoria ram,eso habria que estudiarlo.
lo primero es saver a que velocidades se va a trabajar.

segun veo en los cursos que he dado,en parte de los veiculos.las velocidades de los datos varian segun a que dispositivos se quieran controlar.
no es lo mismo controlar la informacion de apertura y estado de las puertas que la informacion que entrega la unidad de motor o la de la caja de cambios.

los fabricantes de veiculos lo que quieren es abaratar costos,y cuanto menos sea la velocidad de transmision menor sera los costos de fabricacion.

las puertas hasta 20kbit/s
la caja cambios va desde 1kbit /s hasta 125kbits/s
motor desde 125kbit/s hasta 1mbit/s

mas informacion:
formato del mensaje CAN
inicio de trama-campo de asignacion-campo de datos-campo CRC-campo de confirmacion -final de trama. o lo que es lo mismo
start of trame-arbitration field-data fiel-crc field-ack field-end of frame.

Esta es una Trama de Datos, usada para enviar datos a otro Nodo.

(http://img66.imageshack.us/img66/6793/tramadatoscanfa2.png)

CAN soporta dos formatos diferentes que se diferencian por la longitud del identificador.el formato estandar es de 11bits y el ampliado de 29bits.
eso significa que el formato estandar tiene 130bits y el ampliado de 150bits.

INICIO DE TRAMA:
indica el comienzo de un mensage:1bit

CAMPO DE ASIGNACION:
esta compuesto por el identificador y el mensage ,y un bit de control adicional:12bit

CAMPO DE DATOS:
tiene entre 0 y 8 bytes:64bit

CAMPO CRC:
contiene una contraseña del la trama para detectar fallos en la transmision:16bit

CAMPO DE CONFIRMACION:
contiene una señal de confirmacion de todos los receptores que han recivido el mensaje correctamente:2bit

FINAL DE TRAMA:
indica el final del mensaje.7bit

Y ENTRE FINAL DE TRAMA Y COMIENZO DE LA OTRA 3bit.

Esta es una Trama Remota, se utiliza para solicitar un dato a otro Nodo.

(http://img75.imageshack.us/img75/6296/tramaremotacanem7.png)

esto es lo que he estudiado pero hay diferencias en los nuevos sistemas .como el TTCAN "time trigered CAN"es  un sistema que se puede configurar arbitrariamente en cuanto a la distribucion de los fragmentos de comunicacion temporizados o activados por incidencias.y por eso es totalmente compatible con CAN.

ahora solo me queda leer las tramas de bus can de mi veiculo y compararlas con este formato de mensage.
mi idea es hacer un circuito que lea la cabecera del mensage y distribulla los datos que sigen en la memoria ram de un pic.y luego pasarlo a una pantalla lcd.
parecido a un proyecto que hice que capturaba las tramas nmea de un gps.y luego me las pasaba a un lcd.
lo que no se si la velocidad del bus can va ha ser muy rapida para determinado pic que utilize.y como leer y escribir en el bus de mi coche.

Perdon por la edicion, pero es para agregar imagenes que dan valor agregado a tu explicacion...

Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 09 de Noviembre de 2007, 23:23:40
No veo forma que implementes una grabacion a tal velocidad, considerando que un bit dura unos pocos microsegundos y las eeprom tardan mas tiempo en grabar que lo que tarda en pasar un chorizo de datos por el BUS... :(

Por eso es que el monitoreo de datos normalmente se hace con software en PC, donde no hay problemas de almacenamiento.
Yo no dispongo de ninguno de los softwares para realizar monitoreo, tengo entendido que todos son pagos y lo que intento aqui es usar software de uso libre...

Si sabes de alguno que no sea pago para poder hablar aqui, te pido me avises y lo buscare para ponerlo, la idea del hilo es ir compartiendo experiencias sobre un tema que es un poco Tabú en el ambiente, porque cada uno tuvo que pelarse la frente para poder acceder a la información y le cuesta soltarla... :mrgreen: :mrgreen:
Hola marcos
aqui tiene software
http://www.peak-system.com/index_gb.html
no habla de pago y no lo he probado
 :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Noviembre de 2007, 23:33:07
Gracias STK, pero no anda, es decir, este software esta hecho para usar con los analizadores de esa firma... :( :(

Yo tengo el CanKing, en la version que viene con las placas de Microchip, y esa version es gratuita...
Voy a ver de utilizar esa por ahora, para las practicas... :) :)
Título: Re: Mis experiencias con el BUS CAN - Configurando el Nodo B
Publicado por: MGLSOFT en 09 de Noviembre de 2007, 23:58:41
Continuamos con el uso de esta magnifica herramienta para configurar nuestro BUS CAN.

Habíamos elegido una velocidad para el BUS de 250 Kbps.
Todos los Nodos van a la misma velocidad !!

El Nodo B tiene un PIC16F876 y cristal de 10 MHz.
Ademas en la comunicación al BUS CAN tiene un MCP2515, con cristal de 20 MHz

Cuidado aqui!!
No confundirse!!  La frecuencia del cristal a ingresar en este caso es la del MCP2515

Con estos datos en la mano, abrimos el programa y nos encontramos seleccionando estos valores en su ventana..

(http://img401.imageshack.us/img401/1111/eleccioncanbusoq4.png)

Una vez elegidos los valores le damos al boton de avance y nos encontramos con las opciones que el programa encuentra para nosotros, en este caso dos solamente, que se pueden visualizar en la ventana descolgable...

(http://img45.imageshack.us/img45/8027/eleccioncanbus2bnb8.png)

Le damos al boton de avance y nos mostrará las opciones y el gráfico de participación de cada segmento del bit y punto de muestreo, viendo algo así:

(http://img228.imageshack.us/img228/915/eleccioncanbus3bfa8.png)

Por ultimo, le damos al boton Generate Report y obtendremos este informe detallado de los parametros de configuracion que necesitamos...

(http://img337.imageshack.us/img337/1259/informenodobyg6.png)
(http://img442.imageshack.us/img442/9540/informenodobcontqu8.png)

Y ya tenemos los valores que hay que darle en la configuración al Nodo B del BUS !!!

en el proximo vemos donde se configuran estos valores en ambas rutinas del software.... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 10 de Noviembre de 2007, 02:24:48
Gracias STK, pero no anda, es decir, este software esta hecho para usar con los analizadores de esa firma... :( :(

Yo tengo el CanKing, en la version que viene con las placas de Microchip, y esa version es gratuita...
Voy a ver de utilizar esa por ahora, para las practicas... :) :)
:x eso mama racho :D
usan un Tongle
y solo puede usar solo sus soft, por eso no me decido muchos en el Can, por eso soft que lo controla,pero siendo asi veo que tu usa el de Microchip y me imagino que no esta ilimitados como otros, voy a seguir investigando y te tendre informado,
estoy siguiendo tu projecto me gusta :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Noviembre de 2007, 08:32:36
Por supuesto que tambien CanKing no es gratis en todas sus versiones, pero si lo es en las que entrega para Microchip, personalizadas para sus placas...

Veremos si logro personalizar alguna version para usar con mi placa... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 10 de Noviembre de 2007, 09:18:17
Por supuesto que tambien CanKing no es gratis en todas sus versiones, pero si lo es en las que entrega para Microchip, personalizadas para sus placas...

Veremos si logro personalizar alguna version para usar con mi placa... :mrgreen:
quizas tu conozca esta pagina http://www.kvaser.com/index.htm
 :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Noviembre de 2007, 10:58:49
Por supuesto!!!

De alli baje todo lo que se del CanKing !! :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LABmouse en 10 de Noviembre de 2007, 13:35:40
Pos esta quedando muy muy completo!!

Gracias por compartir!!  :-/
Título: Re: Mis experiencias con el BUS CAN - La Norma de Bosch
Publicado por: MGLSOFT en 10 de Noviembre de 2007, 13:48:18
Aqui encontrarán la Norma de Robert Bosch, creador del BUS CAN.

CAN2SPEC (http://www.semiconductors.bosch.de/pdf/can2spec.pdf)

Gracias por las flores PICMOUSE, viniendo de ti es un halago!! :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Noviembre de 2007, 01:17:38
Bueno, anduve enloquecido hasta ahora porque no me andaba el LCD, y como siempre aparecio mi Musa inspiradora, el amigo PIKMAN y encontre el problema...
Gracias PIKMAN (ariel) por tu inspiracion!!! :-/ :-/
Y tu ayuda tambien, que te perdiste un rato y se que estabas haciendo tus cosas, y generosamente me dedicaste un rato a mi... :idea: :idea:

El problema es que solde tiras de zocalo, a falta de poder insertar bien el zocalo de 28 pines dentro del de 40 (para tener ambas posibilidades) y me quedo haciendo falso contacto...

Alli radicaba el problema de mi display y a veces de interrupciones del CAN (que no podia explicarme de donde venian)...

Mañana le dedico tiempo a desarrollar el tema software, ahora que no tengo (creo) mas problemas de hardware... :mrgreen: :mrgreen:
Título: Mis experiencias con el BUS CAN- Configurando la velocidad
Publicado por: MGLSOFT en 11 de Noviembre de 2007, 22:49:50
Bueno, antes mostré como utilizando un programa libre se obtenían los valores a ingresar en el bus para funcionar a la velocidad deseada.

Ahora mostraré el tramo de la libreria de CCS que configura la velocidad, para luego mostrar cual es la forma mas directa utilizada por mí para setear los valores de configuración.

La librería CCS declara cada uno de los valores de configuración en forma separada, utilizandolos luego como parte de una estructura, que es enviada al PIC o al MCP2515.
Aqui vemos la declaración de estos valores:
Código: C
  1. #IFNDEF CAN_BRG_PRESCALAR
  2.   #define CAN_BRG_PRESCALAR  4  //baud rate generator prescalar (def: 4) ( Tq = (2 x (PRE + 1))/Fosc )
  3. #ENDIF
  4.  
  5. #ifndef CAN_BRG_SEG_2_PHASE_TS
  6.  #define CAN_BRG_SEG_2_PHASE_TS   TRUE //phase segment 2 time select bit (def: freely programmable)
  7. #endif
  8.  
  9. #ifndef CAN_BRG_SAM
  10.  #define CAN_BRG_SAM 0 //sample of the can bus line (def: bus line is sampled 1 times prior to sample point)
  11. #endif
  12.  
  13. #ifndef CAN_BRG_PHASE_SEGMENT_1
  14.  #define CAN_BRG_PHASE_SEGMENT_1  5 //phase segment 1 (def: 6 x Tq)
  15. #endif
  16.  
  17. #ifndef CAN_BRG_PROPAGATION_TIME
  18.  #define CAN_BRG_PROPAGATION_TIME 2 //propagation time select (def: 3 x Tq)
  19. #endif
  20.  
  21. #ifndef CAN_BRG_WAKE_FILTER
  22.  #define CAN_BRG_WAKE_FILTER FALSE   //selects can bus line filter for wake up bit
  23. #endif
  24.  
  25. #ifndef CAN_BRG_PHASE_SEGMENT_2
  26.  #define CAN_BRG_PHASE_SEGMENT_2 5 //phase segment 2 time select (def: 6 x Tq)
  27. #endif
  28.  
Título: Mis experiencias con el BUS CAN- Estructuras de configuración
Publicado por: MGLSOFT en 11 de Noviembre de 2007, 22:53:16
Esos valores luego son utilizados en estas estructuras, declaradas en el archivo .h de su librería:

Código: C
  1. ////////////////////////////////////////////////////////////////////////////////
  2. /////////////////////// Baud Control Registers /////////////////////////////////
  3. ////////////////////////////////////////////////////////////////////////////////
  4.  
  5. //baud rate control register 1
  6. struct {
  7.         int brp:6;      //0:5   //baud rate prescalar
  8.         int sjw:2;      //6:7   //synchronized jump width
  9. } BRGCON1;
  10. #byte BRGCON1=0xF70
  11.  
  12. //baud rate control register 2
  13. struct {
  14.         int prseg:3; //0:2 //propagation time select
  15.         int seg1ph:3; //3:5 //phase segment 1
  16.         int1 sam; //6 //sample of the can bus line
  17.         int1 seg2phts; //7 //phase segment 2 time select
  18. } BRGCON2;
  19. #byte BRGCON2=0xF71
  20.  
  21. //baud rate control register 3
  22. struct {
  23.         int seg2ph:3;   //0:2   //phase segment 2 time select
  24.         int void543:3;  //3:5
  25.         int1 wakfil;    //6 //selects can bus line filter for wake-up
  26.         int1 void7;     //7
  27. } BRGCON3;
  28. #byte BRGCON3=0xF72
  29.  
Título: Mis experiencias con el BUS CAN - Uso de estructuras al configurar
Publicado por: MGLSOFT en 11 de Noviembre de 2007, 23:01:53
Una vez declaradas las estructuras la librería utiliza estas estructuras para configurar la velocidad.

Código: C
  1. ////////////////////////////////////////////////////////////////////////
  2. //
  3. // can_set_baud()
  4. //
  5. // Configures the baud rate control registers.  All the defines here
  6. // are defaulted in the can-18xxx8.h file.  These defaults can, and
  7. // probably should, be overwritten in the main code.
  8. //
  9. // Current defaults are set to work with Microchip's MCP250xxx CAN
  10. // Developers Kit if this PIC is running at 20Mhz.
  11. //
  12. //      BRGCON1 contains the prescaler bits and the Synchronization jump
  13. //                width time bits.
  14. //
  15. //                        the prescale values are
  16. //                                111111=(2*64)/clock=Tq
  17. //                                111110=(2*63)/clock=Tq
  18. //                                       continued
  19. //                                000001=(2*2)/clock=Tq
  20. //                                000000=(2*1)/clock=Tq
  21. //
  22. //                        in the case of can-18xxx8.h, the prescale bits are set to
  23. //                        000100=10/clock profided that the user does not define it
  24. //                        differently
  25. //
  26. //                   The Synchronized Jump Width Bits are
  27. //                                11=4*Tq
  28. //                                10=3*Tq
  29. //                                01=2*Tq
  30. //                00=1*Tq
  31. //
  32. //                        in the case of can-18xxx8.h, the SJW bits are set to 0 or 1*Tq
  33. //
  34. //      BRGCON2 contains the Phase Segment 2 Time Select bit, the SAMple bit
  35. //                the Phase Segment 1 bits, and the Propagation Time Select bits
  36. //
  37. //                        SEG2PHTS
  38. //                                1=Freely Programmable
  39. //                                0=Maximum of PHEG1 or IPT, which ever is greatest
  40. //
  41. //                        in the case of can-18xxx8.h, the SEG2PHTS bit is set to 1 for
  42. //                        freely programmable
  43. //
  44. //                        SAM
  45. //                                1=Three Samples
  46. //                                0=One Sample
  47. //
  48. //                        in the case of can-18xxx8.h, the SAM bit is set to 0 for
  49. //                        one sample
  50. //
  51. //                        SEG1PH2:SEG1PH0
  52. //                                Phase Segment 1 = (SEG1PH2:SEG1PH0+1)*Tq
  53. //
  54. //                        in the case of can-18xxx8.h, the SEG1PH2:SEG1PH0 bits are set to 5
  55. //         for 6*Tq Phase Segment 1 Time
  56. //
  57. //                        PRSEG2:PRSEG0
  58. //                           Propogation Time = (PRSEG2:PRSEG0+1)*TQ
  59. //
  60. //                        in the case of can-18xxx8.h, the PRSEG2:PRSEG0 bits are set to 2
  61. //                        for 3*Tq Propogation Time
  62. //
  63. // BRGCON3 contains the WAKFIL bit and the Phase Segment 2 Time Select bits
  64. //
  65. //                        WAKEFIL
  66. //            1=CAN bus line filter is used for wake-up
  67. //                                0=CAN bus line filter is not used for wake-up
  68. //
  69. //                        in the case of can-18xx8.h, the WAKEFIL bit is set to 0 for
  70. //                        CAN bus not used for wake-up
  71. //
  72. //                        SEG2PH2:SEG2PH0
  73. //                                Phase Segment 2 Time = (SEG2PH2:SEG2PH0+1)*Tq
  74. //
  75. //                        in the case of can-18xxx8.h, SEG2PH2:SEG3PH0 is set to 5 for
  76. //         6*Tq Phase Segment 2 Time
  77. //
  78. // More information can be found in the PIC18F4580 datasheet section 23.9
  79. ////////////////////////////////////////////////////////////////////////
  80. void can_set_baud(void) {
  81.  
  82.    BRGCON1.brp=CAN_BRG_PRESCALAR;
  83.    BRGCON1.sjw=CAN_BRG_SYNCH_JUMP_WIDTH;
  84.  
  85.    BRGCON2.prseg=CAN_BRG_PROPAGATION_TIME;
  86.    BRGCON2.seg1ph=CAN_BRG_PHASE_SEGMENT_1;
  87.    BRGCON2.sam=CAN_BRG_SAM;
  88.    BRGCON2.seg2phts=CAN_BRG_SEG_2_PHASE_TS;
  89.  
  90.    BRGCON3.seg2ph=CAN_BRG_PHASE_SEGMENT_2;
  91.    BRGCON3.wakfil=CAN_BRG_WAKE_FILTER;
  92. }
  93.  

Es un método cuanto menos muy pulcro y refinado, para la gente que sabe y conoce mucho, ya que declarando los valores en el programa principal se evita la carga de los valores por default.

En mi caso soy muy inexperto en el tema CAN, por lo que resolví cargar los valores directos del programa de calculo de velocidad que explique anteriormente, para eso tuve que desarrollar una forma que me permitiera configurar todo cambiando solo una línea de codigo desde mi programa principal, lo que sigue es lo que quedó... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Noviembre de 2007, 23:12:34
Modifiqué solamente la función de carga de valores, dejando la posibilidad de cargar tres valores de velocidad en forma rápida.
Las velocidades elegidas fueron 125, 250 y 500 Kbps.

Una de estas ahora puede ser seleccionada desde el programa principal, según la necesidad.

Ahora vemos como quedó la función CAN_Set_Baud (), que es la encargada de configurar la velocidad.
Aqui está:

Código: C
  1. ////////////////////////////////////////////////////////////////////////
  2. //
  3. // can_set_baud()
  4. //
  5. // Configures the baud rate control registers.  All the defines here
  6. // are defaulted in the can-18xxx8.h file.  These defaults can, and
  7. // probably should, be overwritten in the main code.
  8. //
  9. // Current defaults are set to work with Microchip's MCP250xxx CAN
  10. // Developers Kit if this PIC is running at 20Mhz.
  11. //
  12. //      BRGCON1 contains the prescaler bits and the Synchronization jump
  13. //                width time bits.
  14. //
  15. //
  16. //      BRGCON2 contains the Phase Segment 2 Time Select bit, the SAMple bit
  17. //                the Phase Segment 1 bits, and the Propagation Time Select bits
  18. //
  19. //
  20. // BRGCON3 contains the WAKFIL bit and the Phase Segment 2 Time Select bits
  21. //
  22. //
  23. // More information can be found in the PIC18F4580 datasheet section 23.9
  24. ////////////////////////////////////////////////////////////////////////
  25. void can_set_baud(void) {
  26.    #ifdef Set_125K_Baud {
  27.       BRGCON1 = 0x01;
  28.       BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 125 KBps
  29.       BRGCON3 = 0x07;      //con reloj a 10 MHz
  30.    }
  31.    #endif
  32.  
  33.    #ifdef Set_250K_Baud {
  34.       BRGCON1 = 0x00;
  35.       BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 250 KBps
  36.       BRGCON3 = 0x07;      //con reloj a 10 MHz
  37.    }
  38.    #endif
  39.  
  40.    #ifdef Set_500K_Baud {
  41.       BRGCON1 = 0x00;
  42.       BRGCON2 = 0x92;      //modificado 5/11/07 para usar CAN a 500 KBps
  43.       BRGCON3 = 0x02;      //con reloj a 10 MHz
  44.    }
  45.    #endif
  46. }
  47.  

Como se ve, la función ahora ingresa directamente los valores a los registros de configuración.
Para poder utilizar una configuración u otra, se la llama declarando la velocidad elegida desde el programa principal, antes de llamar a la librería de CAN.

Se hace de esta forma:

Código: C
  1. #define CAN_DO_DEBUG TRUE
  2.  
  3. #define Set_250K_Baud TRUE  /// <<<Aqui configuro que velocidad del BUS utilizo
  4.  
  5. #include "can-18F4580.c"

Quedó mas simple, no?? :mrgreen: :mrgreen:
Esa era la finalidad, ya entiendo como es la configuración, ahora a contarles las experiencias con los cambios de velocidad.... :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 12 de Noviembre de 2007, 03:17:00
Sencillo y eficaz, maestro Marcos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Noviembre de 2007, 11:00:38
Gracias, Manolo.

Luego seguire explicando las experiencias que hice en el cambio de velocidades, me parece importante recalcarlo antes de ir al guisado... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ESTECA55 en 12 de Noviembre de 2007, 17:37:51
Felicitaciones por todo lo desarrollado y publicado hasta ahora!!!

Recien termino de leer todos los mensajes, la verdad que esta muy bueno!


Aca hay otro lector que se prende en esto del CAN.

saludos

PD: muy linda la placa!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Noviembre de 2007, 17:47:12
Gracias Esteban!!
Si leíste todo lo que va del hilo habras visto mi agradecimiento a vos por pasarme al dato para hacer la placa, es muy buen trabajo el que hizo el Sr. Sanchez.

Despues le pasaremos aqui el anuncio, je..je.. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: PalitroqueZ en 13 de Noviembre de 2007, 12:26:21
uff lectura interesante que me he perdido estos dias

Saludos Marcos  :-) :-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 13 de Noviembre de 2007, 13:22:34
 :-/ perdona marco no habia pasado por aqui
esta muy eso, y ya ha tenido una experiencia mas en los dichoso Zocalo y mi tambien me paso lo mismo con un circuito, sacaba y metia el chip y no habia contacto en zocalo
en hora buena amigo :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Noviembre de 2007, 17:48:29
Gracias STK, igual esa es solo una de mis desventuras con esta placa, ya pondre las demas, je..je :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Noviembre de 2007, 00:46:33
Bueno!!! :-/ :-/
Recién acabo de solucionar mi problema existencial con la placa de mis amores, je..je :mrgreen: :mrgreen:

Mañana prometo retomar las clases, tengo mucho rollo para cortar ahora que estoy mas tranquilo.

No me funcionaba el primer MCP25050 que programe, y son OTP, así que no se puede pifiar demasiado, especialmente cuando tienes solo dos y crees que programaste mal el primero!!! :mrgreen: :mrgreen:
Título: Mis experiencias con el BUS CAN - El primer programa
Publicado por: MGLSOFT en 18 de Noviembre de 2007, 18:11:00
Bueno, retomamos el tema luego de unas cortas vacaciones.... :D :D
Despues de ir descubriendo y reparando todos los problemas de mi placa (muchos por desconocimiento al momento de desarrollarla y otros creados por mi luego de tenerla), creo que ya estoy a punto de ir escribiendo las experiencias...

El primer programa:
Como veran, no es cuestión de ponerse muy locos al primer movimiento para probar nuestros equipos, la experiencia me dice que cuanto mas probadas las cosas que uses mejor para tener menos dolores de cabeza, por lo tanto el primer ejemplo es directamente el de CCS, modificado para usarlo con mi placa, que tiene un PIC18F4580.

El codigo del ejemplo, adaptado para 250 KBPs (viene a 125 KBPs) es este:
Código: C
  1. /////////////////////////////////////////////////////////////////////////
  2. ////                         EX_CAN_CCS_A.C                          ////
  3. ////                                                                 ////
  4. //// Example of CCS's CAN library, using the PIC18Fxx8.  This        ////
  5. //// example was tested with and written for the CCS CAN Prototype   ////
  6. //// board.                                                          ////
  7. ////                                                                 ////
  8. //// The CCS CAN Prototype board has four CAN nodes that communicate ////
  9. //// to each other.  Node A is the 18F458 with it's internal CAN     ////
  10. //// peripheral, Node B is a PIC16F87x connected to an external      ////
  11. //// MCP2510 CAN peripheral, and Node C and Node D are both MCP250xx ////
  12. //// stand-alone CAN I/O expanders.  This example is the firmware    ////
  13. //// for Node A.                                                     ////
  14. ////                                                                 ////
  15. //// Every two seconds this firmware sends out a command to node B   ////
  16. //// to change it's leds (CAN ID 0x202)                              ////
  17. ////                                                                 ////
  18. //// Upon change of the A/D reading, a value of 0-9 is sent to       ////
  19. //// Node D which is displayed on the 8-seg LCD (CAN ID 0x400)       ////
  20. ////                                                                 ////
  21. //// Pressing the Node A button sends a request to Node B (CAN ID    ////
  22. //// 0x201) for Node B's A/D reading, which Node B will respond      ////
  23. //// with a CAN message with it's A/D reading (with CAN ID 0x201).   ////
  24. //// Also, pressing the Node A button will change the LEDs on Node   ////
  25. //// C (CAN ID 0x300)                                                ////
  26. ////                                                                 ////
  27. //// Pressing Node C's buttons will cause Node A's buttons to change ////
  28. //// (Node C transmits button changes with CAN ID 0x303)             ////
  29. ////                                                                 ////
  30. //// Using a serial port, you can examine all the CAN traffic as     ////
  31. //// seen by the 18xxx8.                                             ////
  32. ////                                                                 ////
  33. //// For more documentation on the CCS CAN library, see can-18xxx8.c ////
  34. ////                                                                 ////
  35. ////  Jumpers:                                                       ////
  36. ////     PCH    pin C7 to RS232 RX, pin C6 to RS232 TX               ////
  37. ////                                                                 ////
  38. ////  This example will work with the PCH compiler.                  ////
  39. /////////////////////////////////////////////////////////////////////////
  40. ////                                                                 ////
  41. //// Baud rate settings to use to connect to the CCS CAN Prototype   ////
  42. //// board at 20Mhz:                                                 ////
  43. ////                                                                 ////
  44. ////    Baud Rate Prescalar: 4                                       ////
  45. ////    Propagation Segment: 3xTq                                    ////
  46. ////    Phase Segment 1: 6xTq                                        ////
  47. ////    Phase Segment 2: 6xTq                                        ////
  48. ////    Synchronized Jump Width: 1xTq                                ////
  49. ////    Sample Rate: 1x                                              ////
  50. ////    Wakeup Filter:  Off                                          ////
  51. ////                                                                 ////
  52. /////////////////////////////////////////////////////////////////////////
  53. ////                                                                 ////
  54. //// Node C and D are seperate stand-alone MCP250xx CAN I/O          ////
  55. //// expanders.  The CCS CAN Prototype board has these chips already ////
  56. //// programmed correctly.  However, if you wish to program your own ////
  57. //// to work with this example, then use the provided .HEX files     ////
  58. //// a programmer capable of programming these chips.  Or, make a    ////
  59. //// a new HEX file with these properties:                           ////
  60. ////                                                                 ////
  61. //// NODE C: Set RX ID mask and buffers to receive ID 0x3**. (The ** ////
  62. //// means make the least signifcant 8bits no-care in the mask).     ////
  63. //// Set TX1 buffer to ID 0x301, TX2 buffer to ID 0x302, TX3 buffer  ////
  64. //// to ID 0x303. Set GP0 to analog (and enable the A/D).  Set GP1,  ////
  65. //// GP2 and GP3 to OUTPUT.  Set GP4, GP5 and GP6 as INPUT with edge ////
  66. //// trigger enable.  Leave OPTREG2 clear, disable PWM1 and PWM2,    ////
  67. //// and disable scheduled transmission.  Also, see the baud rate    ////
  68. //// settings above.                                                 ////
  69. ////                                                                 ////
  70. //// NODE D: Set RX ID mask and buffers to receive ID 0x4**. (The ** ////
  71. //// means make the least signifcant 8bits no-care in the mask).     ////
  72. //// Set TX1 buffer to ID 0x401, TX2 buffer to ID 0x402, TX3 buffer  ////
  73. //// to ID 0x403. Configure all ports as OUTPUT.  Leave OPTREG2      ////
  74. //// clear, disable PWM1 and PWM2, and disable scheduled             ////
  75. //// transmission.  Also, see the baud rate settings above.          ////
  76. ////                                                                 ////
  77. /////////////////////////////////////////////////////////////////////////
  78. ////        (C) Copyright 1996,2003 Custom Computer Services         ////
  79. //// This source code may only be used by licensed users of the CCS  ////
  80. //// C compiler.  This source code may only be distributed to other  ////
  81. //// licensed users of the CCS C compiler.  No other use,            ////
  82. //// reproduction or distribution is permitted without written       ////
  83. //// permission.  Derivative programs created using this software    ////
  84. //// in object code form are not restricted in any way.              ////
  85. /////////////////////////////////////////////////////////////////////////
  86.  
  87. #include <18F4580.h>
  88. #device ICD=TRUE
  89. #device adc=8
  90.  
  91. #FUSES NOWDT                    //No Watch Dog Timer
  92. #FUSES WDT128                   //Watch Dog Timer uses 1:128 Postscale
  93. #FUSES HS                       //High speed Osc (> 4mhz)
  94. #FUSES NOPROTECT                //Code not protected from reading
  95. #FUSES BROWNOUT                 //Reset when brownout detected
  96. #FUSES BORV21                   //Brownout reset at 2.1V
  97. #FUSES PUT                      //Power Up Timer
  98. #FUSES NOCPD                    //No EE protection
  99. #FUSES STVREN                   //Stack full/underflow will cause reset
  100. #FUSES NODEBUG                  //No Debug mode for ICD
  101. #FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
  102. #FUSES NOWRT                    //Program memory not write protected
  103. #FUSES NOWRTD                   //Data EEPROM not write protected
  104. #FUSES NOIESO                   //Internal External Switch Over mode enabled
  105. #FUSES FCMEN                    //Fail-safe clock monitor enabled
  106. #FUSES PBADEN                   //PORTB pins are configured as analog input channels on RESET
  107. #FUSES BBSIZ1K                  //1K words Boot Block size
  108. #FUSES NOWRTC                   //configuration not registers write protected
  109. #FUSES NOWRTB                   //Boot block not write protected
  110. #FUSES NOEBTR                   //Memory not protected from table reads
  111. #FUSES NOEBTRB                  //Boot block not protected from table reads
  112. #FUSES NOCPB                    //No Boot Block code protection
  113. #FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
  114. #FUSES MCLR                     //Master Clear pin enabled
  115. #FUSES NOXINST                  //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
  116.  
  117. //#include <18F4580.h>
  118. //#fuses HS,NOPROTECT,NOLVP,NOWDT
  119. #use delay(clock=10000000)
  120. //#use delay(clock=20000000)
  121. #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
  122.  
  123. #define CAN_DO_DEBUG TRUE
  124.  
  125. //#include <can-18xxx8.c>
  126. #include "can-18F4580.c"
  127.  
  128. #define PIN_LED1  PIN_A5
  129. #define PIN_LED2  PIN_B5
  130. #define PIN_LED3  PIN_B4
  131.  
  132. #define LED1_LOW  output_low(PIN_LED1)
  133. #define LED1_HIGH output_high(PIN_LED1)
  134. #define LED2_LOW  output_low(PIN_LED2)
  135. #define LED2_HIGH output_high(PIN_LED2)
  136. #define LED3_LOW  output_low(PIN_LED3)
  137. #define LED3_HIGH output_high(PIN_LED3)
  138.  
  139. #define BUTTON    PIN_A4
  140.  
  141. #define BUTTON_PRESSED  !input(BUTTON)
  142.  
  143. int16 ms;
  144.  
  145. const char lcd_seg[10]={0x40,0x79,0x24,0x30,0x19,0x12,0x02,0x78,0x00,0x10};   //0 for on, 1 for off
  146.  
  147. #int_timer2
  148. void isr_timer2(void) {
  149.    ms++; //keep a running timer that increments every milli-second
  150. }
  151.  
  152. #define ASK_FOR_ID_AD_B      0x201  //ask for AD info from CAN port B
  153. #define SET_LED_ID_B         0x202  //set LEDs for CAN port B
  154. #define RESPOND_TO_LED_C_ID  0x303
  155. #define WRITE_REGISTER_C_ID  0x300
  156. #define WRITE_REGISTER_D_ID  0x400
  157.  
  158. void main() {
  159.    int b_leds=0;
  160.    int c_leds=1;
  161.    int a_leds=0;
  162.    struct rx_stat rxstat;
  163.    int32 rx_id;
  164.    int buffer[8];
  165.    int rx_len;
  166.  
  167.    int last_lcd_output=0xFF;
  168.    int i,curr_lcd_output;
  169.  
  170.    setup_port_a(RA0_ANALOG);
  171.    setup_adc(ADC_CLOCK_INTERNAL);
  172.    set_adc_channel(0);
  173.  
  174.    for(i=0;i<8;i++) {
  175.       buffer[i]=0;
  176.    }
  177.  
  178.    LED1_HIGH;
  179.    LED2_HIGH;
  180.    LED3_HIGH;
  181.    printf("\r\n\r\nCCS CAN EXAMPLE\r\n");
  182.    delay_ms(1000);
  183.    LED1_LOW;
  184.    LED2_LOW;
  185.    LED3_LOW;
  186.  
  187.    setup_timer_2(T2_DIV_BY_4,79,16);   //setup up timer2 to interrupt every 1ms if using 20Mhz clock
  188.  
  189.    can_init();
  190.  
  191.    enable_interrupts(INT_TIMER2);
  192.    enable_interrupts(GLOBAL);
  193.  
  194.    printf("\r\nRunning...");
  195.  
  196.    while(TRUE)
  197.    {
  198.       if ( can_kbhit() )
  199.       {
  200.          printf("\r\n");
  201.          if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) {
  202.             if (rx_id == ASK_FOR_ID_AD_B) {
  203.                printf("Channel B AD: %X\r\n",buffer[0]);
  204.             }
  205.             else if (rx_id == RESPOND_TO_LED_C_ID) {  //node C is an mcp250x0 which sends out a message upon edge detection on IO
  206.                printf("Chaning LEDs\r\n");            //in_data[0]=iointfl, in_data[1]=gpio
  207.                a_leds=~(buffer[1]);
  208.                if (bit_test(a_leds,4)) {LED1_HIGH;} else {LED1_LOW;}
  209.                if (bit_test(a_leds,5)) {LED2_HIGH;} else {LED2_LOW;}
  210.                if (bit_test(a_leds,6)) {LED3_HIGH;} else {LED3_LOW;}
  211.             }
  212.          }
  213.       }
  214.  
  215.       if ( can_tbe() && (ms > 2000))       //every two seconds, send new data if transmit buffer is empty
  216.       {
  217.          ms=0;
  218.  
  219.          //change leds on port b
  220.          printf("\r\n\r\nSet LEDs on Port B to %U",b_leds);
  221.          can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);
  222.          b_leds++;
  223.          if (b_leds > 7) {b_leds=0;}
  224.       }
  225.  
  226.       if (BUTTON_PRESSED) {
  227.          while (BUTTON_PRESSED) {}
  228.          delay_ms(200);
  229.  
  230.          //ask for AD on port B
  231.          printf("\r\n\r\nAsking for A/D reading on Port B...");
  232.          can_putd(ASK_FOR_ID_AD_B, 0, 1, 1, 1, 1);
  233.  
  234.          //change LEDs on port C
  235.          buffer[0]=0x1E;            //addr of gplat on 25050
  236.          buffer[1]=0x0E;            //mask
  237.          buffer[2]=~(c_leds << 1);  //new gplat values
  238.          printf("\r\nIncrementing LED on Port C");
  239.          can_putd(WRITE_REGISTER_C_ID, &buffer[0], 3, 1, 1, 0);
  240.          c_leds++;
  241.          if (c_leds > 7) {c_leds=0;}
  242.       }
  243.  
  244.          //change lcd segment on port d
  245.          i=read_adc();
  246.          curr_lcd_output=i/26;   //scale to 0-9
  247.          if (curr_lcd_output != last_lcd_output) {
  248.             last_lcd_output=curr_lcd_output;
  249.             printf("\r\nChanging 8-seg LCD on D to current A/D reading (%X, %X)",i,curr_lcd_output);
  250.             buffer[0]=0x1E;                    //addr of gplat
  251.             buffer[1]=0x7F;             //mask
  252.             buffer[2]=lcd_seg[curr_lcd_output];                //new gplat values
  253.             can_putd(WRITE_REGISTER_D_ID, &buffer[0], 3, 1, 1, 0);
  254.          }
  255.    }
  256. }
  257.  
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Noviembre de 2007, 18:27:31
Explico que hace este programa, sección por sección.

Atención de mensajes de otros Nodos.
En esta zona del código se leen los mensajes en el BUS CAN y se comparan con los ID para saber si es alguno de los que se estan esperando.

Código: C
  1.       if ( can_kbhit() )
  2.       {
  3.          printf("\r\n");
  4.          if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) {
  5.             if (rx_id == ASK_FOR_ID_AD_B) {
  6.                printf("Channel B AD: %X\r\n",buffer[0]);
  7.             }
  8.             else if (rx_id == RESPOND_TO_LED_C_ID) {  //node C is an mcp250x0 which sends out a message upon edge detection on IO
  9.                printf("Chaning LEDs\r\n");            //in_data[0]=iointfl, in_data[1]=gpio
  10.                a_leds=~(buffer[1]);
  11.                if (bit_test(a_leds,4)) {LED1_HIGH;} else {LED1_LOW;}
  12.                if (bit_test(a_leds,5)) {LED2_HIGH;} else {LED2_LOW;}
  13.                if (bit_test(a_leds,6)) {LED3_HIGH;} else {LED3_LOW;}
  14.             }
  15.          }
  16.       }

En el ejemplo veremos que el Nodo A oficia de Master en este Bus (recordemos que el bus puede ser multi Master) y espera el dato del conversor A/D del Nodo B (variable de 8 Bits) y tambien espera leer el estado de tres pulsadores del Nodo C.
Este ultimo nodo tiene un MCP25050 que es un expansor I/O con CAN.
Cuando recibe el dato, transmite el valor del conversor A/D del Nodo B por el puerto serie (ya modificado por mi para mostrarlo en display en mis prácticas) y representa el estado de los pulsadores (dato que proviene del Nodo C) en tres leds del Nodo A.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Noviembre de 2007, 18:35:05
Segunda sección del código, el envío a otros nodos.
Esta parte del código se encarga de escribir datos en el Nodo D, que es otro MCP25050 con un display de 7 segmentos conectado), y de solicitar el dato del conversor A/D al Nodo B, que es un PIC16F876 con un MCP2515.

Código: C
  1.       if (BUTTON_PRESSED) {
  2.          while (BUTTON_PRESSED) {}
  3.          delay_ms(200);
  4.  
  5.          //ask for AD on port B
  6.          printf("\r\n\r\nAsking for A/D reading on Port B...");
  7.          can_putd(ASK_FOR_ID_AD_B, 0, 1, 1, 1, 1);
  8.  
  9.          //change LEDs on port C
  10.          buffer[0]=0x1E;            //addr of gplat on 25050
  11.          buffer[1]=0x0E;            //mask
  12.          buffer[2]=~(c_leds << 1);  //new gplat values
  13.          printf("\r\nIncrementing LED on Port C");
  14.          can_putd(WRITE_REGISTER_C_ID, &buffer[0], 3, 1, 1, 0);
  15.          c_leds++;
  16.          if (c_leds > 7) {c_leds=0;}
  17.       }
  18.  
  19.          //change lcd segment on port d
  20.          i=read_adc();
  21.          curr_lcd_output=i/26;   //scale to 0-9
  22.          if (curr_lcd_output != last_lcd_output) {
  23.             last_lcd_output=curr_lcd_output;
  24.             printf("\r\nChanging 8-seg LCD on D to current A/D reading (%X, %X)",i,curr_lcd_output);
  25.             buffer[0]=0x1E;                    //addr of gplat
  26.             buffer[1]=0x7F;             //mask
  27.             buffer[2]=lcd_seg[curr_lcd_output];                //new gplat values
  28.             can_putd(WRITE_REGISTER_D_ID, &buffer[0], 3, 1, 1, 0);
  29.          }
  30.    }
  31.  

Ademas incrementa la cuenta de leds en el Nodo C, en los leds conectados a ese nodo.
Olvide decir que este codigo solo se ejecuta con intervención del usuario, ya que debe presionar un pulsador para obtener esta funcionalidad... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 18 de Noviembre de 2007, 18:36:49
 :-/ adelante marcos :-/

muchas suerte  :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Noviembre de 2007, 18:38:53
Ultima sección, escritura de los leds del Nodo B.

Esta sección del codigo se ejecuta solo si el Bus no esta ocupado y cuando se cumplieron 2 segundos.

Código: C
  1.       if ( can_tbe() && (ms > 2000))       //every two seconds, send new data if transmit buffer is empty
  2.       {
  3.          ms=0;
  4.  
  5.          //change leds on port b
  6.          printf("\r\n\r\nSet LEDs on Port B to %U",b_leds);
  7.          can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);
  8.          b_leds++;
  9.          if (b_leds > 7) {b_leds=0;}
  10.       }
  11.  

Como verán este solo ejemplo muestra la interactividad del BUS, donde todos los nodos pueden leer o escribir datos desde o hacia otro Nodo del BUS. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LABmouse en 18 de Noviembre de 2007, 20:54:55
Amigo Marcos... Este hilo es estupendo, déjame le pongo su debida Chincheta por la importancia para todos!!

SALUDOS y ABRAZOS AMIGO!!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 19 de Noviembre de 2007, 03:17:15
Marcos, ¿podrías explicar el significado de los parámetros en estas funciones?

can_getd(rx_id, &buffer[0], rx_len, rxstat);
can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);

Gracias guapetón  :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 08:45:49
Marcos, ¿podrías explicar el significado de los parámetros en estas funciones?

can_getd(rx_id, &buffer[0], rx_len, rxstat);
can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);

Gracias guapetón  :D
Como no, Maestro Manolo!!
Pongo los encabezados de las funciones, y los explicamos un poco...
Código: C
  1. ////////////////////////////////////////////////////////////////////////
  2. //
  3. // can_getd()
  4. //
  5. // Gets data from a receive buffer, if the data exists
  6. //
  7. //    Parameters:
  8. //      id - ID who sent message
  9. //      data - pointer to array of data
  10. //      len - length of received data
  11. //      stat - structure holding some information (such as which buffer
  12. //             recieved it, ext or standard, etc)
  13. //
  14. //    Returns:
  15. //      Function call returns a TRUE if there was data in a RX buffer, FALSE
  16. //      if there was none.
  17. //
  18. ////////////////////////////////////////////////////////////////////////
  19. int1 can_getd(int32 & id, int * data, int & len, struct rx_stat & stat)

Creo que es bastante explicativo, pero veamos los parametros que estamos enviando:
rx_id, como lo pide la función, indica la ID (numero hexadecimal) que identifica en forma unívoca el Nodo en el BUS.
&buffer[0], es el puntero a los datos entrantes, cuya cantidad es indicada por el siguiente parametro.
rx_len, es la cantidad de datos a recibir, cada mensaje permite enviar hasta 8 bytes.
rxstat, indica que tipo de mensaje es enviado, si usa mensaje estandar (11 bits) o extendido (29bits)

Ahora veamos la funcion Can_putd()

Código: C
  1. ////////////////////////////////////////////////////////////////////////
  2. //
  3. // can_putd()
  4. //
  5. // Puts data on a transmit buffer, at which time the CAN peripheral will
  6. // send when the CAN bus becomes available.
  7. //
  8. //    Paramaters:
  9. //       id - ID to transmit data as
  10. //          enumerated as - RXB0ID,RXB1ID,B0ID,B1ID,B2ID,B3ID,B4ID,B5ID
  11. //       data - pointer to data to send
  12. //       len - length of data to send
  13. //       priority - priority of message.  The higher the number, the
  14. //                  sooner the CAN peripheral will send the message.
  15. //                  Numbers 0 through 3 are valid.
  16. //       ext - TRUE to use an extended ID, FALSE if not
  17. //       rtr - TRUE to set the RTR (request) bit in the ID, false if NOT
  18. //
  19. //    Returns:
  20. //       If successful, it will return TRUE
  21. //       If un-successful, will return FALSE
  22. //
  23. ////////////////////////////////////////////////////////////////////////
  24. int1 can_putd(int32 id, int * data, int len, int priority, int1 ext, int1 rtr) {

en el uso de esta función en el ejemplo se usan estos parametros:
SET_LED_ID_B, si miran el codigo, es una constante que contiene la ID del Nodo
&b_leds, es el puntero a los datos que se van a enviar.
1, indica que se enviara un solo byte, en este caso envía el estado de los leds.
1, le dice al BUS que tipo de prioridad llevara este mensaje, para que el BUS lo maneje con mayor o menor prioridad.
1, un uno aqui indica al BUS que el mensaje es extendido (29 bits)
0, no usa el bit RTR (esto da para un tratado, lo dejamos para otra explicación)

Bueno, espero haya mejorado el entendimiento, por favor pidan explicaciones sobre lo que no entiendan.... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 19 de Noviembre de 2007, 08:53:53
Claro como el agua
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 19 de Noviembre de 2007, 18:02:25
Nose si es muy tarde la pregunta pero, esque estoy interesado en el tema, ya que debo hacer una aplicacion sencilla entre 2 o 3 micros que usen en BUS CAN, y esto que veo talvez sea mas trabajado, y como menciono solo quisiera iniciarme con algo sencillo, tengo a la disposicion 3 micros 18f4685, y pues del CAN nunca sape nada, jeje, hasta ahora, y si no fuera molestia me explican mas o menos en que consiste?? es como el I2C?

bueno disculpen si interfiero, un saludo, muchas gracias por la ayuda
Título: Como funciona el BUS CAN ? De que se trata ??
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 20:52:52
Que significa CAN ??

CAN (Controller Area Network)  
CAN es un protocolo de comunicaciones desarrollado por la firma alemana Robert Bosch GmbH, basado en una topología bus para la transmisión de mensajes en ambientes distribuidos, además ofrece una solución a la gestión de la comunicación entre múltiples unidades centrales de proceso.

Este bus de comunicaciones es ampliamente utilizado dentro de automóviles de alta gama (al principio, pero hoy se implementa en la mayoría de la gama media también), y su éxito lo ha trasladado a maquinaria pesada y también a la industria.

El protocolo de comunicaciones CAN proporciona los siguientes beneficios:

Es un protocolo de comunicaciones normalizado, con lo que se simplifica y economiza la tarea de comunicar subsistemas de diferentes fabricantes sobre una red común o bus.
El procesador anfitrión (host) delega la carga de comunicaciones a un periférico inteligente, por lo tanto el procesador anfitrión dispone de mayor tiempo para ejecutar sus propias tareas.
Al ser una red multiplexada, reduce considerablemente el cableado y elimina las conexiones punto a punto.
Para simplificar aun más la electrónica del coche se puede utilizar una subred más simple, que se conecta a la red CAN, llamada LIN.


 Principales características de CAN
CAN se basa en el modelo productor/consumidor, el cual es un concepto, o paradigma de comunicaciones de datos, que describe una relación entre un productor y uno o más consumidores.
CAN es un protocolo orientado a mensajes, es decir la información que se va a intercambiar se descompone en mensajes, a los cuales se les asigna un identificador y se encapsulan en tramas para su transmisión.
Cada mensaje tiene un identificador único dentro de la red, con el cual los nodos deciden aceptar o no dicho mensaje.

Dentro de sus principales características se encuentran:



CAN fue desarrollado, inicialmente para aplicaciones en los automóviles y por lo tanto la plataforma del protocolo es resultado de las necesidades existentes en el área de la automoción.
La Organización Internacional para la Estandarización (ISO, International Organization for Standarization) define dos tipos de redes CAN: una red de alta velocidad (hasta 1 Mbps), bajo el estándar ISO 11898-2, destinada para controlar el motor e interconectar la unidades de control electrónico (ECU); y una red de baja velocidad tolerante a fallos (menor o igual a 125 Kbps), bajo el estándar ISO 11519-2/ISO 11898-3, dedicada a la comunicación de los dispositivos electrónicos internos de un automóvil como son control de puertas, techo corredizo, luces y asientos.


Protocolo de comunicaciones CAN
CAN es un protocolo de comunicaciones serie que soporta control distribuido en tiempo real con un alto nivel de seguridad y multiplexación.

El establecimiento de una red CAN para interconectar los dispositivos electrónicos internos de un vehículo tiene la finalidad de sustituir o eliminar el cableado.
Las ECUs, sensores, sistemas antideslizantes, etc. se conectan mediante una red CAN a velocidades de transferencia de datos de hasta 1 Mbps.

De acuerdo al modelo de referencia OSI (Open Systems Interconnection), la arquitectura de protocolos CAN incluye tres capas: física, de enlace de datos y aplicación, además de una capa especial para gestión y control del nodo llamada capa de supervisor.

Capa física: define los aspectos del medio físico para la transmisión de datos entre nodos de una red CAN, los más importantes son niveles de señal, representación, sincronización y tiempos en los que los bits se transfieren al bus. La especificación del protocolo CAN no define una capa física, sin embargo, los estándares ISO 11898 establecen las características que deben cumplir las aplicaciones para la transferencia en alta y baja velocidad.

Capa de enlace de datos: define las tareas independientes del método de acceso al medio, además debido a que una red CAN brinda soporte para procesamiento en tiempo real a todos los sistemas que la integran, el intercambio de mensajes que demanda dicho procesamiento requiere de un sistema de transmisión a frecuencias altas y retrasos mínimos.
En redes multimaestro, la técnica de acceso al medio es muy importante ya que todo nodo activo tiene los derechos para controlar la red y acaparar los recursos.
Por lo tanto la capa de enlace de datos define el método de acceso al medio así como los tipos de tramas para el envío de mensajes
Cuando un nodo necesita enviar información a través de una red CAN, puede ocurrir que varios nodos intenten transmitir simultáneamente.
CAN resuelve lo anterior al asignar prioridades mediante el identificador de cada mensaje, donde dicha asignación se realiza durante el diseño del sistema en forma de números binarios y no puede modificarse dinámicamente.
El identificador con el menor número binario es el que tiene mayor prioridad.

El método de acceso al medio utilizado es el de Acceso Múltiple por Detección de Portadora, con Detección de Colisiones y Arbitraje por Prioridad de Mensaje (CSMA/CD+AMP, Carrier Sense Multiple Access with Collision Detection and Arbitration Message Priority).
De acuerdo con este método, los nodos en la red que necesitan transmitir información deben esperar a que el bus esté libre (detección de portadora); cuando se cumple esta condición, dichos nodos transmiten un bit de inicio (acceso múltiple).
Cada nodo lee el bus bit a bit durante la transmisión de la trama y comparan el valor transmitido con el valor recibido; mientras los valores sean idénticos, el nodo continúa con la transmisión; si se detecta una diferencia en los valores de los bits, se lleva a cabo el mecanismo de arbitraje.

CAN establece dos formatos de tramas de datos (data frame) que difieren en la longitud del campo del identificador, las tramas estándares (standard frame) con un identificador de 11 bits definidas en la especificación CAN 2.0A, y las tramas extendidas (extended frame) con un identificador de 29 bits definidas en la especificación CAN 2.0B.

Para la transmisión y control de mensajes CAN, se definen cuatro tipos de tramas: de datos, remota (remote frame), de error (error frame) y de sobrecarga (overload frame).
Las tramas remotas también se establecen en ambos formatos, estándar y extendido, y tanto las tramas de datos como las remotas se separan de tramas precedentes mediante espacios entre tramas (interframe space).

En cuanto a la detección y manejo de errores, un controlador CAN cuenta con la capacidad de detectar y manejar los errores que surjan en una red. Todo error detectado por un nodo, se notifica inmediatamente al resto de los nodos.

Capa de supervisor: La sustitución del cableado convencional por un sistema de bus serie presenta el problema de que un nodo defectuoso puede bloquear el funcionamiento del sistema completo.
Cada nodo activo transmite una bandera de error cuando detecta algún tipo de error y puede ocasionar que un nodo defectuoso pueda acaparar el medio físico.
Para eliminar este riesgo el protocolo CAN define un mecanismo autónomo para detectar y desconectar un nodo defectuoso del bus, dicho mecanismo se conoce como aislamiento de fallos.

Capa de aplicación: Existen diferentes estándares que definen la capa de aplicación; algunos son muy específicos y están relacionados con sus campos de aplicación.
Entre las capas de aplicación más utilizadas cabe mencionar CAL, CANopen, DeviceNet, SDS (Smart Distributed System), OSEK, CANKingdom.

Extraido de Wikipedia
Título: Historia del BUS CAN
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 21:59:21
Antes del BUS CAN, una instalación interna de un vehículo tenía este formato:

(http://img210.imageshack.us/img210/2176/pag2nm0.jpg)

Ya con la aparición del BUS CAN se adopta esta arquitectura...

(http://img204.imageshack.us/img204/2438/pag3xt4.jpg)

Aquí vemos las particularidades del BUS...

(http://img206.imageshack.us/img206/8896/pag4sm6.jpg)

(http://img204.imageshack.us/img204/5329/pag5bi2.jpg)

Como se distribuyen Nodos en el BUS...

(http://img206.imageshack.us/img206/8848/pag6nk7.jpg)
Título: Logica del BUS CAN
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 22:08:25
(http://img204.imageshack.us/img204/7139/pag7kt4.jpg)

(http://img204.imageshack.us/img204/5332/pag8yq6.jpg)

Como es el arbitraje cuando hay dos nodos transmitiendo a la vez...

(http://img510.imageshack.us/img510/6849/pag9sc1.jpg)

Control a traves de bit stuffing (1 de 5)...

(http://img519.imageshack.us/img519/6650/pag10bo1.jpg)

(http://img206.imageshack.us/img206/4276/pag11cg6.jpg)

(http://img204.imageshack.us/img204/4418/pag12zp7.jpg)
Título: Tramas del BUS CAN
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 22:15:15
(http://img214.imageshack.us/img214/1680/pag13sk8.jpg)

(http://img401.imageshack.us/img401/6853/pag14ja5.jpg)

(http://img204.imageshack.us/img204/6192/pag15jk2.jpg)

(http://img401.imageshack.us/img401/2/pag16wv8.jpg)

(http://img206.imageshack.us/img206/1446/pag17vf4.jpg)

(http://img510.imageshack.us/img510/2319/pag18qb8.jpg)

Título: Tipos de Errores del BUS
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 22:18:19
(http://img519.imageshack.us/img519/3279/pag19qa7.jpg)

(http://img510.imageshack.us/img510/1225/pag20cg6.jpg)
(http://img510.imageshack.us/img510/1225/pag20cg6.jpg)

(http://img210.imageshack.us/img210/1112/pag22ke0.jpg)

(http://img519.imageshack.us/img519/9466/pag23ga5.jpg)
Título: Protocolo CAN extendido
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 22:20:43
(http://img204.imageshack.us/img204/6193/pag24uk3.jpg)

(http://img519.imageshack.us/img519/845/pag25gs3.jpg)

(http://img214.imageshack.us/img214/302/pag26uj4.jpg)

Título: Manejo de bits y resincronización en el BUS CAN
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 22:26:07
(http://img267.imageshack.us/img267/742/pag27za8.jpg)

(http://img206.imageshack.us/img206/899/pag28ly5.jpg)

(http://img516.imageshack.us/img516/2263/pag29id5.jpg)

(http://img204.imageshack.us/img204/4170/pag30jt1.jpg)

(http://img204.imageshack.us/img204/849/pag31ht3.jpg)


Título: Selección de velocidad del BUS CAN
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 22:30:11
(http://img210.imageshack.us/img210/1193/pag32xr4.jpg)

(http://img401.imageshack.us/img401/1442/pag33uv5.jpg)

(http://img510.imageshack.us/img510/1051/pag34wn0.jpg)

(http://img519.imageshack.us/img519/9929/pag35rt1.jpg)

Título: Medio físico y estandar de tiempo del bit...
Publicado por: MGLSOFT en 19 de Noviembre de 2007, 22:33:56
(http://img519.imageshack.us/img519/9929/pag35rt1.jpg)

(http://img204.imageshack.us/img204/5636/pag37mo5.jpg)

(http://img204.imageshack.us/img204/4526/pag38ne2.jpg)

Bueno hasta aquí llegamos por hoy, ya trabajé demasiado, je..je.. :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 20 de Noviembre de 2007, 00:41:18
uyy con esto ya tengo harto para leer, jejeje, muchas gracias

un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LordLafebre en 20 de Noviembre de 2007, 00:52:59
Hola:

Felicidades Marcos por excelente explicación...!!!

Mas claro que esto ni el agua...  :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 20 de Noviembre de 2007, 02:37:02
Guauuuuu, maldito el día que te ayudé a pegar imágenes, ¡qué montón de curro nos dejas!
(http://www.mundovital.es/images/sudando.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 20 de Noviembre de 2007, 04:23:20
 :shock: Ayy Dios mio :5]

pero todos eso marcos!  :D :D
aqui hay para leer una eternidad :D :D
pero muy buenos :-) :-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Noviembre de 2007, 08:08:33
El tema de las imágenes, aunque sea cansador, ayuda a poder explicar con claridad de que se trata.

No hay que enloquecerse, la mitad de las tareas que estan representadas aquí son realizadas por el transceptor CAN, en mi caso utilizo el MCP2551, pero hay cantidades de transceptores de excelente calidad, de casi todas las marcas...

Casi todo el control de errores, bit stuffing, optimización de la velocidad versus el ruido, parte del resincronismo, quedan a cargo del transceptor CAN.

La gran responsabilidad del diseñador es elegir una velocidad de comunicación acorde a sus necesidades reales, definido esto debe elegir la resistencia a colocarle al transceptor (ver la hoja de datos del que se implementa, no todos son iguales), elegir el medio fisico adecuado a su instalación, y luego dedicarse a evitar errores mientras programa, ya que el resto seguramente el lenguaje de programación tendrá funciones probadas que le ayuden a realizar su trabajo... :mrgreen: :mrgreen:

Hay mas info, pero vamos a dedicarle unos días a hacer unas practicas, así descansan... :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 20 de Noviembre de 2007, 08:13:10
MGLSoft, ¿podrías exponer más información sobre tus experiencias con el medio físico? ¿qué tipo de cableado piensas utilizar?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Noviembre de 2007, 08:48:16
En mi caso usaré el mas estandar que conozco, un par retorcido mas un par para llevar tensión, ya que alimento las placas de los Nodos desde una fuente centralizada.
Esto me da una ventaja, consigo aterrizar a todos los Nodos a un mismo nivel, evitando así tener diferencias de nivel de masa, que pueden hacer que el bit sea interpretado mal por uno de los transceptores.

(http://img204.imageshack.us/img204/4526/pag38ne2.jpg)

Si miras en la imagen, cada bit se basa en un nivel de tensión diferencial respecto a GND, por ello es muy importante mantener la referencia...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 20 de Noviembre de 2007, 09:37:43
Gracias MGLSOFT, yo pensaba utilizar cable Ethernet de 4 pares trenzados, dedicando los 2 hilos de un par a la tensión positiva, los 2 hilos de otro par a la tensión nula (he visto que esto es habitual en los sistemas de alimentación PoE), los dos hilos de otro par a la comunicación CAN, y quedándome un par de repuesto para sustituir a alguno de los anteriore en caso de fallo y evitar tener que tender nuevo cableado.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ESTECA55 en 20 de Noviembre de 2007, 10:51:15
Muy Buena la Explicación Marcos!!!

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 20 de Noviembre de 2007, 11:06:16
 :mrgreen: magnifica explicacion, una joyita de hilo :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Leon Pic en 20 de Noviembre de 2007, 13:13:50
Muy buena explicación.  :-/ :-/ :-/ :-/
Título: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Noviembre de 2007, 21:13:03
Nose si es muy tarde la pregunta pero, esque estoy interesado en el tema, ya que debo hacer una aplicacion sencilla entre 2 o 3 micros que usen en BUS CAN, y esto que veo talvez sea mas trabajado, y como menciono solo quisiera iniciarme con algo sencillo, tengo a la disposicion 3 micros 18f4685, y pues del CAN nunca sape nada, jeje, hasta ahora, y si no fuera molestia me explican mas o menos en que consiste?? es como el I2C?

bueno disculpen si interfiero, un saludo, muchas gracias por la ayuda

Bueno Cryn, ahora estoy en posición de contestar tus dudas.
Primero:
Si tienes micros 18F4685, aún falta para conectarlos a un BUS CAN, que tengas los transceiver.
Este es un diagrama de como se conecta un PIC de 40 Pines (creo que asi es el tuyo) al transceiver...

(http://img509.imageshack.us/img509/3364/conexionnodocanamcp2551xk3.jpg)

Luego para interconectar dos de ellos en un BUS CAN (no pongo la imagen del PIC para no ocupar mucha imagen) la interconexión es así:

(http://imageshack.us/a/img206/7923/conexionentrenodoscanconk6.jpg)

Si consigues rápido los MCP2551 podremos hacer ejercicios para tus micros, te aconsejo no los armes en un protoboard, al menos no la parte de CAN, porque sino limitaras las velocidades a algunas muy bajas, yo tuve armado mi esquema en un protoboard y a 125 KBPs dejaba de funcionar apenas lo miraba un poco fijo.
Hoy armado en una placa, al doble de velocidad, no se detiene aunque resetee uno de los micros, apenas esta el PIC energizado retoma la comunicación sin problemas, esto no lo lograría en un proto!!

Para información, la gente de Texas me ha enviado muestras de sus tranceivers y realmente funcionan de maravillas!!
Las pedí como samples en su pagina WEB y en 15 días las tuve en mis manos sin pagar un solo peso.
Felicitaciones a Texas por su sistema de samples!!!
El modelo que pedí es el SN65HVD251P, funciona maravillosamente bien mezclado con los MCP2551 de Microchip.
Título: Mis experiencias con el BUS CAN - Interconexión
Publicado por: MGLSOFT en 20 de Noviembre de 2007, 21:20:50
En el BUS CAN se utiliza normalmente este tipo de interconexión, Cryn.

(http://img267.imageshack.us/img267/7999/pag36fd6.jpg)

Es un par retorcido.
También existen buses por fibra optica y por conexión inalámbrica.... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 20 de Noviembre de 2007, 21:24:23
gracias por las respuestas. Es necesario si o si los tranceptores que mencionas? ya que por aca no existen a la venta, y pues tendria que esperar mucho tiempo, nose, se puede hacer algo sin tranceptores?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Noviembre de 2007, 21:28:42
En realidad no se!!
Dejame averiguar...
Igual te recomiendo busques en la página de Texas y llenando una ficha de un desarrollo ellos te enviarán hasta 5 muestras de cada uno, los que yo pedí son muy buenos, formato DIP de 8 pines...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Noviembre de 2007, 21:38:47
No, lo lamento...
Sin los transceiver solo tienes una comunicación serial entre ambos Nodos, no hay forma de determinar todos los temas de errores y deteccion de bit dominante o recesivo...

(http://img212.imageshack.us/img212/4450/datadelmcp2551dc4.jpg)

Solo queda probar entre ambos PIC conectados entre sí con los TXD de uno cableado al RXD del otro y viceversa.

Pierdes la posibilidad de manejar mas de dos nodos y es monopunto, pero no se pierde nada con intentarlo...
Probemos :-/ :-/

Recomendaría que uses cristales de cuarzo de al menos 10 MHz en ambos Clocks, así no calculamos tu comunicación y sirven las adaptaciones que ya tengo hechas...
Si no dispones de dos cristales me dices que tienes y vemos... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 20 de Noviembre de 2007, 21:44:28
crees que manden muestras hasta mi pais?? ya que aca no mandan casi nada :( pero lo intentare

mmm, bueno no hay problema si se hace solo entre dos PIC's solo es para iniciarse, si puedo disponer de crisatales de 10MHz :-/

gracias :mrgreen:
Título: Mis experiencias con el BUS CAN - El codigo del Nodo B
Publicado por: MGLSOFT en 20 de Noviembre de 2007, 21:53:47
El otro día dejé el ejemplo de código del Nodo A, usando un 18F4580.
Hoy quiero pegar aquí el código que uso en el Nodo B, que tiene un PIC16F876, conectado a través de un controlador CAN MCP2515...

El código:
Recordemos que el Nodo A envía un mensaje escribiendo el valor de los leds del Nodo B y otro mensaje (si se presiona una tecla en el Nodo A) solicitando al Nodo B la lectura de su convertidor A/D.
Cuando este recibe el primer mensaje, escribe los leds con los valores recibidos (agregué yo el envío de otro mensaje en devolución para escribir los tres leds del Nodo A, para probar el delay entre mensajes).
Cuando el Nodo B recibe el segundo mensaje, efectúa la conversión y envia el mensaje con el dato.

Ambos mensajes utilizan in ID diferente para enviarlo, de esa forma pueden ser consumidos por los Nodos que los necesiten...

Código: C
  1. /////////////////////////////////////////////////////////////////////////
  2. ////                         EX_CAN_CCS_B.C                          ////
  3. ////                                                                 ////
  4. //// Example of CCS's MCP2510 CAN library.  This example was tested  ////
  5. //// using MCP250xxx CCS's CAN Prototype board.                      ////
  6. ////                                                                 ////
  7. //// This example provides the firmware for the B node in CCS's      ////
  8. //// CAN prototyping board.  Node B responds to CAN ID 0x202         ////
  9. //// by setting the 3 LEDs to the value transmitted by Node A.       ////
  10. //// Node B also repsonds to requests from CAN ID 0x201 by           ////
  11. //// transmitting an A/D reading.                                    ////
  12. ////                                                                 ////
  13. //// Using a serial port, this example also shows all traffic on the ////
  14. //// CAN bus as received by the MCP2510.                             ////
  15. ////                                                                 ////
  16. //// For more documentation on the MPC2510 CAN library, see          ////
  17. //// can-mcp2510.c                                                   ////
  18. ////                                                                 ////
  19. //// For more documentation on the CCS Can Prototype board see       ////
  20. //// ex_can_ccs_a.c                                                  ////
  21. ////                                                                 ////
  22. ////  Jumpers:                                                       ////
  23. ////     PCM,PCH    pin C7 to RS232 RX, pin C6 to RS232 TX           ////
  24. ////                                                                 ////
  25. ////  This example will work with the PCM compiler.                  ////
  26. /////////////////////////////////////////////////////////////////////////
  27. ////        (C) Copyright 1996,2003 Custom Computer Services         ////
  28. //// This source code may only be used by licensed users of the CCS  ////
  29. //// C compiler.  This source code may only be distributed to other  ////
  30. //// licensed users of the CCS C compiler.  No other use,            ////
  31. //// reproduction or distribution is permitted without written       ////
  32. //// permission.  Derivative programs created using this software    ////
  33. //// in object code form are not restricted in any way.              ////
  34. /////////////////////////////////////////////////////////////////////////
  35.  
  36. #include <16F876.h>
  37. #device ICD=TRUE
  38. #device adc=8
  39. #fuses HS,NOPROTECT,NOLVP,NOWDT
  40.  
  41. #use delay(clock=10000000)
  42. #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
  43.  
  44. #define CAN_DO_DEBUG TRUE
  45.  
  46. #define Set_250K_Baud TRUE  /// Aqui configuro que velocidad del BUS utilizo
  47. #include "can-mcp2510.c"
  48.  
  49. #define PIN_LED1  PIN_A1
  50. #define PIN_LED2  PIN_A2
  51. #define PIN_LED3  PIN_A3
  52.  
  53. #define LED1_LOW  output_low(PIN_LED1)
  54. #define LED1_HIGH output_high(PIN_LED1)
  55. #define LED2_LOW  output_low(PIN_LED2)
  56. #define LED2_HIGH output_high(PIN_LED2)
  57. #define LED3_LOW  output_low(PIN_LED3)
  58. #define LED3_HIGH output_high(PIN_LED3)
  59.  
  60. #define BUTTON    PIN_E2
  61.  
  62. #define BUTTON_PRESSED  !input(BUTTON)
  63.  
  64. int16 ms;
  65.  
  66. #int_timer2
  67. void isr_timer2(void) {
  68.    ms++; //keep a running timer that increments every milli-second
  69. }
  70.  
  71. #define RESPOND_TO_ID_AD   0x201
  72. #define RESPOND_TO_ID_LED  0x202
  73. #define Escribe_LEDs_A_ID  0x303
  74.  
  75. void main() {
  76.    struct rx_stat rxstat;
  77.    int32 rx_id;
  78.    int buffer[8];
  79.    int rx_len;
  80.  
  81.  
  82.    int i;
  83.  
  84.    setup_port_a(RA0_ANALOG);
  85.    setup_adc(ADC_CLOCK_INTERNAL);
  86.    set_adc_channel(0);
  87.  
  88.    for(i=0;i<8;i++) {
  89.       buffer[i]=0;
  90.    }
  91.  
  92.    LED1_HIGH;
  93.    LED2_HIGH;
  94.    LED3_HIGH;
  95.    printf("\r\n\r\nEJEMPLO CAN DE CCS\r\n");
  96.    delay_ms(1000);
  97.    LED1_LOW;
  98.    LED2_LOW;
  99.    LED3_LOW;
  100.  
  101.    setup_timer_2(T2_DIV_BY_16,53,3);
  102.  
  103.    can_init();
  104.  
  105.    enable_interrupts(INT_TIMER2);   //enable timer2 interrupt
  106.    enable_interrupts(GLOBAL);       //enable all interrupts (else timer2 wont happen)
  107.  
  108.    printf("\r\nMarchando...");
  109.  
  110.    while(TRUE)
  111.    {
  112.  
  113.       if ( can_kbhit() )   //if data is waiting in buffer...
  114.       {
  115.          if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) { //...then get data from buffer
  116.             if (rx_id == RESPOND_TO_ID_LED) {
  117.                printf("Cambiando los LEDs\r\n\r\n");
  118.                if (bit_test(buffer[0],0)) {LED1_HIGH;} else {LED1_LOW;}
  119.                if (bit_test(buffer[0],1)) {LED2_HIGH;} else {LED2_LOW;}
  120.                if (bit_test(buffer[0],2)) {LED3_HIGH;} else {LED3_LOW;}
  121.  
  122.                //change leds on port b
  123.                printf("\r\n\r\nEnvía los valores al Nodo A");
  124.                can_putd(Escribe_LEDs_A_ID, &buffer[0], 1, 1, 1, 0);
  125.                //can_putd(Escribe_LEDs_A_ID, &buffer[1], 2, 1, 1, 0);
  126.             }
  127.             if (rx_id == RESPOND_TO_ID_AD) {
  128.                i=read_adc();
  129.                printf("Enviando lectura del conversor AD: %X\r\n\r\n",i);
  130.                can_putd(RESPOND_TO_ID_AD, &i, 1,1,1,0); //put data on transmit buffer
  131.             }
  132.          }
  133.       }
  134.    }
  135. }
  136.  
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Noviembre de 2007, 22:00:47
crees que manden muestras hasta mi pais?? ya que aca no mandan casi nada :( pero lo intentare

mmm, bueno no hay problema si se hace solo entre dos PIC's solo es para iniciarse, si puedo disponer de crisatales de 10MHz :-/

gracias :mrgreen:
Así me gusta!!
A no desanimarse!!

Veamos esto, deberías darme por privado una cuenta donde enviarte un codigo inicial, de esa forma tu preparas ambos PICs y armas en un circuito ambos PICs conectandolos entre si como te escribi en el otro POST...

Una vez que estan ambos con su codigo y conectados deberias poder ver algo por sus puertos serie (en cada ejemplo, para hacer debug, deberan estar conectados), utilizando el Port Monitor de CCS.
 :) :) :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 21 de Noviembre de 2007, 02:36:04
Marcos, según Microchip todos estos micros tienen periférico CAN:
http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=50&mid=10&lang=en&pageId=74

¿sabes si con ellos nos podemos ahorrar los transceptores?, ¿conoces la diferencia entre bus CAN y ECAN?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: elreypic2 en 21 de Noviembre de 2007, 06:18:31
Exelente trabajo MGLSOFT.

Antes que nada me disculpo porque no me fue posible recuperar la informacion que te habia mencionado con respecto al CAN.

Por otro lado, sino te molesta, contestare las preguntas de Nocturno.

Pregunta 1:
¿sabes si con ellos nos podemos ahorrar los transceptores?

Respuesta 1:
No, porque los micros solo contienen el engine de CAN, asi que el transceptor es necesario, es decir el MCP2551 o algun otro.

Pregunta 2:
¿conoces la diferencia entre bus CAN y ECAN?

Respuesta 2:
ECAN es la version extendida del CAN. La diferencia radica en la longitud del identificador en el frame. Para CAN, la longitud del identificador es de 11 bits, en el caso de ECAN es de 23 bits.

Saludos y perdon si me entrometo, pero al menos quiero ayudar en algo. Y nuevamente Felicidades, un excelente tema.

Elreypic.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Noviembre de 2007, 08:34:41
Marcos, según Microchip todos estos micros tienen periférico CAN:
http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=50&mid=10&lang=en&pageId=74

¿sabes si con ellos nos podemos ahorrar los transceptores?, ¿conoces la diferencia entre bus CAN y ECAN?

No conozco ningun micro de marca alguna que implemente al transceptor dentro del micro.
La razon es que ese transceptor es elemento de sacrificio ante brutalidades como que el BUS sea expuesto a tensiones o descargas que provoquen su destrucción, imaginate que si estuvieran incorporados al micro, en ese caso deberías cambiar el micro completo, mientras que de esta forma cambias el transceptor y asunto solucionado (luego de haber localizado la causa de la falla).
Por otro lado por las características del BUS CAN, se busca que aún en circunstancias de falla, cada componente tenga la mayor autonomía y control posibles, por lo tanto en transceptor incorporado tampoco cumple con ese precepto.
Se entiende??

Respecto a las diferencias entre BUS CAN y ECAN, creo que la nota de Microchip es mas explicativa de lo que yo sería, ademas no quiero pecar de sabelotodo, por eso prometo investigar y luego contestaré con más idea al respecto.  :mrgreen:
La Nota (http://ww1.microchip.com/downloads/en/AppNotes/00916a.pdf)

Aquí algo de las diferencias, remarco en azul las mas importantes:

CAN INTERFACE CHARACTERISTICS
• Implementation of the CAN protocols: CAN 1.2, CAN 2.0A and CAN 2.0B
• Standard and extended data frames
• 0-8 bytes data length
• Programmable bit rate up to 1 Mbit/sec
• Support for remote frames
• Double-buffered receiver with two prioritized received message storage buffers
• Six full (standard/extended identifier) acceptance filters; two associated with the high priority receive buffer and four associated with the low priority receive buffer
• Two full acceptance filter masks, one each associated with the high and low priority receive buffers
• Three transmit buffers with application specified prioritization and abort capability
• Programmable wake-up functionality with integrated low-pass filter
• Programmable Loopback mode supports self-test operation
• Signaling via interrupt capabilities for all CAN receiver and transmitter error states
• Programmable clock source
• Programmable link to timer module for time-stamping and network synchronization
• Low-power Sleep mode

ECAN INTERFACE CHARACTERISTICS
• Implementation of the CAN protocols: CAN 1.2, CAN 2.0A and CAN 2.0B
• DeviceNet™ data bytes filter support
• Standard and Extended data frames
• 0-8 bytes data length
• Programmable bit rate up to 1 Mbit/sec
• Fully backward compatible with PIC18XX8 CAN module
• Three modes of operation:
- Mode 0 – Legacy mode
- Mode 1 – Enhanced Legacy mode with DeviceNet support
- Mode 2 – FIFO mode with DeviceNet support
• Support for remote frames with automated handling
• Double-buffered receiver with two prioritized received message storage buffers
• Six buffers programmable as RX and TX message buffers
• 16 full (standard/extended identifier) acceptance filters that can be linked to one of four masks
• Two full acceptance filter masks that can be assigned to any filter
• One full acceptance filter that can be used as either an acceptance filter or acceptance filter mask
• Three dedicated transmit buffers with application specified prioritization and abort capability
• Programmable wake-up functionality with integrated low-pass filter
• Programmable Loopback mode supports self-test operation
• Signaling via interrupt capabilities for all CAN receiver and transmitter error states
• Programmable clock source
• Programmable link to timer module for time-stamping and network synchronization
• Low-power Sleep mode
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Noviembre de 2007, 08:48:28

ECAN es la version extendida del CAN. La diferencia radica en la longitud del identificador en el frame. Para CAN, la longitud del identificador es de 11 bits, en el caso de ECAN es de 23 bits.



Hola Elreypic. :)
Corrijo dos errores en tu respuesta:
Uno es que ambos, tanto CAN como ECAN, soportan tramas estandar y extendidas.
La trama Estandar usa identificadores de 11 bits , mientras la trama Extendida usa identificadores de 29 bits.

ECAN significa Expanded CAN, o CAN Expandido, y la diferencia fundamental es que esta preparado para ser usado dentro de una capa de protocolo de mas nivel como DeviceNet o CanOpen.

Disculpa la aclaración, pero prefiero hacerla a confundir a los que lean el hilo, ya es un tema confuso de por sí, preferiría no agregar confusión. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 21 de Noviembre de 2007, 12:17:35
sabes en qeu consisten cada unos de esos tres modos??

• Three modes of operation:
- Mode 0 – Legacy mode
- Mode 1 – Enhanced Legacy mode with DeviceNet support
- Mode 2 – FIFO mode with DeviceNet support

estan disponibles en el 18f4685, verdad?

crees que pueda trabajar con ellos??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Noviembre de 2007, 13:17:13
No se bien de que se tratan, pero si leí un POST de otro forista que protesta porque las librerias de CCS no los soportan (lease: no tienen código que soporte la utilización de estos modos), por lo tanto hay que ponerse a trabajar para hacer ese codigo... :mrgreen:
Título: Mis experiencias con el BUS CAN - Monitoreo de mensajes
Publicado por: MGLSOFT en 21 de Noviembre de 2007, 13:39:59
Para hacer DEBUG del BUS CAN hay herramientas que permiten conectarse directo al BUS y realizar varios tipos de evaluaciones, todas las herramientas que conozco son PAGAS... :mrgreen:

Una de las prioridades que me fije al crear este hilo fué que pudieramos todos  usar herramientas  gratis para hacer los ejercicios y las experiencias, por lo tanto busqué la forma de hacer Debug en forma económica también...

La gente de CCS tiene entre sus herramientas un software llamado SIOW, que al principio venía junto con el software pero había que llamarlo desde fuera del IDE y hace ya muchas versiones esta integrado al IDE.
Esta es la herramienta que, en conjunto con un set de instrucciones que propone CCS en sus mismas librerías, utilizaré (y los invito a hacer lo mismo, para hacer Debug de nuestros ejemplos... :mrgreen:

Una vista de SIOW y de la pantalla para configurar la velocidad, puerto, etcetera...
Si miran la pantalla de mensajes, verán los mensajes que salen del puerto serie del PIC cada vez que emite un mensaje CAN...

(http://img98.imageshack.us/img98/6841/portmonitorrx8.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: luscho en 21 de Noviembre de 2007, 23:23:31
saludos marcos:
        esto esta muy pero muy bueno y avanzas a pasos agigantados, si no te seguimos todos los días, pues no perdemos, muy buena explicación, muy buenos gráficos, aunque yo aun voy en el inicio je, je, je
                                 
                         sigue adelante..........
Título: Re: Mis experiencias con el BUS CAN
Publicado por: luscho en 21 de Noviembre de 2007, 23:47:10
Citar
Una vez que estan ambos con su codigo y conectados deberias poder ver algo por sus puertos serie (en cada ejemplo, para hacer debug, deberan estar conectados), utilizando el Port Monitor de CCS.
 :) :) :)

me puedes hablar algo mas del port monitor ... es una conexion por puerto serial?? :shock: o es algo especifico de ccs....

                                                                                  saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Noviembre de 2007, 22:38:01
Citar
Una vez que estan ambos con su codigo y conectados deberias poder ver algo por sus puertos serie (en cada ejemplo, para hacer debug, deberan estar conectados), utilizando el Port Monitor de CCS.
 :) :) :)

me puedes hablar algo mas del port monitor ... es una conexion por puerto serial?? :shock: o es algo especifico de ccs....

                                                                                  saludos

Je..je.. :lol: :lol:
Yo escribi Port Monitor, estoy peor que Diego.... :D :D

Se trata del SIOW que comento dos POST antes a este!!! :mrgreen: :mrgreen:

Y si es una conexión serial, si miras los ejemplos esta usada a 9600, 8 N 1....
Igual que la configuración que muestra la ventana del software en la imagen...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Noviembre de 2007, 23:14:47
Hola amigos!!
Ando en estos momentos lidiando con los MCP25050, aprendiendo a usarlos a pleno!! :mrgreen:

Proximamente pondre aqui las experiencias sobre estos cacharritos, que son muy lindos!!! :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 26 de Noviembre de 2007, 00:16:26
esperamos con ansias :mrgreen:
 :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: aitopes en 27 de Noviembre de 2007, 11:06:17
... la mitad de las tareas que estan representadas aquí son realizadas por el transceptor CAN, en mi caso utilizo el MCP2551, pero hay cantidades de transceptores de excelente calidad, de casi todas las marcas...

Hola Marcos!
Me parece que voy a tener que obligatoriamente ponerme a experimentar con CAN. Donde conseguiste esos transceptores? ¿Tenes idea del precio?

Gracias por toda esta info! Esta muy bueno.

Saludos!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Noviembre de 2007, 08:35:28
Los MCP2551 los consegui en Cika, valen unos 2 dolares cada uno.
Tambien consegui muestras de uno de Texas Instruments, que andan tan bien como los de Microchip... :lol:

En cuanto a los MCP2515 y los MCP25050, los consegui por medio de MCELectronics, que me los trajeron a pedido, ya que Cika ni siquiera los tiene en su catalogo... :o
Título: Mis experiencias con el BUS CAN - El MCP25050
Publicado por: MGLSOFT en 30 de Noviembre de 2007, 00:25:46
MCP25050

Este dispositivo es un expansor de I/O con protocolo CAN.

Aquí una imagen de su Pinout, con las funciones de cada pin....

(http://img529.imageshack.us/img529/9041/pinotdelmcp25050nb0.jpg)

Hay pines con varias funciones, que detallaremos enseguida...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Noviembre de 2007, 00:34:08
Pines de I/O:

GP0 a GP6 son pines que pueden ser configurados como entradas o salidas digitales, GP7 solo puede ser entrada digital o pin de Reset...

Funciones Analógicas:

En el caso de GP0 hasta GP5, estos pines pueden ser configurados como entradas de conversor A/D hasta 10 bits de resolución, disponiendo hasta 4 entradas analogicas en GP0 a GP3, y las referencias de tension (si se quieren usar externas) en Gp4 y GP5...

Los pines GP2 y GP3 ademas pueden ser configurados como salidas PWM, tambien con resolucion de 10 bits.
El ancho de pulso y la frecuencia del PWM son configurables a traves de registros de escritura a traves del CAN...


En los siguientes post trataremos el listado de registros disponibles para la configuracion del dispositivo...
Título: Mis experiencias con el BUS CAN - Registros del MCP25050
Publicado por: MGLSOFT en 30 de Noviembre de 2007, 09:12:49
Aquí están los registros disponibles del 25050.
Después detallaremos los que pueden ser cambiados por medio del protocolo CAN y los que solo pueden ser configurados una sola vez...
Tener en cuenta que el dispositivo es OTP !!

(http://img264.imageshack.us/img264/5263/registrosdelmcp25050vg7.jpg)
(http://img529.imageshack.us/img529/345/registros2delmcp25050gr7.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Diciembre de 2007, 20:45:55
Voy a subir unos videitos cortos sobre el funcionamiento de la placa, para ilustrar el funcionamiento y amenizar esto que se esta poniendo pesado.
De paso uso la camara que me regalaron mis hijos, asi que ya saben que soy nuevo en esto, disculpen si soy muy malo filmando.... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 01 de Diciembre de 2007, 21:45:39
 :o caramba, yo espero con ansias esos videos, como los filmes :lol:

que seguramente estaran muy buenos :mrgreen: estare atento al hilo
Título: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Diciembre de 2007, 08:20:01
Bueno, costo subirlo, pero ahora esta listo!! :mrgreen:
No hice comentarios mientrs lo filmaba porque ademas de estar ronco, me temblaría mas la mano, y sería peor, je..je :D :D
Por eso les voy a comentar desde el POST...

Bueno, explicaré aquí de que se trata lo que ven.... :mrgreen:
Primera parte:
En el inicio del video muestro que al apretar un pulsador el Nodo A envía un mensaje al Nodo B y este contesta devolviendo el valor del conversor A/D. Si prestan atención veran un led verde que parpadea casi debajo de la placa del display, ese muestra la recepcion OK de datos del Nodo B y su transmición para hacer DEBUG.
Segunda parte:
Muestra los cambios en los estados de tres leds del Nodo C, estos valores son enviados desde el Nodo A tras cada pulsación, el valor mostrado es una cuenta binaria.
Tercera parte:
Presionando un pulsador del Nodo A lanzamos una reconfiguración del Nodo C, en este caso dos de sus leds (Amarillo y Verde) pasan a ser salidas PWM, cambiando su valor por saltos cada 5 segundos, estos valores son enviados desde el Nodo A.
Cuarta parte:
Aquí se muestra la reconfiguración del mismo Nodo C, esta vez vuelven a ser salidas digitales los dos leds anteriores, y siguen con la cuenta binaria...
Quinta parte:
Muestra el Nodo D, que tiene un display de 7 segmentos, que cambia su valor entre valores que van desde 0 a F, los mismos son enviados desde el Nodo A cada 5 segundos.
Ultima parte:
Es un paneo general y si observan bien, veran una cuenta binaria mostrada en el Nodo B (arriba a la derecha), esos datos son enviados desde el Nodo A cada 5 segundos, una vez cambiados el Nodo B envía un mensaje al Nodo A que cambia tambien sus tres leds a la misma cuenta binaria. Alli se aprecian las velocidades en que se comunican estos Nodos entre si.

Como acotación, cada Nodo antes de transmitir, verifica que el BUS CAN no este ocupado, por eso los tiempos son mayores....
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Leon Pic en 03 de Diciembre de 2007, 11:46:49
Muy buen video. Yo también me veo obligado a aprender el BUS CAN. Haber cuando empiezo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: taichin en 04 de Diciembre de 2007, 05:45:54
Hola  :mrgreen:

   Mucho gusto mi nombre es Alejandro Hernández soy de Orizaba, me da gusto que hablen del bus CAN el cual fue gran parte de mi tema de tesis. veo que van avanzando en tema y quiero relizar una aportacion a favor de la comunidad. TENGO 2 CODIGOS A NIVEL ENSAMBLADOR sobre el bus CAN (un codigo para un nodo A y otro para un nodo B), donde el nodo A realiza una conversion A/D por su canal AN0 dicho valor se envia por el bus CAN al nodo B y este a su vez refleja la conversion por sus puertos.  Como todos saben no existe nada mas rapido y didactico que el mismo ensamblador, nada se escapa a los ojos del programador,  todo se configura a nivel de bit o como yo lo digo, ensamblador es hablarle de TU al PIC, dichos codigos los desarrolle como una inquietud al no encontrar nada por toda la Internet (o cuando menos en lo que yo busque) sobre el bus CAN a nivel ensamblador, los codigos funcionan en plena totalidad con comentarios muy explicitos.

   dejo comentarles que en su momento utilice el MCP2515 el cual es un clon del MCP2510 lei la hoja de datos y comprendi todo sobre su funcionamiento a base del protoclo SPI, me sirvio mucho un codigo en ensamblador dado por microchip el cual no contemplaba nada de filtros ni mascaras, era un codigo muy sencillo el cual corregi por que contenia errores. sin embargo opte por dejar a un lado el MCP2515 por que no me funciono, checamos con oscilscopio las señales SPI y todo era correcto, pero parecia el MCP estaba muerto.

 opte por usar el PIC18F458 el cual incluye controlador CAN interno y como si el MCP2515 estuviera embebido dentro de este Pic, hasta los registros reciben el mismo nombre, la misma cantidad de buffers de transmision y recepcion. todo era identico al MCP2515 con la ventaja que no hay que usar el SPI si no simplemente cargar los registros y el Pic es economico, realmente no hay gran ahorro usando el MCP2515 con un PIC16F876... el costo es el mismo ademas iba a obtener mejor rendimiento, con un pic mas rapido y sobre todo poder SIMULAR en el MPLAB. pues prosegui a armar y tampoco me funciono...

Despues di con el problemas y es que el transceptor MCP2551 necesitaba una resistencia que en algunos diagramas habia visto que no lo usaban y por eso yo no lo puse. este problema lo venia arrastrando desde que use el MCP2515 por eso no me funciono en su momento.

otra aclaracion.... hice pruebas y halle que es lo mismo usar el transceptor MCP2515 de microchip y el 82C250 DE PHILIPS los son equivalentes.

Para terminar los codigos dejenme los busco entre mis miles de discos ahi estan y lo estare posteando lo mas pronto posible o si lo desean escribanme a mi correo taichin_fly@hotmail.com, Actualemente estoy interesado en el USB y en el ETHERNET a nivel ensamblador con los PICS, pero ese es otro tema y les estare realizando una invitacion a trabajar a fondo sobre estos temas a quienes esten interesados. gente COMPROMETIDA... no familia, no trabajo, gente que reporte avances en tiempo y forma. pero en el siguiente mensaje les estare diciendo las bases y es que creo que si somos mas y nos ayudamos podemos avanzar mejor.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 04 de Diciembre de 2007, 07:36:50
 :-/ :-/ en horas buenas Marcos :-/ :-/
ya nos aclarara´ lo que hace con los pulsadores, donde me imagino que es el Menu del Display activando comando :mrgreen:
muchas suerte amigo  en tu projectos :-/ :-/ sigue ahi que eso va................. :-/ :-/ :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Diciembre de 2007, 08:15:21
Citar
Despues di con el problemas y es que el transceptor MCP2551 necesitaba una resistencia que en algunos diagramas habia visto que no lo usaban y por eso yo no lo puse. este problema lo venia arrastrando desde que use el MCP2515 por eso no me funciono en su momento.

Tienes razon, esa resistencia lo que hace es una especie de filtro EMI, si tu velocidad es baja pones un valor mas alto y tienes un gran filtrado, si la velocidad es muy alta pones un valor muy bajo y funciona correctamente...
Aqui un ejemplo de su conexión:
(http://img509.imageshack.us/img509/3364/conexionnodocanamcp2551xk3.jpg)

Citar
otra aclaracion.... hice pruebas y halle que es lo mismo usar el transceptor MCP2515 de microchip y el 82C250 DE PHILIPS los son equivalentes.
Casi todas las marcas poseen sus transceiver de CAN, yo uso ademas del MCP2551, uno de la firma Texas.
El modelo es SN65HVD251P, funciona maravillosamente bien mezclado con los MCP2551 de Microchip.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Diciembre de 2007, 08:20:32
:-/ :-/ en horas buenas Marcos :-/ :-/
ya nos aclarara´ lo que hace con los pulsadores, donde me imagino que es el Menu del Display activando comando :mrgreen:
muchas suerte amigo  en tu projectos :-/ :-/ sigue ahi que eso va................. :-/ :-/ :-/ :-/

Gracias STK !!
Pronto hago los comentarios directamente en el mismo POST, no olvides releerlo...!! :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Diciembre de 2007, 09:01:52
Comentarios en el Video Hechos, veanlo allí !!! :mrgreen: :mrgreen:
Título: Mis experiencias con el BUS CAN - La comunicación
Publicado por: MGLSOFT en 04 de Diciembre de 2007, 11:21:35
Aquí les pongo otro video, que es complemento del anterior, y muestra el DEBUG hecho a traves del puerto serie de uno solo de los nodos (para que vean a que velocidad es el trafico de datos), a pesar que los mensajes por tiempo son cada 5 segundos, ya que originalmente esto era cada 2 segundos, pero no se podía leer en la ventana del SIOW... :mrgreen: :mrgreen: :mrgreen:

Aquí el video:

Los comentarios serán hechos según las consultas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 04 de Diciembre de 2007, 11:30:41
 :-/ :-/muy bien los datos corren rapido :mrgreen: aunque no se pueda distinguir bien las letras pero se ve como corren :mrgreen: estupendo Marcos, eso es los mas importante la comunicaciones de los datos :-/ :-/
Gratulacion Marcos  :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: taichin en 04 de Diciembre de 2007, 23:30:31
FILTROS Y MASCARAS........  :-/

Hola yo de nuevo.... ahora quiero explicar lo que es el filtro y las mascaras.... no se si esta explicacion venga como anillo al dedo o si ya lo tienen claro en el foro. por si las dudas ahi les va.

recuerdan cual es el objetivo de una  interrupcion?? pues con los filtros y las mascaras pasa algo similar, cuando un mensaje viaja por el bus lleva un identificador pero en el caso del bus CAN dicho identificador debe ser comprobado por cada nodo que integra la red pero esto roba consumo de tiempo ya que todo mensaje generara una activacion en la bandera de recepcion del bus y si a esto le agregamos que en el bus se transfieren cientos de mensajes pues esto produciria una comprobacion exaustiva por cada nodo para estar "escuchando" el bus en todo momento, degradando el procesamiento del PIC, recordemos que el pic no debe fijar toda su atencion en el bus, solo debe poner atencion o "escuchar" los mensajes con los identificadores que le interesan.
y es aqui donde entra en accion el criterio de arbitraje y mascaras.... pero nada mejor que un ejemplo:

SUPONGAMOS QUE SE USA CAN ESTANDAR CON IDENTIFICADOR DE 11 BITS

supongamos que deseamos programar el nodo A para que reciba mensajes con un identificador que vayan del 0x7F0 al 0x7FF.

COMO LE HACEMOS?? pues simple primero aplicamos la mascara.... si ponemos a 1 los bits del registro mascara indicamos que esos mismos bits del mensaje son los que queremos poner a prueba en el filtrado.... son los bits a los que debe enfocarse el filtrado...

entonces si nos fijamos segun lo explicado en las mascaras podemos ver que la variacion se da en los ultimos 4 bits y no nos importa que valor tenga ya que si vienen presedidos del 7F entonces este mensaje MERECE LA ATENCION DEL PIC.... entonces eso quiere decir que los bits a poner a prueba son estos osea el 7F....

hasta aqui termina la chamba de la mascara entonces podemos concluir que el valor a introducir en la mascara para este caso es..... 111 1111 0000 ... indicando que los bits a poner a prueba del identificador son el 7F y los ultimos 4 bits no nos interesa ponerlos a prueba ya que no nos importan si tienen 1's o 0's .....

sigue el filtro y esto tambien es algo sencillo...  pues aqui es muy facil... el filtro tambien es un registro de 11 bits al igual que la mascara y es obvio que lo encontremos partido por que el pic trabja solo registros de 8 bits.... pues bueno el registro filtro debe tener en 1 los bits que queremos que sean 1 en el identificador y 0 en caso contrario...

pues como los primeros 4 bits no importa si son ceros o unos pues en el registro filtro tmpoco importa y es indistinto poner un cero o un uno.... pero en los bits que la mascara selecciono (7F) si es importante poner lo correspondiente... en este caso en particular pues la cosa nos quedaria asi....

                          filtro= 111 1111 XXXX      donde X no importa si es 0 o uno.....

espero que haya quedado claro...

recapitulando para aceptar identificadores de mensaje del 7F0 al 7FF, el regisro mascara y filtro queda asi...

                         mascara= 111 1111 0000
                          filtro     = 111 1111 XXXX


suponiendo el caso de que el rango identificador sea distinto al anterior por ejemplo del 6F0 al 6F0 la cosa quedaria asi...

                     mascara= 111 1111 0000
                     filtro      = 101 1111 XXXX

espero se haya entendido..... por mi es todo.... solo no se si alguien en el foro pueda explicarme el CODIGO DE REDUDANCIA CICLICA por que no se que valor es X en el polinomio generador... si tengo una idea que el polinomio cambia con cada transferencia valida y supongo que esto se traduce en mayor seguridad para el bus y lo vuelve complicado de implementar de otro modo que no sea por controladores CAN que ya incluyan dicho modulo CRC..... la verdad es que este tema no lo toque a fondo por que no encontre una corrida paso a paso del polinomio y por que los pics ya lo incluyen y no es necesario calcularlo por que como digo ya viene en el silicio....

y tambien el tema de la sincronizacion... no lo pude entender muy bien.... de hecho en mi tesis hace 2 años use el programa bit timing calculator que me evito muchos problemas.. comprendi lo general pero no pude comprenderlo a fondo.... pues es todo por mi ojala exista respuesta y si no a investigar y suerte... aa y los codigos se los dare muy pronto por aki desentierre algunos discos

OJALA Y HAYA SIDO DE UTILIDAD ESTE POST.    SALUDOS


 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Diciembre de 2007, 23:47:20
Taichin, la verdad me sorprendes!!! :-/ :-/
Es tu segundo POST y cada letra que pones no tiene desperdicio!!
Gracias por tu colaboración, en mi caso ahora sí me queda claro como es el tema de filtros y máscaras, que me tenía a maltraer, aunque ya le estaba tomando la mano.

Respecto al calculo de CRC, ni suquiera lo tomé en cuenta, porque como bien dices esta grabado en piedra (de silicio  :D), así que no hay de que preocuparse.

En cuanto al sincronismo, eso sí creo entenderlo, está preparado para minimizar el error producido por los distintos osciladores de cada Nodo, la longitud del BUS y otros temas que provocan un desfasaje entre los inicios de mensajes en el BUS.
Realmente es asombroso como funciona, y en las gráficas que puse varios POST antes hay ideas y estrategias para mejorar la ubicación y ancho del punto de muestreo.

Microchip, en sus Placas desarrollo, usa resonadores cerámicos, por lo tanto utiliza velocidades no mayores a 125 KBPs y el maximo (4 segmentos) para el punto de muestreo.

En mi caso utilizo cristales de cuarzo en cada Nodo y a 250 KBPs uso un solo segmento para el punto de muestreo.

Recuerda que según el punto de muestreo del bit sucede la resincronización posterior...
Allí está la parte importante de este tema, a mi entender... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 05 de Diciembre de 2007, 01:21:21
muy bueno, los videos estan muy buenos :mrgreen: ya tengo unos mcp y pues espero ponerme al tanto por aca, un saludo, muchas gracias por los aportes muchachos, esta quedando muy bueno el hilo :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: escarpa en 05 de Diciembre de 2007, 05:18:59
Hola!
Acabo de encontrar este foro y me parece muy interesante todo lo que estáis aportando en el. Yo estoy realizando un proyecto con el cual a partir de un pc y la herramienta labwindows, como maestro me comunico con una serie de nodos que consisten en unos servomotores, todo ello con can bus, cada uno de estos servos tiene un pic 18F4480, y desde el PC mando informacion para mover los servos y desde los servos mando medidas de velocidad, tension corriente...de cada uno de los servos. tengo algunas dudas, como cual es la manera más adecuada para recibir y tratar los datos desde cada pic. sabes algo del canopen?. estos pics tienen un módulo de ECAN.

Si pudieras ayudarme estaría muy agradecido y tambien os iria contando mis experiencias y avances.
Título: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Diciembre de 2007, 08:32:12
CanOpen es uno de los protocolos montados sobre CAN que hoy se utilizan en la industria.
No es mala idea ir integrando tus productos a ese estandar, que te permitira competir y meter tu producto en el mercado con mas facilidad.
Si quieres ver sobre el protocolo, especificaciones, normativas, etcetera, te recomiendo entrar en la pagina oficial de CanOpen y registrarte, empezaras a recibir información que será muy importante al momento de desarrollar para ese protocolo.
La pagina es:
CanOpen (http://www.canopen.org/index.php?id=68&L=2)

o en la pagina de Can-Cia que es:
Can-CIA (http://www.can-cia.de/)
Título: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 10 de Diciembre de 2007, 04:05:57
Buenos días !!!! :)

Estoy realizando un proyecto con BUS CAN (para domotizar mi casa) y el PIC18F2580 con el driver MCP2551.

La cuestión es que estaría interesado:

*1º En los esquemas de un SNIFFER par el BUS CAN . Ya he visto que Marcos utiliza un SW que me seria mas suficiente, pero lo que me hace falta el HW (el circuito en cuestión).

*2º Esta segunda petición va lanzada a Marcos. Seria posible disponer de los esquemas eléctricos y de la placa de tu entrenador.

*3º Ya por ultimo. Estoy realizando el proyecto con el COMPILADOR MIKROC, si alguien también lo ha usado agradecería que se pusiese en contacto vía al foro.


Muchas gracias de por adelantado....

Un saludo PERE. :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 08:43:00
OK, en breve pondre aqui el esquematico completo, no pienso hacerme rico con esto... :mrgreen: :mrgreen:
En cuanto a tu direccion de mail, no hace falta que la publiques aqui, te expones a correo SPAM, aunque segunn veo esta mal escrita... :mrgreen:
Título: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 10 de Diciembre de 2007, 09:23:53
Muchas   :-/ GRACIAS :-/  MGLSOFT !!!!

 :-) También he de comentar que he visto que has configurado MCP2515, del cual yo dispongo de 3 unidades; pero no he sido capaz de programarlos con la aplicación que te da microchip con el kit de desarrollo. Si no te importa estaría interesado en saber como lo has hecho.
MUCHAS MUCHAS GRACIAS......

De todos modos os remitiré a todo el que este interesado el tema de las placas que estoy haciendo para el control de la domótica así como todo el código que he implementado. El código esta en C del compilador de MikroC.

Para poneros un poco en contexto de la situación, os comento de que va el proyecto en cuestión.

El objetivo de este proyecto es el control de la casa desde cualquier punto de la tierra mediante internet. Para ello usaremos el CAN bus para comunicar los distintos dispositivos de (campo) la casa, como las persianas, luces , temperatura etc... y estos le remitirán toda la información a PLC con NODO MASTER CAN BUS. Este PLC en cuestión también tiene puerto ethernet y da soporte para la creación de una pasarela entre el CAN BUS e INTERNET.

Bueno para resumir que los estoy alargando mucho

- Elementos de campo (luces, persianas, calefacción, aire....)
- Comunicación e interrogación de los elementos de campo mediante CAN BUS
- Pasarela CAN bus ETHERNET  mediante el PLC y un PC (hará las meces de servidor).


Muchas gracias por vuestra atención y estaremos en contacto.....

Un saludo

                             PERE.   :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 10:13:58
Es muy interesante tu proyecto!!
La finalidad del mío es hacer algo parecido, aunque no pensaba usar un PLC de interfaz a Ethernet...
Que PLC usas en ese proyecto?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 10 de Diciembre de 2007, 13:02:20
HOLA MGLSOFT!!!

El PLC es un TWIDO de TELEMECANIQUE (grupo Schneider).
El uso del PLC es por que ya dispongo del mismo, y también por el grado de fiabilidad en horas de funcionamiento.
Otra de las ventajas es que la medida ya que su reducido espacio permite introducirlo en la caja de los térmicos de la vivienda sobre carril DIN.

Antes te he realiza la consulta sobre como has programado el MCP2515... Yo compre para las primeras pruebas este kit de desarrollo (te adjunto el link del PDF http://ww1.microchip.com/downloads/en/DeviceDoc/51416a.pdf ), y no he tenido narices a realizar la programación. Supongo que tu lo estas programando mediante conector ICSP. Pero claro lo que no entiendo es como lo has configurado.

Si tienes un doc de como programar el tema o me comentas donde puedo bajar documentación para la programación del mismo.
Yo me he leído al documentación de microchip y no he conseguido nada. También me hace falta saber el programador que usas (yo uso el USB LITE) pero en el WIN800 no da soporte para el MCP2515.

Después de todo esto que no es poco.... Si me puedes ayudar en algo de esto  :-/ te lo agradezco de antemano.


Un saludo

                        PERE.
Título: Mis experiencias con el BUS CAN - Esquematico Placa
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 13:14:54
Aquí les pongo el esquematico, luego pondré un link al .pdf, así pueden bajarlo a sus máquinas...

(http://img135.imageshack.us/img135/3627/placacanetha4hz9.jpg)
Título: Re: Mis experiencias con el BUS CAN - Esquematico Placa
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 13:22:40
Aquí les pongo el  link al .pdf, así pueden bajarlo a sus máquinas...

Placa en pdf (http://rapidshare.com/files/75629129/Placa_CAN_ETH.pdf)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Leon Pic en 10 de Diciembre de 2007, 13:36:19
Muchas, muchas, muchas gracias  :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 13:54:32
Citar
El PLC es un TWIDO de TELEMECANIQUE (grupo Schneider).
El uso del PLC es por que ya dispongo del mismo, y también por el grado de fiabilidad en horas de funcionamiento.
Otra de las ventajas es que la medida ya que su reducido espacio permite introducirlo en la caja de los térmicos de la vivienda sobre carril DIN.
Pregunta:
Ese PLC tiene CAN o CANOpen ?? :shock:
Mira que hay una diferencia importante de protocolo a favor de CANOpen....

Citar
Antes te he realiza la consulta sobre como has programado el MCP2515... Yo compre para las primeras pruebas este kit de desarrollo (te adjunto el link del PDF http://ww1.microchip.com/downloads/en/DeviceDoc/51416a.pdf ), y no he tenido narices a realizar la programación. Supongo que tu lo estas programando mediante conector ICSP. Pero claro lo que no entiendo es como lo has configurado.

Si tienes un doc de como programar el tema o me comentas donde puedo bajar documentación para la programación del mismo.
Yo me he leído al documentación de microchip y no he conseguido nada. También me hace falta saber el programador que usas (yo uso el USB LITE) pero en el WIN800 no da soporte para el MCP2515.

Si ya tienes esa placa desarrollo, y has leido la hoja de datos del MCP2515, habras visto que es un controlador CAN, es decir tiene todos los elementos para establecer la comunicación en el bus CAN (usando un transceiver como el MCP2551).
No tiene inteligencia propia, necesita del uso de un Micro para tenerla, y la configuración de sus registros se hace por medio de un BUS SPI, que veras como se implementa en el esquematico de la placa mía, donde uso un MCP2515 para comunicar un PIC16F876 en el Nodo B y también uso otro (el mismo que lo cambio de zócalo) para comunicarme desde una PC...

El MCP2515 NO se programa desde un programador, debes haber interpretado esto en mis comentarios sobre los Nodos C y D de mi placa, pero esos dispositivos son MCP25050, expansores I/O a traves de CAN, que hasta donde investigué solo Microchip fabrica algo parecido...

Cualquier duda me comentas...
 :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: aitopes en 10 de Diciembre de 2007, 15:41:07
Aquí les pongo el  link al .pdf, así pueden bajarlo a sus máquinas...

Placa en pdf (http://rapidshare.com/files/75629129/Placa_CAN_ETH.pdf)


 :D :D QUE HIJO DE POTTER!!!!!!!!!!  :D :D
Marcos, es impresionante ese circuito!  8)

Felicitaciones por hacer andar algo asi....
(que lejos estoy!!!!!!!!!!!!!!!  :shock:)

Ariel.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 15:43:17
Aquí les pongo el  link al .pdf, así pueden bajarlo a sus máquinas...

Placa en pdf (http://rapidshare.com/files/75629129/Placa_CAN_ETH.pdf)


 :D :D QUE HIJO DE POTTER!!!!!!!!!!  :D :D
Marcos, es impresionante ese circuito!  8)

Felicitaciones por hacer andar algo asi....
(que lejos estoy!!!!!!!!!!!!!!!  :shock:)

Ariel.



Cual?? :shock: :shock:

Harry o Billy ?? :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 10 de Diciembre de 2007, 20:21:14
Buenas MGLSOFT!!!

1º- Lo primero es pedirte perdon porque ayer con las cosas del as prisas me equivoque con el tema delos PIC.
Si es cierto ayer me te dije lo  del mcp2515, pero no se como cometí este error. Perdón  :( . Los que tengo que de programar son los MCP25050 y los MCP25020. Esos si que hay que programarlos, y la gente de micro chip me dice que lo puedo hacer de la placa de desarrollo es la de los MCP250xx.
Con esta y el programa que me han dado los de micro chip (que se llama MCP250xx programer version 1.1) no soy capaz de programarlos.
Estos chip ahora mismo no les estoy dando uso por que no se como hacer ir, pero bueno espero que todo llegara.

2º- Lo segundo es que el PLC tiene CANopen. Te he dejado una foto para descargar. Si te interesa te puedo pasar mas informacion sobre el tema del PLC.


Cambiando de tercio....
Bueno lo que estoy haciendo con los otros son 18F2580 es intentar mandar un mensaje de uno al otro y por lo menos que se vean, que de momento no lo he conseguido. Por eso te pedí el esquema de tu placa de desarrollo para poder fabricarla y por lo menos tener claro que si no comunica es error de HW y no se SW.

Os pego aquí el código de programa muy básico a ver si alguien lo puede verificar y asegurarme que funciona correctamente y así por lo menos me podre centrar en donde tengo ahora mismo el error.
La comunicacion que pretendo mantener es que emita de momento el NODO1 y el NODO2 interprete lo que manda el NODO1



// *************** ESTO SERIA NODO1 que solo manda mensajes. El 18F2580_BASIC_CAN.hex
Código: [Seleccionar]

unsigned short init, init_send, len, aa2;
unsigned char count,  data[8];
long id;
unsigned short zr, cont, oldstate;



void main() {

// ******************** CONFIGURACION OSCILADOR INTERNO  *******************//
// Con esta configuracion no sera necesario instalar oscilador externo, de  //
// este modo ganaremos un par RA6 y RA7 I/O  pag 27 manual 18F2580          //

 OSCTUNE = 0x8F;  // OSCILADOR ineterno a maxima frecuencia 8Mhz Pag 27
 OSCCON = 0xFF;   // Pag 30
 
// ******************* CONFIGUATACION DE LOS PUERTOS        ****************//
// con el TRIS_ lo que decimos si el bit = 1 que es entrada y =0 que es salida
 TRISA = 0x00;
 ADCON0 = 0;     // con esto digo q NO uso los conversores A/D pag 247 manual
 ADCON1 = 0x0F;  // y q I/O son digitales para A,B,C pag 248 manual del 18F2580
 // OJO con la asignacion a los registros ADCON0 y ADCON1, si no la haces no
 // funcionan como entradas digitales y lospulsadores RA0...RA3 no funcionan.


 TRISB = 0X04; //Pin CAN TX lo congfiguro como digital OUT
 LATC.F2 = 0;

 //TRISB.F3 = 1; //Pin CAN RX lo congfiguro como digital INPUT
 LATB.F3 =0;





 TRISC = 0xFF;
 // La configuracion de los puertos de SALIDA se realiza mediante la sentancia
 // TRIS, pero ahora el acceso a estos puertos se realiza mediante la sentencia
 // LATX. Siendo X el nombre del puerto en cuestion. OJO ESTO ES SOLO PARA LOS
 // PUERTOS DE SALIDA OUTPUT.  (Pag 130 del manual 18F2580)
  LATA = 0;

// *******************  CONFIGURACION CAN BUS PARA 500.000 Kbs ***************//
  init = 0;
  init_send = 0;
  aa2 = 0;

  init_send =  CAN_TX_PRIORITY_0 &           // Form value to be used
          CAN_TX_XTD_FRAME &            //  with CANSendMessage
          CAN_TX_NO_RTR_FRAME;

  init =   CAN_CONFIG_SAMPLE_THRICE &    // Form value to be used
          CAN_CONFIG_PHSEG2_PRG_ON &    //  with CANInitialize
          CAN_CONFIG_STD_MSG &
          CAN_CONFIG_DBL_BUFFER_ON &
          CAN_CONFIG_VALID_XTD_MSG &
          CAN_CONFIG_LINE_FILTER_OFF;


  data[0] = 9;

  // CANInitialize(SJW, BRP, PHSEG1, PHSEG2, PROPSEG, CAN_CONFIG_FLAGS);
  CANInitialize(0,1,1,2,1,init);              // initialize CAN

  // CANSetOperationMode(mode, wait_flag);
  CANSetOperationMode(CAN_MODE_CONFIG,0xFF); // Pasamos a modo configuracion

  id = -1;   // 0xFFFFFFFFFFFFFFFF

  // Configuramos las mascaras con todo a 1, ya que id=(-1 q es lo mismo 0xfffffffffffff)
  // CAN_CONFIG_XTD_MSG se refiere a CAN extendido
  CANSetMask(CAN_MASK_B1,id,CAN_CONFIG_XTD_MSG);   // set all mask1 bits to ones
  CANSetMask(CAN_MASK_B2,id,CAN_CONFIG_XTD_MSG);   // set all mask2 bits to ones

  CANSetFilter(CAN_FILTER_B2_F3,3,CAN_CONFIG_XTD_MSG); // set id of filter B1_F1 to 3
  CANSetOperationMode(CAN_MODE_NORMAL,0xFF);       // set NORMAL mode

  LATA = 0x0;

  for(id=0; id<8;id++)
  {
   data[id]=0;
  }

  //CANWrite(id,data,1,aa1);
  count=0;
  id = 12111;
  while (1) {
    LATA.F1 = ~LATA.F1;                    //     output second byte at portA

    if(count==5)
    {
     data[0]= LATA.F0;
     CANWrite(id, data, 8, init_send);
     count=0;
     LATA.F0 = ~LATA.F0;
    }

    Delay_ms(1000);
    count++;
  }
}//~!



//************************** EL NODO 2 solo los recibe.    18F2580_ESPEJO_CAN.hex ************************////


Código: [Seleccionar]
unsigned short aa, aa1, len, aa2;
unsigned char data[8];
long id;
unsigned short zr;


void main() {

// ******************** CONFIGURACION OSCILADOR INTERNO  *******************//
// Con esta configuracion no sera necesario instalar oscilador externo, de  //
// este modo ganaremos un par RA6 y RA7 I/O  pag 27 manual 18F2580          //

 OSCTUNE = 0x8F;  // OSCILADOR ineterno a maxima frecuencia 8Mhz Pag 27
 OSCCON = 0xFF;   // Pag 30
 
// ******************* CONFIGUATACION DE LOS PUERTOS        ****************//
// con el TRIS_ lo que decimos si el bit = 1 que es entrada y =0 que es salida
 TRISA = 0x00;
 ADCON0 = 0;     // con esto digo q NO uso los conversores A/D pag 247 manual
 ADCON1 = 0x0F;  // y q I/O son digitales para A,B,C pag 248 manual del 18F2580
 // OJO con la asignacion a los registros ADCON0 y ADCON1, si no la haces no
 // funcionan como entradas digitales y lospulsadores RA0...RA3 no funcionan.


 TRISB = 0X04; //Pin CAN TX lo congfiguro como digital OUT
 LATC.F2 = 0;

 //TRISB.F3 = 1; //Pin CAN RX lo congfiguro como digital INPUT
 LATB.F3 =0;



  aa = 0;
  aa1 = 0;
  aa2 = 0;

  aa1 =  CAN_TX_PRIORITY_0 &           // Form value to be used
          CAN_TX_XTD_FRAME &            //  with CANSendMessage
          CAN_TX_NO_RTR_FRAME;

  aa =   CAN_CONFIG_SAMPLE_THRICE &    // Form value to be used
          CAN_CONFIG_PHSEG2_PRG_ON &    //  with CANInitialize
          CAN_CONFIG_STD_MSG &
          CAN_CONFIG_DBL_BUFFER_ON &
          CAN_CONFIG_VALID_XTD_MSG &
          CAN_CONFIG_LINE_FILTER_OFF;

  data[0] = 0;
  //CANInitialize(1,1,3,3,1,aa);              // initialize CAN
  CANInitialize(0,1,1,2,1,aa);              // initialize CAN
  CANSetOperationMode(CAN_MODE_CONFIG,0xFF); // set CONFIGURATION mode
  id = -1;

  CANSetMask(CAN_MASK_B1,id,CAN_CONFIG_XTD_MSG);   // set all mask1 bits to ones
  CANSetMask(CAN_MASK_B2,id,CAN_CONFIG_XTD_MSG);   // set all mask2 bits to ones

  CANSetFilter(CAN_FILTER_B2_F3,12111,CAN_CONFIG_XTD_MSG); // set id of filter B1_F1 to 3

  CANSetOperationMode(CAN_MODE_NORMAL,0xFF);       // set NORMAL mode

  //id = 3;
  LATA.F5 = 1;

  while (1) {
    zr = CANRead(&id , data , &len, &aa2);
    if ((id == 12111) && zr)
    {
      LATA.F0 = data[0];
      Delay_ms(1000);
                             // output data at portC
    }
    else
    {
     LATA.F5 = ~LATA.F5;
     Delay_ms(500);
    }

  }
}//~!


Este código es muy básico pero aun así no me funciona. Os he adjuntado directamente los ficheros .HEX por si alguien los puede probar. Aquí que ver que he configurado la velocidad del bus a 500.000 Kbs.
También fijaros en que no estoy usando cristal oscilador externo, estoy utilizando el oscilador interno del PIC que llega hasta 8Mhz.

Bueno de momento no os molesto mas con el tema....

Os agradezco el tiempo prestado y que paséis un buen día.


                       Un saludo

                                                         PERE.

PD: MGLSOFT muy bueno el esquema GRACIAS  :-/ . Remitirme si puedes el diseño de las pistas de la placa para insolar (el fotolito de las pitas) si es que lo tienes claro. GRACIAS DE NEW.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfh900 en 10 de Diciembre de 2007, 20:38:41
MGLSOFT excelente trabajo. Una pregunta: ¿podrías poner una relación de los integrados utilizados y la utilidad de cada uno de ellos, con un pequeño dibujo de su conexión al bus o circuito?. Se que es mucho pedir pero seguro que nos aclararía a todos los integrados que son necesario.

Un saludo
Título: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 22:31:35
Citar
Si es cierto ayer me te dije lo  del mcp2515, pero no se como cometí este error. Perdón   . Los que tengo que de programar son los MCP25050 y los MCP25020. Esos si que hay que programarlos, y la gente de micro chip me dice que lo puedo hacer de la placa de desarrollo es la de los MCP250xx.
Con esta y el programa que me han dado los de micro chip (que se llama MCP250xx programer version 1.1) no soy capaz de programarlos.

OK, vamos por partes, como dijo Jack... :mrgreen: :mrgreen:

Sobre los MCP250xx ya estuve escribiendo en este hilo, de todos modos te comento lo que se:
La placa desarrollo de Microchip adolece de varios problemas de hardware y software (ver detalles en el propio foro de Microchip, donde muchos hacen consultas que nadie contesta ) , tema fatal para programar un dispositivo que es OTP...
Yo mismo utilize el software de Microchip para desarrollar mi aplicación, pero al hacer el archivo .hex, primero que si no le pones a mano la extensión no lo guarda como hex, ademas calcula mal el checksum, por lo cual ese software NO SIRVE!!! :lol:

Mi solución es escribirlo con las mismas plantillas que Microchip dió en la versión 5.50 del MPLab, y que ahora no volvi a ver en las versiones mas nuevas...
Luego lo grabo a traves del ICD40 de CCS directamente a traves del conector ICSP que deje a tal fin en el Nodo D.
Saco dos jumpers y pongo el dispositivo a grabar y Voila!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 22:46:59
Citar
Lo segundo es que el PLC tiene CANopen. Te he dejado una foto para descargar. Si te interesa te puedo pasar mas informacion sobre el tema del PLC.

Je, je... :D :D
Si que tiene CANOpen!! :lol: :lol:
Menudo PLC tienes para jugar!!
Es un M340!!  te encargo si te sobra otro de esos para mi casa!! :D :D :-/ :-/

Igual estuve averiguando y el nuevo PLC Twido (creo que el modelo es Xtreme, y es antiexplosivo) tiene CAN en norma industrial...
Título: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 23:22:46
Yendo al tema que te tiene preocupado:
Creo que tienes dos problemas...

Citar
// ******************** CONFIGURACION OSCILADOR INTERNO  *******************//
// Con esta configuracion no sera necesario instalar oscilador externo, de  //
// este modo ganaremos un par RA6 y RA7 I/O  pag 27 manual 18F2580          //

 OSCTUNE = 0x8F;  // OSCILADOR ineterno a maxima frecuencia 8Mhz Pag 27
 OSCCON = 0xFF;   // Pag 30

Estas tratando de llevar el PIC a trabajar con el BUS CAN a 500 KBPS y con el oscilador interno!!
Si mal no recuerdo ese oscilador no llega ni siquiera a la precisión de un oscilador integrado!!
Encima a 8 MHz la variación del oscilador se nota mucho mas, por lo tanto, para evitar esto te propongo que coloques un cristal externo de 8 MHz y sus capacitores de 20 pF , tal como veras en los circuitos que utiliza MikroC para sus nodos CAN.
Cuando se usan osciladores de baja velocidad y una rata de velocidad del BUS alta, el protocolo CAN basa su efectividad en la capacidad de resincronizar a sus nodos a traves del bit de sincronismo, para ello se incrementa al maximo la ventana de tiempo en que se permite encontrar dicho bit, ese segmento se llama SJW.

Para la tasa que quieres lograr nunca podra ser mayor a 2.

Citar
  //CANInitialize(1,1,3,3,1,aa);              // initialize CAN
  CANInitialize(0,1,1,2,1,aa);              // initialize CAN

Aquí has cometido el pecado de retocar los valores prefijados de fábrica (léase MikroC) para configurar la velocidad del Nodo CAN, seguramente lo has hecho en tu desesperación por que funcionara, pero aunque soluciones el tema del cristal, deberas tener cuidado de ponerle a ambos nodos otra vez la configuración que tienes comentada arriba y no otra, ya que esa es la que necesitas para que el bus te funcione... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Diciembre de 2007, 23:31:17
MGLSOFT excelente trabajo. Una pregunta: ¿podrías poner una relación de los integrados utilizados y la utilidad de cada uno de ellos, con un pequeño dibujo de su conexión al bus o circuito?. Se que es mucho pedir pero seguro que nos aclararía a todos los integrados que son necesario.

Un saludo

Mira, creo que a lo largo del hilo (tal vez en forma desordenada) fui describiendo la funcionalidad de cada uno de los componentes "extraños", en cuanto a sus pines y conexión, tuve que matarme para hacer las librerias en Protel, para que cada pin tenga la descripción de sus funciones (en cada componente, incluso los micros), ademas estan las interconexiones al circuito en forma de conectores tipo buses, en realidad no se que mas ponerles para que sea bien explicito... :? :?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 11 de Diciembre de 2007, 04:04:02
Buenos días MGLSOFT!!!

Atendiendo a tus correcciones ya he cambiado el tema de los cristales de y los he puesto de 16Mhz.

Si que es cierto que retoque el código de MikroC en un interno desesperado por ver si era eso lo necesario para realizar la comunicación. Pero claro también es verdad que puse el resultado de la configuración que me proporciono el programa BIT Time Calculator. De todos modos he realizado un recalculo de los parámetros y os he adjuntado 3 reports en PDF, de varias configuraciones. 3 de ellas con 16 time quanta y una de ellas con 8 time quanta. Notar que en todas ellas le he dado preferencia o mas quantas a la PROPAGATION... ¿no se si esto es del todo correcto????

Ahora bien con estos ajustes que te da el Bit Time Calculatorl, se mas o menos donde se corresponden con la función de MikroC todos a falta de uno el "Propagation Delay" yo se lo asigno este valor al "PROSEG" ya que la llamada a la función es tal que así :

Código: [Seleccionar]
// CANInitialize(SJW, BRP, PHSEG1, PHSEG2, [b]PROPSEG[/b], CAN_CONFIG_FLAGS);

  CANInitialize(2,0,8,6,1,init);              // initialize CAN

init =   CAN_CONFIG_SAMPLE_THRICE &    // Form value to be used
          CAN_CONFIG_PHSEG2_PRG_ON &    //  with CANInitialize
          CAN_CONFIG_STD_MSG &
          CAN_CONFIG_DBL_BUFFER_ON &
          CAN_CONFIG_VALID_XTD_MSG &
          CAN_CONFIG_LINE_FILTER_OFF;

MGLSOFT como tienes el report (PDF adjunto) de la conflagración de BIT TIME CALCULATOR, y la llamada a la función "CANInitialize(2,0,8,6,1,init); ". Aconsejame si ahora lo estoy realizando bien o también estoy en algún tipo de error...

MUCHAS GRACIAS  :-/  MGLSOFT por tu ayuda......................

Un saludo

                   PERE.




Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Diciembre de 2007, 08:05:21
Buenos días MGLSOFT!!!

Atendiendo a tus correcciones ya he cambiado el tema de los cristales de y los he puesto de 16Mhz.

Si que es cierto que retoque el código de MikroC en un interno desesperado por ver si era eso lo necesario para realizar la comunicación. Pero claro también es verdad que puse el resultado de la configuración que me proporciono el programa BIT Time Calculator. De todos modos he realizado un recalculo de los parámetros y os he adjuntado 3 reports en PDF, de varias configuraciones. 3 de ellas con 16 time quanta y una de ellas con 8 time quanta. Notar que en todas ellas le he dado preferencia o mas quantas a la PROPAGATION... ¿no se si esto es del todo correcto????

Ahora bien con estos ajustes que te da el Bit Time Calculatorl, se mas o menos donde se corresponden con la función de MikroC todos a falta de uno el "Propagation Delay" yo se lo asigno este valor al "PROSEG" ya que la llamada a la función es tal que así :

Código: [Seleccionar]
// CANInitialize(SJW, BRP, PHSEG1, PHSEG2, [b]PROPSEG[/b], CAN_CONFIG_FLAGS);

  CANInitialize(2,0,8,6,1,init);              // initialize CAN

init =   CAN_CONFIG_SAMPLE_THRICE &    // Form value to be used
          CAN_CONFIG_PHSEG2_PRG_ON &    //  with CANInitialize
          CAN_CONFIG_STD_MSG &
          CAN_CONFIG_DBL_BUFFER_ON &
          CAN_CONFIG_VALID_XTD_MSG &
          CAN_CONFIG_LINE_FILTER_OFF;



A mi el Can Bit Timing Calculator me da otros valores.... :shock: :shock:
  CANInitialize(1,0,8,6,1,init);              // initialize CAN

Si ambos PICs tienen el mismo cristal y configuración (el bit de config H4 del PIC en cero), debería funcionarte, ten en cuenta de insertar al menos una resistencia de fin de línea de 120 OHMs.... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 11 de Diciembre de 2007, 08:47:13
Hola MGLSOFT!!!

En primer lugar agradecerte el que me contestes con tanta rapidez...  :-/ GRACIAS  :-/
Si que es cierto que el programa BIT Time Calculator me da otros valores, exactamente los mismo que a ti.
Mi consulta es  ¿He de poner esos valores tal como aparecen ???? o seria mas interesante el modificar los valores para que le demos prioridad a PROPAGATION... ¿¿que significa el % que aparece en el report??

Bueno de todos modos también el programa me da dos posible soluciones uno con quanta 8 y otro son quanta 16.
Con la respuesta que me das, entiendo que he de usar la configuración de quanta 16.

CANInitialize(1,0,8,6,1,init);              // initialize CAN

El bit de config H4 del PIC en cero... No entiendo lo del H4!!!

Bueno muchas gracias de nuevo por tu tiempo dedicado.

Un saludo

                      PERE.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Diciembre de 2007, 09:08:49
Vuelve a subir el ultimo programa que hagas, asi te lo reviso nuevamente, con uno de los Nodos basta...
Y si tuvieras el esquematico del circuito que utilizas, podria revisartelo a ver si veo cosas que se escapen... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 11 de Diciembre de 2007, 15:20:05
saludos, me han llegado los samples de texas de los CAN transceiver :-/ :-/ :-/

ahora a comenzar mejor con esto, tb tengo 2 de microchip, weno ahora comenzare con una placa para ellos, un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Diciembre de 2007, 15:46:11
Felicidades !!! :-/ :-/
Me alegro mucho por ver un nuevo participante activo del hilo!! :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 11 de Diciembre de 2007, 17:54:59
Buenas noches MGLSOFT!!!
Es que en España es de noche ja ja ja....

Ya he montado la nueva placa y lo único que me falta es el detalle de  que el conflagración me hablas de un "H4 a CERO".
Pero no se a que te refieres  :shock:.

Te importaría aclarármelo  :).

Muchas GRACIAS  :-/

Un saludo


                   PERE.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Diciembre de 2007, 18:22:30
Buenas noches MGLSOFT!!!
Es que en España es de noche ja ja ja....

Ya he montado la nueva placa y lo único que me falta es el detalle de  que el conflagración me hablas de un "H4 a CERO".
Pero no se a que te refieres  :shock:.

Te importaría aclarármelo  :).

Muchas GRACIAS  :-/

Un saludo


                   PERE.

Por eso te pedí que vuelvas a publicar tu codigo, para verificar si ese bit esta activo.
El problema puede ser que actives el PLL (eso hace ese fuse) y multipliques por 4 la frecuencia de entrada, en ese caso el calculo de velocidad del Nodo CAN no sirve y nunca comunicaria, se entiende ?? :mrgreen:

Algo mas puedo hacer por tí, ya que no uso el MikroC...
Publica tu esquema (en pdf, a mano alzada escaneado, etcetera) y yo te hago un codigo de pruebas para testear si no anda el hardware o que puede pasar...
Te sirve?? :lol:
Título: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 11 de Diciembre de 2007, 18:44:34
MGLSOT con mucha diferencia eres el número 1.....  :mrgreen:

1º Te mando el código  del nodo que solo realiza envíos:

NODO1 solo TX
Código: [Seleccionar]

unsigned short init, init_send, len;
unsigned char count,  data[8];
long id;
unsigned short zr;



void main() {

 
// ******************* CONFIGUATACION DE LOS PUERTOS        ****************//
// con el TRIS_ lo que decimos si el bit = 1 que es entrada y =0 que es salida
 TRISA = 0x00;
 ADCON0 = 0;     // con esto digo q NO uso los conversores A/D pag 247 manual
 ADCON1 = 0x0F;  // y q I/O son digitales para A,B,C pag 248 manual del 18F2580
 // OJO con la asignacion a los registros ADCON0 y ADCON1, si no la haces no
 // funcionan como entradas digitales y lospulsadores RA0...RA3 no funcionan.



  TRISB = 0X04; //Pin CAN TX lo congfiguro como digital OUT
 //TRISB.F3 = 1; //Pin CAN RX lo congfiguro como digital INPUT
 LATB.F3 =0;






 // La configuracion de los puertos de SALIDA se realiza mediante la sentancia
 // TRIS, pero ahora el acceso a estos puertos se realiza mediante la sentencia
 // LATX. Siendo X el nombre del puerto en cuestion. OJO ESTO ES SOLO PARA LOS
 // PUERTOS DE SALIDA OUTPUT.  (Pag 130 del manual 18F2580)


// *******************  CONFIGURACION CAN BUS PARA 500.000 Kbs ***************//

  init = 0;
  init_send = 0;

init_send =  CAN_TX_PRIORITY_0 &           // Form value to be used
          CAN_TX_XTD_FRAME &            //  with CANSendMessage
          CAN_TX_NO_RTR_FRAME;

  init =   CAN_CONFIG_SAMPLE_THRICE &    // Form value to be used
          CAN_CONFIG_PHSEG2_PRG_ON &    //  with CANInitialize
          CAN_CONFIG_STD_MSG &
          CAN_CONFIG_DBL_BUFFER_ON &
          CAN_CONFIG_VALID_XTD_MSG &
          CAN_CONFIG_LINE_FILTER_OFF;


  data[0] = 0;

  // CANInitialize(SJW, BRP, PHSEG1, PHSEG2, PROPSEG, CAN_CONFIG_FLAGS);
  CANInitialize(1,0,8,6,1,init);              // initialize CAN

  // CANSetOperationMode(mode, wait_flag);
  CANSetOperationMode(CAN_MODE_CONFIG,0xFF); // Pasamos a modo configuracion

  id = -1;   // 0xFFFFFFFFFFFFFFFF

  // Configuramos las mascaras con todo a 1, ya que id=(-1 q es lo mismo 0xfffffffffffff)
  // CAN_CONFIG_XTD_MSG se refiere a CAN extendido
  CANSetMask(CAN_MASK_B1,id,CAN_CONFIG_XTD_MSG);   // set all mask1 bits to ones
  CANSetMask(CAN_MASK_B2,id,CAN_CONFIG_XTD_MSG);   // set all mask2 bits to ones

  CANSetFilter(CAN_FILTER_B2_F3,3,CAN_CONFIG_XTD_MSG); // set id of filter B1_F1 to 3
  CANSetOperationMode(CAN_MODE_NORMAL,0xFF);       // set NORMAL mode



  for(id=0; id<8;id++)
  {
   data[id]=id;
  }

  LATA = 0;

  LATA.F3 = 1;
 
  count=0;
  id = 12111;

  while (1) {
 
    LATA.F3 = ~LATA.F3;                    //     output second byte at portA

    if(count==5)
    {
     data[0]= LATA.F0;
     CANWrite(id, data, 8, init_send);
     count=0;
     LATA.F0= ~LATA.F0;
    }

    Delay_ms(1000);
    count++;
  }
}



NODO 2 es el nodo que ha de interpretar el envio
Solo RX

Código: [Seleccionar]

unsigned short init,init_send, len, aa2;
unsigned char data[8];
long id;
unsigned short zr;


void main() {


// ******************* CONFIGUATACION DE LOS PUERTOS        ****************//
// con el TRIS_ lo que decimos si el bit = 1 que es entrada y =0 que es salida
 TRISA = 0x00;
 ADCON0 = 0;     // con esto digo q NO uso los conversores A/D pag 247 manual
 ADCON1 = 0x0F;  // y q I/O son digitales para A,B,C pag 248 manual del 18F2580
 // OJO con la asignacion a los registros ADCON0 y ADCON1, si no la haces no
 // funcionan como entradas digitales y lospulsadores RA0...RA3 no funcionan.


 TRISB = 0X04; //Pin CAN TX lo congfiguro como digital OUT
 //TRISB.F3 = 1; //Pin CAN RX lo congfiguro como digital INPUT
 LATB.F3 =0;



  init = 0;
  init_send = 0;

  init_send =  CAN_TX_PRIORITY_0 &           // Form value to be used
          CAN_TX_XTD_FRAME &            //  with CANSendMessage
          CAN_TX_NO_RTR_FRAME;

  init =   CAN_CONFIG_SAMPLE_THRICE &    // Form value to be used
          CAN_CONFIG_PHSEG2_PRG_ON &    //  with CANInitialize
          CAN_CONFIG_STD_MSG &
          CAN_CONFIG_DBL_BUFFER_ON &
          CAN_CONFIG_VALID_XTD_MSG &
          CAN_CONFIG_LINE_FILTER_OFF;

  data[0] = 0;
 
 // CANInitialize(SJW, BRP, PHSEG1, PHSEG2, PROPSEG, CAN_CONFIG_FLAGS);
  CANInitialize(1,0,8,6,1,init);              // initialize CAN
 
  CANSetOperationMode(CAN_MODE_CONFIG,0xFF); // set CONFIGURATION mode
  id = -1;

  CANSetMask(CAN_MASK_B1,id,CAN_CONFIG_XTD_MSG);   // set all mask1 bits to ones
  CANSetMask(CAN_MASK_B2,id,CAN_CONFIG_XTD_MSG);   // set all mask2 bits to ones

  CANSetFilter(CAN_FILTER_B2_F3,12111,CAN_CONFIG_XTD_MSG); // set id of filter B1_F1 to 3

  CANSetOperationMode(CAN_MODE_NORMAL,0xFF);       // set NORMAL mode

  //id = 3;

  LATA=0;
 
  LATA.F3 = 1;

  while (1) {
    zr = CANRead(&id , data , &len, &aa2);
    if ((id == 12111) && zr)
    {
      LATA.F0 = data[0];
      Delay_ms(1000);
                             // output data at portC
    }
    else
    {
     LATA.F3 = ~LATA.F3;
     Delay_ms(500);
    }

  }
}//~!



Cuando termine la noche si no he conseguido nada te remito el esquema de lo que tengo montado.

Muchas GRACIAS  :-/


Un saludo

                PERE.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Diciembre de 2007, 22:41:10
No le veo problemas, debe estar en el Hardware el problema... :? :?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Diciembre de 2007, 08:25:03
Has tenido novedades en cuanto al funcionamiento?? :shock:
Por favor relatanos tus experiencias, por malas o buenas que sean, serviran para todos, ademas para seguir con la ayuda!! :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 16 de Diciembre de 2007, 19:41:12
Buenas noches MGLSOFT!!!  :-/

Como va todo?? Espero que bien.

Bueno hoy he terminado mi segundo diseño del HW del entrenador para CAN BUS con PIC18F2580 (ya que el anterior me esta dando muchos problemas para comunicar). Lo he adjuntado todo en PDF (listo para su impresión y posterior insolación).

El archivo adjunto contiene 4 ficheros PDF:
1- Esquema eléctrico.
2- Placa de circuito impreso con los componentes.
3- Placa circuito impreso por el lado de las pistas.
4- Placa con pistas y componentes todo junto.

Os agradecería que si observáis algún tipo de anomalía me lo comunicaseis.

Espero que le sea de ayuda a todos aquellos que se inician en la materia.

Disfrutarlo.

Un saludo

                    PERE.
PD: Si crees que se puede mejorar comunicarmelo y lo haré. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Diciembre de 2007, 21:29:02
Pierno:

Es posible que tu error este tambien en tu anterior desarrollo.
Aunque solo mire el circuito, ya encontre que cruzas las lineas de TX y RX entre el PIC y el MCP2551...
Asi nunca va a funcionarte, definitivamente no creo que sea de codigo tu problema, es de circuito!!

El pedazo de esquema:
(http://img155.imageshack.us/img155/3851/errorpiernonv6.jpg)

En el dibujo explico lo que esta mal... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 17 de Diciembre de 2007, 04:16:50
Buenos días MGLSOFT!!!

MUCHAS GRACIAS POR TU CORRECCIÓN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  :-/  :-/

Estos son los detalles que hacen que uno se quede en la estacada durante varios días.
Nunca me canso de de decirlo, pero te lo repito de nuevo ¡¡¡¡¡¡¡¡¡¡¡¡ GRACIAS!!!!!!!!!!!!.

He realizado la corrección pertinente a todos los niveles circuito eléctrico, y placa lado pistas.

Contenido del ZIP ( Ya con la corrección pertinente).

El archivo adjunto contiene 5 ficheros PDF:
1- Esquema eléctrico.
2- Placa de circuito impreso con los componentes.
3- Placa circuito impreso por el lado de las pistas.
4- Placa con pistas y componentes todo junto.
5- Puntes conexión en la parte inferior de la placa.

Todo el error me viene de esta explicación de la ayuda de mickroC. Os adjunto el GIF con ese esquema erróneo.

Un saludo

                    PERE.

PD: Si crees que se puede mejorar comunicarmelo y lo haré.  :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 17 de Diciembre de 2007, 08:26:47
Te propongo lo siguiente, asi no pierdes tiempo y esfuerzos en el nuevo circuito...
Hazle el cambio a dos de los nodos de la placa que no te funciona...
Prueba tu codigo alli, hasta que no estes seguro que funciona, no hagas tu nueva placa...

Esto ya lo pase, hay informacion bastante confusa en la web al respecto de como conectar estos componentes, pero yo me guié con los circuitos de Microchip de sus placas para CAN !!! :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 17 de Diciembre de 2007, 11:20:24
Buenas tardes MGLSOFT  :-/ !!!

Ok por lo de proposición, pero ahora ya las tengo insoladas y atacadas. He terminado ahora mismo.
Solo me falta taladrar y montar los componentes que si no pasa nada lo haré a lo largo de la tarde.
Esta noche colgare los resultados y comentare como ha ido la cosa.

GRACIAS por el apoyo que me estas prestando. Seguro que con este seguimiento tan preciso no puedo fracasar  :mrgreen: .

Un saludo
                     PERE.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 17 de Diciembre de 2007, 11:27:58
Bueno, bueno!! :D :D
Veo que es mas rapido el hecho que el pensamiento allí !! :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 18 de Diciembre de 2007, 04:10:58
Buenos días MGLSOFT!!!

Encestaría (si lo tienes o donde lo puedo bajar)  un SNIFFER (o analizador de paquetes) de red CANBUS.

Me explico. Ahora para saber que tipo de paquete estoy transmitiendo necesito un circuito que este escuchando todo los paquetes que pasan por el bus.
Si sabes de algún circuito y el SW que se requiera???? comunicarmelo.

Un saludo


                    PERE.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Diciembre de 2007, 07:53:11
Esto significa lo que imagino?? :shock: :shock:
Anda tu placa ahora?? :lol: :lol:

Yo uso el software CanKing, si miras el resto del hilo veras que hablo del mismo.
Viene con los discos de las placas desarrollo de Microchip, y puedes bajarlo de su pagina WEB... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Diciembre de 2007, 21:30:24
Aun no respondes?? :shock: :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 20 de Diciembre de 2007, 18:46:24
Buenas noches MGLSOFT!!!!

Ya estoy x aki de nuew....

Me esta volviendo loco el tema del CAN BUS  :5].

Ahora ya mando cosas pero lo mejor de todo es que tengo 2 SNIFFERs, uno de USB y otro de puerto paralelo y ambos entienden el mismo mensaje. Pero lo mejor de todo es que yo no estoy mandando este mensaje :shock: . Mando un mensaje y el SNIFFER (CANKING) lo detecta. Pero yo mando un mensaje de pruebas muy simple y el detecta otra cosa. Lo he intentado a varias velocidades y las respuesta siempre es la misma.
Conclusión el error lo estoy cometiendo al crear el mensaje... VAMOS digo yo.

Imagina si estoy desesperado que ya estoy programando en CCS.

Ahora te dejo aki un poco de código en CCS para ver si me lo corriges para que solo mande un par de mensajes cuando inicie el PIC a 50Kbs, 125Kbs y 250Kbs.

Ya no se si cambiar de plataforma y pasarme SILABS  :? .

Espero tu ayuda como de costumbre y ya me comentas.

Te recuerdo que el micro que utilizo es 18F2580.

Un saludo


                     PERE.

Te adjunto un PDF de lo tengo para realizar el desarrollo.

Aquí te dejo el código este a ver si lo ves OK. Si no te agradecería las correcciones o que me generases un archivo de CCS que mandase un mennsaje y ya lo compilo yo.

Código: [Seleccionar]
#include "C:\Documents and Settings\Administrador\Escritorio\kk\main2.h"

#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, stream=outstream)
#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>

void main()
{

    int32 can_id;
    int can_data[8],i;
    int can_length, counter;
    struct rx_stat rxstat;

 


   setup_adc_ports(NO_ANALOGS|VSS_VDD);
   setup_adc(ADC_OFF|ADC_TAD_MUL_0);
   setup_spi(SPI_SS_DISABLED);
   setup_wdt(WDT_OFF);
   setup_timer_0(RTCC_INTERNAL);
   setup_timer_1(T1_DISABLED);
   setup_timer_2(T2_DISABLED,0,1);
   setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
   setup_vref(FALSE);
//Setup_Oscillator parameter not selected from Intr Oscillotar Config tab

   // TODO: USER CODE!!
   
   

 can_init();
   

   can_set_mode(CAN_OP_CONFIG);


// configuracion 50kbs q=8 62.5% oscilador 16MHZ
   BRGCON1=0x53;
   BRGCON2=0x90;
   BRGCON3=0x02;
   
   /*
   // configuracion 125kbs q=8 62.5% oscilador 16MHZ
   BRGCON1=0x07;
   BRGCON2=0x90;
   BRGCON3=0x02;
   */
   /*
   // configuracion 250kbs q=8 62.5% oscilador 16MHZ
   BRGCON1=0x03;
   BRGCON2=0x90;
   BRGCON3=0x02;
   */
   
   
   

   can_set_mode(CAN_OP_NORMAL);
   
counter = 0;
puts("Starting");

can_data[0] = 0x55;
can_data[1] = 0x99;


delay_ms(10000);
if(can_putd(0x111, can_data, 2, 3, 0,0))
 {
   puts("tx ok");
   delay_ms(10000);
 }
 
 
can_data[0] = 0x66;
can_data[1] = 0x47;

if(can_putd(0x222, can_data, 2, 0, 0, 0))
 {
   puts("tx ok");
   delay_ms(10000);
 }
 
 if ( can_tbe())
        {
          can_data[0] = 0x45;
          can_data[1] = 0x36;

          if (can_putd(0x123, can_data, 2,3,0,0)) { //success, a transmit buffer was open
            fprintf(outstream,"OKOK ");
            for (i=0;i<2;i++) {
               fprintf(outstream,"%X ",can_data[i]);
            }
            fprintf(outstream,"\r\n");
          }
          else { //fail, no transmit buffer was open
            fprintf(outstream,"\r\nFAIL on PUTD\r\n");
          }
          }


}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Diciembre de 2007, 08:06:56
Ante todo felicitaciones porque ye estas "hablando" en el BUS CAN, que no es poco... :mrgreen: :mrgreen:

Otra felicitacion y mi envidia (sana) por lo que hay en tu mesa de trabajo, pavadas de herramientas tienes!!! :lol: :lol:

Respecto al codigo, salvo algunos nudos que te has hecho, y espero tengas un poco mas de paciencia.
Quiero pedirte que pongas aqui que mensajes recibes en los sniffers, para saber cual de tus mensajes y porque los recibes...

En los sniffers, como tienes puesta la configuracion de todos los parametros del BUS CAN ???

Ponme esas respuestas y seguimos, asi puedo ayudarte sin tratar de adivinar, que es una ciencia oculta que no manejo... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 21 de Diciembre de 2007, 11:11:49
Buenas tardes MGLSOFT!!!

En primer lugar agradecer tu interés y ganas de ayudar al projimo.....

En segundo lugar en estas fechas tan especiales desearte lo mejor para los tuyos y que pases unas felices navidades y prospero año nuevo.

Y ahora pasemos a la materia.

Los mensajes que estoy enviando son 3. Si te fijas en el código que te mando (compilado en CCS) veras que solo se ejecuta una sola vez, ya que no le he puesto WHILE(1). Pero claro cada vez que yo reseteo el pic se ejecuta de nuevo, ese el modo que he elegido para controlar los mensajes que estoy mandando.

Código: [Seleccionar]

#include "C:\Documents and Settings\Administrador\Escritorio\kk\main2.h"

#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, stream=outstream)
#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>

void main()
{

    int32 can_id;
    int can_data[8],i;
    int can_length, counter;
    struct rx_stat rxstat;

 


   setup_adc_ports(NO_ANALOGS|VSS_VDD);
   setup_adc(ADC_OFF|ADC_TAD_MUL_0);
   setup_spi(SPI_SS_DISABLED);
   setup_wdt(WDT_OFF);
   setup_timer_0(RTCC_INTERNAL);
   setup_timer_1(T1_DISABLED);
   setup_timer_2(T2_DISABLED,0,1);
   setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
   setup_vref(FALSE);
//Setup_Oscillator parameter not selected from Intr Oscillotar Config tab

   // TODO: USER CODE!!
   
   

 can_init();
   

   can_set_mode(CAN_OP_CONFIG);


// configuracion 50kbs q=8 62.5% oscilador 16MHZ
/*
   BRGCON1=0x53;
   BRGCON2=0x90;
   BRGCON3=0x02;
   */
   
   // configuracion 125kbs q=8 62.5% oscilador 16MHZ
   BRGCON1=0x07;
   BRGCON2=0x90;
   BRGCON3=0x02;
   
   /*
   // configuracion 250kbs q=8 62.5% oscilador 16MHZ
   BRGCON1=0x03;
   BRGCON2=0x90;
   BRGCON3=0x02;
   */
   
   
   

   can_set_mode(CAN_OP_NORMAL);
   
counter = 0;
puts("Starting");

can_data[0] = 0x55;
can_data[1] = 0x99;


delay_ms(10000);
if(can_putd(0x111, can_data, 2, 3, 0,0))
 {
   puts("tx ok");
   delay_ms(10000);
 }
 
 
can_data[0] = 0x66;
can_data[1] = 0x47;

if(can_putd(0x222, can_data, 2, 0, 0, 0))
 {
   puts("tx ok");
   delay_ms(10000);
 }
 
 if ( can_tbe())
        {
          can_data[0] = 0x45;
          can_data[1] = 0x36;

          if (can_putd(0x123, can_data, 2,3,0,0)) { //success, a transmit buffer was open
            fprintf(outstream,"OKOK ");
            for (i=0;i<2;i++) {
               fprintf(outstream,"%X ",can_data[i]);
            }
            fprintf(outstream,"\r\n");
          }
          else { //fail, no transmit buffer was open
            fprintf(outstream,"\r\nFAIL on PUTD\r\n");
          }
          }


}



Cada uno de los mensajes  tiene un identificador diferente para diferenciarlos, y además están en CAN ID Standar (no extendido). Aun así lo que ven los sniffer es lo que te he adjuntado en el PDF. Veras que hay 2  cuadros de color rojo, uno corresponde como bien sabes al CANKING (de la tarjeta de desarrollo de MICROCHIP para MCP25050) y el otro a un Sniffer que me han dejado que es USB (mas sencillo).
Los 2 en el caso de las capturas están configurados a 125kbs, aunque a 50kbs hacen exactamente lo mismo. Cuando cambio la velocidad evidentemente también recompilo el PIC y configuro los registros a lo que corresponda.

Código: [Seleccionar]
// conflagración 50kbs q=8 62.5% oscilador 16MHZ
/*
   BRGCON1=0x53;
   BRGCON2=0x90;
   BRGCON3=0x02;
   */
   
   // conflagración 125kbs q=8 62.5% oscilador 16MHZ
   BRGCON1=0x07;
   BRGCON2=0x90;
   BRGCON3=0x02;
   
   /*
   // conflagración 250kbs q=8 62.5% oscilador 16MHZ
   BRGCON1=0x03;
   BRGCON2=0x90;
   BRGCON3=0x02;


La pregunta del millón es ¿¿que es lo que estoy mandando que ambos casos están viendo lo mismo???
Lo mando mal esta claro pero que me esta fallando???
Solo se trata de lo  mas básico mandar un mensaje de CAN y aun no he sido capaz....


Un saldudo y MUCHAS GRACIAS..... :-)

                   PERE.

PD: Lo único que necesito ahora es un código lo más simple posible que mande un mensaje CAN y al leerlo con el Sniffer se corresponda. No pido más de momento...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Diciembre de 2007, 11:47:05
Ok, es indudable que tu software esta haciendo algo mal, porque los ID no coinciden con los que envias... :mrgreen: :mrgreen:

Para que avances coincido contigo, te hago un ejemplo y lo haces funcionar en tu placa, pero necesito el archivo de encabezados que tu programa menciona :

Citar
#include "C:\Documents and Settings\Administrador\Escritorio\kk\main2.h"

Podras pasarmelo por privado??
O postearlo aqui mismo?? :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 21 de Diciembre de 2007, 12:18:12
Buenas tardes MGLSOFT!!

Aquí te remito lo que me estas pidiendo....

Muchas gracias de nuevo  :-/


Un saludo

                   PERE.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Diciembre de 2007, 16:55:53
Que version de CCS utilizas??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Diciembre de 2007, 22:16:14
Creo que lo que tienes es solamente una contradiccion, la rutina Can_Init(), selecciona el Can extendido, mientras en cada mensaje tu intentas enviarlo en Can estandar.

Prueba cambiando:
Citar
(can_putd(0x111, can_data, 2, 3, 0,0))

por

Citar
(can_putd(0x111, can_data, 2, 3, 1,0))

a ver si ese mensaje es bien leido, luego vemos si lo que digo es real o no, te parece??

El programa compilo bien en mi maquina, pero no tengo un 2580 para probarlo en la practica... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 22 de Diciembre de 2007, 12:32:36
Buenas tardes MGLSOFT!!!
He realizado el cambio que me has propuesto pero sigue saliendo exactamente lo mismo.....  :shock:
Es muy curioso ya que como has visto el Sniffer entiende que se trata de una trama extendida tanto si la mando STANDAR como si no.
Que mas podemos hacer para ver que sucede???
Alguna sugerencia????  :-/

Seguimos en contacto.


Un saludo


                       PERE.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Diciembre de 2007, 06:40:31
Lo unico que se me ocurre entonces es que hagas al revés, que utilizes la trama extendida , en vez de la standard, porque el Canking ya vi que no tiene pestaña alguna donde seleccionar trabajar con trama estandar.

Vuelve a poner el 1 en cada Can_putd() y cambia esto:

Citar
#define CAN_USE_EXTENDED_ID FALSE

por esto:

Citar
#define CAN_USE_EXTENDED_ID TRUE
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 28 de Diciembre de 2007, 03:38:22
Buenos días MGLSOFT!!!!

Esto sigue sin ir y yo soy un tío muy empeñado...  Por lo tanto no pienso rendirme.

El correo de hoy es ya el de vamos a sincronizarnos para dar solución al asunto.

Te propongo una cosa, como no se si el HW mio funciona correctamente y tu tarjeta de desarrollo parece que si lo va a soportar, te planteo lo siguiente:

- Manda un privado con tu dirección personal (la de tu casa por ejemplo), y cuando la tenga te remito un par de PIC 18F2580. Así tendré una referencia segura y fiable del porque esto no funciona. ¿¿¿Vamos si no te importa???

Espero tu respuesta



Un saludo

                  PERE.

PD: Gracias por tu atención y apoyo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Diciembre de 2007, 10:40:51
OK, pasate por tu casilla Hotmail...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 30 de Diciembre de 2007, 16:03:08
hola

me alegro de este hilo, que lo intento seguir con entusiasmo aunque ultimamente no dispongo de mucho tiempo libre, creo haber leido en los ultimos posts (lei por encima) algo de un sniffer, yo me veo en la necesidad de diseñar un pequeño sniffer apra capturar unas tramas CAN de un dispositivo que tengo, para luego con otro hardware que diseñe procesar esas tramas. ¿Alguien tiene hecho el sniffer? Me suena que lei por encima que Marcos lo tenia, pero es que ando muy mal de tiempo y no peudo revisarme todo el hilo  :(

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Diciembre de 2007, 07:12:26
El que tiene un sniffer por hardware es Pierno10 !!

Citar
Contexto del taller.pdf (201.23 KB - descargado 5 veces.)

Lo conminamos a traves del foro a que intente copiarlo y ponernos el esquema (salvo que tenga un micro y programa que no se puede copiar).... :-/ :-/ :-/
Título: Mis experiencias con el BUS CAN - Pruebas PERE
Publicado por: MGLSOFT en 11 de Enero de 2008, 08:57:19
Buenos días MGLSOFT!!!!

Esto sigue sin ir y yo soy un tío muy empeñado...  Por lo tanto no pienso rendirme.

El correo de hoy es ya el de vamos a sincronizarnos para dar solución al asunto.

Te propongo una cosa, como no se si el HW mio funciona correctamente y tu tarjeta de desarrollo parece que si lo va a soportar, te planteo lo siguiente:

- Manda un privado con tu dirección personal (la de tu casa por ejemplo), y cuando la tenga te remito un par de PIC 18F2580. Así tendré una referencia segura y fiable del porque esto no funciona. ¿¿¿Vamos si no te importa???

Espero tu respuesta



Un saludo

                  PERE.

PD: Gracias por tu atención y apoyo.

OK, fué recibido el dia de ayer y ya tengo parte de los resultados...
Probé uno de tus PICs en reemplazo del Nodo B de mi placa.
Acomode el software para usar el módulo can propio del micro, y los resultados son excelentes!!!
Anda perfectamente!!
Aún me falta hacer lo propio con el otro (aqui ya tengo mas trabajo, porque no podre utilizar la pantalla LCD), pero dame unos días mas para hacerlo.
Por último una vez hayan sido probados ambos y funcionen, pondré a funcionar tu software a ver si es por alli el problema...

Así están las cosas, creo que vamos bien hasta ahora, tenme paciencia... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 21 de Enero de 2008, 05:09:52
Buenos días MGLSOFT y compañía!!!   :-/

He decidido poner de nuevo el entrenador de CANBUS ya con todas las correcciones y testeado.
Funciona de lujo a todas las velocidades, incluso a 1Mbs sin problemas con 15 mts de cable.
Yo ahora mismo lo estoy usando a 250Kbs y 235 mts de cable y sin ningún tipo de problema.

HW Entrenador
El archivo adjunto contiene 4 ficheros PDF:
1- Esquema eléctrico.
2- Placa de circuito impreso con los componentes.
3- Placa circuito impreso por el lado de las pistas.
4- Placa con pistas y componentes todos juntos.

SW Entrenador
1- Os he adjuntado proyectos de MikroC ya compilados y con todos los archivos. Están testeados y funciona OK.

Espero que os sea de gran ayuda para todos aquellos que os inicias en el mundo CAN BUS.

Os agradecería que si observáis algún tipo de mejora, me lo comunicaseis.


Disfrutarlo.

Un saludo

                    PERE.

PD: MGLSOFT tu y yo seguimos trabajando a fondo.... estamos en contacto.  :-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Enero de 2008, 08:30:41
Podras poner el esquema del sniffer??
Esta muy bueno al parecer!!
Con que soft analizas los recibido del sniffer?? :mrgreen:
Título: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 21 de Enero de 2008, 15:55:39
Buenas tardes MGLSOFT!!!   :mrgreen:

El analizador que utilizo es solo el puerto RS-232 (si la velocidad es baja, como el caso de 125Kbs configurar a  115200). Lo veo directamente con la consola que trae el entrono de desarrollo de MIKROC. También se puede utilizar el hiperterminal.

Ahora mismo el sniffer lo hago funcionar con la placa de desarrollo de MIKROC, la que viste en las fotos de mi mesa de trabajo. Pero esta semana terminare el diseño de una que lo tendrá todo y con un MAX233 para quitar componentes y que quede la cosa mas pequeña. Os la remitiré a lo largo de la semana.
También estoy trabajando en otra en SMD con el 18F4580 y 18F2580 que estoy a la espera de material. Esta se prototipo definitivo para el tema de la domotización de la casa ya que el tamaño en este caso ya es muy importante....

Os daré nuevas proximamente...  Seguramente mañana o pasado. OK!!!   :-/

Un saludo


                   PERE.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Enero de 2008, 16:01:28
Vas como el viento!!
Lograre ponerme a la par tuya?? :shock:
Título: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 22 de Enero de 2008, 14:21:40
Buenas tardes MGLSOFT!!!!

Lo prometido es deuda.... aquí os dejo los esquemas de y los fotolitos para creación de las placas de CI. CUIDADO!!! Se trata de una placa a 2 caras.

Lo de siempre, si alguien piensa que se puede mejorar que me remita la modificación y la realizare de buen gusto.

HW NODO CANBUS + Sniffer CANBUS (RS-232)
Sniffer CANBUS.rar (contiene)

El archivo adjunto contiene 4 ficheros PDF:
1- Esquema eléctrico.
2- Placa de circuito impreso con los componentes.
3- Placa circuito impreso por el lado de las pistas.
4- Placa circuito impreso por el lado de los componentes.

Un saludo a todos

                  PERE.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Enero de 2008, 16:03:02
También estoy trabajando en otra en SMD con el 18F4580 y 18F2580 que estoy a la espera de material. Esta se prototipo definitivo para el tema de la domotización de la casa ya que el tamaño en este caso ya es muy importante....

Pasame el esquematico de ese prototipo, y te ayudo a revisarlo, te comento por privado luego mi opinion o consultas, asi lo tienes revisado antes de armarlo... :mrgreen:
Título: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 24 de Enero de 2008, 08:24:47
Buenos días MGLSOFT!!!!!!!

Ok así será... Te lo remito en cuanto lo tenga ya todo mas o menos claro así lo revisas tu a ver si hay algo que no te cuadre o creas que se puede mejorar....
La idea es que la placa de SMD tenga fuente de alimentación integrada de 5Vcc para poder mandar por el cable de CAT-5 UTP la señal de CANBUS en uno de los pares, en otro de los pares una alimentación de 12Vcc ya que en función de los metros que extendamos a lo largo de la casa la tensión ira decreciendo y esto afecta al funcionamiento correcto del micro (esto ya esta testeado y funciona OK).
Como podrás apreciar he puesto un par de bornes que en realidad no están conectadas a ningún tipo de pista, pero que nos servirán para hacer una conexión del bus tipo estrella permitiendo el ahorro de cable en la instalación(esto te lo explicare mas detenidamente con fotos para que veas la utilidad).

Bueno espero tener en breve el fotolito para poder realizar las primeras placas PROTOTIPOS con las que sacaremos las primeras conclusiones....

Os deseo un buen día a todos....


             PERE.
PD: MGLSOFT te he dejado en tu correo... nos vemos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 24 de Enero de 2008, 08:29:25
Pierno, me interesa muchíiiiiisimo eso de la topología estrella en el bus CAN. ¿Podrías dar algún pequeño detalle más?

Gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Enero de 2008, 09:24:28
El BUS CAN puede adoptar una topologia estrella, mientras sus ramas no superen los seis metros de longitud desde el punto del BUS principal.
Esto es utilizado en redes industriales como DeviceNet y CanOpen.... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 24 de Enero de 2008, 12:01:52
Buenos días!!!

Vamos por partes....
El esquema de conexionado que yo estoy proponiendo no es una topología en estrella desde el punto de vista físico. Ya que en todo momento lo que utilizamos en una topología en BUS.
Pero a nivel óptico esquemático o queramos llamarlo, se puede entender como una topología en estrella. Ya que nos permite conectar los nodos entre ellos con solo un cable (de 4 pares UTP).

El tema es siguiente:
1- Partimos de una instalación con cable UTP (CAT-5 en mi caso)
2- El segundo de los pares del cable UTP es el que uso para CANBUS (para el bus IDA ->) PAR (Naranja, Naranja_Blanco) PAR1
3- Para el tema de alimentacion de BUSCAN (12Vcc ya que la placa CI ya tiene 7805 para reducir la tension a 5Vcc) utilizo uno d3 los 4 pares que tiene el cable UTP PAR (Marrón, Marrón_Blanco) PAR2
4- Si observamos a cada nodo llega cable UTP con 4 pares que tiene libres 2 pares (Azul,Azul_Blanco) y (Verde,Verde_Blanco).
5- CANBUS (para el bus VUELTA ->) PAR (Verde,Verde_Blanco) PAR3 



Conexionado:

En el caso que estoy desarrollando ahora he puesto 2 pares de bornas (4 bornas en total) de circuito impreso (CI), que no tienen ningún tipo de pista conectada. Son conexiones auxiliares que en realidad no influyen ni interfieren en el funcionamiento de la placa de CI.

Ahora que mas o menos conocemos el contexto de la situación, os mostrare un ejemplo de como conectar 5 nodos en el cual uno de ellos que es el que tienes 2 pares de bornas AUX (no conectadas a ningun sitio) hace las labores desde el punto de vista físico de HUB de CAN.

Os adjunto un esquema a mano alzada, ahora mismo estoy en el trabajo y no dispongo de autocad. Os lo pasa a autocad si alguno no lo entiende tal cual.

Un saludo para todos....   :-) ESPERO QUE OS SEA DE AYUDA  :-) .

                     PERE.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 24 de Enero de 2008, 12:09:23
Está clarísimo, pierno. Muchas gracias.

No te había entendido bien, pensaba que ibas a utilizar una topología en estrella para el bus y no sabía que esto era posible.

En realidad utilizas una topología geográfica de estrella, pero con topología de datos tipo bus.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Enero de 2008, 12:19:11
Es correcto, de todos modos los nodos pueden ser colgados del bus con hasta 6 metros de cable sin cables de retorno...

Lo dificil en ese tipo de instalacion es determinar donde van los resistores de fin de linea, que deben ir colocados en los dos extremos mas alejados del BUS... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 26 de Enero de 2008, 19:56:41
Hola a todos:

Bueno es mi primer post, y me he topado con este foro y he quedado perplejo con la calidad de este, he visto bastante foros, pero pocos como este y el tema CAN que me ha encantado desde hace algunos meses y buscando informacion al respecto he encontado este foro, mis felicitaciones a todos por sus aportes y comentarios que han dejado en muy buen pie este foro.

Bueno paso a presentarme, soy desarrollador con uC y uP, desde hace mucho (24 annos..  uff bastante), trabajo exclusivamente con Unix desde hace mas o menos 8 o 10 annos, desarrollo sobre MCS51 y AVR normalmente, nada sobre PIC, pero son temas afines, y llegue a este foro porque estoy trabajando en un proyecto con CAN, usando el AVR ATmega8 + MCP2515 + PCA82C250. Lo cual hace de este comentario bastante atingente al tema.

Leyendolo atentamente, de hecho desde algunas horas sin siquiera detenerme, he entendido algunas oscuridades que tenia con el MCP2515 y el seteo de velocidad, cosa que era un completo misterio de antes de leer, pero ahora ya a quedado claro.

Por el momento queria presentarle mis respectos a todos y a este gran tema y a su autor. Queda bastante por desarrollar aun y mis temas de interes son el del "sniffer_can" y en entender un poco mas el uso del MCP2515 desde el punto de vista de su programacion.

Valgan mis felicitaciones a todos y estare atento a ver si despues meto mi cuchara y les cuento en lo que estoy.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Enero de 2008, 20:07:30
Bienvenido al foro Electrolinux !!

Me alegra mucho que el tema te sirva, esa es la idea !!
Como a vos te ha pasado, no hay mucha información en Español acerca del BUS CAN, por eso abrí este tema, para que nos ayudemos entre todos.

Sera bienvenida tu experiencia con los AVR, sientete en libertad de postear aquí tus avances y dudas, y todos aprenderemos juntos mientras nos ayudamos mutuamente.

Te recomiendo leer las reglas del foro, así tu comportamiento dentro del mismo será acorde a ellas...
Nuevamente te deseo una larga estadía dentro de este foro maravilloso.

MGLSOFT :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 26 de Enero de 2008, 20:18:44
> Bienvenido al foro Electrolinux !!

Muchas gracias por tu acogida :-)

> Me alegra mucho que el tema te sirva, esa es la idea !!
> Como a vos te ha pasado, no hay mucha información en Español acerca del BUS CAN, por eso abrí este tema, para que nos
> ayudemos entre todos.

Ciertamente... es por eso de tanto buscar y bajar info, he caido aqui... :-) de lo cual me alegra.

> Sera bienvenida tu experiencia con los AVR, sientete en libertad de postear aquí tus avances y dudas, y todos
> aprenderemos juntos mientras nos ayudamos mutuamente.

Por supuesto que si ... podemos aportar a que todos aprendamos y esa es la fortaleza del foro y del software libre.

> Te recomiendo leer las reglas del foro, así tu comportamiento dentro del mismo será acorde a ellas...

No creo que sean muy distintas a varias de los foros que ya estoy, tengo experiencia en ellos y como principioo debe prevalecer el respeto entre las personas y la libre opinion.

> Nuevamente te deseo una larga estadía dentro de este foro maravilloso.

Muchas gracias por tus palabras.

MGLSOFT :mrgreen:

Saludos nuevamente a todos
Título: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 28 de Enero de 2008, 05:46:51
Buenos días compañeros del foro!!!  :mrgreen:

Como os comente la semana pasada, he estado trabajando en una placa con 18F4580 en SMD con CANBUS y 3 PORT de E/S.
Aquí os dejo la documentación para que le echéis un vistazo y me comentáis cualquier tipo de error o anomalía.

MGLSOFT ya comentamos....espero vuestras aportaciones y correcciones  :-/

Un saludo

                          PERE.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 28 de Enero de 2008, 05:54:20
Hola pierno, os sigo muy atentamente porque yo también estoy ideando un sistema domótico basado en CAN.

Sin apartarnos mucho del tema del hilo, ¿podrías contarnos que dispositivos actuadores/sensores vas a utilizar? Vas a usar módulos comerciales, o piensas desarrollarte tus propios actuadores, dimmers, sensores de temperatura, ...

Muy chula la placa smd
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 12:24:53
Estimados amigos:

Bueno cuento un poco lo que estoy desarrollando, es una placa que tiene un AVR-ATmega16 y otra con en ATmega8, ambas trabajando (o intentando trabajar) con el MCP2515 y el PCA82C250, aun estoy en la etapa de desarrollo del codigo. Adjunto una foto de la PCB.

Ambos uC-AVR los programa en lenguaje 'C' con el compiolador AVR-GCC-4.1.0, trabajo habitualmente sobre maquinas Unix (Debian, FreeBSD) y todo lo hago desde este S.O., desde el diseNo del esquematico hasta el PCB, la programacion y su grabacion en la Flash del Microcontrolador. Les dejo este link para que lean un articulo que publica respecto de este tema (http://www.eldemonio.org/documentos/020507184907.html).

Los pasos que he seguido en el codigo son los siguiente:
(1) Inicializacion de la interfaz SPI del controlador.
(2) Funciones de acceso a los registros del MCP2515 de read y write.
(3) Funciones de imprimir los registros del MCP2515 para debug a la puerta serial del AVR.
(4) Inicializacion del MCP2515.

Lo que me queda es ahora trabajar en las rutinas de envio y recepcionar mensajes desde el MCP2515. Tengo un primer hacercamiento que aun no me ha funcionado.

Bueno eso por el momento, si alguien tiene algunas rutinas de envio y recepcion de mensajes que pudiese compartir, serial genial poder verlas, aunque haya que cambiarlas, pero al menos ya es una idea de como tomar el desarrollo.

Saludos a todos.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 13:07:56
Alguien prodria indicar como subir las fotos a este foro... he tratado pero con el icono "insertar imagen" cuando uno responde, no se en donde poner el archivo de imagen ya que la imagen me imagino que debe ser "subida" antes...

Saludos a todos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 28 de Enero de 2008, 13:15:40
Para electrolinux: http://www.todopic.com.ar/foros/index.php?topic=8120.0
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 13:33:27
Gracias por tu respuesta, aqui subire mis primeras imagenes de las PCB.

http://www.flickr.com/photos/electrolinux/2225418875/ (http://www.flickr.com/photos/electrolinux/2225418875/)
http://www.flickr.com/photos/electrolinux/2226209804/ (http://www.flickr.com/photos/electrolinux/2226209804/)
http://www.flickr.com/photos/electrolinux/2226210018/ (http://www.flickr.com/photos/electrolinux/2226210018/)
http://www.flickr.com/photos/electrolinux/2226209900/ (http://www.flickr.com/photos/electrolinux/2226209900/)

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 14:09:59
Prototipos e imagenes de la PCB armada y terminada.

(http://img183.imageshack.us/img183/5513/pcbcanatmega1606gn3.jpg)
(http://img169.imageshack.us/img169/2598/pcbcanatmega1603ou5.jpg)
(http://img169.imageshack.us/img169/1710/pcbcanatmega803gw7.jpg)
(http://img144.imageshack.us/img144/2535/pcbcanatmega802ni6.jpg)

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Enero de 2008, 17:59:26
Buenos días compañeros del foro!!!  :mrgreen:

Como os comente la semana pasada, he estado trabajando en una placa con 18F4580 en SMD con CANBUS y 3 PORT de E/S.
Aquí os dejo la documentación para que le echéis un vistazo y me comentáis cualquier tipo de error o anomalía.

MGLSOFT ya comentamos....espero vuestras aportaciones y correcciones  :-/

Un saludo

                          PERE.


Bueno, si de corregir se trata!! :) :)

Creo que tiene razon Jfmateos, ya la placa deberia tener incluidas las entradas y salidas con sus interfases, ya que es muy dificil usar cables planos para conectarlas a otras plaquitas sin sufrir los efectos de la EMI (ruidos electricos).
Para ello lo mejor es sentarse a charlar acerca de las interfases necesarias segun las necesidades de funcionalidad de cada Nodo.

Tal vez me apresuro y aun no es el diseño definitivo...

Lo bueno: mejoraste la fuente, suavizando el ripple con el capacitor de 22 uf, eso ayudara en el futuro, seguramente.

Lo que no entiendo: porque si llevas la placa a smd no cambias el MCP2551 a smd tambien?? Hoy queda tan grande como el micro, y no veo el espacio como para montarlo en zocalo, que permitiria extraerlo si se frita...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Enero de 2008, 18:18:13
Estimados amigos:

Bueno cuento un poco lo que estoy desarrollando, es una placa que tiene un AVR-ATmega16 y otra con en ATmega8, ambas trabajando (o intentando trabajar) con el MCP2515 y el PCA82C250, aun estoy en la etapa de desarrollo del codigo. Adjunto una foto de la PCB.

Ambos uC-AVR los programa en lenguaje 'C' con el compiolador AVR-GCC-4.1.0, trabajo habitualmente sobre maquinas Unix (Debian, FreeBSD) y todo lo hago desde este S.O., desde el diseNo del esquematico hasta el PCB, la programacion y su grabacion en la Flash del Microcontrolador. Les dejo este link para que lean un articulo que publica respecto de este tema (http://www.eldemonio.org/documentos/020507184907.html).

Los pasos que he seguido en el codigo son los siguiente:
(1) Inicializacion de la interfaz SPI del controlador.
(2) Funciones de acceso a los registros del MCP2515 de read y write.
(3) Funciones de imprimir los registros del MCP2515 para debug a la puerta serial del AVR.
(4) Inicializacion del MCP2515.

Lo que me queda es ahora trabajar en las rutinas de envio y recepcionar mensajes desde el MCP2515. Tengo un primer hacercamiento que aun no me ha funcionado.

Bueno eso por el momento, si alguien tiene algunas rutinas de envio y recepcion de mensajes que pudiese compartir, serial genial poder verlas, aunque haya que cambiarlas, pero al menos ya es una idea de como tomar el desarrollo.

Saludos a todos.



Muy buen trabajo Electrolinux!!
Te ha quedado muy profesional!!
Felicitaciones!!

Respecto a la comunicacion con el MCP2515, el creador del software CanKing (buscalo en google) tiene un software en C de PC para establecer la comunicacion spi y cargar los datos, configurar y utilizarlo.
En su web esta todo el codigo fuente, yo no te lo dije, pero me pasaria por alli a ver, je..je

Para que podamos ayudarte mejor te pediria si puedes poner la parte del esquematico donde conectas el AVR > MCP2515 > 82C250...
Eso si no te molesta y puedes hacerlo.

Interesante el proyecto de balanza inteligente, puedes contarnos mas ?? , por curiosidad solamente... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 18:35:00
Muy buen trabajo Electrolinux!!
Te ha quedado muy profesional!!
Felicitaciones!!

Respecto a la comunicacion con el MCP2515, el creador del software CanKing (buscalo en google) tiene un software en C de PC para establecer la comunicacion spi y cargar los datos, configurar y utilizarlo.
En su web esta todo el codigo fuente, yo no te lo dije, pero me pasaria por alli a ver, je..je

Para que podamos ayudarte mejor te pediria si puedes poner la parte del esquematico donde conectas el AVR > MCP2515 > 82C250...
Eso si no te molesta y puedes hacerlo.

Interesante el proyecto de balanza inteligente, puedes contarnos mas ?? , por curiosidad solamente... :mrgreen: :mrgreen:

Gracias por tus felicitaciones amigo... se agradece a los que aprecian nuestros trabajos :-)

Supongo que te refieres a este link http://www.kvaser.com/index.htm... respecto del CanKing, pero veo que es bajo Windows 98, NT, XP, Vista.... ningun Unix. Buscare con detalle ya que me interesa bastante, pero la forma de acceder a los puertos paraleo (que creo que es lo que usan CanKing), es muy diferente entre estas plataformas. En todo caso buscare su codigo fuente para verlo, aun no lo busco detalladamente sobre esa web.

No hay problemas en poner el esquematico, le sacare una imagen y lo envio, no hay problemas en ello.

Ha...(buena vista :-)) bueno respecto a la balanza es otro proyecto y desgraciadamente no con CAN, pero es un proyecto contratado y no tengo posibilidad de contar mucho ya que hay contratos de por medio de confidencialidad... Sorry pero estoy amarrado.

Saludos y envio el esquematico.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Enero de 2008, 18:40:57
Te hago una correccion. :lol:
El lenguaje C, nacido en un laboratorio, es el lenguaje de computacion mas portable que existe...
Si tienes el fuente y un compilador que funcione sobre Linux (el mismo Linux esta escrito en C) podras utilizarlo tal y como viene sin inconvenientes. :lol: :lol:

Respecto al proyecto, era solo curiosidad, no hay problema... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Enero de 2008, 18:48:42
Lo podras bajar de aqui (piden registro).
http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510-pc.txt (http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510-pc.txt)

y de aqui otro ejemplo...

http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510.txt (http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510.txt)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: maunix en 28 de Enero de 2008, 18:58:50
El lenguaje C, nacido en un laboratorio, es el lenguaje de computacion mas portable que existe...
Si tienes el fuente y un compilador que funcione sobre Linux (el mismo Linux esta escrito en C) podras utilizarlo tal y como viene sin inconvenientes. :lol: :lol:

Coincido en que es muy portable como lo está siendo java ahora, pero no coincido con que con solo fuente + compilador se pueda trasladar algo de una plataforma a otra sin inconvenientes.

Los programas que permiten eso están preconcebidos para que así sea (basados en las librerías QT o GTK si hablamos de windows & linux por citar un ejemplo); pero un código por el solo hecho de estar en C no es migrable 100% a otra plataforma, requiere ser adaptado con mayor o menor complejidad.



Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 19:22:04
Te hago una correccion. :lol:
El lenguaje C, nacido en un laboratorio, es el lenguaje de computacion mas portable que existe...

Si y no... si el lenguaje 'C' es estandart POSIX, si lo es, pero hay cada fabricante que le ponen 'C' a algunas cosas que son solo entendidas por el compilador especifico y eso NO tiene nada de PORTABLE.

Si tienes el fuente y un compilador que funcione sobre Linux (el mismo Linux esta escrito en C) podras utilizarlo tal y como viene sin inconvenientes. :lol: :lol:

Aun no he visto el codigo, por lo que opino sin verlo aun... de todas formas espero que sea asi de simple, tomarlo compilarlo y usarlo.

Respecto al proyecto, era solo curiosidad, no hay problema... :mrgreen: :mrgreen:

No te preocupes... no hay problemas, pudiendo compartir lo que se y lo que puedo, lo hago... asi aprendemos todos y ahi es donde esta la riqueza de esto.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 19:26:21
Lo podras bajar de aqui (piden registro).
http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510-pc.txt (http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510-pc.txt)

y de aqui otro ejemplo...

http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510.txt (http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510.txt)

Gracias MGLSOFT.... estoy haciendo el esquematico en forma decente para ponerlo en el foro.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Enero de 2008, 19:48:32
Lo podras bajar de aqui (piden registro).
http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510-pc.txt (http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510-pc.txt)

y de aqui otro ejemplo...

http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510.txt (http://www.kvaser.com/cgi-bin/sendfile.cgi?dir=files&file=mcp2510.txt)

Gracias MGLSOFT.... estoy haciendo el esquematico en forma decente para ponerlo en el foro.

Saludos

Si pones el esquematico escaneado de uno hecho a mano alzada, si se entiende es lo mismo, la intencion es ayudarte, no complicarte.

respecto al codigo, dame tu mail por el privado y te paso un ejemplo hecho en lenguaje C para los PICs, luego seguramente tu mismo podras descartar lo que sirve y lo que no para usarlo en AVR, disculpa que no se nada sobre AVR para ayudarte mejor... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: maunix en 28 de Enero de 2008, 20:10:47
Te hago una correccion. :lol:
El lenguaje C, nacido en un laboratorio, es el lenguaje de computacion mas portable que existe...

Si y no... si el lenguaje 'C' es estandart POSIX, si lo es, pero hay cada fabricante que le ponen 'C' a algunas cosas que son solo entendidas por el compilador especifico y eso NO tiene nada de PORTABLE.

El sistema operativo (si lo hubiere) también debe cumplir con el estándar... no solo el compilador.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Enero de 2008, 20:22:02
Gracias Maunix, por tus aclaraciones ante mi tremenda ignorancia sobre Linux.
intentaba darle al amigo una herramienta de software que le permita probar la conexion y aprender de la configuracion sin adentrarme en el ambiente de desarrollo de AVR, del cual soy tremendamente ignorante.

Ahora lo que voy a hacer para ayudarlo es pasarle un codigo para PIC y tratar juntos de adaptarlo a sus necesidades... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: maunix en 28 de Enero de 2008, 20:28:49
Gracias Maunix, por tus aclaraciones ante mi tremenda ignorancia sobre Linux.
intentaba darle al amigo una herramienta de software que le permita probar la conexion y aprender de la configuracion sin adentrarme en el ambiente de desarrollo de AVR, del cual soy tremendamente ignorante.

Marcos, tus intenciones son las mejores y nadie duda de ello, solo quise aclarar que no todo es tan fácil como suena  :mrgreen: , si te fijas bien las cosas se han solucionado mejor con los "virtualizadores" de otros entornos en vez de que una aplicación esté presente en ambos sistemas operativos en forma nativa.  El solo hecho de pensar de que algo está en C , incluso entre microcontroladores requiere su adaptación (a veces bastante compleja).

Por ello MPLAB por ejemplo no está en linux, porque portarlo no es tan simple :)  . 

Mi intención fue solo la de aportar un granito de arena sobre que no es tan fácil migrar de un lado para el otro, nada más, sigan con lo del CAN que está muy bueno el hilo :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 20:32:18
El sistema operativo (si lo hubiere) también debe cumplir con el estándar... no solo el compilador.

En el caso de Linux y BSD (FreeBSD, NetBSD, OpenBSD), siempre lo son, cumplen fielmente el standart POSIX, por eso ni siquiera lo mencione asumi eso como sabido, ya que es asi de base siempre y todo el codigo Open-Source lo es.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 20:36:56
Gracias Maunix, por tus aclaraciones ante mi tremenda ignorancia sobre Linux.

Cuando quieras te ayudo en eso...

intentaba darle al amigo una herramienta de software que le permita probar la conexion y aprender de la configuracion sin adentrarme en el ambiente de desarrollo de AVR, del cual soy tremendamente ignorante.
Si leiste el link que deje sobre sistemas embebidos en FreeBSD... ya sabes algo por donde  partir :-)

Ahora lo que voy a hacer para ayudarlo es pasarle un codigo para PIC y tratar juntos de adaptarlo a sus necesidades... :mrgreen:

Gracias por tu ayuda MGLSOFT... una vez funcional lo publicamos.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: maunix en 28 de Enero de 2008, 20:46:16
En el caso de Linux y BSD (FreeBSD, NetBSD, OpenBSD), siempre lo son, cumplen fielmente el standart POSIX, por eso ni siquiera lo mencione asumi eso como sabido, ya que es asi de base siempre y todo el codigo Open-Source lo es.

electrolinux lo aclaré en el contexto del sentido genérico de la portabilidad de un código entre plataformas, cualquiera sea.  Este foro es visitado por mucha gente y conviene aclarar algunas cosas, nada más, no fue una corrección sino un agregado.

todo el codigo Open-Source lo es.
Disciento, yo puedo hacer un código "open source" de un led que parpadee hecho en assembly y que no cumpla con ningún estándar... y como ese miles de ejemplos.  Una cosa no implica la otra.



Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 20:49:20
Si pones el esquematico escaneado de uno hecho a mano alzada, si se entiende es lo mismo, la intencion es ayudarte, no complicarte.

Gracias por tus intenciones... pero ya lo he terminado y lo adjunto como archivo, es un PNG

respecto al codigo, dame tu mail por el privado y te paso un ejemplo hecho en lenguaje C para los PICs, luego seguramente tu mismo podras descartar lo que sirve y lo que no para usarlo en AVR, disculpa que no se nada sobre AVR para ayudarte mejor... :mrgreen: :mrgreen:

Te acabo de enviar un mensaje privado.... espero que lo hayas recibido... Respecto a los AVR, no hay problemas, nadie nace sabiendo, yo por mi parte no se de PIC... asi que estamos iguales.:mrgreen:

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 28 de Enero de 2008, 20:55:23
electrolinux lo aclaré en el contexto del sentido genérico de la portabilidad de un código entre plataformas, cualquiera sea.  Este foro es visitado por mucha gente y conviene aclarar algunas cosas, nada más, no fue una corrección sino un agregado.

No te preocupes.. no quise armar una discucion y entiendo que tu tampoco, asi que no hay problemas.

Disciento, yo puedo hacer un código "open source" de un led que parpadee hecho en assembly y que no cumpla con ningún estándar... y como ese miles de ejemplos.  Una cosa no implica la otra.

Cierto lo que dices, pero eso un caso especial el que planteas, cuando uno hace un proyecto Open-Source hay ciertos estandares que cumplir y es a eso a lo que me referia, hay normas y procedmientos en ello. Pero la idea es simplificarle la vida a la gento no al reves. :)

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: maunix en 29 de Enero de 2008, 10:06:44
Cierto lo que dices, pero eso un caso especial el que planteas, cuando uno hace un proyecto Open-Source hay ciertos estandares que cumplir y es a eso a lo que me referia, hay normas y procedmientos en ello. Pero la idea es simplificarle la vida a la gento no al reves. :)

No lo quiero hacer más offtopic al hilo pero me parece que estás mezclando el uso y buenas costumbres, las sugerencias de cómo hacer un código a la filosofía de open source en sí.  Open source es lo que uno haga y quiera liberar el código para que otro lo use, modifique , etc.  Si está documentado, fácil o no de entender, eso es otro tema.  Eso lo hará más o menos popular, lo hará más masivo, hará que la gente se sienta más interesado en él, etc.

Te doy un ejemplo -> KTechLab, lo comenzó alguien porque quería aprender C++, está en pañales, de hecho sigo su lista de correo, su código no está muy documentado y sin embargo es open source!
Otro ejemplo -> El proyecto GnuPIc y sus software asociados.

Saludos y si el tema interesa abrimos otro hilo y listo.  :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Enero de 2008, 10:51:28
Bueno, espero que no nos vayamos nuevamente de tema en este hilo... :mrgreen: :mrgreen:
Veo que el software libre tambien crea polemicas, de todos modos cada uno elige con que trabaja, y como o cuanto reniega para cumplir su objetivo.
Eso debe respetarse.

Volviendo al tema del hilo, la mayor parte del codigo que te envie esta relacionado con los PICs, pero las funciones de inicializacion y librerias del MCP2510 (antecesor del MCP2515) seguramente con muy pocos cambios te serviran en tu software C.

Podras enviarme el codigo que estas utilizando en C para el AVR??
Un poco para aprender y otro para ayudar a adaptar estas rutinas a tus AVR, de paso te quedan las librerias.
No se si Maunix o Pikman u otros trabajaron en AVR, pero si leen el hilo los conmino a ayudar a nuestro amigo ElectroLinux... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 29 de Enero de 2008, 11:09:18
No lo quiero hacer más offtopic al hilo pero me parece que estás mezclando el uso y buenas costumbres, las sugerencias de cómo hacer un código a la filosofía de open source en sí.  Open source es lo que uno haga y quiera liberar el código para que otro lo use, modifique , etc.  Si está documentado, fácil o no de entender, eso es otro tema.  Eso lo hará más o menos popular, lo hará más masivo, hará que la gente se sienta más interesado en él, etc.

Te doy un ejemplo -> KTechLab, lo comenzó alguien porque quería aprender C++, está en pañales, de hecho sigo su lista de correo, su código no está muy documentado y sin embargo es open source!
Otro ejemplo -> El proyecto GnuPIc y sus software asociados.

Me imagino que ejemplos de malas/ buenas practicas sin duda habran por montones, pero son conceptos que pueden ser interpretados de una forma u otra. En todo caso, estimado amigo, no cambiemos el tema de este hilo que lo encuentro apasionante.

Saludos y que estes muy bien.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 29 de Enero de 2008, 11:18:19
Bueno, espero que no nos vayamos nuevamente de tema en este hilo... :mrgreen: :mrgreen:

Sin duda... volvamos a lo nuestro.

Veo que el software libre tambien crea polemicas, de todos modos cada uno elige con que trabaja, y como o cuanto reniega para cumplir su objetivo.
Eso debe respetarse.

Sin duda... pero no son polemicas, simplemente son distintos puntos de vista y respetables por cierto. En mi caso elegi trabajar hace annos con Open-Source he pasado por varias distribuciones de Linux y de FreeBSD, NetBSD y OpenBSD, dificilmente vuelva a usar Windows en cualquiera de sus sabores, es por ello que hice en mis inicios todos los esfuerzos para reunir y aprender a usar todas las herramientas disponibles y es por ello ademas que he publicado algunos paper's en esa linea para facilitar el uso de estas herramientas.

Volviendo al tema del hilo, la mayor parte del codigo que te envie esta relacionado con los PICs, pero las funciones de inicializacion y librerias del MCP2510 (antecesor del MCP2515) seguramente con muy pocos cambios te serviran en tu software C.
Los imprimi y los estoy mirando detenidamente.

Podras enviarme el codigo que estas utilizando en C para el AVR??
Un poco para aprender y otro para ayudar a adaptar estas rutinas a tus AVR, de paso te quedan las librerias.
No se si Maunix o Pikman u otros trabajaron en AVR, pero si leen el hilo los conmino a ayudar a nuestro amigo ElectroLinux... :mrgreen: :mrgreen:

Sin duda que lo enviare, dejenme empaquetarlos y lo envio como archivos de texto.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 29 de Enero de 2008, 11:48:02
Ok... adjunto en un zip, los archivos del ejemplo de desarrollo con AVR. En este ZIP estan los siguientes arcivos:

(1) main.c       -> programa principal
(2) mcp2515_tool -> definiciones de funciones basicas de acceso al mcp2515 que estan funcionales
(3) spi          -> rutinas de definicion de la interfaz SPI del AVR y sus funciones basicas
(4) uart         -> rutinas de acceso a la serial con sus definiciones, con buffers circulares de TX y RX.
(5) mcp2515_defs -> Estan definidos todos los registros internos del MCP2515.

Los comentarios estan definidos con formato Doxygen, que es una herramiente de documentacion de aplicaciones, muy util para dejar el desarrollo autodocumentado mientras se esta en el desarrollo.

Bueno espero sus comentarios al respecto, si hay sugerencias estare gustoso de escucharlas.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Enero de 2008, 12:01:55
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??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 29 de Enero de 2008, 12:20:05
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
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 29 de Enero de 2008, 12:31:31
Adjunto nuevamente los archivos en formato DOS. Sorry por el "lapsus"... ni me acorde de ese detalle.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Javicho en 29 de Enero de 2008, 20:34:23
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.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 29 de Enero de 2008, 20:43:06
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
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 29 de Enero de 2008, 20:51:00
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
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Javicho en 29 de Enero de 2008, 21:03:25
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.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Enero de 2008, 09:59:17
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 (http://es.wikipedia.org/wiki/I%C2%B2C)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Enero de 2008, 10:50:36

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...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 30 de Enero de 2008, 11:38:10
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
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Javicho en 30 de Enero de 2008, 14:35:07
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.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 31 de Enero de 2008, 02:54:00
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 :mrgreen:

muchas gracias, y no me hagas caso si es que soy muy molestoso
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Enero de 2008, 11:15:55
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... :mrgreen: :mrgreen:

Placa Entrenador CAN (http://rapidshare.com/files/88049847/Preview_ETH_CAN.pdf)

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

Comprimido con Winrar (http://rapidshare.com/files/88069365/Preview_ETH_CAN.rar)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 31 de Enero de 2008, 12:26:14
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... :mrgreen: :mrgreen:

Placa Entrenador CAN (http://rapidshare.com/files/88049847/Preview_ETH_CAN.pdf)

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
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Enero de 2008, 12:58:46
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... :mrgreen: :mrgreen:

Placa Entrenador CAN (http://rapidshare.com/files/88049847/Preview_ETH_CAN.pdf)

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... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 31 de Enero de 2008, 16:22:23
 :-/ lo descargue correctamente

muchas gracias MGLSOFT :mrgreen: ahora lo intentare hacer en un pcb en ceunto me libre de unos trabajos, desde ya teimpo que lo voy postergando, caray :(

peor ya tengo para empezar, solo me faltaria el pic de 28pines y el otro MCP :(  me dejas una lista de lso amteriales, porfavor?

muchas gracias :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Enero de 2008, 16:42:59
Aquí estoy colocando otro archivo para bajar que es la mascara de componentes y la ubicación de cada uno.
Prestar atención a los puentes, que son varios, producto de mi alta ineficiencia para hacer este trabajo...
También me faltaron las resistencias PullUp para las cinco teclas del teclado y display, que como va enchufado los puse sobre esa placa, pero si lo desconecto la placa comienza a hacer pavadas, detectando pulsaciones de teclas inexistentes, je..je

Son los gajes del oficio... :mrgreen:

Mascara Componentes (https://copy.com/KuJfZPUaEL3D)

Los componentes no hice el listado, pero los valores los encuentras en el esquemático este.

Esquematico Placa (https://copy.com/FsHGSZifhjSs)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 31 de Enero de 2008, 23:10:10
ok gracias :mrgreen:

Citar
Prestar atencion a los puentes, que son varios, producto de mi alta ineficiencia para hacer este trabajo...
hombre pero te ha salido un trabajo en esencia muy bueno, fantastico diria yo, felicitaciones por la dediocación y por ser tan buena persona y compartirlo con nosostros sin ningun interés, eres un IDOLO!!! :mrgreen:

 :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Febrero de 2008, 09:26:37
Gracias por tus conceptos, Cryn...

Igual ese trabajo no me conforma, y eso que tarde un buen tiempo en hacerlo...
Respecto a publicarlo, si miras el comienzo del hilo, me comprometi a dejar todo lo que se y/o aprenda en el hilo.
Ayudandonos entre nosotros aprenderemos mas, cometeremos menos errores y lo que es mejor, aprenderemos mas rapido la solucion correcta, porque hay mas masa cerebral al servicio de obtener un resultado.

Esa es la esencia de este Foro, y yo intento no traicionarla, no hay heroismo en eso, porque obtengo inmediata recompensa... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 01 de Febrero de 2008, 11:10:22
[..........]
Respecto a publicarlo, si miras el comienzo del hilo, me comprometi a dejar todo lo que se y/o aprenda en el hilo.
Ayudandonos entre nosotros aprenderemos mas, cometeremos menos errores y lo que es mejor, aprenderemos mas rapido la solucion correcta, porque hay mas masa cerebral al servicio de obtener un resultado.

Bueno comparto lo dicho sobre MGLSOFT... me mueve el mismo espiritu y una de las cosas que me encanto de este foro es precisamente el compartir conocimientos en forma desinteresada... lo que comparto plenamente y es por esta y otras razones, que uso Software libre hace mucho.

Bueno... entrando al tema que realmente nos interesa, adjunto un articulo que encontre en Aleman (que me tradujo un muy buen amigo frances), quiero enviarlo en formato PDF normal, (sin CRC), para que todos lo puedan leer, la idea de esto es que podamos completarlo/corregirlo entre todos ya que creo que se puede hacer algo mejor o complementar los temas tratados, lo que espero que sea trabajado por todos. Los comentarios y correcciones al articulo, me los envian y yo los incorporo en el documento, asi mantendremos un orden en el y quedara algo bien terminado.

El codigo mostrado, tiene algunos errores menores que he ido probando y mejorando, pero la idea es precisamente que todos lo discutamos y lo perfeccionemos...

Les parece?

Saludos a todos y no nos apartemos de este hilo que esta super bueno.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Febrero de 2008, 11:21:47
Bueno, nos dejaste tarea para leer un rato!! :D

Lo vemos y empezamos a comentar...

Estoy en el proyecto de armarme la interfase CAN para el CanKing, una vez tenga algo mas concreto, lo posteo aqui... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 01 de Febrero de 2008, 12:00:31
Bueno, nos dejaste tarea para leer un rato!! :D
Lo vemos y empezamos a comentar...

Bueno precisamente es la idea que todos colaboremos, espero sus comentarios.  :mrgreen:

Estoy en el proyecto de armarme la interfase CAN para el CanKing, una vez tenga algo mas concreto, lo posteo aqui... :mrgreen:

Me interesa eso.... y que paso con el Sniffer CAN de pierno10... esta operativo ya?

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Febrero de 2008, 13:08:07
No se!!
Anda perdido, al menos no da señales de vida!! :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 02 de Febrero de 2008, 13:24:22
No entiendo nada de italiano, pero esto puede interesarle a pierno (http://www.elettronicain.it/Main/riviste/p_rivista.asp)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Febrero de 2008, 20:46:57
Yo no vi nada interesante, que parte has visto tu?? :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfmateos2 en 03 de Febrero de 2008, 16:19:26
Me refería a esto que aparece en el número 116 y siguientes:
Citar
Primo impianto domestico con Can-Bus
Iniziamo ad utilizzare i moduli Velbus realizzando un piccolo impianto domestico che ci darà la possibilità di approfondire la conoscenza dei vari moduli e del sistema di programmazione manuale.
(http://www.elettronicain.it/Main/riviste/imgSommario/VELBUS.jpg)

Que está basado en el velbus de velleman http://www.vellemanprojects.com/be/en/product/list/?id=361192
Título: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 03 de Febrero de 2008, 19:51:19
Buenas noches compañeros!!!!  :-/

He estado un poco ausente por que tengo varias cosas en marcha y no tengo tiempo para todo.

En primer lugar comunicaros que el SNIFFER no lo tengo aun operativo (porque no he tenido tiempo de montarlo...). Lo haré en breve y os comento.

En segundo lugar y visto que se que hay gente que tiene dificultades para la construcción de las placas de circuito impreso a 2 caras en SMD, os he preparado un nodo genérico de CANBUS súper reducido que os permitirá su construcción con placas a una sola cara y con componentes DIL.

Este placa no está probada. Pero he seguido el mismo esquema que en las los entrenadores (que os remití en el pasado) que funcionan a las 1000 maravillas a todas las velocidades. Luego doy por bueno y estoy seguro que el resultado será el mismo.
Esta vez me lo he currado un poco más y he añadido el tema de la lista de los componentes y en la vista de placa lado componentes he puesto el valor de los mismos.
Fijaos que hay que realizar unos puentes ya que al poner todas las pistas en una cara la cosa se ha complicado mucho, y también esto es debido a que la placa solo mide 60mm*40mm. He dejado también en este prototipo una borna AUX que no va conectada a ningún sitio para poder realizar aquello que os comente de la conexión CANBUS en estrella (en estrella desde el punto de vista óptico, no nos confundamos)...

Bueno a lo que vamos....

El archivo RAR contiene:

1- Lista de componentes TXT
2- Lado pistas listo imprimir en un fotolito y posteriormente insolar... PDF
3- Lado componentes con sus valores y posición. PDF
4- Puentes necesarios que no he sido capaz de poner en la placa directos..... Pondremos unos hilitos ja ja ja PDF
5- Esquema eléctrico.... Muy importante ya que como el 18F2580 el puerto A solo tiene disponible para I/O del pin 0...5 lo he completado con los pines del puerto B 0 y 4 (si hay dudas mirar el esquema eléctrico). El puerto C esta completo del 0...7. PDF
6- Vista 3D del circuito. JPG

Después de ver todo esto, podréis ver que lo que he construido es un  MICRO nodo CANBUS, con jumper y su resistencia terminal de 120 ohm para nodos fianles del BUS, y dos puertos de 8 I/O cada uno (total 16 I/O)... Creo que no está nada mal.

Espero que os guste y que os sea de ayuda.... ya sabéis que como siempre para cualquier tipo de consulta o duda os ponéis en contacto y comentamos... También si veis que se puede mejorar no dudéis en comentarlo.

Un saludo para todos

                 PERE.   :mrgreen: 


PD:MGLSOFT estamos en contacto y comentamos que tal lo has visto.... sigo currando.   :-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Febrero de 2008, 09:26:50
Me refería a esto que aparece en el número 116 y siguientes:
Citar
Primo impianto domestico con Can-Bus
Iniziamo ad utilizzare i moduli Velbus realizzando un piccolo impianto domestico che ci darà la possibilità di approfondire la conoscenza dei vari moduli e del sistema di programmazione manuale.
(http://www.elettronicain.it/Main/riviste/imgSommario/VELBUS.jpg)

Que está basado en el velbus de velleman http://www.vellemanprojects.com/be/en/product/list/?id=361192

Disculpa, crei que te referias a que ese sistema trabajaba con CanBus, por eso la pregunta...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 04 de Febrero de 2008, 17:01:58
Estimados amigos:

(1) Alguien ha tenido el tiempo de leer el documento que envie MCP2515-AVR.pdf...
Algun comentario?

(2) Estuve viendo el circuito del Sniffer de pierno10, pense en armarlo para ver como funciona pero en los proveedores no encontre el 18F2580... el unico similar es el 18F2550, pero es un asalto lo que cuesta ese uC US$15.10.... los AVR valen la cuarta parte... creo que desistire de "probar" pic's

Por mi parte sigo avanzando sin terminar aun.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Febrero de 2008, 17:11:37
Je..je.. :mrgreen:
Bienvenido al clan !!

Puedes reemplazar un PIC18F2580 por PIC18F258, son compatibles pin a pin y la diferencia (asi lo tengo entendido) es que el 2580 implementa Extended CAN.
Para el uso que les damos aqui es igual uno que otro, la otra diferencia entiendo es que tiene mas memoria flash y de datos...

Cuanto sale el AVR + el MCP2515 ??
En el PIC18F2580 los tienes a ambos juntos en un solo circuito integrado !! :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Febrero de 2008, 17:22:44
Respecto al documento en si, la verdad es que lo lei a la rapida, termine este fin de semana un trabajo que debia entregar, asi que ahora prometo meterme mas dentro de lo tuyo.

Me extrañan los precios que te pasan por los PICs alli.
Mira aqui:
http://www.mcelectronics.com.ar/productos/pic18.html (http://www.mcelectronics.com.ar/productos/pic18.html)
o aqui:
http://www.cika.com/quotation/search.php (http://www.cika.com/quotation/search.php)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 04 de Febrero de 2008, 17:38:20
Bienvenido al clan !!

Sinceramente amigo prefiero los AVR   :lol:

Puedes reemplazar un PIC18F2580 por PIC18F258, son compatibles pin a pin y la diferencia (asi lo tengo entendido) es que el 2580 implementa Extended CAN.
Para el uso que les damos aqui es igual uno que otro, la otra diferencia entiendo es que tiene mas memoria flash y de datos...
Hmm tampoco se encuentra disponible  :(

Cuanto sale el AVR + el MCP2515 ??
En el PIC18F2580 los tienes a ambos juntos en un solo circuito integrado !! :mrgreen: :mrgreen:

Los AVR sale como ~US$4 y al MCP2515 sale mas caro si, pero lo tuve que importar y ahi los precios son nada que ver con los locales establecidos.... pero tambien hay flete e internacion... que se compensa si uno trae mas cosas en la importacion, pero acopio y traigo una sola vez cada cierto tiempo.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Febrero de 2008, 17:57:01
Hola Electrolinux!!

Seguramente si lo que quieres es armar un sniffer, puedo ofrecerte la programacion para hacerlo a traves de un PIC16F876 Mismo pinout del PIC18F2580 pero no tiene CAN.
En este caso iria acompañado de un MCP2515, que tu si tienes.
Averigua alli si consigues el PIC16F876 para cristal de 20 Mhz, a ver si va!!

Si lo consigues y el precio no es ofensivo para tus deseos de gastar, podremos desarrollar un sniffer que a todos nos sirva, te parece bien??

Luego no importaria que gama de micros usemos cada uno, los mensajes los veriamos todos por igual... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 04 de Febrero de 2008, 18:34:07
Hola Electrolinux!!

Amigo como estas?... espero que todo este bien.

Seguramente si lo que quieres es armar un sniffer, puedo ofrecerte la programacion para hacerlo a traves de un PIC16F876 Mismo pinout del PIC18F2580 pero no tiene CAN.
En este caso iria acompañado de un MCP2515, que tu si tienes.
Averigua alli si consigues el PIC16F876 para cristal de 20 Mhz, a ver si va!!

Perfecto... MUY AGRADECIDO... pero mi problema es que en donde compro solo hay estos, PIC16F716, PIC18F242, PIC18F252, PIC18F2550, PIC18F452, PIC16C63A, PIC16C66-10, PIC16F88... No se si alguno sirva, como ya sabes soy un completo ignorante en el tema PIC... y lo otro es como diantres programo uno de estos bichos.


Si lo consigues y el precio no es ofensivo para tus deseos de gastar, podremos desarrollar un sniffer que a todos nos sirva, te parece bien??
Me parece perfecto, ya que un sniffer lo considero una muy buena herramienta.

Luego no importaria que gama de micros usemos cada uno, los mensajes los veriamos todos por igual... :mrgreen:
Si exacto...

Saludos a todos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Febrero de 2008, 19:02:25
Yo tengo PIC18F252, con ese podemos desarrollar el sniffer con el 2515 !!
Lo hariamos al hardware de tal forma que pueda ser usado con el PIC18F2580 tambien, haciendo dos versiones de firmware, por supuesto!!

Te parece bien asi?? :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 04 de Febrero de 2008, 19:14:45
Yo tengo PIC18F252, con ese podemos desarrollar el sniffer con el 2515 !!
Tu mandas en esto amigo... te hera caso en lo que me indiques  :)

Lo hariamos al hardware de tal forma que pueda ser usado con el PIC18F2580 tambien, haciendo dos versiones de firmware, por supuesto!!
Ok me parece perfecto.

Te parece bien asi?? :lol: :lol:
Genial...

La duda que tengo es como grabar un PIC... solo eso por ahora.  :mrgreen:

En el AVR uso un DAPA (que fabrico yo mismo) que es un circuito simple que se conecta a la puerta paralela de mi laptop y programo al AVR por el puerto SPI del AVR, el software que uso es el AVRdude y opera a las 1000 maravillas sobre Unix. Para los PIC no tengo ni idea de como hacerlo.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Febrero de 2008, 19:17:15
Si tienes un esquematico de tu programador, veriamos si adaptandolo al software del winpic pudieramos manejarlo, en todo caso consulto al maestro Sisco... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 04 de Febrero de 2008, 19:57:47
Si tienes un esquematico de tu programador, veriamos si adaptandolo al software del winpic pudieramos manejarlo, en todo caso consulto al maestro Sisco... :mrgreen: :mrgreen:

Usa las lineas SCK, MISO, MOSI y Reset del AVR...

LPT
PC --- AVR
1  --- SCK
2  --- MOSI
11 --- MISO
16 --- Reset

Las 2 adicionales es +5V y GND, que alimentan este circuito porque uso un 74HC07 y las R de Open-Collector, pero las se~nales son las que te indico.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Febrero de 2008, 15:40:22
Le envie un privado al maestro Sisco, a ver si sabe si es posible que se grabe un PIC con tu hardware...esperemos pueda contestarnos...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 05 de Febrero de 2008, 15:55:23
Le envie un privado al maestro Sisco, a ver si sabe si es posible que se grabe un PIC con tu hardware...esperemos pueda contestarnos...

Ok... gracias MGLSOFT... en todo caso si el PIC se programa por una interfaz SPI, es probale que si, sin embargo puede que hayan comandos o una secuencia de ellos para entrar al modo de programacion que permitan hacer eso en el PIC... no lo se.

No se, si alguien de aca, trabaja con PIC en Unix (Linux o BSD)... que pueda comentar algo.

Saludos y gracias nuevamente.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Sispic en 06 de Febrero de 2008, 05:01:22
El primer problema es que todabia no corre WinPic800 en  linux , o si con emulador algo leí .

Tampoco programa AVR por el puerto paralelo .
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Febrero de 2008, 09:46:31
No interpretaste bien la pregunta Sisco... :mrgreen:

La pregunta es si el programador de AVR podria programar PICs ??
y si ademas puede manejarlo el software Winpic ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Sispic en 06 de Febrero de 2008, 16:56:26
Ha vale ¡¡  :?

pasanos el esquema y lo miramos electrolinux .
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 06 de Febrero de 2008, 17:27:51
pasanos el esquema y lo miramos electrolinux .

Esquema del programador:
(http://img100.imageshack.us/img100/718/dapafinal8x6dg3.png)

Este programador funciona sin problemas, es el que uso a diario y opera super bien. Es de bajo costos y esta al alcance de cualquiera.  :lol:

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Sispic en 07 de Febrero de 2008, 18:13:08
Lo podrias adaptar pero le falta una salida para controlar los 13v de Vpp que necesitan los pics .
Y para eso te recomiendo te hagas uno completo para pic y no modificar este.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 07 de Febrero de 2008, 18:21:53
Lo podrias adaptar pero le falta una salida para controlar los 13v de Vpp que necesitan los pics .
Y para eso te recomiendo te hagas uno completo para pic y no modificar este.

Tienes alguno de esos para ver el esquematico o basarme en uno ya funcional... Y con que software los programan?

Bueno gracias por tu respuesta..... y claramente me parece sano tu consejo, no modificare este para nada  :)

Saludos y Gracias de antemano.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Febrero de 2008, 18:24:53
Electrolinux.
Tu pregunta es algo asi como:

Señor DIOS, podras tu saber quien hizo el mundo en 7 dias???

 :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 07 de Febrero de 2008, 18:31:27
Señor DIOS, podras tu saber quien hizo el mundo en 7 dias???

Ok... sorry si no hubico a todos... estoy partiendo en este foro.. disculpad.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Febrero de 2008, 19:54:21
Era broma...  Sisco es el genio de los programadores en este foro, pero es el tipo de mas bajo perfil y colaborador que hay por este lugar...

Pero para que no tengas tantos problemas para llegar a buen fin, te ofrezco programarte el micro aqui y luego te lo envio (eso si, por cobrar alli) a Chile.
En ese caso te pondria un MCP2515 y el PIC16F876, que tengo varios...

Ya arranque con el esquematico de la placa del Sniffer, voy a dejar la posibilidad de usarlo con el PIC reportando al puerto serie, pero tambien poder utilizarlo conectado por el puerto paralelo al CanKing...
Que opinan, sera util asi??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 08 de Febrero de 2008, 16:08:05
Era broma...  Sisco es el genio de los programadores en este foro, pero es el tipo de mas bajo perfil y colaborador que hay por este lugar...
Perfecto... no tenia idea, lo siento.

Pero para que no tengas tantos problemas para llegar a buen fin, te ofrezco programarte el micro aqui y luego te lo envio (eso si, por cobrar alli) a Chile.
En ese caso te pondria un MCP2515 y el PIC16F876, que tengo varios...
Ok...no hay problema, te lo agradeceria, una de las formas que ha resultado bien, es por correo ordinario en un buen embalaje pequeño, ya lo he probado de esa forma con proveedores de chips... Atmel :) y funciona super bien.

Ya arranque con el esquematico de la placa del Sniffer, voy a dejar la posibilidad de usarlo con el PIC reportando al puerto serie, pero tambien poder utilizarlo conectado por el puerto paralelo al CanKing...
Que opinan, sera util asi??
Creo que mientras mas funcionalidades tenga una placa mejor...

Saludos y muchas gracias MGLSOFT.
Título: Creacion Sniffer para el BUS CAN
Publicado por: MGLSOFT en 11 de Febrero de 2008, 09:46:15
Buen, aqui pondre mis adelantos del Sniffer para el BUS CAN.
Por favor hacer las preguntas antes que avance con la placa en si, ya que pueden salir cambios importantes si las hacen.

Como detalles de la placa, concebi las siguientes funciones:

Conección del PIC (puede ser un PIC16F876 si va solo con el 2515) o un PIC18F2580 si va directo al BUS CAN
(http://img106.imageshack.us/img106/7946/snifferpartemicropc1.jpg)

Conección del puerto serie del PIC.
(http://img106.imageshack.us/img106/1061/snifferparteportserialwq1.jpg)

Conección al puerto Paralelo para uso con CANKing.
(http://img106.imageshack.us/img106/1964/snifferparteportparalelqh2.jpg)

La conección al MCP2515.
(http://img106.imageshack.us/img106/2717/snifferparteconeccionmcca3.jpg)

La conección al BUS CAN.
(http://img162.imageshack.us/img162/1493/snifferparteconeccionaldk8.jpg)

Los jumpers de seleccion para el MCP2515.
(http://img106.imageshack.us/img106/5443/snifferparteseleccionorwv5.jpg)

Los jumpers deberian ayudar a elegir entre usar el port paralelo o la version con el MCP2515 o el Bus CAN directo.
Por eso hay varios...

Alimentación de la placa, ver detalles abajo...
(http://img106.imageshack.us/img106/4545/snifferpartefuentealimeqi6.jpg)
La alimentacion de placa puede ser tomada del mismo Bus CAN (con alimentacion aparte, a traves de un jumper) o de una fuente externa.

Espero comentarios... :mrgreen:

Adjunto el esque ma en PDF...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 14 de Febrero de 2008, 12:00:53
Termine recien un esquematico que estaq basado en el que proporciono MGLSOFT, pero lo he sacado todo lo relacionado con la puerta paralela del PC, he dejado solo lo relacionado con el controlador CAN (MCP2515), el driver (PCA82C250) y el Controlador PIC 16F876.

(http://img225.imageshack.us/img225/8539/sniffercan0212hh5.png)

La idea basica es que solo trabaje como Sniffer del protocolo CAN. Si hay cuealquier modificacion o comentario al respecto sera bienvenido.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2008, 15:06:14
Muy bueno Ricardo!!
Yo lo habia revisado, pero no vi que usabas el PCA82C250, tal vez por prestarle mas atencion a la parte del conexionado con el MCP2515...
Segun lei el 82C250 (verificalo, tal vez me confunda por otro) necesita una resistencia de Pull-Up  o de Pull-Down en una de sus pines de comunicacion con el micro, cosa que el transceiver CAN de Microchip no necesita, esto lo lei en el foro de CCS y realmente el de Microchip lo trae interno, por eso no se ve en los circuitos.
este es un tema que yo me olvide de dibujar en mis circuitos a pesar que lo conozco, pero no es menos importante, ya que la comunicacion no se realiza...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 14 de Febrero de 2008, 15:17:21
Muy bueno Ricardo!!

Gracias amigo mio, pero el merito ha sido tuyo.. no mio, yo solo extraje algunas cosas y luego lo resumi en un solo circuito.

Yo lo habia revisado, pero no vi que usabas el PCA82C250, tal vez por prestarle mas atencion a la parte del conexionado con el MCP2515...
Segun lei el 82C250 (verificalo, tal vez me confunda por otro) necesita una resistencia de Pull-Up  o de Pull-Down en una de sus pines de comunicacion con el micro, cosa que el transceiver CAN de Microchip no necesita, esto lo lei en el foro de CCS y realmente el de Microchip lo trae interno, por eso no se ve en los circuitos.
este es un tema que yo me olvide de dibujar en mis circuitos a pesar que lo conozco, pero no es menos importante, ya que la comunicacion no se realiza...

Me dejaste en la duda... ya que revise el datasheet y no indica nada de eso... puedes validar la info que me cuentas?... ya que es importante.

Saludos y gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2008, 15:59:41
El que busca encuentra, y yo encontre!! :mrgreen:

Aqui la pregunta del usuario.
Citar
Problem:
If i connect my board (CAN-L/H, VSS, VDD) to the CCS test board using CAN-H and CAN-L (of the MCP2551), i am not able to establish a functioning connection.
If i don?t use the MCP2551 and wire directly from the TX and RX pins of the uC to the TX and RX pins of the CCS-CAN test board, then everything works fine....

As far as i know the PCA82C251 and MCP2551 should work together - but they don?t ?
I checked the connections and soldering of the MCP2551, seems to be fine. I also get an output out of the MCP2551.

Is there enything else i have to keep in mind ?!?

Y la respuesta de otro:
Citar
The PCA82C251 may not have built-in pullups

Y aqui las diferencias internas, marcadas en sus hojas de datos.

(http://img166.imageshack.us/img166/8329/mcp2551ds9.png)
(http://img166.imageshack.us/img166/9452/pca82c251mt0.png)

Espero que sea clarificador... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 14 de Febrero de 2008, 16:08:24
Gracias por el dato MGLSOFT....

Pero en el circuito esta la R6 y el LED_TXC que hacen el mismo efecto que la R que mencionas ya que "levantan" la linea TXC y solo es forzada a '0' cuando hay una Tx... o me equivoco?

Saludos e igualmente gracias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2008, 16:18:44
No soy electronico, solo un simple electricista devenido a cualquier cosa... :mrgreen: :mrgreen:
Lo que si creo es que el LED, por ser pariente de los diodos, no creo que permita que levantes esa linea, como dices...

Igual este efecto o mejor dicho el defecto de esa pull-up solo debe verse cuando las ratas de intercambio son muy altas y en vez de recibir una perfecta onda cuadrada, recibes una especie de sinusoide o diente de engranaje (se nota mi tendencia tallerista??), alli es donde corres riesgo de perder datos.
Igual en el caso del Sniffer, yo dejaria el lugar para ponerla, es mas aconsejan dejar el lugar para poner una de pull-down en la linea de RX...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 14 de Febrero de 2008, 16:42:47
Estimado amigo MGLSOFT... bueno he modificado el circuito y la idea es que entre los que somos lo prefecionemos, si te fijas he sacado los leds indicadores y he dejado solo los de la RS232, pero como te digo, ya esta hecho.

Ahora veamos como puede operar eso... aun no tengo ni el uC, ni el programador como para probarlo, espero que alguien se anime y pueda comentar como opera ese circuito.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2008, 16:58:43
Pensandolo bien, es probable que lo que dices sea cierto, ya que en mi placa y tambien las que hizo y probo con buen funcionamiento el amigo Pierno10  (que anda desaparecido, ojala disfrutando de unas vacaciones, asi lo envidiamos!!).

Ambos trabajamos a altas ratas, yo lo lleve a 500Kbps y Pierno a 1 Mb, a ambos nos anduvo OK, eso si, yo tengo los MCP2551 y creo que Pierno tambien... :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 15 de Febrero de 2008, 07:13:36
Hola muchachos:

Yo también estoy comenzando mis experimentos con el protocolo can.
Y por supuesto al ser novato estoy empezando a experimentar algunas dudas:

uno) cuando uno implementa un circuito con un micro controlador que tiene bus can se puede usar el transeptor 2551.
Dos) cuando el circuito está implementado con un micro controlador que no contiene bus can en ese caso se utiliza otro tipo de transeptor por ejemplo el 2510 (u otros).
tres) el otro circuito es muy similar solo que no tiene entrada a la pc.


Por el momento he implementado dos circuitos uno será el transmisor y otro será el receptor con el micro controlador pic 18 F. 2580; aquí les adjunto por favor corríjanme si he cometido algún error.

Desde ya muchas gracias.

Pedro Córdoba Argentina
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Febrero de 2008, 08:23:39
Hola quirogaareal!!
Bienvenido al club!! :D :D

Cuando puedas leete todo el hilo, si es posible desde el principio, no es mala onda, sino que lo que voy a explicarte esta ya tocado dentro del hilo.

El transceptor MCP2551 (o cualquier transceptor CAN de otra marca) es absolutamente necesario para establecer la comunicacion, ya que incorpora el protocolo a nivel fisico, es decir es el que se encarga que las señales tengan los valores correspondientes a los ceros y unos, trata los errores, etcetera.

Los micros que tienen CAN incorporado necesitan de este transceptor para comunicarse.

Los micros que no tienen CAN incorporado tambien pueden utilizarse para comunicarse al bus, usando un controlador CAN como el MCP2515 o MCP2510 (el antecesor), que conectara al transceptor MCP2551.

En la placa desarrollo que yo hice veras que puedes usar micros que incorporen el protocolo CAN (alli uso PIC18F2580 o PIC18F4580 de 28 y 40 pines respectivamente), pero tambien puedes utilizar un micro de uno de esos patillajes que no tenga CAN conectandolo al MCP2515.

Espero que esto conteste tus dudas. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 15 de Febrero de 2008, 10:11:17
Estimado quirogaareal:

Bueno bienvenido.... te comento que por el nivel de tus consultas demuestras no haber leido nada del hilo, te sugiero encarecidamente leerlo completo, eso te ayudara a entender mas y de pasada demuestras tu interes en el tema. En lo personal yo cuando entre al hilo y no hace mucho de ello, entre despues de haberme deborado todo el hilo, el cual encontre muy interesante.

Espero que esto lo tomes a bien y entiendas que no son palabras con mala fe, pero demuestra interes en el tema y despues a ponerse el overol y a trabajar  :lol:

Saludos a todos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 15 de Febrero de 2008, 12:14:23
Hoal Muchachos :

Creanme si lo he leido pero lo hice casi al ulimo despuespues de haber leido una gran variedad de documentos, la verdad ya venia cansado . prometo revisarlo muy detalladamente desde el principio   puesto que es un tema que me es de necesida a parte de muy interesante .
Lo que logre o vaya logrando con el transcurso de mis investigaciones y avances lo publicare.
Agradezco su gentileza de responder

Un saludo para todos

Pedro Cordoba Argentina
Título: Re: Mis experiencias con el BUS CAN
Publicado por: escarpa en 18 de Febrero de 2008, 08:43:34
Hola, estoy teniendo problemas con la comunicación can.

Uso el dongle can232, saco las tramas por el puerto serie, y mediante el dongle consigo las tramas de can. no sé si has usado este aparatito, pero me esta dando problemas, únicamente con alimentarlo y configurarlo, deberia funcionar, usando el software que te puedes bajar de la propia pagina. pero no soy capaz de ello. Tengo que configurar, la velocidad del puerto serie, que tengo que poner la que el propio dongle me indica con un codigo de parpadeos nada más ser conectado, inicialmente es de 57600 baudios(3 parpadeos), pero no sé que tengo que poner en Can bit rate, como se cual es esta velocidad?.

muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Febrero de 2008, 08:50:11
La verdad es que la informacion que nos das es escasa.
Podras poner al menos un link a donde esta el manual de tu equipo, ya que no se de que se trata, por lo tanto nunca mas lejos de poder ayudarte... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: escarpa en 18 de Febrero de 2008, 13:52:40
Aqui esta la web del dongle

http://www.can232.com/

a ver si alguien lo ha usado y puede ayudarme!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Febrero de 2008, 15:17:39
Citar
Tengo que configurar, la velocidad del puerto serie, que tengo que poner la que el propio dongle me indica con un codigo de parpadeos nada más ser conectado, inicialmente es de 57600 baudios(3 parpadeos), pero no sé que tengo que poner en Can bit rate, como se cual es esta velocidad?.

Seguramente si configuras mal la velocidad, hay algunas velocidades del BUS CAN que no podras configurar (o al menos lograr que funcionen como corresponde).

En el caso de la velocidad del bus Can o Can Bit Rate, el manual es muy especifico al respecto:
Citar
Sn[CR] Setup with standard CAN bit-rates where n is 0-8.
This command is only active if the CAN channel is closed.
(V1010)
S0 Setup 10Kbit
S1 Setup 20Kbit
S2 Setup 50Kbit
S3 Setup 100Kbit
S4 Setup 125Kbit
S5 Setup 250Kbit
S6 Setup 500Kbit
S7 Setup 800Kbit
S8 Setup 1Mbit
Example: S4[CR]
Setup CAN to 125Kbit.
Returns: CR (Ascii 13) for OK or BELL (Ascii 7) for ERROR.

Incluso da ejemplos de como hacerlo...

Para configurarlo, Si o Si deberas conocer a que velocidad funciona el Bus Can donde conectas ese Dongle. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: morlok en 23 de Febrero de 2008, 08:15:38
Hola gente, primero felicitarlos por este hilo sobre CAN BUS que posee muy buena informcion y me ha venido muy bien como introducción al tema.
 Estoy implementando un sistema didactico para la enseñanza del CAN BUS, y estoy teniendo problemas para establecer la comunicación, tengo experiencia con RS232 ,RS485, USB , pero con este bus soy principiante, por lo que tengo algunas consultas por si alguien puede orientarme.

 El escenario es el siguiente:
 HARDWARE : he montado dos transceivers con el MCP2551, conexionado como en los esquemas de este hilo, RS a masa pasando por R de 10, R de 120 en paralelo entre las lineas L y H de ambos MCP, TXD a B2 del pic y RXD a B3, condensador de .1 uf en alimentacion pegado al MCP, VREF libre.   
 Pic 18f458 montados en placas EasyPIC3 de Mikroelektronika, cristales de 20 Mhz, Port B jumper de pull libres, habilitado puerto serie en C6 y C7.

SOFTWARE : CCS 4.057,  ejemplo EX_CAN.C

SINTOMAS: no se transmiten datos, el buffer de transmision acepta las tres primeras tramas (lo veo por el puerto serie), y ahi se queda no las llega a emitir. En el PIN B2 no hay variacion , esta en alto todo el tiempo.
Si en la libreria can18xxx.c  lo pongo en modo LOOP si libera la trama del buffer, pero claro como esta en modo loop no las transmite externamente.

PREGUNTAS:
1) ¿En la placa que actua como emisora con tener  el MCP2551 deberia transmitir o si no hay un receptor activo no emite.?
2) ¿Se puede conectar directamente la TX y RX del CAN de un pic con las del otro pic ?

Muchas gracias , espero alguna respuesta de alguien que haya tenido alguno de estos problemas, que parece que este tema del CAN tiene sus dificultades.
Saludos.
 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Febrero de 2008, 08:42:47
Hola Morlock!!
Bienvenido al Foro y a este hilo!!

Preguntas respecto a tu problema:

Los ejemplos de CCS trabajan a 125 Kbps, tal vez la resistencia de slope sea muy baja, deberias ver la tabla del MCP2551 a ver cual te conviene o conocer cual usa Mikroe en sus placas, creo que ponen sus esquematicos en su WEB.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: morlok en 23 de Febrero de 2008, 10:15:12
Gracias por la bienvenida, es la primera vez que escribo pero siempre lo he tenido de referencia a este foro, por aqui por España es muy conocido y nos deja bien parados a los argentinos (soy entrerriano).

He estado mirando el kit de CAN de CCS pero no ponen el esquematico , en el kit de MikroElektroniKa si y usan  10 ohm en RS par a sus ejemplos, que se pueden descargar desde alli (fuentes y .hex) , asi que intentare con estos ejemplos compilados con MikroC para asegurarme mi hardware esta correcto, y luego volver a insistir con la version  CCS.

Kit CAN de CCS
https://www.ccsinfo.com/product_info.php?products_id=CANbuskit

Kit CAN de Mikro...
http://www.mikroe.com/en/tools/can1/

En cuanto a los programas de CCS  uso en los dos el mismo pero en el emisor le anule las lineas de codigo que reciben y en el receptor las que emiten, como en el ejemplo mascara y filtro estan configurados para recibir cualquier ID, creo debe funcionar.

Mi duda sigue siendo si el PIC emisor esta conectado correctamente al transceiver y el transceiver esta conectado a otro correctamente, pero el programa del PIC receptor no esta activo o correcto (pero asegurando que el pin B2 esta en alto para no dejar el bus en estado recesivo ) , emite igual el primero, digamos es posible transmitir a ciegas algo asi como SIMPLEX del RS232.

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Febrero de 2008, 10:31:17
Porque no subes el codigo modificado del emisor y receptor aqui, a ver si puedo probartelos.
Me parece buena idea que pruebes el codigo de Mikroe en las placas, asi podras determinar si funciona correcto antes de seguir.

Como andás allí con la provisión de yerba mate??
Podríamos cambiarte yerba por PICs... :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: taichin en 25 de Febrero de 2008, 03:06:06
disculpen por la desaparcion... me vuelvo loco en estos dias de clases... bueno encontre los codigos en ensamblador aki se los dejo.. veo que todo mundo usa C para el CAN... pues yo con ayuda del datasheet me lo avente en ensamblador... algo mucho mas didactico creo yo... el codigo realiza una conversion analogica digital en un nodo A llamado Tx y envia el dato de la conversion a un nodo B que nombre Rx y los despliega por el puerto B a unos leds.. ok. espero les guste y les sirva de ayuda....  :-/

estan como adjuntos dichos archivos.... suerte
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Febrero de 2008, 08:24:42
Gracias por tu aporte Taichin.
Menuda tarea en ensamblador!! :mrgreen:
Título: Placa Sniffer CAN
Publicado por: MGLSOFT en 25 de Febrero de 2008, 09:49:09
Aqui publico la imagen de como queda ruteada mi placa Sniffer CAN.
La forma y tamaño se deben a que ya tengo la caja donde la voy a colocar   :mrgreen: :mrgreen: y a que uso componentes true hole, ya que mi tecnica no da para montaje superficial   :D :D

Aqui va, critiquen ahora o callen para siempre!! :mrgreen:

(http://img187.imageshack.us/img187/1597/placasniffervz8.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 25 de Febrero de 2008, 14:24:53
Buena placa MGLSOFT....

Por mi parte estoy esperando unos PIC que me he encargado, concretamente los PIC16F876A para poder realizar mi placa de sniffer de acuerdo al plano enviado, vere una vez que me lleguen como terminar mi proyecto. Despues posteo los resulatdos de ello.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 25 de Febrero de 2008, 14:28:39
Mi critica  :-/ :-/ :-/ muy chula Marco  :D :D no se cuando le voy a entrar al Can Can  :D :D :D
pero esta guapisima la placa Sniffer  :-/ :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Febrero de 2008, 15:37:45
Bien, les cuento que estoy intentando hacer que nuestro software tenga la posibilidad de detectar (entre varios de un listado) el bit rate del Bus.
Esta funcion se denomina autobaud en la jerga.
Creo que seria muy bueno para un Sniffer poder tener esta comodidad, no es asi?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 25 de Febrero de 2008, 15:43:39
Bueno considero que eso es un lujo! del sniffer.... ya que mi primer objetivo es que simplemente funcione pero bienvenida es esa opcion.

Saludos y ya veremos todo funcionando :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: papinolmedo en 27 de Febrero de 2008, 06:59:14
En primer termino saludo a todos quienes participan de este hilo y a todos quienes forman parte de este distinguido foro. Es primera vez que posteo, por lo cual me presento ante ustedes: soy Rubén Olmedo Valencia, estudiante de ultimo año de Ingeniería Civil Electrónica en la Pontificia Universidad Católica de Valparaíso, Chile. En la actualidad me encuentro trabajando en mi proyecto de titulo, el cual es una aplicación académica en control automático soportada sobre un bus CAN, (por lo cual el hilo me viene como anillo al dedo). Soy visitante recurrente del foro, me ha servido para aclarar varias dudas, y desde hace poco soy miembro registrado.

Tengo experiencia en trabajo con el microcontrolador 16f877, y la mayor parte de mi proyecto la he desarrollado con este pic. Ahora deseo enfocarme a desarrollar la comunicación entre dos pic mediante el bus CAN, por lo cual debo migrar del pic16f877 al pic18f258 ó al pic18f458. Y aunque tal migración no debiera darme problemas, bien se ha encargado Morphy y su ley de que esto no sea así.

Por el momento leo y les presto atención, bien calladito como escolar. Espero pronto participar en forma mas activa en este hilo cuando haya soltado bien los dedos con los pic18fx58.

Se agradece el que existan sitios como este, que sin duda facilitan el aprendizaje y el desarrollo de aplicaciones. Felicitaciones a los moderadores, administradores, participantes y en especial al Maestro MGLSOFT  por abrir este hilo.

Saludos cordiales.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Febrero de 2008, 08:15:38
Bienvenido al Foro y al hilo!! :mrgreen:
Interesante lo que debes realizar.
Puedes contarnos un poco mas, asi podemos ayudarte?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 27 de Febrero de 2008, 10:15:27
Bienvenido Ruben:

Espero que podamos compartir entre todos valiosos conocimientos de CAN, que sin duda seran bien recibidos por todos.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: papinolmedo en 27 de Febrero de 2008, 14:59:05
Muchas gracias por el recibimiento.

MLSOFT, el proyecto corresponde a una aplicación académica en control automático soportada sobre un bus CAN. Me explico, es un sistema (para uso adémico, no una planta industrial) de control distribuido donde dos agentes deben trabajar de modo cooperativo para lograr una tarea. El sistema se compone de dos pistolas y ocho blancos, las pistolas deben deben defenderse de los ataques de los blancos. Cada pistola es controlada mediante un pic18fx58.

Para lograr defenderse de modo óptimo, las pistolas deben comunicarse entre si información que les permita saber que blanco esta atendiendo cada una. Es ahí donde tiene cabida el bus CAN, corresponde al canal por el cual ambas pistolas comparten información.

Les pongo una foto que ilustra cuan avanzada va la planta.

La idea original es del profesor Kevin Passino del Departamento de Ingeniería Eléctrica y en Computación de la Universidad de Ohio (Link a Passino (http://www.ece.osu.edu/~passino/distdynamicsyslab.html) ), pero yo le he hecho ciertas modificaciones como utilizar microcontroladores para realizar el control y utilizar el bus CAN como canal de comunicación.

Espero haber sido lo suficientemente claro maestro MGLSOFT. Como dije antes, por ahora estoy soltando los dedos con los pic 18fx58 ( ¡y ya se me han presentado problemas con el trabajo con ellos! ), cuando avance con eso ire haciendo mis aportes al hilo.

Saludos cordiales.





Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Febrero de 2008, 15:09:15
Muy buen proyecto el tuyo!!
Muy interesante.
En que lenguaje vas a programar o ya programas y cual es el problema que se te presento con los PICs?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 27 de Febrero de 2008, 16:30:06
¡Qué chulada de juguetito!

No lo has explicado, pero supongo que los blancos también son controlados por otro PIC, ¿no?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: papinolmedo en 27 de Febrero de 2008, 17:06:17
Estimados, con mucho gusto aclaro vuestras dudas:


En que lenguaje vas a programar o ya programas?

MGLSOFT, programo en C, utilzo el PIC C Compiler de CCS v4.057.


No lo has explicado, pero supongo que los blancos también son controlados por otro PIC, ¿no?

Así es Nocturno. Los blancos son controlados por un pic 16f877. En la imagen que envié en mi post anterior se ve un circuito, en el medio de todo se ve dicho pic. Es cierto que no he dado todo el detalle de mi proyecto, solo he dado una breve reseña a modo explicativo.


Por ahora es el 16f877 quien controla todo el sistema, los blancos ya están operativos y las pistolas también. Lo que debo hacer ahora es migrar el programa de control de las pistolas del 16f877 a un 18fx58 y luego implementar el bus CAN. Dicho programa de control ya lo tengo bien avanzado, pero como no he trabajado nunca con un 18f, entonces me di en la tarea de desarrollar simples aplicaciones para conocer mejor estos pic. Dado que no tengo animo alguno en desviar la atencion del hilo, he planteado mi problema con el pic 18f258 en otro sitio del foro, les dejo el enlace para que puedan ayudarme:

Problema pic 18f258 (http://www.todopic.com.ar/foros/index.php?topic=20346.20)


Desda ya agradezco vuestra atencion y ayuda.

Saludos cordiales.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Febrero de 2008, 12:05:15
Hola muchachos:

Yo también estoy comenzando mis experimentos con el protocolo can.
Y por supuesto al ser novato estoy empezando a experimentar algunas dudas:

uno) cuando uno implementa un circuito con un micro controlador que tiene bus can se puede usar el transeptor 2551.
Dos) cuando el circuito está implementado con un micro controlador que no contiene bus can en ese caso se utiliza otro tipo de transeptor por ejemplo el 2510 (u otros).
tres) el otro circuito es muy similar solo que no tiene entrada a la pc.


Por el momento he implementado dos circuitos uno será el transmisor y otro será el receptor con el micro controlador pic 18 F. 2580; aquí les adjunto por favor corríjanme si he cometido algún error.

Desde ya muchas gracias.

Pedro Córdoba Argentina


Disculpame, antes no vi bien tu archivo...
Es solo para decirte que con un cristal de 4 mhz no vas a tener muy buena experiencia con alta velocidad en el Bus CAN, salvo que luego actives el FUSE H4, de modo que el PLL interno multiplique por 4 tu frecuencia de trabajo.
Ahi debes calcular tus tiempos internos y el baudrate del Bus a 16 mhz, que ya es bueno.

Yo uso cristales de 20 mhz sin PLL y de 10 mhz activando el PLL. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Febrero de 2008, 15:58:08
Buenas noches compañeros!!!!  :-/

He estado un poco ausente por que tengo varias cosas en marcha y no tengo tiempo para todo.

En primer lugar comunicaros que el SNIFFER no lo tengo aun operativo (porque no he tenido tiempo de montarlo...). Lo haré en breve y os comento.

En segundo lugar y visto que se que hay gente que tiene dificultades para la construcción de las placas de circuito impreso a 2 caras en SMD, os he preparado un nodo genérico de CANBUS súper reducido que os permitirá su construcción con placas a una sola cara y con componentes DIL.

Este placa no está probada. Pero he seguido el mismo esquema que en las los entrenadores (que os remití en el pasado) que funcionan a las 1000 maravillas a todas las velocidades. Luego doy por bueno y estoy seguro que el resultado será el mismo.
Esta vez me lo he currado un poco más y he añadido el tema de la lista de los componentes y en la vista de placa lado componentes he puesto el valor de los mismos.
Fijaos que hay que realizar unos puentes ya que al poner todas las pistas en una cara la cosa se ha complicado mucho, y también esto es debido a que la placa solo mide 60mm*40mm. He dejado también en este prototipo una borna AUX que no va conectada a ningún sitio para poder realizar aquello que os comente de la conexión CANBUS en estrella (en estrella desde el punto de vista óptico, no nos confundamos)...

Bueno a lo que vamos....

El archivo RAR contiene:

1- Lista de componentes TXT
2- Lado pistas listo imprimir en un fotolito y posteriormente insolar... PDF
3- Lado componentes con sus valores y posición. PDF
4- Puentes necesarios que no he sido capaz de poner en la placa directos..... Pondremos unos hilitos ja ja ja PDF
5- Esquema eléctrico.... Muy importante ya que como el 18F2580 el puerto A solo tiene disponible para I/O del pin 0...5 lo he completado con los pines del puerto B 0 y 4 (si hay dudas mirar el esquema eléctrico). El puerto C esta completo del 0...7. PDF
6- Vista 3D del circuito. JPG

Después de ver todo esto, podréis ver que lo que he construido es un  MICRO nodo CANBUS, con jumper y su resistencia terminal de 120 ohm para nodos fianles del BUS, y dos puertos de 8 I/O cada uno (total 16 I/O)... Creo que no está nada mal.

Espero que os guste y que os sea de ayuda.... ya sabéis que como siempre para cualquier tipo de consulta o duda os ponéis en contacto y comentamos... También si veis que se puede mejorar no dudéis en comentarlo.

Un saludo para todos

                 PERE.   :mrgreen: 


PD:MGLSOFT estamos en contacto y comentamos que tal lo has visto.... sigo currando.   :-)


Muy bueno!!
Yo estoy intentando hacerlo en pcb, si lo logro te cuento!! :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: morlok en 03 de Marzo de 2008, 19:41:53
Porque no subes el codigo modificado del emisor y receptor aqui, a ver si puedo probartelos.
Me parece buena idea que pruebes el codigo de Mikroe en las placas, asi podras determinar si funciona correcto antes de seguir.

Como andás allí con la provisión de yerba mate??
Podríamos cambiarte yerba por PICs... :D :D

Recien ahora he podido ponerme en el proyecto del CAN (maqueta automotriz para un centro de enseñanza de mecánica ),  el hard esta correcto, el demo de mikroe anda perfecto, asi que ya me puedo poner con  CCS.  He descartado pasarme a MikroC porque tiene una manera muy rara de manejar las librerias.
Gracias por el ofrecimiento a probarme el soft. Si me la veo fea consultare :-)

En cuanto a la yerba mate por aqui anda a 8 euros el kilo, pero solo soy de terere  en verano , asi que 1 kg me rinde , haber si los de Microchips se deciden a enviar  samples de pics a Argentina, organicemos una cadena spam :-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 06 de Marzo de 2008, 15:55:35
Hola Muchacos....

Estaba un poco perdido por recarga de trabajo... pero he seguido trabajando en el tema del sniffer can, les dejo una imagen del PCB que aun lo estoy trabajando.

(http://img98.imageshack.us/img98/623/sniffercan02pcb8ua9.png)

Cualquier comentario sera bienvenido.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Marzo de 2008, 17:44:46
Muy buena!! :-/ :-/
Un poco de envidia (de la sana) por el manejo con SMD...

La mia esta casi armada ya, por ley de Murphy me olvide el regulador y otras pequeñeces de pedirlos.
La puse en una caja bastante dicharachera, ya pondre fotos por aqui, si es posible mostrandola encendida, que por ahora no puedo hacerlo.. :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 06 de Marzo de 2008, 17:57:02
Muy buena!!
Un poco de envidia (de la sana) por el manejo con SMD...

Gracias por tus palabras, pero nada de envidia, es solo practica, amigo mio.... dicen que la practica hace al maestro.

La mia esta casi armada ya, por ley de Murphy me olvide el regulador y otras pequeñeces de pedirlos.
La puse en una caja bastante dicharachera, ya pondre fotos por aqui, si es posible mostrandola encendida, que por ahora no puedo hacerlo..

Bueno despues contaras y enviaras fotos... lo mismo yo cuando la tenga.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Marzo de 2008, 10:26:15
Bueno, aun no me puse a programar, pero aqui dejo unas fotitos de mi placa terminada.

La placa fuera de la caja (faltan los CI de interfase con el port paralelo, aun no los tengo).

(http://img119.imageshack.us/img119/6667/1001561ao7.jpg)

Y la misma placa dentro de su caja, bastante dicharachera, je..je..

(http://img186.imageshack.us/img186/818/1001562dr5.jpg)

A ver los comentarios... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Marzo de 2008, 10:49:33
Y en este post aparte pongo imagenes de la placa armada, desarrollo de Pierno, para empezar a trabajar con un nodo cableado (en realidad hice dos de estas), quedo bien compacta... :mrgreen:

(http://img523.imageshack.us/img523/5605/1001564ro3.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: stk500 en 09 de Marzo de 2008, 12:02:43
 :-/ :-/muy bien marco te quedo  :-/ :-/ :-/
una pregunta marco? tu conoce el Explorer-16 ya que vi en Elektor una placa Can que va con ese programa ???
y no estoy bien informados,
 :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 09 de Marzo de 2008, 12:57:14
Te han quedado estupendas, Marcos, y la caja muy chula.

Lástima que no puedas poner las fotos más grandes, para ver mejor los detalles  :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Marzo de 2008, 18:13:27
Pucha, tenes razon Manolo!!
Le voy a aumentar la resolucion la proxima vez... :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 10 de Marzo de 2008, 10:58:05
Estimado MGLSOFT:

Tamañas fotos... pero se ve bien, cuando termine las mias, mando las fotos tambien.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Marzo de 2008, 11:55:18
Vere la forma de achicarlas, es el segundo tiron de orejas.... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 10 de Marzo de 2008, 15:47:44
Hola MGLSOFT:

Una pregunta. Como harias para mandar un texto y que se imprima en un nodo que tenga display?

Saludos desde Cordoba Argentina

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Marzo de 2008, 17:07:07
Cada mensaje CAN puede contener 8 Bytes de datos...
Que necesitas hacer en realidad??
La verdad seria mucho mas "liviano" tener los mensajes predefinidos en el nodo y enviarle cual mensaje usar e incluso el dato a mostrar, o los datos a mostrar si son mas de uno.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 10 de Marzo de 2008, 17:53:28
Hola MGLSOFT:

solo estaba contemplando la posibilidad de que se envie una cadena de caracteres a travez del bus , si pudieras poner solo esa parte de ejemplo nada mas, por supuesto seria y de hecho es ma comodo que se detecte un evento y el propio nodo imprima en su diplay algun mensaje "X", solo era para contemplar distintos caso , en este caso mi duda se presento en como enviar una cadena de carateres a travez del nodo y que se imprima en el display del nodo que recibio esa cadena por supuesto intervendran el can_getd y el can_putd.

 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 10 de Marzo de 2008, 18:04:22
hola buenas noches¡¡¡ ante todo felecitar a toda esta gente que esta aportando su granito de arena a este foro. Me ha parecido realmente interesante todo que he leido. Creo que todo el foro me lo he leido en dos o tres dias y hay tanta informacion que ya se me escapa por las orejas.
Mi nombre es marcos ( como el crack que empezo el foro ), estoy haciendo mi proyecto de final de carrera sobre el buscan y la verdad que me he metido en este tema sin saber mucho, se podria decir que estoy en pañales y ustedes ya casi corren ...jejeje
bueno mi idea inicial es orientar este projecto hacia la domotica, como algunos de los aqui presentes, con la idea de controlar 3 habitaciones desde un  nodo maestro, tanto desde casa como desde internet. El nodo maestro estara conectado a un portatil atraves de la comunicación serie RS232 para ello he comprado un adaptador usb232 ya que mi portatil (como todos creo) no llevan incorporado.
El siguiente paso que quiero hacer es programar una interfaz en labview que me permita visualizar y controlar las diferentes variables de los nodos repartidos por la casa. De momento he comprovado que el cable USB232 funciona correctamente ya que he creado una pequeña aplicacion en labview que me permite enviar y recibir informacion atravez del puerto serie. La idea fue sencilla, simplemete conecte el pin 2 y 3 del conetor, que como todos saben es para recibir y enviar informacion, y mediante labview enviaba datos y recibia los mismos. (si alguien lo quiere lo subo al foro sin problemas)
Hoy mismo me acaban de llegar los pic que voy a utilizar : PIC 18F458 y transceptor mcp2551. Antes de empezar con esto ya me surgio a primera duda: me equivoque al pedir los Samples y me llegaron el pic18f458 y el pic18Lf458 Hay alguna diferencia substancial¿?¿ he buscado informacion en el datasheet peor no he visto lo que buscaba.
discupen mi ignorancia pero me gustaria saber para que sirve el sniffer can?¿ sirve para rastrear las tramas¿?puedo utilizar el esquematico que han colgado en el foro como nodo primcipal?
bueno muchas gracias deantemano y felicitaciones, no cada dia se encuentran foros tan buenos como este
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Marzo de 2008, 23:30:11
solo estaba contemplando la posibilidad de que se envie una cadena de caracteres a travez del bus , si pudieras poner solo esa parte de ejemplo nada mas, por supuesto seria y de hecho es ma comodo que se detecte un evento y el propio nodo imprima en su diplay algun mensaje "X", solo era para contemplar distintos caso , en este caso mi duda se presento en como enviar una cadena de carateres a travez del nodo y que se imprima en el display del nodo que recibio esa cadena por supuesto intervendran el can_getd y el can_putd.

De que longitud de cadena de caracteres estas hablando??
Podras poner un ejemplo??

Can_putd permite escribir 8 bytes que pueden contener un caracter cada uno.... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Marzo de 2008, 23:35:13
Antes de empezar con esto ya me surgio a primera duda: me equivoque al pedir los Samples y me llegaron el pic18f458 y el pic18Lf458 Hay alguna diferencia substancial¿?¿ he buscado informacion en el datasheet peor no he visto lo que buscaba.

Segun entiendo la linea LF tiene un rango de alimentacion mas extendido, creo que desde 3 a 5,5 volts, como lo usaras a 5 volts no tendras problemas...

Citar
discupen mi ignorancia pero me gustaria saber para que sirve el sniffer can?¿ sirve para rastrear las tramas¿?puedo utilizar el esquematico que han colgado en el foro como nodo primcipal?

Si, es para rastear tramas.
El esquematico de ejemplo del sniffer no te dara mucho para mejorar, te recomiendo usar el desarrollo que hizo Pierno10 que se adaptara muy bien a tu PIC y podras ejecutar los ejemplos que colguemos aqui... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 12 de Marzo de 2008, 02:03:13
Hola MGLSOFT:

Mira con 8 caracteres seria mas que suficiente , por ej 'E'N'C'I'E'N'D'E' que tiene 7 caracteres


Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Marzo de 2008, 08:16:44
Hola MGLSOFT:

Mira con 8 caracteres seria mas que suficiente , por ej 'E'N'C'I'E'N'D'E' que tiene 7 caracteres


Saludos

Je..Je...
Sera la ciudad de Cordoba que les cambia la vision y equivoca las cuentas???
Yo cuento 8 caracteres alli... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 12 de Marzo de 2008, 08:36:31
ok, gracias mglsoft. he estado revisando post anteriores y encontre lo que me dices.
no me queda muy claro com haces para rastear las tramas, es decir entiendo que utilices un sniffer para escuchar todo lo que se envia por elo bus pero que sw utizas? el que tiene microchip en su pagina? y si es asi es copmpatible con el hw sniffer??
en todo caso voy a empezar a hacer el hw del entrenador que diseño pierno10 para empezar a hacerme una ide mas clara y tener preguntas mas concretas y participar mas activametne en el foro.

gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Marzo de 2008, 09:16:42
El CanKing es compatible con el hardware de Mi sniffer, sin usar PIC.
La idea es desarrollar un sniffer que se comunicara con un software en PC para visualizar las tramas. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 12 de Marzo de 2008, 09:21:56
Hola MGLSOFT:

Chuy  gracias...por marcar el error

Es broma  si tienes razon son 8 caracteres.Mas o menos seria ponerlos en un vector Char y enviarlo , se reduce a eso?

Saludos desde Cordoba Argentina

Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 12 de Marzo de 2008, 09:44:47
El CanKing es compatible con el hardware de Mi sniffer, sin usar PIC.
La idea es desarrollar un sniffer que se comunicara con un software en PC para visualizar las tramas. Mr. Green
[/color][/color]

ok vale, ya entiendo (eso creo) lo que se necesita es tener conectado el bus (sin necesodad de un pic) atraves del puerto serie del computador para que el cankinfg en este caso lea las tramas no¿??¿ supongo q este sw se puede utilizar sin ninguna modificación, voy a bajarmelo para cuando tenga lista la placa provarlo.
Me que da una duda: si quiero controlar los distintos nodos de mi bus can mediante el PC habira que hacer modificaciones substanciles a la palca de pierno10 de nodo + sniffer ¿?¿?

gracias por tu ayuda mglsoft
 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Marzo de 2008, 09:57:02

Mas o menos seria ponerlos en un vector Char y enviarlo , se reduce a eso?



Mas o menos quedaria asi, para que lo pruebes a ver que recibes en el otro... yo no lo probe asi que deberas hacerlo.
Poner en la declaracion del buffer:
Código: C
  1. char buffer[8];

Luego para enviar la trama...
Código: C
  1.             buffer[0]="E";                    
  2.             buffer[1]="N";            
  3.             buffer[2]="C";          
  4.             buffer[3]="I";                    
  5.             buffer[4]="E";            
  6.             buffer[5]="N";
  7.             buffer[6]="D";                    
  8.             buffer[7]="E";            
  9.             can_putd(WRITE_REGISTER_D_ID, &buffer[0], 8, 1, 1, 0);
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Marzo de 2008, 10:02:54

Citar
ok vale, ya entiendo (eso creo) lo que se necesita es tener conectado el bus (sin necesodad de un pic) atraves del puerto serie del computador para que el cankinfg en este caso lea las tramas no¿??¿ supongo q este sw se puede utilizar sin ninguna modificación, voy a bajarmelo para cuando tenga lista la placa provarlo.
La placa sniffer comunica por el port paralelo, no por el serial.
Hay una version para el serial, desarrollada para la placa de Microchip, pero hay que "hacer" el codigo interno para poder usarla con ese.

Citar
Me que da una duda: si quiero controlar los distintos nodos de mi bus can mediante el PC habira que hacer modificaciones substanciles a la palca de pierno10 de nodo + sniffer ¿?¿?

La placa de Pierno es un nodo, no podras usarlo de sniffer... :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 12 de Marzo de 2008, 10:26:16
pierno10:

Buenas tardes MGLSOFT!!!!

Lo prometido es deuda.... aquí os dejo los esquemas de y los fotolitos para creación de las placas de CI. CUIDADO!!! Se trata de una placa a 2 caras.

Lo de siempre, si alguien piensa que se puede mejorar que me remita la modificación y la realizare de buen gusto.

HW NODO CANBUS + Sniffer CANBUS (RS-232)
Sniffer CANBUS.rar (contiene)

El archivo adjunto contiene 4 ficheros PDF:
1- Esquema eléctrico.
2- Placa de circuito impreso con los componentes.
3- Placa circuito impreso por el lado de las pistas.
4- Placa circuito impreso por el lado de los componentes.

Un saludo a todos

                  PERE.


Mmm ok entendido. en todo caso se equivovo al poner "HW NODO CANBUS + Sniffer CANBUS (RS-232)"
intentare entonces hacer un adaptador para puerto paralelo y poder utilizar el canking.

gracias otra vez
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 12 de Marzo de 2008, 10:31:14
que te parece este adaptador¿? es una buena solucion ya que mi herramienta de trabajo es un labtop
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 12 de Marzo de 2008, 10:32:32
http://www.superrobotica.com/S180125.htm

disculpa me olvide de poner el enlace
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Marzo de 2008, 10:34:18
Y puerto serial si tienes??
Si es asi espera a que desarrollemos el Sniffer serial ... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN (OT)
Publicado por: electrolinux en 13 de Marzo de 2008, 13:27:07
Estimados amigos del foro: Sorry por el Off-Topic antes que nada.

Ando en busca de un circuito para medir temperatura con una PT100 de 3 cables.... alguno de ustedes tendra algun circuito que me permita medir?... y debe ser PT100 porque la tengo (y no la encontre muy barata), me falta el circuito acondicionador que funcione, he estado buscando y no he visto algo decente... solo experimentales.

Agradecido de antemano por cualquier ayuda al respecto.
Saludos y gracias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Marzo de 2008, 14:45:04
Yo tambien lo estoy buscando. :lol: :lol:
Puse un post en el foro tecnico, pero aun no recibi respuestas...
Si te enteras avisame... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 13 de Marzo de 2008, 14:53:21
Ok... el primero grita :)

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 13 de Marzo de 2008, 16:52:16
Hola:

Tienen otras alternativas como el ad590 encapsulado metalico .
Lo unicoque yo consegui hasta ahora del pt 100 fue lo que adjunto.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 13 de Marzo de 2008, 17:18:27
No son opciones los basados en semiconductores ya que la temperatura a medir es del orden de los 230grC.... es decir no operan a esas temperaturas. Es por eso que debe ser una PT100.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 13 de Marzo de 2008, 18:56:47
Esto les sirve?

http://www.educypedia.be/electronics/circuitssensortemp.htm
http://ww1.microchip.com/downloads/en/AppNotes/00682c.pdf
http://www.maxim-ic.com/appnotes.cfm/appnote_number/270
Título: Re: Mis experiencias con el BUS CAN
Publicado por: electrolinux en 13 de Marzo de 2008, 19:35:09
Gracias quirogaareal:

Pues si me sirve... y agradecipor por tu tiempo y ayuda.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 16 de Marzo de 2008, 18:05:41
Hola Muchachos :

Aca hay un poco mas de bus can , espero que contribuya en algo mas.

Saludos desde Cordoba Argentina
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 16 de Marzo de 2008, 18:06:23
La parte que sigue
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 16 de Marzo de 2008, 18:06:58
la ultima parte
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Marzo de 2008, 21:55:54
Gracias por compartirlo!! :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 17 de Marzo de 2008, 18:05:14
Uno se alegra de haber sido util.

DND

Saludos desde Cordoba Argentina
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 17 de Marzo de 2008, 18:32:47
Este es para comentarles de mis avances, tengo lista y probada 100% la placa del sniffer CAN (falta el software por supuesto) y tambien los modulos CAN de Pierno10 funcionando y conectados al Bus CAN.
A la brevedad pondre fotos aqui para compartirlas... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 19 de Marzo de 2008, 11:49:43
Hola, estoy avanzando rapidamente en mi placa de buscan y mientras acabo de retocarla estoy empezando a programar en el mplab y me sale este error¡¡ alguien me podria decir a que se debe?¿
en breve colgare el circuito de prueva, que consta de una nodo esclavo y uno master¡¡
gracias

Clean: Deleting intermediary and output files.
Clean: Done.
Executing: "C:\Archivos de programa\PICC\Ccsc.exe" Marcos.c
Error[24]   C:\Archivos de programa\PICC\devices\18F458.h 2 : Unknown device type    -- Try PCH
Halting build on first failed translation as user preferences indicate.
BUILD FAILED: Wed Mar 19 15:46:31 2008
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Marzo de 2008, 21:37:04
Explicanos un poco mas de que compilador se trata, como lo tienes configurado y si lo que quieres es simularlo en MPLAB.
Asi podremos ayudarte mas, ya que con solo esto no creo poderlo hacer...
Ademas si puedes pon el codigo de ambos asi podremos darte mas ayuda.. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Leon Pic en 20 de Marzo de 2008, 10:51:03
Si le hacés doble clic en el error, te lleva al lugar del problema.

mmmmmmmmmmmm. Me parece que tenes mal configurado el mplab. Lo que dice que el dispotivo 18F458.h 2 es desconocido. Ese 2, me parece que está mal.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 22 de Marzo de 2008, 07:42:16
Hola MGLSFT:

En que parte del programa del nodo A defines la velocidad del bus can?
Controlas tu placa tambien desde el teclado de la pc o solo usas el rs232 para monitorear el bus ?


Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Marzo de 2008, 21:29:58
Hola MGLSFT:

En que parte del programa del nodo A defines la velocidad del bus can?
Controlas tu placa tambien desde el teclado de la pc o solo usas el rs232 para monitorear el bus ?


Saludos

La velocidad se define, disculpando la rebuznancia, con el define antes de llamar a la rutina de configuracion del bus can
el rs232 es para monitoreo y debug. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 25 de Marzo de 2008, 23:05:58
Hola MGLSOFT:

Aca te adjunto una copia del primer programa que posteaste (NODO A)

la verdad que no encuentro donde definiste la velocidad ?

Código: C
  1. /////////////////////////////////////////////////////////////////////////
  2. ////                         EX_CAN_CCS_A_4580.C                     ////
  3. ////                                                                 ////
  4. //// Example of CCS's CAN library, using the PIC18Fxx8.  This        ////
  5. //// example was tested with and written for the CCS CAN Prototype   ////
  6. //// board.                                                          ////
  7. ////                                                                 ////
  8. //// The CCS CAN Prototype board has four CAN nodes that communicate ////
  9. //// to each other.  Node A is the 18F458 with it's internal CAN     ////
  10. //// peripheral, Node B is a PIC16F87x connected to an external      ////
  11. //// MCP2510 CAN peripheral, and Node C and Node D are both MCP250xx ////
  12. //// stand-alone CAN I/O expanders.  This example is the firmware    ////
  13. //// for Node A.                                                     ////
  14. ////                                                                 ////
  15. //// Every two seconds this firmware sends out a command to node B   ////
  16. //// to change it's leds (CAN ID 0x202)                              ////
  17. ////                                                                 ////
  18. //// Upon change of the A/D reading, a value of 0-9 is sent to       ////
  19. //// Node D which is displayed on the 8-seg LCD (CAN ID 0x400)       ////
  20. ////                                                                 ////
  21. //// Pressing the Node A button sends a request to Node B (CAN ID    ////
  22. //// 0x201) for Node B's A/D reading, which Node B will respond      ////
  23. //// with a CAN message with it's A/D reading (with CAN ID 0x201).   ////
  24. //// Also, pressing the Node A button will change the LEDs on Node   ////
  25. //// C (CAN ID 0x300)                                                ////
  26. ////                                                                 ////
  27. //// Pressing Node C's buttons will cause Node A's buttons to change ////
  28. //// (Node C transmits button changes with CAN ID 0x303)             ////
  29. ////                                                                 ////
  30. //// Using a serial port, you can examine all the CAN traffic as     ////
  31. //// seen by the 18xxx8.                                             ////
  32. ////                                                                 ////
  33. //// For more documentation on the CCS CAN library, see can-18xxx8.c ////
  34. ////                                                                 ////
  35. ////  Jumpers:                                                       ////
  36. ////     PCH    pin C7 to RS232 RX, pin C6 to RS232 TX               ////
  37. ////                                                                 ////
  38. ////  This example will work with the PCH compiler.                  ////
  39. /////////////////////////////////////////////////////////////////////////
  40. ////                                                                 ////
  41. //// Baud rate settings to use to connect to the CCS CAN Prototype   ////
  42. //// board at 20Mhz:                                                 ////
  43. ////                                                                 ////
  44. ////    Baud Rate Prescalar: 4                                       ////
  45. ////    Propagation Segment: 3xTq                                    ////
  46. ////    Phase Segment 1: 6xTq                                        ////
  47. ////    Phase Segment 2: 6xTq                                        ////
  48. ////    Synchronized Jump Width: 1xTq                                ////
  49. ////    Sample Rate: 1x                                              ////
  50. ////    Wakeup Filter:  Off                                          ////
  51. ////                                                                 ////
  52. /////////////////////////////////////////////////////////////////////////
  53. ////                                                                 ////
  54. //// Node C and D are seperate stand-alone MCP250xx CAN I/O          ////
  55. //// expanders.  The CCS CAN Prototype board has these chips already ////
  56. //// programmed correctly.  However, if you wish to program your own ////
  57. //// to work with this example, then use the provided .HEX files     ////
  58. //// a programmer capable of programming these chips.  Or, make a    ////
  59. //// a new HEX file with these properties:                           ////
  60. ////                                                                 ////
  61. //// NODE C: Set RX ID mask and buffers to receive ID 0x3**. (The ** ////
  62. //// means make the least signifcant 8bits no-care in the mask).     ////
  63. //// Set TX1 buffer to ID 0x301, TX2 buffer to ID 0x302, TX3 buffer  ////
  64. //// to ID 0x303. Set GP0 to analog (and enable the A/D).  Set GP1,  ////
  65. //// GP2 and GP3 to OUTPUT.  Set GP4, GP5 and GP6 as INPUT with edge ////
  66. //// trigger enable.  Leave OPTREG2 clear, disable PWM1 and PWM2,    ////
  67. //// and disable scheduled transmission.  Also, see the baud rate    ////
  68. //// settings above.                                                 ////
  69. ////                                                                 ////
  70. //// NODE D: Set RX ID mask and buffers to receive ID 0x4**. (The ** ////
  71. //// means make the least signifcant 8bits no-care in the mask).     ////
  72. //// Set TX1 buffer to ID 0x401, TX2 buffer to ID 0x402, TX3 buffer  ////
  73. //// to ID 0x403. Configure all ports as OUTPUT.  Leave OPTREG2      ////
  74. //// clear, disable PWM1 and PWM2, and disable scheduled             ////
  75. //// transmission.  Also, see the baud rate settings above.          ////
  76. ////                                                                 ////
  77. /////////////////////////////////////////////////////////////////////////
  78. ////        (C) Copyright 1996,2003 Custom Computer Services         ////
  79. //// This source code may only be used by licensed users of the CCS  ////
  80. //// C compiler.  This source code may only be distributed to other  ////
  81. //// licensed users of the CCS C compiler.  No other use,            ////
  82. //// reproduction or distribution is permitted without written       ////
  83. //// permission.  Derivative programs created using this software    ////
  84. //// in object code form are not restricted in any way.              ////
  85. /////////////////////////////////////////////////////////////////////////
  86.  
  87. #include <18F4580.h>
  88. #device ICD=TRUE
  89. #device adc=8
  90.  
  91. #FUSES NOWDT                    //No Watch Dog Timer
  92. #FUSES WDT128                   //Watch Dog Timer uses 1:128 Postscale
  93. #FUSES HS                       //High speed Osc (> 4mhz)
  94. #FUSES NOPROTECT                //Code not protected from reading
  95. #FUSES BROWNOUT                 //Reset when brownout detected
  96. #FUSES BORV21                   //Brownout reset at 2.1V
  97. #FUSES PUT                      //Power Up Timer
  98. #FUSES NOCPD                    //No EE protection
  99. #FUSES STVREN                   //Stack full/underflow will cause reset
  100. #FUSES NODEBUG                  //No Debug mode for ICD
  101. #FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
  102. #FUSES NOWRT                    //Program memory not write protected
  103. #FUSES NOWRTD                   //Data EEPROM not write protected
  104. #FUSES NOIESO                     //Internal External Switch Over mode enabled
  105. #FUSES FCMEN                    //Fail-safe clock monitor enabled
  106. #FUSES PBADEN                   //PORTB pins are configured as analog input channels on RESET
  107. #FUSES BBSIZ1K                  //1K words Boot Block size
  108. #FUSES NOWRTC                   //configuration not registers write protected
  109. #FUSES NOWRTB                   //Boot block not write protected
  110. #FUSES NOEBTR                   //Memory not protected from table reads
  111. #FUSES NOEBTRB                  //Boot block not protected from table reads
  112. #FUSES NOCPB                    //No Boot Block code protection
  113. #FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
  114. #FUSES MCLR                     //Master Clear pin enabled
  115. #FUSES NOXINST                  //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
  116.  
  117. //#include <18F4580.h>
  118. //#fuses HS,NOPROTECT,NOLVP,NOWDT
  119. #use delay(clock=10000000)
  120. #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
  121.  
  122. #define CAN_DO_DEBUG TRUE
  123.  
  124. #define Set_250K_Baud TRUE  /// Aqui configuro que velocidad del BUS utilizo
  125.  
  126. #include "can-18F4580.c"
  127.  
  128. #include <lcd.c>
  129.  
  130. #define PIN_LED1  PIN_E2
  131. #define PIN_LED2  PIN_E0
  132. #define PIN_LED3  PIN_E1
  133.  
  134. #define LED1_LOW  output_low(PIN_LED1)
  135. #define LED1_HIGH output_high(PIN_LED1)
  136. #define LED2_LOW  output_low(PIN_LED2)
  137. #define LED2_HIGH output_high(PIN_LED2)
  138. #define LED3_LOW  output_low(PIN_LED3)
  139. #define LED3_HIGH output_high(PIN_LED3)
  140.  
  141. #define BOTON_ENTER  PIN_A5
  142. #define BOTON_ESC    PIN_A4
  143. #define BOTON_PROG   PIN_A3
  144. #define BOTON_UP     PIN_A2
  145. #define BOTON_DOWN   PIN_A1
  146.  
  147. #define BOTON_ENTER_PRES   !input(BOTON_ENTER)
  148. #define BOTON_ESC_PRES     !input(BOTON_ESC)
  149. #define BOTON_PROG_PRES    !input(BOTON_PROG)
  150. #define BOTON_UP_PRES      !input(BOTON_UP)
  151. #define BOTON_DOWN_PRES    !input(BOTON_DOWN)
  152.  
  153. int16 ms;
  154.  
  155. const char lcd_seg[16]={0x40,0x79,0x24,0x30,0x19,0x12,0x02,0x78,0x00,0x10,0x08,0x03,0x46,0x21,0x06,0x0E};   //0 for on, 1 for off
  156.  
  157. #int_timer2
  158. void isr_timer2(void) {
  159.    ms++; //keep a running timer that increments every milli-second
  160. }
  161.  
  162. #define ASK_FOR_ID_AD_B      0x201  //ask for AD info from CAN port B
  163. #define SET_LED_ID_B         0x202  //set LEDs for CAN port B
  164. #define RESPOND_TO_LED_C_ID  0x303
  165. #define WRITE_REGISTER_C_ID  0x300
  166. #define WRITE_REGISTER_D_ID  0x80400
  167. #define WRITE_PWM2_D_ID      0x301
  168.  
  169. void main() {
  170.    int b_leds=0;
  171.    int c_leds=1;
  172.    int a_leds=0;
  173.    int AD_NodoB=0;
  174.    struct rx_stat rxstat;
  175.    int32 rx_id;
  176.    int buffer[8];
  177.    int rx_len;
  178.  
  179.    int last_lcd_output=0xFF;
  180.    int i,curr_lcd_output;
  181.  
  182.    int16 curr_pwm2_duty, last_pwm2_duty;
  183.    int byte8_2_pwm2, byte1_0_pwm2;
  184.  
  185.    setup_port_a(AN0);
  186.    setup_adc(ADC_CLOCK_INTERNAL);
  187.    set_adc_channel(0);
  188.  
  189.    for(i=0;i<8;i++) {
  190.       buffer[i]=0;
  191.    }
  192.  
  193.    LED1_HIGH;
  194.    LED2_HIGH;
  195.    LED3_HIGH;
  196.    printf("\r\n\r\nEjemplo CAN CCS\r\n");
  197.    delay_ms(1000);
  198.    LED1_LOW;
  199.    LED2_LOW;
  200.    LED3_LOW;
  201.  
  202.    setup_timer_2(T2_DIV_BY_16,53,3);   //setup up timer2 to interrupt every 1ms if using 20Mhz clock
  203.  
  204.    lcd_init();
  205.    can_init();
  206.    lcd_putc("\f"); //borrar display
  207.  
  208.    enable_interrupts(INT_TIMER2);
  209.    enable_interrupts(GLOBAL);
  210.  
  211.    printf("\r\nMarchando...");
  212.  
  213.    lcd_gotoxy(1,1);
  214.    lcd_putc("Marchando..."); ///escribo en el LCD
  215.    lcd_gotoxy(1,2);
  216.    lcd_putc("GRACIAS ARIEL!!!"); ///escribo en el LCD
  217.  
  218.    while(TRUE)
  219.    {
  220.       if ( can_kbhit() )
  221.       {
  222.          printf("\r\n");
  223.          if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) {
  224.             if (rx_id == ASK_FOR_ID_AD_B) {
  225.                printf("Conversión AD Nodo B: %X\r\n",buffer[0]);
  226.                AD_NodoB = buffer[0];  //guardo valor del conversor AD
  227.             }
  228.             else if (rx_id == RESPOND_TO_LED_C_ID) {  //nodo C es un mcp25050 que envía un a mensaje ante la deteccion de un flanco
  229.                printf("Cambiando LEDs\r\n");            //in_data[0]=iointfl, in_data[1]=gpio
  230.                a_leds=(buffer[0]);
  231.                //a_leds=~(buffer[1]);  //cambiado para poder leer los bits enviados desde Nodo B
  232.                if (bit_test(a_leds,0)) {LED1_HIGH;} else {LED1_LOW;}
  233.                if (bit_test(a_leds,1)) {LED2_HIGH;} else {LED2_LOW;}   //idem anterior
  234.                if (bit_test(a_leds,2)) {LED3_HIGH;} else {LED3_LOW;}
  235.  
  236.             }
  237.          }
  238.       }
  239.  
  240.       if ( can_tbe() && (ms > 2000))       //every two seconds, send new data if transmit buffer is empty
  241.       {
  242.          ms=0;
  243.  
  244.          //change leds on port b
  245.          printf("\r\n\r\nEscribe LEDs en Nodo B a %U",b_leds);
  246.          can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);
  247.          /* if (bit_test(b_leds,0)) {LED1_HIGH;} else {LED1_LOW;}
  248.           if (bit_test(b_leds,1)) {LED2_HIGH;} else {LED2_LOW;}      //envio el dato a mis leds
  249.           if (bit_test(b_leds,2)) {LED3_HIGH;} else {LED3_LOW;}*/
  250.  
  251.                lcd_putc("\f"); //borrar display
  252.                printf(lcd_putc,"Leds Nodo B : %02u",b_leds); ///escribo en el LCD
  253.                lcd_gotoxy(1,2);
  254.                printf(lcd_putc,"Dato Conv.AD:%03u",AD_NodoB); ///escribo en el LCD
  255.  
  256.          b_leds++;
  257.          if (b_leds > 7) {b_leds=0;}
  258.  
  259.          // cuenta para enviar al nodo D
  260.          curr_lcd_output++;
  261.          if (curr_lcd_output > 15) {curr_lcd_output=0;}
  262.       }
  263.  
  264.       if (BOTON_ESC_PRES) {
  265.          while (BOTON_ESC_PRES) {}
  266.          delay_ms(200);
  267.  
  268.          //ask for AD on port B
  269.          printf("\r\n\r\nPidiendo lectura conversor A/D en Nodo B...");
  270.          can_putd(ASK_FOR_ID_AD_B, 0, 1, 1, 1, 1);
  271.  
  272.          //change LEDs on port C
  273.          buffer[0]=0x1E;            //addr of gplat on 25050
  274.          buffer[1]=0x0E;            //mask
  275.         // buffer[2]=~(c_leds << 1);  //new gplat
  276.          buffer[2]=(c_leds << 1);  //new gplat values
  277.          printf("\r\nIncrementar LED en Nodo C");
  278.          can_putd(WRITE_REGISTER_C_ID, &buffer[0], 3, 1, 1, 0);
  279.          c_leds++;
  280.          if (c_leds > 7) {c_leds=0;}
  281.       }
  282.  
  283.       if (BOTON_PROG_PRES) {  // APAGAR EL PWM 2
  284.          while (BOTON_PROG_PRES) {}
  285.          delay_ms(100);
  286.  
  287.          //Reprogramar el MCP25050 del Nodo C a todo salida digital
  288.          printf("\r\n\r\nReprogramando el Nodo C...");
  289.             buffer[0]=0x22;                    //direccion de timer de pwm2
  290.             buffer[1]=0x80;                     //mask
  291.             buffer[2]=0x00;                //apagar el timer de pwm2
  292.             can_putd(WRITE_REGISTER_C_ID, &buffer[0], 3, 1, 1, 0);
  293.       }
  294.      
  295.       if (BOTON_DOWN_PRES) {  // ENCENDER EL PWM 2
  296.          while (BOTON_DOWN_PRES) {}
  297.          delay_ms(100);
  298.  
  299.          //Reprogramar el MCP25050 del Nodo C a PWM2
  300.          printf("\r\n\r\nReprogramando el Nodo C...");
  301.             buffer[0]=0x22;                    //direccion de timer de pwm2
  302.             buffer[1]=0x80;                     //mask
  303.             buffer[2]=0x80;                //apagar el timer de pwm2
  304.             can_putd(WRITE_REGISTER_C_ID, &buffer[0], 3, 1, 1, 0);
  305.       }
  306.  
  307.          //change lcd segment on port d
  308.          i=read_adc();
  309.         // curr_lcd_output=i/26;   //scale to 0-9
  310.  
  311.          if (curr_lcd_output != last_lcd_output) {
  312.             last_lcd_output=curr_lcd_output;
  313.             printf("\r\nCambiando Display 7-seg Nodo D a cuentas del canal A/D (%X, %X)",i,curr_lcd_output);
  314.             buffer[0]=0x1E;                    //addr of gplat
  315.             buffer[1]=0x7F;             //mask
  316.             buffer[2]=lcd_seg[curr_lcd_output];                //new gplat values
  317.             can_putd(WRITE_REGISTER_D_ID, &buffer[0], 3, 1, 1, 0);
  318.          }
  319. // escribe nuevo valor en PWM2 Nodo C
  320.          if (curr_pwm2_duty != last_pwm2_duty) {
  321.             last_pwm2_duty=curr_pwm2_duty;
  322.             printf("\r\nCambiando Display 7-seg Nodo D a cuentas del canal A/D (%X, %X)",i,curr_lcd_output);
  323.             // Escribe los 8 bits altos del PWM2
  324.             byte1_0_pwm2= MAKE8((curr_pwm2_duty & 0x03),0);  //carga el valor del byte bajo
  325.             byte8_2_pwm2= MAKE8((curr_pwm2_duty << 6),1);  //carga el valor del byte alto
  326.                        
  327.             buffer[0]=0x26;                    //direccion de valor de pwm2
  328.             buffer[1]=0xFF;             //mask
  329.             buffer[2]=byte8_2_pwm2;                //new pwm2 values
  330.             can_putd(WRITE_REGISTER_C_ID, &buffer[0], 3, 1, 1, 0);
  331.             // Escribe los 2 bits bajos del PWM2
  332.             buffer[0]=0x22;                    //direccion de timer de pwm2
  333.             buffer[1]=0x03;             //mask
  334.             buffer[2]=byte1_0_pwm2;                //new pwm2 values
  335.             can_putd(WRITE_REGISTER_C_ID, &buffer[0], 3, 1, 1, 0);
  336.          }
  337.          if ((curr_pwm2_duty += 5) > 1023) {curr_pwm2_duty=0;}
  338.    }
  339. }

Nota:
Perdon por modificar tu codigo, pero es la forma de ordenar y a la vez mostrarte donde lo configuro, es en la linea...
Código: C
  1. #define Set_250K_Baud TRUE  /// Aqui configuro que velocidad del BUS utilizo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 25 de Marzo de 2008, 23:11:41
perdon pense que pegando quedaria bien ordenado , sin embargo me remito al primer programa que posteaste .

no encuentro la definicion de velocidad(en el nodo "A") de acuerdo a la modificacion que hiciste en la libreria . En el ejemplo que posteaste en el nodo B ahi si encuentro la velocidad definida.

Saludos desde Cordoba Argentina
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Marzo de 2008, 08:29:57
Cabe aclarar que para poder utilizar esta configuracion previamente cambie las lineas de configuracion de velocidad de la funcion CAN_SET_BAUD() del archivo can-18F4580.c


Código: C
  1. ////////////////////////////////////////////////////////////////////////
  2. //
  3. // can_set_baud()
  4. //
  5. ////////////////////////////////////////////////////////////////////////
  6. void can_set_baud(void) {
  7.    #ifdef Set_125K_Baud {
  8.       BRGCON1 = 0x01;
  9.       BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 125 KBps
  10.       BRGCON3 = 0x07;      //con reloj a 10 MHz
  11.    }
  12.    #endif
  13.    
  14.    #ifdef Set_250K_Baud {
  15.       BRGCON1 = 0x00;
  16.       BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 250 KBps
  17.       BRGCON3 = 0x07;      //con reloj a 10 MHz
  18.    }
  19.    #endif
  20.    
  21.    #ifdef Set_500K_Baud {
  22.       BRGCON1 = 0x00;
  23.       BRGCON2 = 0x92;      //modificado 5/11/07 para usar CAN a 500 KBps
  24.       BRGCON3 = 0x02;      //con reloj a 10 MHz
  25.    }
  26.    #endif
  27. /*
  28.    BRGCON1.brp=CAN_BRG_PRESCALAR;
  29.    BRGCON1.sjw=CAN_BRG_SYNCH_JUMP_WIDTH;
  30.  
  31.    BRGCON2.prseg=CAN_BRG_PROPAGATION_TIME;
  32.    BRGCON2.seg1ph=CAN_BRG_PHASE_SEGMENT_1;
  33.    BRGCON2.sam=CAN_BRG_SAM;
  34.    BRGCON2.seg2phts=CAN_BRG_SEG_2_PHASE_TS;
  35.  
  36.    BRGCON3.seg2ph=CAN_BRG_PHASE_SEGMENT_2;
  37.    BRGCON3.wakfil=CAN_BRG_WAKE_FILTER;*/
  38. }
  39.  
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 26 de Marzo de 2008, 14:04:29
gracias MGLSOFT:

La verdad me habia entrado la duda si en el nodo A se configuraba con los valores por default o con tu modificacion.
Ya tengolas placas casi listas serian 2  con pic18f258.
A medida que las vaya probando  les cuento.

Saludos desde Cordoba
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 26 de Marzo de 2008, 15:26:30
hola a todos aqui cuelgo el nodo principal de mi BUSCAN, en esta primera parte solo cuelgo el squematico, la parte del layout la estoy depurando. Utilizo el pic 18f458 el tranceiver mcp2551 y max232. los cmponentes son en smd (samples de microchip) :)¡¡¡
consta de 5 pulsadores, uno de reset, un canal ID (para elegir la prioridad del mensaje) y dos botones mas para elegir el dato que quiero transmitir. El nodo B sera muy parecido al este solo que no tendra coneccion rs232.
En el nodo principal utilizo la coneccion rs232 para monitorizar lo que estoy recibiendo del bus y dar ordenes atravez del ordenador  a los demas nodos atravez de una interfaz que estoy haciendo en labview.
espero comentarios (esta es una fase de prueva de comunicacion del bus) 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Marzo de 2008, 16:29:07
En apariencia todo esta OK, lo que no entiendo es porque al puerto de 8 bits que maneja los displays no lo tomaste completo, en vez de partirlo en dos nibbles, manejarlo completo es mas rapido y se hace con menos codigo.

Por lo demas , me parece barbaro!! :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 26 de Marzo de 2008, 16:36:32
pues porque el tipo de encapsulado que utilizo es TQFP y los puertos estan juntos en uno de los lados del 42 al 35¡¡

por lo demas si ves algo que no concuerde comentamelo, mañana colgare el layout que lo estoy acabando esta noche con seguridad. utilizo proltel si puedes decirme como colgar el archivo ya que ocupa mucho mas de lo que me permite colgar lo pongo aqui con mucho gust.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Marzo de 2008, 17:01:14
Lo que hago normalmente es enviarlo a imprimir en pdf, seleccionando Acrobat en la lista de impresoras... :lol: :lol:
Eso me permite colgar un archivo que al hacer zoom sobre el puedes ver bien los detalles.
El que colgaste esta ok, pero los detalles no son buenos.
Las imagenes las pongo en imageshack y aqui pongo el link a ellas.
Los archivos no los cuelgo del foro, sino que los subo a rapidshare y aqui pongo los links tambien. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 27 de Marzo de 2008, 16:48:35
hay va, lo prometido es deuda. aqui adjunto el layout del nodo principal. El nodo secundario sera practicamente igual
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marcos P.J en 27 de Marzo de 2008, 16:53:35
en cuanto tenga las placas insoladas y soldadas empezare con la programacion espero que no me lleve mucho tiempo. Cuando lo tenga listo lo cuelgo por aqui. Programare en CCS.

saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MiCrOtRoNiC en 27 de Marzo de 2008, 17:39:37
pues porque el tipo de encapsulado que utilizo es TQFP y los puertos estan juntos en uno de los lados del 42 al 35¡¡

por lo demas si ves algo que no concuerde comentamelo, mañana colgare el layout que lo estoy acabando esta noche con seguridad. utilizo proltel si puedes decirme como colgar el archivo ya que ocupa mucho mas de lo que me permite colgar lo pongo aqui con mucho gust.

los archivos lo puedes subir a

http://www.rapidshare.com/
http://www.badongo.com/es/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Abril de 2008, 22:54:08
Como va todo, muchachos?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 16 de Abril de 2008, 08:18:10
Hola MGLSOFT:

Cuando pones el bit RTR en 0 y cuando en 1?

Saludos desde Cordoba-Argentina


Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Abril de 2008, 10:19:16
El bit RTR implica enviar una trama remota (Remote TRame).
Usualmente se utiliza para enviar mensajes desde un nodo que normalmente es esclavo a otro igual.
Asi lo tengo entendido, voy a averiguar mas, hay poca informacion al respecto... :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Abril de 2008, 10:43:22
Bueno, en apariencia este bit exige a quien lo recibe que conteste devolviendo un valor requerido o lo que tenga programado hacer.
Es decir, el bit RTR activo exige respuesta del receptor del mensaje.

Ejemplo:
El master envia un mensaje con RTR activo al nodo de ID 302.
El nodo con ID 302 devuelve un mensaje con el valor del conversor A/D (puede ser el valor de una presion o temperatura).

Se entiende??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 17 de Abril de 2008, 08:19:31
Hola,


¿Alguien ha intentado leer algo del can bus del coche? Todos los coches de gasolina a partir del 2001 y los de gasoil a partir del 2004 llevan el Can Bus.

Yo estoy haciendo un proyecto sobre esto, aunque aun lo tengo poco avanzado.

Si quereis os puedo pasar un pdf con los tipos de tramas que vienen implementadas. Y a ver si podemos hacer algo interesante.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 17 de Abril de 2008, 08:26:08
Me parece barbaro!!
Seguramente servira mucho para quienes quieran implementar eso en un automovil.

Si luego vemos que toma forma, dividimos el tema y que tenga vida propia... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 17 de Abril de 2008, 09:25:41
Mi idea del proyecto consiste básicamente en construir un tacógrafo digital en el coche, extrayendo la info del canbus. Sería obtener por un lcd datos sobre velocidad, rpms, temperatura del motor... etc.

Y ya avanzando algo más en el tema, pues almacenarlos también en una tarjeta mmc y además lleva un interfaz RS232 para comunicar datos por el puerto serie a un pc. O para usarlo como interfaz de comunicación entre el pc y la ecu del coche.

Hay un dispositivo comercial que ya hace algunas de estas funciones, es el ELM327, que se vende por internet a un precio de unos 30€. Se basa en un pic 2480. Yo para mi proyecto estoy usando el 2580, que prácticamente es el mismo.

Aquí un pdf con la normativa SAE de comunicación con el coche, en varios protocolos, entre ellos el de Can Bus.

Normativa SAE OBD (http://www.4shared.com/file/44407716/d28e50c2/SAE_OBDII_j1979_200204.html)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 24 de Abril de 2008, 14:44:04
como va el tema del sniffer? jejeje

Yo ando con un pequeño desarrollo de can, que tengo que implementar un hardware en una red, de la cual no tengo informacion
y tengo que quitar un hardware para poner este, pero nose el id ni los datos que le llegan, asi que tendria que capturar el id y los datos para emularlos.

saludos de antonio :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Abril de 2008, 15:07:40
Por ahora esta en etapa de estudio las posibilidades tecnicas que tendra...
Como todo proyecto mio tiene un largo tiempo de "masticado" antes de implementarlo.
Como mi trabajo es de proyectista, se perfectamente que cuanto mas tiempo invierta en el proyecto, mas corto y eficiente sera el tiempo de implementacion.
Los años no vienen solos, por suerte... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 24 de Abril de 2008, 17:46:51
Yo ando con la idea de coger todos los datos que llegan y mandarlo por usb a un PC (id, trama, etc), pero la verdad que el C en pic no es mi fuerte, aunque ando con ganas y quiero aprender jejeje.

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Abril de 2008, 21:09:13
como va el tema del sniffer? jejeje

Yo ando con un pequeño desarrollo de can, que tengo que implementar un hardware en una red, de la cual no tengo informacion
y tengo que quitar un hardware para poner este, pero nose el id ni los datos que le llegan, asi que tendria que capturar el id y los datos para emularlos.

saludos de antonio :-/

Hay algo que deberas conocer si o si, y es la velocidad de comunicacion del bus CAN.
Por otro lado, si armas ese hardware sin el PIC, con solo los dos buffers y el transceptor CAN, podras utilizarlo desde un PC con el software gratuito CanKing.
Alli podras analizar tramas y ver identificadores, etcetera, aun sin tener el super Sniffer.

Este que yo planee, es un proyecto que va de menor a mayor, por ello esta opcion estuvo desde el principio lista para usar... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 25 de Abril de 2008, 15:40:28
Se puede eso del Canking y dos bufferes? Como seria? La velocidad la se porque la he medido con un osciloscopio, entonces por lo que dices no me haria falta un pic para interceptar los datos, no? muchas gracias

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Abril de 2008, 22:28:52
La parte de conexion al PC necesita los 74ls245, el MCP2515 y el MCP2550:

(http://img521.imageshack.us/img521/8940/sniffercanah9.jpg)

Si quieres mas info te la puedo enviar por privado... :mrgreen: :mrgreen:

Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 26 de Abril de 2008, 07:16:45
Te lo agradeceria si puedes hacerlo, jejejeje. Muchas gracias.

Un saludo de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LeoKenobi en 27 de Abril de 2008, 22:28:06
Saludos Amigos,

Master Marcos, en primer lugar me gustaría mucho agradecer su post. Yo empecé a desarrollar un panel de una máquina y cuando vi el número de hilos que se han decidido a tratar de pasar otra posibilidad, y era mi interés que surgió en la red CAN.

Se ha intentado en la red, pero fue gracias a su cargo todo lo que podía identificar, desarrollar y probar prototipos de mi trabajo con todas. Mi corazón de la brigado por su valiosa ayuda de su aliento, y me disculpo por no haber hecho esto antes, gracias, pero en dos intentos que se redujo el firefox, y usted no quiere venir aquí incomodá que sin saber lo suficiente para no repetir las mismas preguntas que otros han hecho.

Sin embargo, aunque yo vengo con una pregunta en ese momento si pudiera parasaber me elucidá. Para el proyecto el MCP 25050 sería perfecto porque todos los control de la máquina seneriam , pero estoy en duda acerca de cuáles son los parámetros que no puede cambiar la ruta de mensajes (es decir, cuál sería el mínimo necesario para arrancar i enteneder de los mensajes en el bus). Ya he terminado la base de desarrolladores del microchip en el kit (para utilizar el programa que viene con el kit).

Ahora estoy inmensamente agradecido por la ayuda.
Abrazo y gracias una vez más
Leonardo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Abril de 2008, 08:52:54
Estimado Leo, podras reescribir este mensaje en tu idioma natural, el portugues ???
Pasa que aunque soy incapaz de hablarlo, si puedo leerlo.
Lamentablemente la traduccion que has hecho no es buena, y se entiende menos que si lo escribieras en tu idioma natural.
Gracias. :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LeoKenobi en 28 de Abril de 2008, 11:42:33
Estimado Leo, podras reescribir este mensaje en tu idioma natural, el portugues ???
Pasa que aunque soy incapaz de hablarlo, si puedo leerlo.
Lamentablemente la traduccion que has hecho no es buena, y se entiende menos que si lo escribieras en tu idioma natural.
Gracias. :mrgreen: :mrgreen:

Mestre Marcos, peço desculpas, pois para ler oustras linguas consigo sem problemas, mas para escrever e fala outros idiomas sou muito ruim, dai escrevi em portugues e usei o tradutor do Google, mas percebo que ele sabe menos que eu..   :mrgreen:

Mas o que queria dizer era em primeiro agradecer muito pelo seu post. Cmecei a desenvolver
um painel para máquina e quando vi a quantidade de fios que teria de passar decidi tentar outra possibilidade, e foi dai que surgiu meu interresse na rede CAN. Procurei muito na net, mas foi graças a seu post que consegui entender melhor o funcionamento com PIC, desenvolver meus protótipos e testar com tudo funcionando perfeito de cara. Meu muito obrigado de coração pela sua valiosa ajuda, seu incentivo, e peço desculpas por não ter feito esse agradecimento antes.

Mas ao mesmo tempo estou com uma dúvida e peço se você poderia me elucidá-la. Para o projeto o MCP 25050 seria perfeito pois faria todo o controle da máquina descentralizado, mas estou na dúvida de quais são os parametros nele que não posso alterar via mensagens já que só posso programá-lo uma vez e pelos datasheets não consegui identificar o que seria o mínimo necessário para a inicialização dele + a compreenção das mensagens no bus.

Já fiz o programador baseado no kit da microchip (para poder usar o programa que o acompanha).

Fico imensamente grato pela ajuda e me disponho para qualquer coisa que possa ajudar daqui do Brasil.
Abraços a todos
Leonardo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Abril de 2008, 15:04:51
Bien, ahora se entiende mejor, no queria equivocar la respuesta, por eso te pedi escribieras en portugues.

Veo que necesitas ayuda sobre el MCP25050, que es un dispositivo magnifico para hacer cosas baratas pero limitadas.
Ya hablamos del mismo aqui en el foro.

Debes saber dos cosas del mismo:

Si bien el resto de los parametros son reprogramables por medio del bus CAN, debes saber que cada vez que el dispositivo pierde su alimentacion, vuelve a los valores con los cuales fue programado, por lo tanto es obvio que si lo programas como deseas de entrada, evitaras tener que reprogramarlo cada vez que reinicies el sistema.

Si mal no entiendo, tienes una placa desarrollo de Microchip, debo advertirte algo, el programa no graba correctamente los valores dentro del MCP25050 (hay mucha info en la WEB, incluso en el mismo foro de Microchip) por lo tanto te sugiero armarte de paciencia y de las herramientas necesarias para poder programarlos sin arruinarlos.

espero te sea de ayuda. :mrgreen: :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 28 de Abril de 2008, 21:53:26
Hola  Muchachos:

Miren aca hice una programacion y me detecta que recibe lo que mando pero aparece otra cosa , como ser yo mando la letra A ..como hexa de cimal  0x41 , o como caracter y recibo algo que nada que ver con la letra .
aca les publico el codigo.
Alguna sugerencia

#include "C:\Documents and Settings\Leo\Mis documentos\CAN\CAN_Mod_A\CAN_Mod_A.h"
#define CAN_USE_EXTENDED_ID TRUE

#include "flex_lcd1.c"
#define Set_125K_Baud TRUE
#include "can-18xxx8.c"

char  out_data[8];
int32 tx_id=24;
int1  tx_rtr=1;
int1  tx_ext=1;
int   tx_len=8;
int   tx_pri=3;
char  b0 = 0x30;
char  b1 = 0x41;
int   i, j;

#int_canrx0
void canrx0_int ( )
{
   lcd_putc("\fRX0");   
   delay_ms(500);   
}

#int_canrx1
void canrx1_int ( )
{
   lcd_putc("\fRX1");   
   delay_ms(500);   
}

#int_cantx0
void cantx0_int ( )
{
   if (i != 0xFF)
   {
      lcd_putc("\fEnvio OK");
      delay_ms(300);
      lcd_putc("\f");   
     
      for (j=0;j<tx_len;j++)
         printf(lcd_putc,"%c",out_data[j]);     
      delay_ms(2000);         
   }
   else
   {
      lcd_putc("\fEnvio Fallo");
      delay_ms(1000);           
   }           
}
#int_cantx1
void cantx1_int ( )
{
   if (i != 0xFF)
   {
      lcd_putc("\fEnvio OK");
      delay_ms(300);
      lcd_putc("\f");   
     
      for (j=0;j<tx_len;j++)
         printf(lcd_putc,"%c",out_data[j]);     
      delay_ms(2000);
   }
   else
   {
      lcd_putc("\fEnvio Fallo");
      delay_ms(1000);           
   }   
}
#int_cantx2
void cantx2_int ( )
{
   if (i != 0xFF)
   {
      lcd_putc("\fEnvio OK");
      delay_ms(300);
      lcd_putc("\f");   
     
      for (j=0;j<tx_len;j++)
         printf(lcd_putc,"%c",out_data[j]);     
      delay_ms(2000);
   }
   else
   {
      lcd_putc("\fEnvio Fallo");
      delay_ms(1000);           
   }   
}

void main()
{
   //int8 Buf_Env = 0;

   lcd_init();
   can_init();

   enable_interrupts(int_canrx0);
   enable_interrupts(int_canrx1);
   enable_interrupts(int_cantx0);
   enable_interrupts(int_cantx1);
   enable_interrupts(int_cantx2);

   port_b_pullups(TRUE);
   setup_adc_ports(NO_ANALOGS);
   setup_adc(ADC_OFF);
   setup_spi(SPI_SS_DISABLED);
   setup_wdt(WDT_OFF);
   setup_timer_0(RTCC_INTERNAL);
   setup_timer_1(T1_DISABLED);
   setup_timer_2(T2_DISABLED,0,1);
   setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
   enable_interrupts(GLOBAL);
   setup_low_volt_detect(FALSE);

   for(;;)
   {
      if(!input(PIN_B0))
      {
         lcd_putc("\fB0 PRES");
         delay_ms(1000);         
         
         b0 = 0x30;
         
         for (j=0;j<tx_len;j++)
         {
            out_data[j]=b0;
            b0++;
         }

         i=can_putd(tx_id, out_data, tx_len, tx_pri, tx_ext, tx_rtr);

      }
      if(!input(PIN_B1))
      {
         lcd_putc("\fB1 PRES");
         delay_ms(1000);
         
         b1 = 0x41;
         
         for (j=0;j<tx_len;j++)
         {
            out_data[j]=b1;
            b1++;
         }

         i=can_putd(tx_id, out_data, tx_len, tx_pri, tx_ext, tx_rtr);         
         
      }
      if(!input(PIN_B4))
      {
         lcd_putc("\fB4 PRES");
         delay_ms(1000);
         
         out_data[0] = 0x41;
         out_data[1] = 0x56;
         out_data[2] = 0x41;
         out_data[3] = 0x73;
         out_data[4] = 0x79;
         out_data[5] = 0x73;
         out_data[6] = 0x20;
         out_data[7] = 0x4C;
         
         i=can_putd(tx_id, out_data, tx_len, tx_pri, tx_ext, tx_rtr);         
         
      }     
      lcd_putc("\fMain A");
      delay_ms(100);     
   }

}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Abril de 2008, 22:00:57
Que clock tienes y podras publicar el archivo de encabezado??
Me refiero a CAN_Mod_A.h 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 29 de Abril de 2008, 09:01:51
Perdon tienes razon:


Aqui esta el encabezado


#include <18F258.h>
#device adc=8

#FUSES NOWDT                    //No Watch Dog Timer
#FUSES WDT128                   //Watch Dog Timer uses 1:128 Postscale
#FUSES HS                       //High speed Osc (> 4mhz)
#FUSES NOPROTECT                //Code not protected from reading
#FUSES NOOSCSEN                 //Oscillator switching is disabled, main oscillator is source
#FUSES BROWNOUT                 //Reset when brownout detected
#FUSES BORV20                   //Brownout reset at 2.0V
#FUSES PUT                      //Power Up Timer
#FUSES NOCPD                    //No EE protection
#FUSES STVREN                   //Stack full/underflow will cause reset
#FUSES NODEBUG                  //No Debug mode for ICD
#FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT                    //Program memory not write protected
#FUSES NOWRTD                   //Data EEPROM not write protected
#FUSES NOWRTB                   //Boot block not write protected
#FUSES NOCPB                    //No Boot Block code protection
#FUSES NOWRTC                   //configuration not registers write protected
#FUSES NOEBTR                   //Memory not protected from table reads
#FUSES NOEBTRB                  //Boot block not protected from table reads

#use delay(clock=20000000)





y aqui la libreria can 18xxx





/////////////////////////////////////////////////////////////////////////
////                        can-18xxx8.c                             ////
//// CAN Library routines for Microchip's PIC18Cxx8 and 18Fxx8 line  ////
////                                                                 ////
//// This library provides the following functions:                  ////
////  (for more information on these functions see the comment       ////
////   header above each function)                                   ////
////                                                                 ////
////    can_init - Configures the PIC18xxx8 CAN peripheral           ////
////                                                                 ////
////    can_set_baud - Sets the baud rate control registers          ////
////                                                                 ////
////    can_set_mode - Sets the CAN module into a specific mode      ////
////                                                                 ////
////    can_set_id - Sets the standard and extended ID               ////
////                                                                 ////
////    can_get_id - Gets the standard and extended ID               ////
////                                                                 ////
////    can_putd - Sends a message/request with specified ID         ////
////                                                                 ////
////    can_getd - Returns specifid message/request and ID           ////
////                                                                 ////
////    can_kbhit - Returns true if there is data in one of the      ////
////                receive buffers                                  ////
////                                                                 ////
////    can_tbe - Returns true if the transmit buffer is ready to    ////
////              send more data                                     ////
////                                                                 ////
////    can_abort - Aborts all pending transmissions                 ////
////                                                                 ////
//// PIN_B3 is CANRX, and PIN_B2 is CANTX.  You will need a CAN      ////
//// transeiver to connect these pins to CANH and CANL bus lines.    ////
////                                                                 ////
//// CCS provides an example, ex_can.c, which shows how to use this  ////
//// library.                                                        ////
////                                                                 ////
/////////////////////////////////////////////////////////////////////////
////                                                                 ////
//// Version History                                                 ////
////                                                                 ////
////  Jul 27 04 - can_init() uses CAN_USE_EXTENDED_ID instead of     ////
////              setting all RX filters to extended.                ////
////                                                                 ////
////  Feb 24 04 - can_get_id() fixed for EID<18:20>.                 ////
////                                                                 ////
/////////////////////////////////////////////////////////////////////////
////        (C) Copyright 1996,2003 Custom Computer Services         ////
//// This source code may only be used by licensed users of the CCS  ////
//// C compiler.  This source code may only be distributed to other  ////
//// licensed users of the CCS C compiler.  No other use,            ////
//// reproduction or distribution is permitted without written       ////
//// permission.  Derivative programs created using this software    ////
//// in object code form are not restricted in any way.              ////
/////////////////////////////////////////////////////////////////////////

#include <can-18xxx8.h>

#if CAN_DO_DEBUG
 #define can_debug printf
#else
 #define can_debug
#endif


//macros
#define can_kbhit()                 (RXB0CON.rxful || RXB1CON.rxful)
#define can_tbe()                   (!TXB0CON.txreq || !TXB1CON.txreq || !TXB2CON.txreq)
#define can_abort()                 (CANCON.abat=1)


////////////////////////////////////////////////////////////////////////
//
// can_init()
//
// Initializes PIC18xxx8 CAN peripheral.  Sets the RX filter and masks so the
// CAN peripheral will receive all incoming IDs.  Configures both RX buffers
// to only accept valid valid messages (as opposed to all messages, or all
// extended message, or all standard messages).  Also sets the tri-state
// setting of B2 to output, and B3 to input (apparently the CAN peripheral
// doesn't keep track of this)
//
// The constants (CAN_USE_RX_DOUBLE_BUFFER, CAN_ENABLE_DRIVE_HIGH,
// CAN_ENABLE_CAN_CAPTURE) are given a default define in the can-18xxx8.h file.
// These default values can be overwritten in the main code, but most
// applications will be fine with these defaults.
//
//////////////////////////////////////////////////////////////////////////////
void can_init(void) {
   can_set_mode(CAN_OP_CONFIG);   //must be in config mode before params can be set
   can_set_baud();

   RXB0CON=0;
   RXB0CON.rxm=CAN_RX_VALID;
   RXB0CON.rxb0dben=CAN_USE_RX_DOUBLE_BUFFER;
   RXB1CON=RXB0CON;

   CIOCON.endrhi=CAN_ENABLE_DRIVE_HIGH;
   CIOCON.cancap=CAN_ENABLE_CAN_CAPTURE;

   can_set_id(RX0MASK, CAN_MASK_ACCEPT_ALL, CAN_USE_EXTENDED_ID);  //set mask 0
   can_set_id(RX0FILTER0, 0, CAN_USE_EXTENDED_ID);  //set filter 0 of mask 0
   can_set_id(RX0FILTER1, 0, CAN_USE_EXTENDED_ID);  //set filter 1 of mask 0

   can_set_id(RX1MASK, CAN_MASK_ACCEPT_ALL, CAN_USE_EXTENDED_ID);  //set mask 1
   can_set_id(RX1FILTER2, 0, CAN_USE_EXTENDED_ID);  //set filter 0 of mask 1
   can_set_id(RX1FILTER3, 0, CAN_USE_EXTENDED_ID);  //set filter 1 of mask 1
   can_set_id(RX1FILTER4, 0, CAN_USE_EXTENDED_ID);  //set filter 2 of mask 1
   can_set_id(RX1FILTER5, 0, CAN_USE_EXTENDED_ID);  //set filter 3 of mask 1

   set_tris_b((*0xF93 & 0xFB ) | 0x08);   //b3 is out, b2 is in

   can_set_mode(CAN_OP_NORMAL);
}

////////////////////////////////////////////////////////////////////////
//
// can_set_baud()
//
// Configures the baud rate control registers.  All the defines here
// are defaulted in the can-18xxx8.h file.  These defaults can, and
// probably should, be overwritten in the main code.
//
// Current defaults are set to work with Microchip's MCP250xxx CAN
// Developers Kit if this PIC is running at 20Mhz.
//
////////////////////////////////////////////////////////////////////////
void can_set_baud(void) {
   #ifdef Set_125K_Baud
          {BRGCON1 = 0x03;
           BRGCON2 = 0xBA;
           BRGCON3 = 0x07;//modificado 5/11/07 para usar CAN a 125 KBps         ////con reloj a 20 MHz
 #endif   
 
  #ifdef Set_250K_Baud
  {      BRGCON1 = 0x01;
         BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 250 KBps
          BRGCON3 = 0x07;      //con reloj a 20 MHz
  }   #endif
 
  #ifdef Set_500K_Baud
  {      BRGCON1 = 0x00;
         BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 500 KBps
          BRGCON3 = 0x07;     //con reloj a 20 MHz
  }    #endif
 
 
 
  /*
  BRGCON1.brp=CAN_BRG_PRESCALAR;
   BRGCON1.sjw=CAN_BRG_SYNCH_JUMP_WIDTH;

   BRGCON2.prseg=CAN_BRG_PROPAGATION_TIME;
   BRGCON2.seg1ph=CAN_BRG_PHASE_SEGMENT_1;
   BRGCON2.sam=CAN_BRG_SAM;
   BRGCON2.seg2phts=CAN_BRG_SEG_2_PHASE_TS;

   BRGCON3.seg2ph=CAN_BRG_PHASE_SEGMENT_2;
   BRGCON3.wakfil=CAN_BRG_WAKE_FILTER;*/
}

void can_set_mode(CAN_OP_MODE mode) {
   CANCON.reqop=mode;
   while( (CANSTAT.opmode) != mode );
}


////////////////////////////////////////////////////////////////////////
//
// can_set_id()
//
// Configures the xxxxEIDL, xxxxEIDH, xxxxSIDL and xxxxSIDH registers to
// configure the defined buffer to use the specified ID
//
//   Paramaters:
//     addr - pointer to first byte of ID register, starting with xxxxEIDL.
//            For example, a pointer to RXM1EIDL
//     id - ID to set buffer to
//     ext - Set to TRUE if this buffer uses an extended ID, FALSE if not
//
////////////////////////////////////////////////////////////////////////
void can_set_id(int* addr, int32 id, int1 ext) {
   int *ptr;

   ptr=addr;

   if (ext) {  //extended
      //eidl
      *ptr=make8(id,0); //0:7

      //eidh
      ptr--;
      *ptr=make8(id,1); //8:15

      //sidl
      ptr--;
      *ptr=make8(id,2) & 0x03;   //16:17
      *ptr|=(make8(id,2) << 3) & 0xE0; //18:20
      *ptr|=0x08;


      //sidh
      ptr--;
      *ptr=((make8(id,2) >> 5) & 0x07 ); //21:23
      *ptr|=((make8(id,3) << 3) & 0xF8);//24:28
   }
   else {   //standard
      //eidl
      *ptr=0;

      //eidh
      ptr--;
      *ptr=0;

      //sidl
      ptr--;
      *ptr=(make8(id,0) << 5) & 0xE0;

      //sidh
      ptr--;
      *ptr=(make8(id,0) >> 3) & 0x1F;
      *ptr|=(make8(id,1) << 5) & 0xE0;
   }
}

////////////////////////////////////////////////////////////////////////
//
// can_get_id()
//
// Returns the ID of the specified buffer.  (The opposite of can_set_id())
// This is used after receiving a message, to see which ID sent the message.
//
//   Paramaters:
//     addr - pointer to first byte of ID register, starting with xxxxEIDL.
//            For example, a pointer to RXM1EIDL
//     ext - Set to TRUE if this buffer uses an extended ID, FALSE if not
//
//   Returns:
//     The ID of the buffer
//
////////////////////////////////////////////////////////////////////////
int32 can_get_id(int * addr, int1 ext) {
   int32 ret;
   int * ptr;

   ret=0;
   ptr=addr;

   if (ext) {
      ret=*ptr;  //eidl

      ptr--;     //eidh
      ret|=((int32)*ptr << 8);

      ptr--;     //sidl
      ret|=((int32)*ptr & 0x03) << 16;
      ret|=((int32)*ptr & 0xE0) << 13;

      ptr--;     //sidh
      ret|=((int32)*ptr << 21);

   }
   else {
      ptr-=2;    //sidl
      ret=((int32)*ptr & 0xE0) >> 5;

      ptr--;     //sidh
      ret|=((int32)*ptr << 3);
   }

   return(ret);
}

////////////////////////////////////////////////////////////////////////
//
// can_putd()
//
// Puts data on a transmit buffer, at which time the CAN peripheral will
// send when the CAN bus becomes available.
//
//    Paramaters:
//       id - ID to transmit data as
//       data - pointer to data to send
//       len - length of data to send
//       priority - priority of message.  The higher the number, the
//                  sooner the CAN peripheral will send the message.
//                  Numbers 0 through 3 are valid.
//       ext - TRUE to use an extended ID, FALSE if not
//       rtr - TRUE to set the RTR (request) bit in the ID, false if NOT
//
//    Returns:
//       If successful, it will return TRUE
//       If un-successful, will return FALSE
//
////////////////////////////////////////////////////////////////////////
int1 can_putd(int32 id, int *data, int len, int priority, int1 ext, int1 rtr) {
   int i;
   int * txd0;
   int port;

   txd0=&TXRXBaD0;

    // find emtpy transmitter
    //map access bank addresses to empty transmitter
   if (!TXB0CON.txreq) {
      CANCON.win=CAN_WIN_TX0;
      port=0;
   }
   else if (!TXB1CON.txreq) {
      CANCON.win=CAN_WIN_TX1;
      port=1;
   }
   else if (!TXB2CON.txreq) {
      CANCON.win=CAN_WIN_TX2;
      port=2;
   }
   else {
      #if CAN_DO_DEBUG
         can_debug("\r\nCAN_PUTD() FAIL: NO OPEN TX BUFFERS\r\n");
      #endif
      return(0);
   }

   //set priority.
   TXBaCON.txpri=priority;

   //set tx mask
   can_set_id(TXRXBaID, id, ext);

   //set tx data count
   TXBaDLC=len;
   TXBaDLC.rtr=rtr;

    for (i=0; i<len; i++) {
      *txd0=*data;
      txd0++;
      data++;
    }

   //enable transmission
   TXBaCON.txreq=1;

   CANCON.win=CAN_WIN_RX0;

   #if CAN_DO_DEBUG
            can_debug("\r\nCAN_PUTD(): BUFF=%U ID=%LX LEN=%U PRI=%U EXT=%U RTR=%U\r\n", port, id, len, priority, ext, rtr);
            if ((len)&&(!rtr)) {
               data-=len;
               can_debug("  DATA = ");
               for (i=0;i<len;i++) {
                  can_debug("%X ",*data);
                  data++;
               }
               can_debug("\r\n");
            }
   #endif

   return(1);
}

////////////////////////////////////////////////////////////////////////
//
// can_getd()
//
// Gets data from a receive buffer, if the data exists
//
//    Returns:
//      id - ID who sent message
//      data - pointer to array of data
//      len - length of received data
//      stat - structure holding some information (such as which buffer
//             recieved it, ext or standard, etc)
//
//    Returns:
//      Function call returns a TRUE if there was data in a RX buffer, FALSE
//      if there was none.
//
////////////////////////////////////////////////////////////////////////
int1 can_getd(int32 id, int *data, int len, struct rx_stat stat)
{
    int i;
    int * ptr;

    if (RXB0CON.rxful) {
        CANCON.win=CAN_WIN_RX0;
        stat.buffer=0;

        CAN_INT_RXB0IF=0;

        stat.err_ovfl=COMSTAT.rx0ovfl;
        COMSTAT.rx0ovfl=0;

        if (RXB0CON.rxb0dben) {
         stat.filthit=RXB0CON.filthit0;
        }
    }
    else if ( RXB1CON.rxful )
    {
        CANCON.win=CAN_WIN_RX1;
        stat.buffer=1;

        CAN_INT_RXB1IF=0;

        stat.err_ovfl=COMSTAT.rx1ovfl;
        COMSTAT.rx1ovfl=0;

        stat.filthit=RXB1CON.filthit;
    }
    else {
      #if CAN_DO_DEBUG
         can_debug("\r\nFAIL ON CAN_GETD(): NO MESSAGE IN BUFFER\r\n");
      #endif
      return (0);
    }

    len = RXBaDLC.dlc;
    stat.rtr=RXBaDLC.rtr;

    stat.ext=TXRXBaSIDL.ext;
    id=can_get_id(TXRXBaID,stat.ext);

    ptr = &TXRXBaD0;
    for ( i = 0; i < len; i++ ) {
        *data = *ptr;
        data++;
        ptr++;
    }

    // return to default addressing
    CANCON.win=CAN_WIN_RX0;

    stat.inv=CAN_INT_IRXIF;
    CAN_INT_IRXIF = 0;

    if (stat.buffer) {
      RXB1CON.rxful=0;
    }
    else {
      RXB0CON.rxful=0;
    }

    #if CAN_DO_DEBUG
       can_debug("\r\nCAN_GETD(): BUFF=%U ID=%LX LEN=%U OVF=%U ", stat.buffer, id, len, stat.err_ovfl);
       can_debug("FILT=%U RTR=%U EXT=%U INV=%U", stat.filthit, stat.rtr, stat.ext, stat.inv);
       if ((len)&&(!stat.rtr)) {
          data-=len;
          can_debug("\r\n    DATA = ");
          for (i=0;i<len;i++) {
            can_debug("%X ",*data);
            data++;
          }
       }
       can_debug("\r\n");
    #endif

    return(1);
}



Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Abril de 2008, 09:08:06
Podras poner el caracter que recibes??
En apariencia esta todo bien... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 29 de Abril de 2008, 10:31:46
Hola Marcos:

Ya a la tarde te respondere de los caracteres , por las dudas te envio el circuito ...aunque no creo que este mal.

saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 29 de Abril de 2008, 10:40:19
Mira  por ej se envia un caracter "A" ..como carater y recibo uno o con dieresis (parece un carácter aleman), otras veces envio la A y me pone donde deberia aparecer el caracter un cuadrado negro , también probe de mandarlo como ascii ...y nada . Eso es en cuanto  al tema caracter. o lo que sea que se quiera enviar

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Abril de 2008, 11:56:44
Por que pusiste ese capacitor entre las lineas CANH y CANL ??
Me refiero al capacitor C10 de 100pF.

Existe realmente??
Si es asi prueba cortar una de sus patillas... y comenta como te fue. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LeoKenobi en 30 de Abril de 2008, 01:07:17
Bien, ahora se entiende mejor, no queria equivocar la respuesta, por eso te pedi escribieras en portugues.

Veo que necesitas ayuda sobre el MCP25050, que es un dispositivo magnifico para hacer cosas baratas pero limitadas.
Ya hablamos del mismo aqui en el foro.

Debes saber dos cosas del mismo:
  • debes especificar cuales tareas hara el dispositivo en el bus CAN a la perfeccion, ya que es OTP (One Time Programming)
  • los parametros o direcciones que NO se pueden cambiar luego haciendo uso del BUS CAN son todos aquellos que programan a que velocidad y modo trabajara el dispositivo en el BUS, por razones obvias son los que debes conocer antes que todo

Si bien el resto de los parametros son reprogramables por medio del bus CAN, debes saber que cada vez que el dispositivo pierde su alimentacion, vuelve a los valores con los cuales fue programado, por lo tanto es obvio que si lo programas como deseas de entrada, evitaras tener que reprogramarlo cada vez que reinicies el sistema.

Si mal no entiendo, tienes una placa desarrollo de Microchip, debo advertirte algo, el programa no graba correctamente los valores dentro del MCP25050 (hay mucha info en la WEB, incluso en el mismo foro de Microchip) por lo tanto te sugiero armarte de paciencia y de las herramientas necesarias para poder programarlos sin arruinarlos.

espero te sea de ayuda. :mrgreen: :mrgreen: :mrgreen:

Mestre Marcos, mais uma vez me desculpe pela vergonha com as linguas...

Mas sim, foi de muita ajuda, porque estava na duvida se tinha mais algum parametro critico que podeira arruinar o bichinho, alem da velociade do bus (250 Kbps no projeto) e o modo de trabalho. Embora sabendo que todos os parametros tem de estar de acordo, o mais crítico era não correr o risco de perde-lo, mas tendo a certeza já fico mais tranquilo.

Sobre o programa, acho que interpretei mal o que li então.. porque o que tinha entendido é que o programador do kit da microchip era ruim, e por isso fiz um basedo apenas nos sinais de controle, e não baseado no circuito. Mas se é programa que é ruim, vou verificar outra opção então.

Mais uma vez muito obrigado pela ajuda.
Grande Abraço a todos   
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Abril de 2008, 09:12:25
Yo utilize el software que provee Microchip para hacer la aplicacion, el problema es que no guarda la aplicacion en formato .hex, por lo tanto hay que obligarlo a hacerlo.
Cuando fui a programar el chip, mi programador me dijo que el archivo no correspondia con el cheksum, afortunadamente no me dejo grabarlo, sino lo perdia....

La aplicacion la hice con las plantillas que vienen con el MPLAB y las compile con el MPLAB, luego las pase al chip con el ICDS40 que tengo, que permite hacerlo, ya que los programadores de Microchip no lo soportan, salvo los grandes... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: LeoKenobi en 03 de Mayo de 2008, 15:28:30
Yo utilize el software que provee Microchip para hacer la aplicacion, el problema es que no guarda la aplicacion en formato .hex, por lo tanto hay que obligarlo a hacerlo.
Cuando fui a programar el chip, mi programador me dijo que el archivo no correspondia con el cheksum, afortunadamente no me dejo grabarlo, sino lo perdia....

La aplicacion la hice con las plantillas que vienen con el MPLAB y las compile con el MPLAB, luego las pase al chip con el ICDS40 que tengo, que permite hacerlo, ya que los programadores de Microchip no lo soportan, salvo los grandes... :mrgreen:

É Mestre marcos, estou realmente apanhando aqui... infelizmente só tenho um ICD2br que não tem a possibilidade de gravar o mcp25050, e mesmo com o gravador operando não consigo fazer o programa da microchip funcionar. Me empolguei tanto quando achei o manual com o esquema e e programa que não tinha pesquisado mais a fundo para saber que não funcionava direito... :(

Bom, acho que vou usar o mcp2515 com 16f628a mesmo... já tinha feito uma tentativa com o 2515 e o 16f877a e funcionou. Mas de qualaquer forma agradeço a ajuda e precisando que alguma coisa daqui por contar.

Grande abraço a todos
Leonardo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Mayo de 2008, 18:33:11
Hola Leo!!
Dime con que lengueje programas??
Si es C de CCS, puede hacerte un adaptador para programar el MCP25050 a traves del ICDS40, del cual hay planos y firmware en la web para hacertelo.
No desistas de utilizarlos, son unos chips excelentes para ciertas aplicaciones, ya que tienen resuelto en el hardware el protocolo CAN...
Si precisas ayuda puedo proporcionartela, escribeme al privado... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Mayo de 2008, 14:50:11
Leo, deberias leerte la nota de aplicacion de Microchip AN815 titulada:
Understanding the MCP250XX Devices

Te ayudara a entender estos chips y como programarlos... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: kdaver en 09 de Mayo de 2008, 17:27:04
MGLsoft:

Hola, soy nuevo en este foro y en CAN, y tengo algunas dudas a ver si me las puedes contestar:

1.- ¿los nodos can tiene que armarlos uno mismo o existe en elk mercado un nodo por asi decir "generico", que sirva para conectarlo con otro y poder comunicarse?
2.- ¿es posible utilizar estos nodos en un proyecto de domotica?, por lo que he leido en otros lados, si, pero no he visto ningun proyecto desarrollado.

A mi coterraneo de electrolinux:
Los micros para el protocolo CAN los compraste afuera o existe algun lugar donde poder adquirirlos?

eso, si alguien puede responder a mis preguntas, se agradece!!!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Mayo de 2008, 18:48:19
Hola y bienvenido al foro, Kdaver!!

Me gusta tu actitud, a pasar al rio por la parte mas profunda, me haces acordar a mi hace unos años... :mrgreen: :mrgreen:

Respuesta 1:
Hay de todo, desde modulos CAN que hacen lo que quieres, Sniffers para hacer debug o control, software de control, etcetera. Hay buenos y malos, caros y no tan caros, pero te recomendaria te armes de una placa desarrollo que te permita hacer tus experencias sin depender de los demas...

Respuesta 2:
Si que es posible, es mas hay muchos proyectos de domotica que se estan desarrollando sobre este BUS, que es uno de los mas confiables en funcionamiento, ya que fue desarrollado para uno de los ambientes mas hostiles, como es un automovil...

Espero haber respondido bien tus inquietudes, en cuanto a donde conseguir componentes en Chile, no tengo idea, pero hay muchos foristas coterraneos tuyos aqui en el foro, que seguramente podran ayudarte en eso, te sugiero hacer uso del mensaje privado para esas consultas.

Saludos!! :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: escarpa en 11 de Mayo de 2008, 12:59:12
hola!

Os dejo unas preguntas, primero generales, y luego ire indagando más

Es necesario, darle una ID fija a cada nodo?, en tal caso con que función fijais esa ID.
o es posible recibir la trama, sea cual sea, capturar la ID y comparar con una variable donde tenga esa ID.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Mayo de 2008, 21:13:07
Hay dos formas en que un nodo CAN recibe y clasifica un mensaje.
La primaria es con una ID, que puede ser fija o si esta hecho el nodo en base a un microcontrolador, puedes modificar una parte o toda la direccion con dip switch, desde los cuales puedes adaptar tu modulo a direcciones distintas a las que normalmente serian fijas.
El segundo modo de clasificar un mensaje para responder o no, es a traves de los filtros de los buffer de recepcion, donde puedes setearlos para recibir una direccion determinada, un rango de direcciones, o simplemente no responder a una o varias direcciones que hayan emitido el mensaje.

Lo que dices en la ultima frase tuya es lo que normalmente hace un nodo, comparar la direccion recibida con la propia a ver si debe o no ejecutar accion alguna... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: betin en 12 de Mayo de 2008, 20:46:18
Los recursos del Nodo B son los siguientes:

  • Zócalos para líneas de PIC de 28 y 40 pines, puede usarse un PIC sin CAN o la línea PIC18 con CAN incorporado.
  • Hardware de comunicacion CAN a PC con software CanKing (permite hacer Debug del BUS CAN).
  • Memoria 93C86 con interfaz SPI.
  • Pulsador para pruebas.
  • Conjunto de LEDs en configuración semáforo.
  • Un puerto completo de LEDs.
  • Canal de comunicación serial.
  • Conector ICD / ICSP, para programación In Circuit y Debug.
  • Controlador CAN MCP2515, para utilizar con micros sin CAN incorporado.
  • Selector de origen de Controlador CAN.
  • Hardware de comunicación CAN.


Primero gracias por la respuesta anterior, ahora otra, cuando mencionas el 2515, lo haces vinculado a la frase para utilizar con micros sin CAN incorporado, entonces es posible omitir esta pieza cuando se utilizan chips con CAN incorporado, o es imprescindible para cualquier configuracion.
Me explico si tienes varios chips de cualquier gama que incorporen CAN o ECAN son necesarios los transceivers y el 25050, o los micros se pueden comunicar entre si sin la necesidad de estos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Mayo de 2008, 21:48:48
Entendiste bien, si usas PICs con CAN o ECAN incorporado, solo necesitas el transceiver MCP2551 para conectar cada PIC al BUS CAN, nada de lo demas....

Si el PIC no tiene CAN, la estructura es PIC >> MCP2515 >> MCP2551  , es decir agregas el 2515... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: aismirlian en 13 de Mayo de 2008, 11:11:31
BUENAS!! Antes que nada quiero comentarles que soy nuevo en el foro y espero poder aportar con mi escaso conocimiento.

Pero en esta oportunidad los molesto ya que tengo que hacer funcionar algo y lei varios de sus posts, y llegue a la conclusion de que la tienen bastante clara con CAN BUS.

Mi problema es el siguiente:

Tengo que hacer andar esta plaqueta:

http://www.emicros.com/microcan/#Introduction

y no consigo el software que me pueda llegar a manejarla, el problema mas grave es que no tiene PIC y no tengo tiempo de ponerme a programar uno, asi que si alguien sabe de algun software que me pueda llegar a manejar esa plaqueta por favor chifle.

Desde ya muchas gracias!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Mayo de 2008, 11:39:16
Compara ese esquema con el que yo puse aqui en el hilo del sniffer CAN (obviando el microcontrolador), si es similar, puedes usar el software CanKing...que es gratuito.
Si no la opcion es que armes el sniffer que yo puse en el foro, que si es compatible con CanKing. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfh900 en 13 de Mayo de 2008, 14:11:02
Esta claro que tus conocimientos son escasos. En primer lugar no puedes programar el PIC por que no lleva ningún PIC y en segundo lugar tienes el programa de control de la placa en la página que pusistes, claro está para hacer el programa en Delphi. Lo unico que necesitas es ponerte a trabajar, por que tienes todos los elementos.

Un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Mayo de 2008, 14:13:47
Ese lenguaje es Delphi??
No lo conocia... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfh900 en 13 de Mayo de 2008, 15:05:38
Si es Delphi:

Software     

The software to control the MicroCAN is written using Borland's Delphi programming language and runs under either Windows 95/98. Delphi is a powerful development environment for Windows applications. The object Pascal is similiar enough to C allowing applications to be built quickly and easily. The software is contained in the MicroCAN.dpr file.

Un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: kdaver en 13 de Mayo de 2008, 16:17:37
MGLSOFT!!

Hola de nuevo, sorry no pude responder antes, es que telefonica me habia suspendido el servicio y no me lo repuso hasta ahora, para armarme
una placa como sugieres, cuales son los componentes basicos que esta debe tener?
por lo que entiendo de lo que tu has hecho aca, la placa consta o esta formada por varios nodos CAN a los cuales envias informacion,
es eso correcto o entendi mal el esquema?

otra cosa: alquien sabe donde hay un ejemplo de domotica utilizando can?
porfa!!!!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Mayo de 2008, 23:18:34
No conozco ejemplos "firmes" que usen CAN como bus...
En todo caso hasta donde da mi conocimiento el EIB tiene algo de pimienta parecida...

En cuanto a que componentes debe tener tu placa, no lo se, primero yo definiria que funciones quiero obtener de la misma, antes de definir que componentes voy a tener.
Supongo que en todo el foro no vas a obtener una respuesta muy diferente.. :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: aismirlian en 14 de Mayo de 2008, 10:04:24
Antes que nada, jfh900, tengo conocimientos escasos porque no me puse a leer bien la pagina ya que me dedique a armar el hardware directamente, asi que admito fue mi error.

Es cierto el Borland Delphi es el legunaje que me va a permitir manejar esta plaqueta, ahora me voy a poner a usarlo para empezar a familiarizarme (sera parecido al C, o al ASM??)

En cuanto al proposito de este proyecto, es simular el auto, o sea yo quiero mandar datos por medio del puerto paralelo (donde ira colgada la plaqueta) y a la salida obtenerlos el CAN_L y CAN_H.

En cuanto progrese el proyecto seguire escribiendoles asi si alguien lo necesita ya tiene como hacerlo.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jfh900 en 14 de Mayo de 2008, 16:27:58
Hola aismirlian no te tomes a mal mi comentario, solo que muchas veces miramos la información de forma apresurada y no nos esteramos de los requerimientos ni de las necesidades para llevar a buen puerto el proyecto.

Respecto a Delphi decirte que es Pascal orientado a objetos y controlado por eventos (como todas las aplicaciones sobre Windows), es similar a "C" pero más estructurado (dicen las malas lenguas que es el mejor lenguaje para aprender programación, ya que no se adquieren "malos vicios").

Por cierto muy buena página la que pusiste, por que es una plaquita sencilla y fácil de montar.

Adelante con tu proyecto y no dudes en preguntar lo que necesites.

Un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: aismirlian en 15 de Mayo de 2008, 09:36:13
No lo tome a mal, fue un comentario nomas, gracias igualmente por los consejos, estamos en contacto!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: kdaver en 15 de Mayo de 2008, 12:40:52
gracias mglsoft por tus respuestas,
me han aclarado un poco el panorama.

otra cosa sabes donde puedo encontrar informacion  sobre CAN, como el tipo de cableado,
la cantidad maxima de nodos, componentes basicos de un nodo, etc...

se agradece!!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Mayo de 2008, 14:31:12
Se que el hilo ya lleva 22 paginas, y que se pone denso leerlo todo, pero te sugiero leerlo completo, porque esto que me preguntas, esta explicado a lo largo del hilo... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: kdaver en 15 de Mayo de 2008, 16:26:34
si me  he leido casi todo el hilo, unas 15 pag mas o menos
pero a lo ke me referia es a ke si tienes algunos documentos o algunas
paginas donde sacar información, esop,
si no tienes de todas maneras agradesco ke me hallas respondido mis
consultas!!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Mayo de 2008, 17:15:03
Las paginas del tema que tienen la info sobre CAN BUS mas didactica estan entre la 15 y la 18.
Si no las viste te las recomiendo.

Como dijiste que te interesa la domotica, te recomiendo este sitio:
http://www.domoprac.com/ (http://www.domoprac.com/)

Alli hablan de los buses utilizados comercialmente.

En realidad CAN esta presente mucho mas en edificios que en casas, pero eso no quita que no se pueda o deba hacer...

Tambien puedes ver sobre CAN en:
http://www.canbus.us/#Books (http://www.canbus.us/#Books)               <<  pagina en ingles
http://www.diveng.net/ (http://www.diveng.net/)                        << tambien en ingles
http://www.can-cia.de/ (http://www.can-cia.de/)

debo tener mas links, pero con estos ya puedes entretenerte, creo. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: kdaver en 15 de Mayo de 2008, 18:49:46
mas que suficiente por el momento,

el asunto de domotica es ke en mi proyecto de tesis
estamos investigando domotica!!!!!

ahora voy a revisar las paginas  que me diste

muchas gracias!!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Mayo de 2008, 19:56:55
Muy bien.
Esa pagina tiene ademas de mucha informacion, varios enlaces interesantes, no tiene desperdicio... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ekys en 19 de Mayo de 2008, 15:44:59
Hola a todos,

llevo tiempo pateandome este hilo y primero de todo me dirigo a MGLSOFT para elogiar el altruismo demostrado en todo este tiempo, y lo digo en el sentido de que pocas personas se tomarian las molestias que el se ha tomado para ayudar a otras que como yo, se encuentran atascadas en este mundillo.

Bien, el caso es que estoy interesado con el protocolo CAN y mi intencion es realizar un analizador logico de este. En principio todo se va a quedar en una simulacion sin implementacion fisica, y para ello utilizo Proteus para realizar pruebas MUY sencillas
(de momento) con este protocolo.

El diseno consiste en dos pics 18F458 conectados directamente a traves de sus pines CANTX y CANRX, y la pequeña prueba que realizo para comprobar que se efectua la comunicacion se basa en que el 18F458_emisor cada 5 seg envia un simple caracter al 18F458_receptor para que posteriormente el 18F458_receptor saque por pantalla via RS-232 el dato recibido. Lo tengo que hacer asi porque no existe ningun simulador de circuitos (o por lo menos que yo sepa) que implemente transceivers tipo MCP2551 o 82C250, ademas de que esta es la unica manera que se me ocurre para poder simular las tramas CAN que necesito para su posterior analisis.

El problema que me antane es que cuando inicio la simulacion no se ve nada y en el log del Proteus aparecen interminables mensajes del tipo:

[PIC18MEMORY]PC=0x0010. Read of CAN Controller register 0x0F6F(CANCON) returns las value stored.
[PIC18MEMORY]PC=0x0014. Write 0x8A to CAN Controller register at 0x0F6F(CANCON) only stores value.
[PIC18MEMORY]PC=0x0016. Read of CAN Controller register 0x0F6E(CANSTAT) returns las value stored.
[PIC18MEMORY]PC=0x0016. Read of CAN Controller register 0x0F6E(CANSTAT) returns las value stored.
[PIC18MEMORY]PC=0x0016. Read of CAN Controller register 0x0F6E(CANSTAT) returns las value stored.
...
(y asi infinitamente)

Les adjunto el diseno en Proteus y les copypasteo los dos códigos:

Código: [Seleccionar]

*******************
*   *
* 18F458_emisor.c *
*   *
*******************


#include <18F458.h>
#use delay(clock=2000000)
#include "can-18xxx8.c"

void main(void)
{
   int DATA_TX=5;
   can_init();
   enable_interrupts(GLOBAL);
   while(true)
   {
    can_putd(0, &DATA_TX, 1, 1, 1, 0);
delay_ms(5000);
   }

}


*********************
*     *
* 18F458_receptor.c *
*     *
*********************


#include <18F458.h>
#fuses HS,NOPROTECT,NOLVP,NOWDT
#use delay(clock=20000000)
#include "can-18xxx8.c"
#use rs232(baud=9600,bits=8,parity=N,xmit=PIN_C6,rcv=PIN_C7)

void main(void)
{
   int data[8];
   struct rx_stat rxstat;
   int32 id;
   int leng;

   int i;
   for(i=0;i<8;i++) {
      data[i]=0;
   }

   can_init();
   enable_interrupts(GLOBAL);
   while (true)
   {
      if ( can_kbhit() )
      {
if(can_getd(id, &data[0], leng, rxstat))
{
                printf("%s", "Se ha transmitido via CAN el caracter: ");
            printf("\%X\r", data[0]);
          }
       }
   }
}

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Mayo de 2008, 18:08:39
Por favor sube aqui los dos archivos compilados para verlos, aparentemente el proteus no simula CAN, pero ademas veo que le pones cristales de 20 mhz y los ejemplos de CCS son para cristales de 16 MHz (hay que respetar las velocidades porque eso da las velocidades del bus CAN.
Puedes verlo durante el transcurso del hilo, la incidencia que tiene la frecuencia del reloj sobre la velocidad del BUS.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ekys en 19 de Mayo de 2008, 21:03:34
veo que le pones cristales de 20 mhz y los ejemplos de CCS son para cristales de 16 MHz (hay que respetar las velocidades porque eso da las velocidades del bus CAN.
Puedes verlo durante el transcurso del hilo, la incidencia que tiene la frecuencia del reloj sobre la velocidad del BUS.

Cierto. Inicialmente los puse a 16Mhz pero lo probe a diferentes velocidades entre ellas 20Mhz para ver que efecto producian.... no producian ninguno.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: betin en 20 de Mayo de 2008, 19:21:22
 :g) Hola, perdon por perderme; pero mi proyecto me tiene loco, ya no se me ocurre q mas hacer, a si que diganme en que simulador encuentro el PIC 18F4685?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Mayo de 2008, 08:33:16
:g) Hola, perdon por perderme; pero mi proyecto me tiene loco, ya no se me ocurre q mas hacer, a si que diganme en que simulador encuentro el PIC 18F4685?

No tengo idea que simulador puede trabajar con CAN.
Yo mas vale apostaria a armar un circuito que a emularlo... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Mayo de 2008, 08:45:48
veo que le pones cristales de 20 mhz y los ejemplos de CCS son para cristales de 16 MHz (hay que respetar las velocidades porque eso da las velocidades del bus CAN.
Puedes verlo durante el transcurso del hilo, la incidencia que tiene la frecuencia del reloj sobre la velocidad del BUS.

Cierto. Inicialmente los puse a 16Mhz pero lo probe a diferentes velocidades entre ellas 20Mhz para ver que efecto producian.... no producian ninguno.

Ya lo simule, y obtengo lo mismo que tu, no pasa nada con el modulo CAN, es evidente que Proteus es incapaz de simularlo.
Lo lamento, y repito, yo armaria una placa en vez de intentar simularlo. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ekys en 21 de Mayo de 2008, 11:04:26
Buff... esto es desalentador. Lo que no entiendo entonces es porque demonios proteus permite utilizar PICs de la serie 18Fxx8 que son los que incorparan CAN.

A nadie se le ocurre ninguna manera de poder simular una comunicacion CAN entre pics?????? Estoy desesperado.


PD: De todas maneras, gracias x las molestias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Mayo de 2008, 11:25:41
Yo en mis pruebas active los marcadores de lineas con colores, y la verdad es que en ningun momento se le ocurrio a Proteus intentar cambiar el estado de una de ellas... :( :(
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 23 de Mayo de 2008, 20:25:11
hola a todos estoy desarrollando un controlador de sistema de aire acondicionado e iluminacion con protocolo can estoy utilizando pic1f258 a 10MHz he trabajado con las plantillas que proporciona microchip igual que las que ocupan uds pero yo las uso en ensamblador, lo estoy simulando en mplab 8 (por cierto si lo quieren lo tengo con medicina), el problema que me da por el momento es que en el simulador se queda trabado en el registro
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 23 de Mayo de 2008, 20:28:47
 :-/ SE QUEDA TRABADO EN CANSTAT CUANDO QUIERO PONERLE EL MODO NORMAL DEL CAN
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 23 de Mayo de 2008, 21:03:59
aqui les pongo el codigo que estoy utilizando

;    El siguiente programa configura al PIC18F258 para operar
;   en comunicacion CAN Bus con ID=0x001 para captura de datos que
;   posteriormente son enviados al nodo 2.

   list p=18f258
   #include <p18F258.inc>
; oscillator selection
   CONFIG   OSC = HS

;   Secccion de Memoria Reservada   
#DEFINE   NODO1_SOURCE
   
   #include "CAN18.inc"
   

   
NODO1 UDATA   
W_temp      res   01
Status_temp   res   01
BSR_temp   res   01
PRO_temp   res   01


   
   org   0x0000
   goto   Init
   
   org   0x0008
   goto   HighPINT
   
   org   0x0018
   goto   LowPINT


NODO1_SOURCE CODE
   org   0x00100   
Init:

;   Configuracion de los Puertos del PIC

   initPORTA    OUT & PIN_0          ;^ PIN_1 ^ OUT            
                     ; Puerto A SALIDA  RA0
   movlw      0x07            
   iorwf      ADCON1,f      
   
   initPORTB   IN & PIN_0 ^ PIN_1 ^ PIN_3 ^ OUT
                     ; Puerto B con entradas RB0, RB1 y RB2
                     ; el resto salidas
                     
   initPORTC   IN            ; Puerto C completo como ENTRADAS

;    Configurando Interrupciones   

   bsf   RCON, IPEN      ; habilita prioridad de interrupcion
   ;bsf   INTCON, GIEH      ; habilita prioridad alta
   movlw   B'11010000'
   movwf   INTCON
   movlw   B'01100000'      ; habilita interrupcion en flanco de bajada
   movwf   INTCON2         ; habilita interrupcion en flanco de bajada
   movlw   B'00001000'      ; habilita prioridad alta para int1
   movwf   INTCON3         ; tambien habilita interrupcion 1 y 2
   
   ;movlw      0xD0            ; Habilitando las interrupciones de
   ;movwf      INTCON            ; GIEH, GIEL e INT0 (High Priority)            
   ;movlw      0xE0            ; Configurando interrupciones en Rising Edge
   ;movwf      INTCON2            ; para INT0 e INT1
   ;movlw      0x08            ; Habilitando interrupciones por INT1
   ;movwf      INTCON3            ; en Low Priority
   SETF   PIE3               ; HABILITA TODAS LAS INTERRUPCIONES DEL CAN
   setf   IPR3            ; Interrupciones CAN todas en High Priority
   CLRF   PIR3
   

;   Configuracion del Modulo CAN         

;   Inicializando el Modulo
   
   CANInitialize   1, 5, 7, 6, 2, CAN_CONFIG_LINE_FILTER_ON & CAN_CONFIG_VALID_STD_MSG

;   Configurando los Filtros y Mascaras, Modo de Operacion en Configuracion

   CANSetOperationMode   CAN_OP_MODE_CONFIG
   
;   Estableciendo la Mascara del Buffer 0

   CANSetReg   CAN_MASK_B0, 0x00000007, CAN_CONFIG_STD_MSG
   
;   Filtro RX0 Buffer 0

   CANSetReg   CAN_FILTER_B0_F1, 0x00000000, CAN_CONFIG_STD_MSG

;   Filtro RX1 Buffer 0

   CANSetReg   CAN_FILTER_B0_F2, 0x00000002, CAN_CONFIG_STD_MSG

;   Estableciendo el Modo de Operacion Normal

   CANSetOperationMode   CAN_OP_MODE_NORMAL

Main:   goto   Main


;************************************************************
;
;      ATENCION DE INTERRUPCIONES
;
;************************************************************

;**********INTERRUPCIONES CON ALTA PRIORIDAD*****************
HighPINT:

   DISABLE_GIE
   SAVE_STATUS_W_BSR

   btfss   INTCON3,INT1IF   ; REVISA SI FUE ESTA LA INTERRUPCION QUE SE GENERO
   bra    OTRO
   goto    pinb2
OTRO:   btfss   INTCON,INT0IF   ; revisa si fue generada int0
   BRA   OTRO2

pinb1:            ;atencion a interrupcin int0

   bcf   INTCON,INT0IF   ;limpia bandera de interrupcion
   RESTORE_STATUS_W_BSR   ;reestablece registros
   ENABLE_GIE      ;habilita interrupcion global
   retfie   

pinb2:            ;atencion a interrupcion int1
   
   bcf   INTCON3,INT1IF   ;limpia bandera de interrupcion
   RESTORE_STATUS_W_BSR   ;reestablece registros
   ENABLE_GIE      ;habilita interrupcion global
   retfie

OTRO2:
   

;   call    CANISR

   banksel   PIR3
   btfss   PIR3,IRXIF
   goto   IsWAKIF
   goto   AbortU
IsWAKIF:
   btfss   PIR3,WAKIF
   goto   IsERRIF
   goto   EndHigh
IsERRIF:
   btfss   PIR3,ERRIF
   goto   IsTXB2IF
   goto   AbortU
IsTXB2IF:
   btfss   PIR3,TXB2IF
   goto   IsTXB1IF
   goto   EndHigh
IsTXB1IF:
   btfss   PIR3,TXB1IF
   goto   IsTXB0IF
   goto   EndHigh
IsTXB0IF:
   btfss   PIR3,TXB0IF
   goto   IsRXB1IF
   goto   EndHigh
IsRXB1IF:
   btfss   PIR3,RXB1IF
   goto   IsRXB0IF
   call   RxRou
   call   PROCESSFun
   goto   EndHigh
IsRXB0IF:
   btfss   PIR3,RXB1IF
   goto   IsRXB0IF
   call   RxRou
   call   PROCESSFun
   goto   EndHigh
AbortU:
   CANAbortAll
EndHigh:
   clrf   PIR3
   RESTORE_STATUS_W_BSR
   ENABLE_GIE

   retfie

;************INTERRUPCIONES CON BAJA PRIORIDAD*****************
   
LowPINT:
   
   DISABLE_GIE
   SAVE_STATUS_W_BSR
      
   btfss      INTCON,INT0IF
   bra      isINT1
   movff      PORTC,PRO_temp
   ;movlw      0x00
   ;cpfseq      PRO_temp
   ;bra      in1
;try1:   call      CANIsTxReady
   bnc      TxNotRdy
   banksel      MessageData
   movlw      0x00
   movwf      MessageData,1
   movlw      0x82
   movwf      MessageData+1,1   
   movlw      0x0F
   movwf      MessageData+2,1
   movlw      0x01
   movwf      MessageData+3,1
   CANSendMessage   0x001, MessageData, 8, CAN_TX_STD_FRAME & CAN_TX_NO_RTR_FRAME

   bcf      INTCON,INT0IF
   bra      EndLow
   
in1:   movlw      0x01
   cpfseq      PRO_temp
   bra      EndLow
   call      CANIsTxReady
   bnc      TxNotRdy
   banksel      MessageData
   movlw      0x03
   movwf      MessageData,1
   movlw      0x80
   movwf      MessageData+1,1   
   movlw      0x0F
   movwf      MessageData+2,1
   movlw      0x00
   movwf      MessageData+3,1
   CANSendMessage   0x001, MessageData, 8, CAN_TX_STD_FRAME & CAN_TX_NO_RTR_FRAME

   bcf      INTCON,INT0IF
   bra      EndLow

isINT1:
   btfss      INTCON3,INT1IF
   bra      EndLow
try1   call      CANIsTxReady
   bnc      TxNotRdy
   banksel      MessageData
   ;movlw      0x02
   movff      PORTC,WREG
   movwf      MessageData,1
   ;movlw      0x82
   movlw      0x00
   movwf      MessageData+1,1   
   ;movlw      0x0F
   movlw      0x00
   movwf      MessageData+2,1
   ;movlw      0x00
   movlw      0x00
   movwf      MessageData+3,1
   CANSendMessage   0x001, MessageData, 1, CAN_TX_STD_FRAME & CAN_TX_NO_RTR_FRAME

   bcf      INTCON3,INT1IF
   bra      EndLow

TxNotRdy:
   goto try1
   
EndLow:   
   
   RESTORE_STATUS_W_BSR
   ENABLE_GIE
   retfie

RxRou
   call      CANIsRxReady
   bnc      RxNotRdy

   banksel      NewMessage

   CANReadMessage   NewMessage, NewMessageData, NewMessageLen, NewMessageFlags
   bra      ExitRx

RxNotRdy:

ExitRx:

   return
   
   end   
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Mayo de 2008, 08:42:36
En la linea que dice:
CANSendMessage   0x001, MessageData, 8, CAN_TX_STD_FRAME & CAN_TX_NO_RTR_FRAME

Indicas al Bus CAN que trasmita 8 bytes (tercer argumento), pero antes le das valores a solo 4 argumentos de MessageData...

Una pregunta:
Estas probando en un circuito real o intentando simular??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 24 de Mayo de 2008, 13:40:56
tengo el circuito armado en protoboard pero no lo he probado, por el momento solo lo he simulado

le voy a cambiar esa parte al codigo y lo publicare de nuevo ok.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Mayo de 2008, 08:09:35
Una experiencia personal, no simules el programa en CAN, pruebalo en un impreso, al menos el hardware CAN, en protoboard por alguna razon que desconozco, a mi me comunicaba durante unos segundos y luego empezaba a fallar, hasta que lo arme en placas... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 26 de Mayo de 2008, 12:17:02
aqui te mando el codigo que estoy utilizando, voy a hacer el circuito impreso para montarlo

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Mayo de 2008, 15:22:16
Hasta aqui llegue leyendo el codigo, y es el punto donde seteas la configuracion del Bus CAN:

CANInitialize   1, 5, 7, 6, 2, CAN_CONFIG_LINE_FILTER_ON & CAN_CONFIG_VALID_STD_MSG

De donde has sacado esos valores??
Pregunto porque si tu cristal es de 10 MHz, no me coincide con ninguna de las velocidades normales...
Como los calculaste??
Estan asi en el ejemplo??
El ejemplo usa ese mismo cristal??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 27 de Mayo de 2008, 05:52:13
hola marcos como estas

tenias razon los valores de configuracion estaban mal te mando la pagina de calculo para que la revises, tambien quisiera saber si puedo conectar el canking con un mcp2510,  es que tengo un stand alone can y lo quiero conectar a la pc para generar trafico pero no se si me funcionara. aqui te mando la informacion del nodo para que la revises porfa

cuidate estamos en contacto
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 27 de Mayo de 2008, 05:53:21
aqui los documentos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 27 de Mayo de 2008, 06:03:30
aqui estan los parametros
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Mayo de 2008, 08:19:57
Bueno, vamos mejorando...
Una pregunta:
Ahora lo has compilado y ya no se traba el programa??
Empiezas a tener algo en el bus??

Al menos deberias tener un mensaje inicial, ya que si no mire mal el codigo, trabaja por las interrupciones del Bus CAN, cosa que solamente ocurrira si algun nodo le responde o poniendolo en modo LoopBack, que creo es el modo que querias ponerlo.

El nodo que me pasaste esta bastante borroso el esquema, pero parece tener un cristal de 5 MHz en el MCP2510, eso no le da mucha velocidad que digamos, ademas te recomiendo adaptarlo a un PIC12Fxxx, que es flash, ya que un PIC OTP es bueno para produccion, pero en pruebas perderas unos cuantos antes de obtener un resultado...

En todo caso tu circuito lo puedes adaptar a la velocidad que consigas con este nodo, asi no lo retocas...
OOOPPSS!!!  Perdon, puede trabajar a 125 Kbps, no dije nada!!! :lol: :lol:

Respecto al CanKing, hay una de las versiones que esta preparado para usar el MCP2515, si armas la parte correspondiente del Sniffer Can que publique aqui, puedes usarlo via puerto paralelo del PC, generando el trafico y leyendo el BUS CAN.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 27 de Mayo de 2008, 12:58:40
buenos dias marco
gracias por los comentarios

estaba leyendo una pdf de microchip que supuestamente podes conectar el mcp2510 a la pc me imagino que atravez de un max232, no se si mal entiendo el documento pero no tiene ningun pic conectado al mcp2510 si lo conectan directo a la pc por el serial. lo raro es que estaba chekeado el data sheet de mcp y tiene algunas banderas que se generan como interrupcion las cuales se conectan para hacerlo funcionar.

y el serial solo tiene pocas lineas 2 o 3, bueno aqui te mando el pdf para que lo veas supuestamente se maneja el mcp con el canking desde el serial
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 27 de Mayo de 2008, 13:04:12
aqui te mando el diagrama del nodo can con el mcp2510
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Mayo de 2008, 16:57:01
El puerto paralelo del PC tiene señales del tipo TTL, no es lo recomendado, pero se puede conectar el MCP2510 directo al puerto (lo usual es usar buffers para conectarlo) y con el programa lo que hace es acceder via el puerto SPI a los registros y manejarlo desde el PC como si lo hiciera un PIC, con una ventaja:

Codigo ILIMITADO.

Los que fabrican el CanKing ademas de este software tienen un Can SDK (que puedes bajar una demo gratuita) para desarrollar tu codigo y hacerlo funcionar.
Los mas vagos (como yo) optamos por conectarlo y manejarlo con el CanKing que es muy versatil, para hacer ciertas pruebas alcanza y sobra...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: betin en 30 de Mayo de 2008, 21:09:44
En la linea que dice:
CANSendMessage   0x001, MessageData, 8, CAN_TX_STD_FRAME & CAN_TX_NO_RTR_FRAME

Indicas al Bus CAN que trasmita 8 bytes (tercer argumento), pero antes le das valores a solo 4 argumentos de MessageData...

Una pregunta:
Estas probando en un circuito real o intentando simular??

ENTONCES SI ES POSIBLE SIMULAR ALGUIEN ME DICE CON QUE SIMULADOR
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Mayo de 2008, 08:11:02
Lamentablemente hasta ahora no se que simulador podria simular los pics o elementos del bus can.
Es confuso porque Proteus trae entre sus modelos varios PIC con CAN incorporado, pero no hay transceivers de ninguna marca, ni tampoco estan los mcp25050, mcp2515 o algun otro...
De echo, creo que es muy dificil para un simulador manejar el trafico del bus, por eso creo que debe ser muy dificil, cada componente debe tener el manejo de colisiones y arbitracion, etcetera.

Le puse una nota preguntandole esto al creador del PIC Simulator IDE (muy buen software), para ver si lo simula o en algun momento lo hara, pero aun no recibi contestacion. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Mayo de 2008, 08:21:30
hola marcos como estas

tenias razon los valores de configuracion estaban mal te mando la pagina de calculo para que la revises, tambien quisiera saber si puedo conectar el canking con un mcp2510,  es que tengo un stand alone can y lo quiero conectar a la pc para generar trafico pero no se si me funcionara. aqui te mando la informacion del nodo para que la revises porfa

cuidate estamos en contacto

OK, estuve revisando el software de tu nodo standalone, y creo que seria bueno que pudieras entrar al bus a traves de un nodo hecho a traves del MCP2515/ MCP2510 y crearle y visualizar trafico a traves de CanKING.
Puedes armarte el hardware para conectar a PC que figura en la nota del sistema de desarrollo del MCP2515 o hacer el que yo puse aqui para el Sniffer CAN, sacando la parte del PIC18F y del puerto serie.

Lo que necesitas es algo asi:

Puerto Paralelo PC >> Interfaces (buffers) >> MCP2515  >>  Bus CAN

con ese esquema y el software del CanKING podras hacer tus practicas sin problemas.

Yo estoy trabajando en un ejemplo que apenas lo tenga probado pondre aqui todos los detalles, para transmitir una temperatura desde un nodo y mostrarla en un display LCD en otro nodo.
Para quien le interese aprender sobre el bus CAN seguramente sera una buena ayuda. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 05 de Junio de 2008, 17:08:57
hola marco que tal
sabes arme el nodo CAN con el mcp2510, pero no me lo detecta la pc
como mi pc no tiene puerto paralelo compre un conversor de usb a paralelo pero no funciona no de tecta el hardware, luego lo probe en una desktop con un puerto paralelo directo y me da el mismo error de software en canking y no se porque
te mando el esquema del circuito que arme
revisalo porfa cuidate estamos en contacto
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Junio de 2008, 18:17:20
hola marco que tal
sabes arme el nodo CAN con el mcp2510, pero no me lo detecta la pc
como mi pc no tiene puerto paralelo compre un conversor de usb a paralelo pero no funciona no de tecta el hardware, luego lo probe en una desktop con un puerto paralelo directo y me da el mismo error de software en canking y no se porque
te mando el esquema del circuito que arme
revisalo porfa cuidate estamos en contacto

Comparalo a tu circuito con este otro, a ver las diferencias...
Es el de la placa desarrollo de Microchip para el mcp2510/mcp2515.
Bajate el archivo de aqui y mira en la pagina 38:
MCP2510 DevKit User Manual (http://ww1.microchip.com/downloads/en/DeviceDoc/51195c.pdf)

No se que version del CanKing estas utilizando pero deberias bajartela de aqui:
Software CanKing MCP2510 (http://www.microchip.com/Microchip.WWW.SecureSoftwareList/secsoftwaredownload.aspx?device=en531891&lang=en&ReturnURL=http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en531891#)
y clickea en el link llamado:
MCP2510 EVALUATION KIT
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 05 de Junio de 2008, 21:22:12
HOLA MARCO ya baje el software para utilizar el mcp2510 con le canking ya funciona asi con el circuito que te enseñe

a simple vista funciona bien voy a chequear bien luego te aviso, estoy terminando de montar el otro nodo can en circuito impreso despues lo conecto al canking haber que tal muchas gracias hombre estamos en contacto
cuidate
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Junio de 2008, 08:02:48
Aleluya!!
Me alegro mucho.
Yo estoy haciendo funcionar (anoche tuve una aproximacion a que funcionara bien) el hardware del Sniffer conectado al CanKing via puerto serial.
Uso un PIC18F4580 en vez del PIC18F458 para el que viene hecho el software.
Tuve que aprender un poco de C18, ya que esta hecho en ese entorno la aplicacion, a pesar que nunca lo habia agarrado, tengo que decir a favor de el que no me desagrada el entorno que tiene.
Igual extraño mi CCS querido. :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: realpe en 08 de Junio de 2008, 22:32:54
Hola a todos
queria comentar que tengo una aplicacion con una red can pero con el micro pic18f258 mas el mcp2551,  para eso utilizo las librerias del c18. saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 09 de Junio de 2008, 00:07:36
si  pudieras publicar el codigo para verlo, ayudaria mucho.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Junio de 2008, 08:21:27
Si, seria bueno, ya publicamos codigo de CCS y de MikroC, no vendria mal encontrar aqui cosas hechas con todos los compiladores, incluso Basic y otros mas... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: realpe en 14 de Junio de 2008, 00:05:58
Listo, en el transcurso de la proxima semana lo estare, montando.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 24 de Junio de 2008, 01:40:42
hola marcos que tal,
he regresado sabes no se si te acuerdas de mi, ya termine el nodo can para la pc e instale el canking de microchip y me funciona bien tengo problemas con el nodo can con  el micro no funciona trato de mandar varias tramas al micro y no las recibe y trato de mandar tramas desde el micro y no las manda, ya revise los registros de configuracion estan correctos segun la pagina bit timing del can,

sabes me he fijado que cuando mido el voltaje desde tierra hasta rxcan del micro mide 5 voltios y en txcan tambien, no si esto es correcto porque el puerto b esta configurado para que el pin rb2 sea salida y rb3 entrada, no si siendo entrada tiene que tener 5 voltios
tambien he notado que cuando mido el voltaje entre tierra y tx el sniffer empiesa a recibir mensajes raros con valores que nose de donde salen
bueno espero que me puedas ayudar

tambien estoy queriendo armar un ICD PARA revisar el codigo en chip si tienes alguno me avisas
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Junio de 2008, 08:06:07
Hola ArquiLester.
Podras subir aqui el esquematico y el codigo fuente que no te funciona??
Las tensiones del bus CAN son diferenciales, por lo tanto no se si estaras midiendolas bien o no respecto a que tierra... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 25 de Junio de 2008, 21:35:02
el codigo que estoy probando es el anexo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Junio de 2008, 09:44:11
Voy por la segunda vez que escribo este mensaje...

Hacia mucho que no leia un programa completo en Assembler... :lol: :lol:
Lo que veo es lo siguiente:


Corrige esos problemas y la seguimos...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: earmc en 27 de Junio de 2008, 22:23:28
Hola, soy nuevo en el tema del bus can y me gustaria saber si es posible realizar la transmision de informacion entre dos pics sin necesidad del transaiver. O si existe alguna forma de realizarlo con electronica convencional. En verdad les agradezco la informacion ke puedan suministrarme. A y a proposito si tienen un ejemplo en ASM les agradezco muchisimo ya ke e estado trabando como 2 semanas en el mplab y no e podido avanzar mucho . Adios y gracias de antemano
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Junio de 2008, 08:02:48
Hola, soy nuevo en el tema del bus can y me gustaria saber si es posible realizar la transmision de informacion entre dos pics sin necesidad del transaiver. O si existe alguna forma de realizarlo con electronica convencional. En verdad les agradezco la informacion ke puedan suministrarme. A y a proposito si tienen un ejemplo en ASM les agradezco muchisimo ya ke e estado trabando como 2 semanas en el mplab y no e podido avanzar mucho . Adios y gracias de antemano
Respuesta a la pregunta del transceiver, la respuesta es no.
Precisamente el transceiver es quien implementa la parte fisica del protocolo.
Hay un ejemplo en ASM en los POST anteriores, y en la pagina de Microchip tambien encontraras varios ejemplos en:
http://www.microchip.com/can (http://www.microchip.com/can)

Bienvenido al foro!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: quirogaareal en 30 de Junio de 2008, 00:12:04
Hola :

Mira por el problema de transmision con can fijate y estudia bien la implementacion del bit "RTR" puede que este ahi el problema.
Yo estuve viendo algo de can hasta marzo . pero debido a un cambio de trabajo tuve que dejar el proyecto.
Repito fijate si es eso por lo que no te funciona

Saludos

Desde Rio Gallegos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 01 de Julio de 2008, 00:19:36
el programa esta divido en dos partes una parte para transmitir y otra para resivir  mensajes, LAZO  esta en el area de resivir
la cosa esta que antes de entrar a la configuracion de los registros de recepcion salto hasta el area donde se resiven  mensajes y ahi se queda
bueno eso es lo que  he probado, yo estoy seguro que el sniffer con el mcp2510 funciona ya lo probe y hasta en loopback funciona,entonces se que puedo mandar tramas desde la pc por lo que estoy tratando de recibir con el pic

Código: ASM
  1. #include        "p18f258.inc"
  2. #include        "CAN18xx8.inc"
  3.  
  4.  
  5.  
  6. ; oscillator selection
  7.         CONFIG  OSC = HS
  8.  
  9. #define TX_TEST
  10. #define RX_TEST
  11.  
  12.        
  13.         UDATA
  14. CANDt1  RES     02
  15. Tmp     equ     0xff
  16. #ifdef  RX_TEST
  17. RxMsgID         RES     04
  18. RxData          RES     08
  19. RxDtLngth       RES     01
  20. RxFlag          RES     01
  21. RxFilterMatch   RES     01
  22. #endif
  23.  
  24.  
  25. ;***********************************************
  26. ;               DEFINICION DE BLOQUE
  27. ;***********************************************
  28.  
  29.         cblock  0x000
  30.         salto
  31.         endc
  32.  
  33.  
  34.        
  35.  
  36.  
  37. Sta     CODE    0x00
  38.         bra     Main
  39.  
  40. ;************INTERRUPCIONES DE ALTA PRIORIDAD************
  41. IHP     CODE    0x08
  42.         GOTO    INTER0
  43. ;#ifndef CANIntLowPrior
  44.  ;       call    CANISR          ;Call CAN Interrupt Service routine
  45. ;#endif
  46.  
  47. ;       btfss           INTCON,INT0IF   ;revisa int0
  48. ;       goto            EXITIH          ;SI NO ES INT0 SALIR
  49. ;       goto            INTER0          ;ATENCION INT0
  50. ;EXITIH
  51. ;       BCF     PIR3,0
  52.  ;       retfie  FAST
  53.  
  54. ;************INTERRUPCIONES DE BAJA PRIORIDAD*************
  55. IHL     CODE    0x018
  56.  
  57. #ifdef  CANIntLowPrior
  58.         movwf   W_IL            ;Save W
  59.         movff   STATUS,STAT_IL  ;Save STATUS
  60.         movff   BSR,BSR_IL      ;Save BSR
  61.         call    CANISR          ;Call CAN Interrupt Service routine
  62.         movff   BSR_IL,BSR      ;Restore BSR
  63.         movff   STAT_IL,STATUS  ;Restore Status
  64.         movf    W_IL,W          ;Restore W reg
  65.         ;return
  66. #endif
  67.  
  68.         btfss   INTCON3,0       ;REVISA INT1
  69.         goto    EXITIL          ;SI NO ES INT1 SALIR
  70.         goto    INTER1          ;ATENCION INT1
  71.  
  72. EXITIL:
  73.         BCF     INTCON3,0
  74.         retfie  FAST
  75.  
  76.  
  77.  
  78.  
  79. Test1   CODE
  80.  
  81. Main:
  82.  
  83. ;Define TRIS bits to define CANRx pin as i/p and CANTx pin as o/p
  84.  
  85.        ;Configuracion de los Puertos del PIC
  86.  
  87. ;**********************PUERTO A*******************************
  88.         CLRF    PORTA                                   ;CONFIGURA PORT A COMO SALIDA DIGITAL                          
  89.                                                         ; Puerto A SALIDA  RA0
  90.         movlw   0x07                           
  91.         iorwf   ADCON1,f
  92.         CLRF    TRISA                                   ;
  93.         BSF     PORTA,0                         ; apaga salidas
  94.        
  95. ;**********************PUERTO B*******************************
  96.         CLRF    PORTB
  97.         MOVLW   B'00001011'                             ; Puerto B con entradas RB0, RB1
  98.         MOVWF   TRISB                                   ; configura R2 y R3 para TX y RX del CAN