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
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
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. }

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. }

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. }
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.    }

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.       }

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. }
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. }
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
  99.                                                         ; el resto salidas
  100.                                                        
  101. ;**********************PUERTO C*******************************
  102.         CLRF    PORTC                           ; Puerto C completo como SALIDAS
  103.         MOVLW   0x00
  104.         MOVWF   TRISC
  105. ;************** Configurando Interrupciones     **************
  106.  
  107.         bsf     RCON, IPEN              ; habilita prioridad de interrupcion
  108.         ;bsf    INTCON, GIEH            ; habilita prioridad alta
  109.         movlw   B'11010000'             ;
  110.         movwf   INTCON
  111.         movlw   B'00000000'             ; habilita interrupcion en flanco de bajada
  112.         movwf   INTCON2                 ; habilita interrupcion en flanco de bajada
  113.         movlw   B'00001000'             ; habilita prioridad BAJA para int1
  114.         movwf   INTCON3                 ; tambien habilita interrupcion 1
  115.        
  116.        
  117.         ;SETF   PIE3                                    ; HABILITA TODAS LAS INTERRUPCIONES DEL CAN
  118.         ;setf   IPR3                            ; Interrupciones CAN todas en High Priority
  119.         ;CLRF   PIR3
  120.  
  121. ;***************** CONFIGURACION DEL PROTOCOLO CAN****************
  122. ;configuracion inicial 125kbps@20MHz all valid messages
  123.  
  124.          CANInitialize   1, 0A, 3, 3, 1,CAN_CONFIG_ALL_VALID_MSG
  125.        
  126.         ;goto   RcvMsg
  127. ;Set Loop-back mode for testing in Stand alone mode
  128. ;       CANSetOperationMode     CAN_OP_MODE_LOOP        ;Loop back mode
  129.  
  130. #ifdef  RX_TEST
  131.  
  132. ;Set configuration mode
  133.         CANSetOperationMode     CAN_OP_MODE_CONFIG      ;
  134.  
  135. ;Following settings will ensure only following messages in Buf 0
  136. ; 0x25 and 0x125 (Filter Hit 0)
  137. ; 0x36 and 0x136 (Filter Hit 1)
  138.  
  139. ;Set Mask B0 to 0xfffffeff
  140.         CANSetReg CAN_MASK_B0, 0xfffffeff, CAN_CONFIG_XTD_MSG
  141. ;Set Filer 0 with 0x25
  142.         CANSetReg CAN_FILTER_B0_F1, 0x025, CAN_CONFIG_XTD_MSG
  143. ;Set Filer 1 with 0x36
  144.         CANSetReg CAN_FILTER_B0_F2, 0x036, CAN_CONFIG_XTD_MSG
  145.  
  146.  
  147.  
  148. ;Following settings will ensure only following messages in Buf 1
  149. ; 0x08,0x88, 0x1000008, 0x1000088 (Filter Hit 2)
  150. ; 0x06,0x86, 0x1000006, 0x1000086 (Filter Hit 3)
  151. ; 0x02,0x82, 0x1000002, 0x1000082 (Filter Hit 4)
  152. ; 0x01,0x81, 0x1000001, 0x1000081 (Filter Hit 5)
  153.  
  154. ;Set Mask B1 to 0xfeffff7f
  155.         CANSetReg CAN_MASK_B1,0xfeffff7f, CAN_CONFIG_XTD_MSG
  156. ;Set Filer 2 with 0x08
  157.         CANSetReg CAN_FILTER_B1_F1,0x08, CAN_CONFIG_XTD_MSG
  158. ;Set Filer 3 with 0x05
  159.         CANSetReg CAN_FILTER_B1_F2,0x06, CAN_CONFIG_XTD_MSG
  160. ;Set Filer 4 with 0x02
  161.         CANSetReg CAN_FILTER_B1_F3,0x02, CAN_CONFIG_XTD_MSG
  162. ;Set Filer 5 with 0x01
  163.         CANSetReg CAN_FILTER_B1_F4,0x01, CAN_CONFIG_XTD_MSG
  164.  
  165. ; Restore to Normal mode.
  166.         CANSetOperationMode     CAN_OP_MODE_NORMAL      ;
  167.  
  168. #endif
  169.  
  170.         GOTO    RcvMsg 
  171.        
  172. ;LAZO:
  173. #ifdef  TX_TEST
  174. ;-------------------------------
  175. ;Message 1, Data 01,02, ID 20
  176. Msg1Agn:
  177.         movlw   low(CANDt1)
  178.         movwf   FSR0L
  179.         movlw   high(CANDt1)
  180.         movwf   FSR0H
  181.         movlw   0x01
  182.         movwf   POSTINC0
  183.         movlw   0x02
  184.         movwf   POSTINC0
  185.         CANSendMessage  0x20,CANDt1,2,CAN_TX_XTD_FRAME
  186.         addlw   0x00            ;Check for return value of 0 in W
  187.         bz      Msg1Agn         ;Buffer Full, Try again
  188. ;-------------------------------
  189.  
  190.  
  191. ;-------------------------------
  192. ;Message 2, Data 03,04, ID 30
  193. Msg2Agn:
  194.         movlw   low(CANDt1)
  195.         movwf   FSR0L
  196.         movlw   high(CANDt1)
  197.         movwf   FSR0H
  198.         movlw   0x03
  199.         movwf   POSTINC0
  200.         movlw   0x04
  201.         movwf   POSTINC0
  202.         movlw   0xaa
  203.         movwf   POSTINC0
  204.         movlw   0xbb
  205.         movwf   POSTINC0
  206.         CANSendMessage  0x31,CANDt1,4,CAN_TX_XTD_FRAME
  207.         addlw   0x00            ;Check for return value of 0 in W
  208.         bz      Msg2Agn         ;Buffer Full, Try again
  209. ;-------------------------------
  210.  
  211.  
  212. ;-------------------------------
  213. ;Message 3, Data 05,06, ID 15
  214. Msg3Agn:
  215.         movlw   low(CANDt1)
  216.         movwf   FSR0L
  217.         movlw   high(CANDt1)
  218.         movwf   FSR0H
  219.         movlw   0x05
  220.         movwf   POSTINC0
  221.         movlw   0x06
  222.         movwf   POSTINC0
  223.         CANSendMessage  0x1,CANDt1,2,CAN_TX_XTD_FRAME
  224.         addlw   0x00            ;Check for return value of 0 in W
  225.         bz      Msg3Agn         ;Buffer Full, Try again
  226. ;-------------------------------
  227.  
  228.  
  229. ;-------------------------------
  230. ;Message 4, Data 07,08, ID 05
  231. Msg4Agn:
  232.         movlw   low(CANDt1)
  233.         movwf   FSR0L
  234.         movlw   high(CANDt1)
  235.         movwf   FSR0H
  236.         movlw   0x07
  237.         movwf   POSTINC0
  238.         movlw   0x08
  239.         movwf   POSTINC0
  240.         CANSendMessage  0x02,CANDt1,2,CAN_TX_XTD_FRAME
  241.         addlw   0x00            ;Check for return value of 0 in W
  242.         bz      Msg4Agn         ;Buffer Full, Try again
  243. ;-------------------------------
  244.  
  245.  
  246. ;-------------------------------
  247. ;Message 5, Data 09,0A, ID 10
  248. Msg5Agn:
  249.         movlw   low(CANDt1)
  250.         movwf   FSR0L
  251.         movlw   high(CANDt1)
  252.         movwf   FSR0H
  253.         movlw   0x09
  254.         movwf   POSTINC0
  255.         movlw   0x0A
  256.         movwf   POSTINC0
  257.         CANSendMessage  0x3,CANDt1,2,CAN_TX_XTD_FRAME
  258.         addlw   0x00            ;Check for return value of 0 in W
  259.         bz      Msg5Agn         ;Buffer Full, Try again
  260. ;------------------------------
  261.  
  262.  
  263.  
  264. ;-------------------------------
  265. ;Message 6, Data 0B,0C, ID 15
  266. Msg6Agn:
  267.         movlw   low(CANDt1)
  268.         movwf   FSR0L
  269.         movlw   high(CANDt1)
  270.         movwf   FSR0H
  271.         movlw   0x0B
  272.         movwf   POSTINC0
  273.         movlw   0x0C
  274.         movwf   POSTINC0
  275.         CANSendMessage  0x4,CANDt1,2,CAN_TX_XTD_FRAME
  276.         addlw   0x00            ;Check for return value of 0 in W
  277.         bz      Msg6Agn         ;Buffer Full, Try again
  278. ;-------------------------------
  279.  
  280.  
  281. ;-------------------------------
  282. ;Message 7, Data 0D,0E, ID 20
  283. Msg7Agn:
  284.         movlw   low(CANDt1)
  285.         movwf   FSR0L
  286.         movlw   high(CANDt1)
  287.         movwf   FSR0H
  288.         movlw   0x0D
  289.         movwf   POSTINC0
  290.         movlw   0x0E
  291.         movwf   POSTINC0
  292.         CANSendMessage  0x20,CANDt1,2,CAN_TX_XTD_FRAME
  293.         addlw   0x00            ;Check for return value of 0 in W
  294.         bz      Msg7Agn         ;Buffer Full, Try again
  295. ;-------------------------------
  296.  
  297. ;-------------------------------
  298. ;Message 8, Data 0F,10, ID 05
  299. Msg8Agn:
  300.         movlw   low(CANDt1)
  301.         movwf   FSR0L
  302.         movlw   high(CANDt1)
  303.         movwf   FSR0H
  304.         movlw   0x0F
  305.         movwf   POSTINC0
  306.         movlw   0x10
  307.         movwf   POSTINC0
  308.         CANSendMessage  0x05,CANDt1,2,CAN_TX_XTD_FRAME
  309.         addlw   0x00            ;Check for return value of 0 in W
  310.         bz      Msg8Agn         ;Buffer Full, Try again
  311. ;-------------------------------
  312. #endif
  313.         ;GOTO LAZO
  314. ;       CANAbortAll             ;Use to abort transmission of all messages.
  315. ;       CANGetTxErrorCount      ;Get Tx Error count
  316. ;       CANGetRxErrorCount      ;Get Rx Error count    
  317.  
  318. RcvMsg:
  319. Loop:                                  
  320.         ;call CANIsRxReady      ;verifica si hay un mensaje
  321.         ;bnc    Loop
  322.         ;nop
  323.  
  324. ;#ifdef  RX_TEST
  325.         CANReadMessage  RxMsgID, RxData, RxDtLngth, RxFlag
  326.         ;movlw  0x01
  327.         xorlw   0x01
  328.        
  329.         bnz     Loop
  330.         incf    PORTC
  331.         bcf     TRISA,RA0       ;enciende el pin0 puerto A para mostrar que
  332.                                 ;se recibio un mensaje
  333.         BRA     Loop
  334. ; revisa que tipo de mensaje recibio
  335.         banksel RxFlag
  336.         btfsc   RxFlag,CAN_RX_OVERFLOW_BIT_NO
  337.         bra     RxOvrFlow       ;Branch to Logic for Rx
  338.                                 ;overflow occurred.
  339.         btfsc   RxFlag,CAN_RX_INVALID_MSG_BIT_NO
  340.         bra     RxInvldMsg      ;Branch to Logic for Invalid
  341.                                 ;Message received
  342.         btfsc   RxFlag,CAN_RX_XTD_FRAME_BIT_NO
  343.         bra     RxExtMsg        ;Logic for Extended frame
  344.                                 ;received
  345.         bra     RxStdMsg        ;Else logic for standard
  346.                                 ;frame received
  347.         btfsc   RxFlag,CAN_RX_RTR_FRAME_BIT_NO
  348.         bra     RxRTRFrame      ;Branch to Logic for RTR
  349.                                 ;frame received
  350.         nop                     ;Regular frame received
  351.         movlw   CAN_RX_FILTER_BITS
  352.         andwf   RxFlag,W
  353.         movwf   RxFilterMatch   ;Save matched Filter ;number
  354.                                 ;aqui trato a mensajes con un filtro determinado
  355.         CLRF    PORTC
  356.         BSF     PORTC,5
  357.         goto    Loop
  358.  
  359.  
  360.  
  361. RxOvrFlow:                      ;trato de sobre flujo
  362.         clrf    PORTC
  363.         bsf     PORTC,0
  364.         goto    Loop
  365. RxInvldMsg:                     ;trato a mensajes invalidos
  366.         CLRF    PORTC
  367.         BSF     PORTC,1
  368.         goto    Loop
  369.  
  370. RxExtMsg:                       ;trato a mensajes ID EXTENDIDO
  371.         CLRF    PORTC
  372.         BSF     PORTC,2
  373.         movlw   low(RxData)     ;Direcciona el inicio de los datos a chequear
  374.         movwf   FSR0L
  375.         movlw   high(RxData)
  376.         movwf   FSR0H
  377.  
  378.         banksel RxDtLngth
  379.         movf    RxDtLngth,w     ;longitud de datos que se recibieron
  380. lazo2:
  381.         movff   POSTINC0,PORTC
  382.                
  383. infinito:
  384.         btfsc   Tmp,1           ;variable de control
  385.         goto infinito  
  386.        
  387.         BCF     PORTA,0
  388.         decfsz  WREG
  389.         bra     lazo2
  390.         bra     Loop
  391.  
  392. RxStdMsg:                       ;trato a mensajes ID STANDAR
  393.         CLRF    PORTC
  394.         BSF     PORTC,3
  395.         movlw   0xff
  396.         goto    Loop
  397. RxRTRFrame:                     ;trato a mensajes RTR
  398.         CLRF    PORTC
  399.         BSF     PORTC,4
  400.         GOTO    Loop
  401.  
  402.  
  403.        
  404. ;*******************************************************
  405. ;
  406. ;       This procedure copy the coming information
  407. ;       recived in NewMessData
  408. ;
  409. ;*******************************************************
  410.        
  411. ;COPYvalFun
  412.        
  413. ;       movlw   low(NewMessageData)
  414. ;       movwf   FSR0L
  415. ;       movlw   high(NewMessageData)
  416. ;       movwf   FSR0H
  417. ;       banksel TempCommand
  418. ;       movff   POSTINC0,TempCommand
  419. ;       banksel TempAdd
  420. ;       movff   POSTINC0,TempAdd
  421. ;       banksel TempComp
  422. ;       movff   POSTINC0,TempComp
  423. ;       banksel TempData
  424. ;       movff   POSTINC0,TempData
  425. ;       movff   POSTINC0,TempData+1
  426. ;       movff   POSTINC0,TempData+2
  427. ;       movff   POSTINC0,TempData+3
  428.  
  429. ;       return
  430.  
  431.  
  432. ;Message Recd. Successfully
  433. ;       RxMsgID = 32 bit ID
  434. ;       RxData = Received Data Buffer
  435. ;       RxDtLngth = Length f Received data
  436. ;       RxFlag = Flag of CAN_RX_MSG_FLAGS type, Use it for Message
  437. ;       information
  438.  
  439. final:
  440.         nop
  441. ;#endif
  442.  
  443.         bra     Loop
  444.  
  445.  
  446. ;********************************************************
  447. ;                atencion a interrupcion ALTA PRIORIDAD
  448. ;********************************************************
  449.  
  450. INTER0:                                 ;ATENCION INT0 ALTA PRIORIDAD
  451. #ifndef CANIntLowPrior
  452.        call    CANISR          ;Call CAN Interrupt Service routine
  453. #endif 
  454.  
  455.         btfss           INTCON,INT0IF   ;revisa int0
  456.         goto            EXITIH          ;SI NO ES INT0 SALIR
  457.         goto            INTERA          ;ATENCION INT0
  458. EXITIH
  459.         BCF     PIR3,0
  460.         GOTO    SALIR
  461.  
  462. INTERA:
  463.         bcf     INTCON,INT0IF           ;LIMPIA BANDERA DE INTERRUPCION 0
  464.         BSF     PORTA,0                 ;ENCIENDE LED INTERRUPCION OCURRIO
  465.         ;setf   PORTC
  466.         CLRF    PORTC                   ;limpia puerto c
  467.         BCF     Tmp,1                   ;limpia bandera de control
  468.        
  469.  
  470. SALIR:
  471.         RETFIE  FAST
  472.  
  473.  
  474.  
  475. INTER1:                                 ;ATENCION INT1 BAJA PRIORIDAD
  476.         BCF     INTCON3,0               ;LIMPIA BANDERA DE INTERRUPCION
  477.         BSF     PORTA,0
  478.         MOVLW   0xf0
  479.         movwf   PORTC
  480.         retfie  FAST
  481.        
  482.         END
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Julio de 2008, 08:13:23
Dame unos dias para poder probarlo.
Mientras tanto si subes el esquematico de tu circuito, ayudara a poder revisarlo.

Cuando has probado desde el sniffer y CanKing, estas seguro de haber puesto la misma velocidad en la configuracion??? :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 03 de Julio de 2008, 16:58:43
hola marco que tal aqui esta el diagrama del nodo can con el pic18f258 :shock:

gracias por ayudarme espero te funcione en tu circuito.

ahh por cierto cuando utilizo el canking ocupo mcp2510 basic en la pantalla donde dice bus statistics en la parte de bus parameters
aparece
bus speed: 125kbps
bit timing: Q=8, s1=5, s2=3, sp=62.5, sjw=1
de esto 6 valores solo puedo ajustar la velocidad del bus, el sp y sjw. y los demas valores los pone elprograma. nose si esto afecta en algo

bueno muchas gracias nos vemos al rato cuidate
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Julio de 2008, 12:51:44
Lo otro que deberias poder ajustar, es la velocidad del cristal que tiene el MCP2515, que deberia ser la misma que tiene en la placa, y si no lo tiene entonces deberias ponerle una velocidad identica y datos identicos al de tu nodo CAN...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 09 de Julio de 2008, 11:17:46
el circuito con el pic tiene un cristal de 20mhz y el nodo de la pc tiene el mcp2510 con un cristal de 20mhz
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 11 de Julio de 2008, 12:18:08
HOLA marco como estas, que tal pudiste probar el codigo, sabes estaba pensando en  trabajar en lenguaje C,  pero tengo entendido que puedes mezclar ensamblador con lenguaje c creando archivos objetos, la verdad nunca he hecho eso tu sabes como se hace. asi pudiera ocupar el programa que controla al CAN en lenguaje c y unirlo con el codigo que tengo en ensamblador

cuidate mucho
gracias por la ayuda
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Julio de 2008, 22:32:03
Esta semana estoy fuera de casa, y la siguiente tambien.
Prometo probarlo cuando vuelva... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: luscho en 26 de Julio de 2008, 23:20:19
Hola marcos:

      Je,  je, después de mucho tiempo de vuelta por el foro y por el hilo, la verdad es que estaba muy ocupado.

Pero ahora que también después de tanto tiempo me llegaron mis transeivers , (se perdieron en el camino y parecia que para siempre, pero que aparecieron :-/ :-/),  he decidido retomar con este proyecto, es decir empezar, je, je, (de entre tantos que tengo postergados).

así que pronto me tendrás haciendo muchas preguntas, espero no ser mucha molestia  :D :D :D :D
                                                         lucho
 
....................caramba como avanzaron, me intimida leer 25 paginass, je, je ................
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Julio de 2008, 08:20:51
Bueno, me alegro Luscho!!
Y no le tengas miedo a las 25 paginas, te servira de repaso, ya que hay muchas preguntas contestadas que te serviran de mucho para no repetirlas... :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Cryn en 29 de Julio de 2008, 18:25:55
pucha que no puedo meter las manos en este tema :( a pesar de las muchas ganas qeu siempre tuve, siempre se me ha pasado algo, caramba, ojala despues si pueda, pero seguramente ya ira en las 40 paginas :D :D  o quien sabe, quiza sean mas :shock:

pues espero leer muchas cosas qeu digan aca y tb las de ti lucho, jaja, y espero que despues lo conpartas conmigo y me enseñes :mrgreen:

un saludo compatriota, y un slaudo a los del foro :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 29 de Julio de 2008, 20:17:57
hola marco que tal espero que  haya ido bien, nosotros por aca extrañando tus consejos
cuentame revisasteel codigo espero que encuentres algo porque ya me estoy frustrando con el CAN. he estado pensando utilizar un programa en C que tenga funcional el CAN si tienes uno tu te agradeceria muchisito y eternamente y Dios te va ha bendecir mucho espero tu respuesta cuidate nos vemos al rato bye
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Julio de 2008, 08:19:01
Prometo ponerme de nuevo en tema, estuve un poco alejado, por viajes de trabajo y ademas por vagancia estos ultimos dias... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 20 de Septiembre de 2008, 22:51:34
gracias por la ayuda, por preocuparse por las preguntas que se hacen.

ya me funciona el CAN con un codigo en ensamblador.... hoy si funciona

jajajajaja
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Septiembre de 2008, 08:34:42
Bueno, me alegro y gracias por avisar.
Recien ahora retomo el tema, por varias razones no pude seguir en mi proyecto.
Les comento que estoy probando un Sniffer CAN / CanOpen, y anda muy bien, salvo porque adentro tiene un micro Motorola, veo que a traves de CAN no se tienen alergia con los PICs... :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ekys en 25 de Noviembre de 2008, 21:51:05
Hola,
la verdad es q nose si este hilo sigue activo, pero tampoco se me ocurre un lugar más apropiado para poner esto.


Bueno, el caso es q dispongo de una placa con dos micros PIC18F4680 y me gustaria saber si podria utilizar alguna d estas librerias, sin tener q preocuparme de modificar el codigo CCS para la programacion d la placa: can-18xxx8.c, can-18F4580.c.
Para la libreria can-18xxx8.c tengo mis dudas d q esto sea asi, ya q en mi caso supongo q necesitaria mas bien una libreria dl tipo can-18xxx8x.c. Sin embargo, la can-18F4580.c, no deberia dar problemas sobre micros PIC18F4680 ya que he estado revisando cada uno d los registros q ambos micros utilizan para la comunicacion CAN y son exactamente los mismos.

Alguna ayuda i/o sugerencia?


Saludos.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Noviembre de 2008, 21:56:29
No tendras problemas si usas las librerias de CCS para el 4580 en el 4680.
Lo afirmo porque ya lo hice... :mrgreen: :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 26 de Noviembre de 2008, 08:50:16
Hola, yo también ando ahora liado con el canbus.

Ayer estuve programando un par de placas para comunicarlas entre ellas usando el 18F2580. Me dieron bastantes problemas con la carga de valores por defecto que hacen estas librerías. Ya que vienen por defecto para un reloj de 20Mhz y 250kbps (creo).

Al final cargué los valores de los registros de configuracion del Canbus manualmente (BRGCON). Como lo puso MGLSOFT en este post:
aqui (http://www.todopic.com.ar/foros/index.php?topic=19182.60)   Modificando una copia de la libreria original en la misma carpeta del proyecto.

Tengo una pregunta, usando el "Can Bit timing Calculator", me da varias opciones para una misma velocidad, pero con diferentes Tq (time quantas). ¿Que es mejor un TQ alto o bajo? Supongo que un Tq alto mejora la sincronización, pero aumenta la carga de trabajo del chip, ¿es asi?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Noviembre de 2008, 09:26:21
Depende con que lo uses y la velocidad.
Como tu dices el hecho de usar un valor alto de Time Quanta significa mas trabajo del hardware, pero a la vez permite sincronizar mejor el punto de muestreo y de esa forma lograr mayor estabilidad y seguridad en las comunicaciones del bus.
Si usas cristales de cuarzo todo barbaro, pero si usas osciladores encapsulados esto te ayuda a sincronizar bien el bus.

Tambien ayuda cuando tienes diferentes cristales en el bus, que es muy normal, ya que permite poner difenerntes placas de diferentes marcas y tecnologias.

Si tienes problemas una buena idea es pasar la cantidad de bits de muestra de 1 a 3.

Igual la carga del hardware al programador no le interesa demasiado, al fin y al cabo fue diseñado para eso.
Lo que si debe interesarte es que el bus no se sobrecargue cuando hay mucho trafico, y si ocurre ya tendrias que buscar una solucion en el software y no en el hardware.

Cualquier cosa consulta, yo tengo nodos con el 2580 y ya hice alguna experiencia. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 26 de Noviembre de 2008, 10:03:04
Es que el hard de mi proyecto ya va bastante cargado, tengo todos los pines del 2580 ocupados. Además de la comunicación Can, lleva Uart (Rs 232), Pantalla LCD, y una memoria MMC.

Estoy desarrollando el Soft por partes. Ya tengo controlado el LCD, y la comunicación del Rs232. La MMC me está dando un poco de problemas, sobre todo para su simulación en el Proteus. Y con el Can estoy empezando ahora a darle fuerte. He montado otro nodo Can en una protoboard, con un 2580 y el transceiver, con el que hago las comunicaciones de pruebas.

Un esquema de mi placa:

(http://www.fotosupload.com/imagenes/FuD61494_esquema-placa-proteus.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: PalitroqueZ en 26 de Noviembre de 2008, 14:25:58
hola teleko

miré el circuito que montaste en el ISIS, y te diré unos tips para aumentar la rapidez en la simulación

- no hace falta el divisor de voltajes en la MMC
- los leds se pueden sustituir por unos conectores logicos que se enecuentran en debugins tools (no me acuerdo como se llaman, pero está entre los primeros en la ventana de componentes)
- los pulsadores también se pueden sustituir de manera similar que los leds.
- el max232 es imprescindible, pon el virtual terminal directamente al pic.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Noviembre de 2008, 16:06:37
Citar
el max232 es imprescindible, pon el virtual terminal directamente al pic.

Querras decir que es prescindible... :lol: :lol:

Lo unico que no podras simular es lo del Bus CAN :( :(
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 27 de Noviembre de 2008, 07:25:03
Bueno, en realidad este no es el circuito de simulación, ya que el canbus no tiene simulación en proteus. Sólo era para que se vea el esquema de los componentes que uso. Ahí sólo falta la alimentación (tiene para 5v o 12v con conversión), el oscilador (cuarzo a 20MHz), y los conectores (ICSP, DB9, jumpers), y algunos componentes más (como los potenciometros para el LCD).

Suelo usar el virtual terminal conectado directamente, pero así también me funciona hasta 57600bps.

Otra cosa, en el proteus no viene el 2580, el que está es el 258 (versión anterior). Y cambia internamente en algunos registros, con lo que el proteus no lo simula bien. A veces uso el 2525 para simuaciones, que sí es casi igual, excepto por lo del can bus.

El MMC, es de locos en proteus. Según la versión que tenga instalada funciona de una forma u otra....

Y explicando un poco de la placa, los 2 conectores que hay a la izquierda, son los interruptores internos que tiene el conector de la MMC, uno para tarjeta insertada y otro para la protección de escritura.
El led que hay abajo, simula el led de la pantalla, así se puede encender y apagar el backlight cambiando el pin_B4 del micro.
El max232 que uso es el max232a, que lleva condensadores de 0.1micro, en lugar de 1micro, segun su datasheet, alcanza los 200kbps.
Casi todos los componentes que tengo montados son SMD (vaya locura para soldarlos....), y creo que tengo que rehacer la placa, ya que hay que hacer unos cambios de hard, y solucionar algunos pequeños fallos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Noviembre de 2008, 08:23:08
Citar
Y explicando un poco de la placa, los 2 conectores que hay a la izquierda, son los interruptores internos que tiene el conector de la MMC, uno para tarjeta insertada y otro para la protección de escritura.

Eso de los interruptores del conector de la MMC no lo sabia.

Una pregunta:
Cual es el proposito de esta placa??
Pregunto porque me llama la atencion que no tiene teclado propio pero si tiene display, y me deja intrigado la MMC... :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 27 de Noviembre de 2008, 09:02:51
Ya lo expliqué una vez. Es una especie de tacógrafo, u ordenador de a bordo para coches. Se conecta al OBD (On board diagnostic), y usando el canbus te va monitorizando diferentes parámetros del motor. También guarda los datos en la tarjeta de memoria.

No lleva teclado porque debe funcionar de forma autónoma (tan solo lleva el botón del reset), y para configurarlo se hace a través del Rs232.

El funcionamiento que busco es parecido al ELM, aunque solo para canbus. Y también algo parecido a esto:
enlace (http://66.196.80.202/babelfish/translate_url_content?lp=en_es&url=http%3A%2F%2Fwww.blafusel.de%2Fmisc%2Fobd2lcd_4en.html&.intl=es)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Noviembre de 2008, 21:01:19
Disculpa, no recordaba tu explicacion.
Es interesante tu proyecto.
Ya sabes los ID de cada equipo en el OBD??
Y el formato de los mensajes??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 02 de Diciembre de 2008, 09:17:37
Aquí está la normativa de comunicación con las centralitas del coche:

sae OBD (http://www.4shared.com/file/74089156/77de9073/SAE_OBDII_j1979_200204.html)

Y aquí se explica el funcionamiento del ELM, más o menos lo que yo quiero hacer, se entiende bastante bien cómo es el proceso de comunicación, enviando comandos y recibiendo las respuestas (pag 20):

(http://dc107.4shared.com/img/74089537/518aafbf/ELM327DS.pdf) (http://www.4shared.com/file/74089537/518aafbf/ELM327DS.html)

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Diciembre de 2008, 12:17:06
Importante y abundante informacion has puesto aqui!! :-/
A leer para poder colaborarte en tu proyecto!!! :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 02 de Diciembre de 2008, 13:14:47
Se agradece la ayuda y nuevas ideas o sugerencias.

Ahora tengo que rehacer la placa, ya que tenía algunos fallos que tengo que solucionar antes de poder continuar con las pruebas.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Diciembre de 2008, 15:20:42
Este chip que pusiste, el ELM327, donde se consigue??
Sabes el precio del mismo??
Es demasiado parecido a un PIC18F2580, no?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 02 de Diciembre de 2008, 15:36:58
Lo puedes conseguir en su propia página, enlace (http://www.elmelectronics.com/)

EL precio son unos 32$.
Está basado en el 18F2480, versión anterior y muy similar al 2580, creo que con algo menos de memoria. Viene ya programado (y protegido...), por lo que no lo puedo modificar para añadirle mi hardware.

Además del Canbus, trae otros protocolos, como el ISO, KWP... Para conectarlo a otros coches. Y también conexión por USB.


Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Diciembre de 2008, 16:30:51
Posiblemente ya lo hayas visto, pero no esta demas darte este link, me parece importante.

PICOBDII Proyect source Code (http://picobdii.googlecode.com/svn/trunk/Code/)

Espero le saques utilidad... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 02 de Diciembre de 2008, 16:59:30
Posiblemente ya lo hayas visto, pero no esta demas darte este link, me parece importante.

PICOBDII Proyect source Code (http://picobdii.googlecode.com/svn/trunk/Code/)

Espero le saques utilidad... :mrgreen:

Muchas gracias por el enlace, este no lo habia visto antes.  :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Diciembre de 2008, 17:48:46
 :mrgreen: :mrgreen:

Prendele una vela a San Google !!

A mi me sirvio la busqueda, por que descubri algo muy interesante para mi... :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 11 de Diciembre de 2008, 10:11:43
Hola, tengo una pequeña duda, ¿has probado a hacer un cambio de velocidad del bus?

Te explico, en principio no sabemos a qué velocidad (baud rate) está funcionando el bus. Hay varios valores por defecto a los que puede funcionar (500, 250, 125 o 62.5 kbps). Y nosotros nos debemos enchufar al bus en caliente, o sea, con el bus ya funcionando.

Hay un modo de operación, que es el listen_mode. Modo de sólo escucha en el bus. Según la documentación que tengo, este modo viene bien para poder escuchar el bus, y según si las tramas que recibimos son erróneas o no, saber si estamos bien sincronizados en velocidad.

A ver si me puedes echar una mano con esto, ya que no se muy bien cómo implementarlo. La idea es conectar al can y ver las tramas en el pc a través del hyperterminal.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Diciembre de 2008, 16:10:20
Estuve reuniendo informacion al respecto.
Mi idea es hacer un Sniffer CAN bien completo, que pueda detectar la velocidad del bus, dentro de las velocidades estandar.

Can Bus Autobaud (http://www.ccsinfo.com/forum/viewtopic.php?t=33729&highlight=canbus+autobaud)

En este hilo hay una sintesis de lo averiguado, despues lo podemos explayar al tema dentro de este hilo, si te parece bien... :mrgreen:

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MDMEOQUI en 13 de Diciembre de 2008, 12:13:13
Hola soy nuevo en este grupo y estoy trabajando con NMEA 2000 este formato de comunicación se basa en CAN, si alguien tiene
algo que me ayude muchas gracias, tengo basta experiencia con micros de microchip (USB PWM ADC DAC y otras), cualquier ayuda agradecido.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Diciembre de 2008, 18:00:08
Hola y bienvenido al Foro!!  :-/ :-/

El protocolo NMEA 2000 esta bastante bien explicado Aquí (http://en.wikipedia.org/wiki/NMEA_2000) y Aquí (http://www.nmea.org/pub/2000/index.html)...

Primera vez que lo leo, no sabia que NMEA (siempre crei que era de los GPS) estaba basado en CAN.

Prometo ponerme mas en tema, por ahora o hasta recien nomas era totalmente ignorante del tema.

Puedes comentarnos mas de tu trabajo?? :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Diciembre de 2008, 00:04:29
Solamente comentarles que estoy probando un SNIFFER CAN con conexion USB al PC e interfaz en PC.
Por ahora lo tengo armado en pruebas, apenas haya probado mejor les voy a ir poniendo los avances.... :mrgreen: :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MDMEOQUI en 15 de Diciembre de 2008, 13:55:16
Hola de vuelta, trabajo en desarrollo de equipos aplicados ala navegación e estado investigando el tema nmea2000   pues la nmea183 la conozco muy bien y la empleo siempre . Ahora lo nuevo es nmea2000 y tengo que realizar unas interfaces para adaptar de un protocolo a otro. Este protocolo tiene banderas o identificadores particulares de acuerdo con la información que transportan y asta ahora no e conseguido algún texto que me lo explique en su totalidad, su supieran de algo les agradezco me lo comuniquen . Si puedo ayudar en algo por favor pregunten gracias. 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Diciembre de 2008, 15:15:50
En este enlace tienes la norma para comprarla completa o por secciones.
Si eres socio de la NMEA tienes importantes descuentos... :lol:

https://www.nmea.org/secure/purchase.cgi?T=P (https://www.nmea.org/secure/purchase.cgi?T=P)

Perdon, habia olvidado poner el link... :lol:
Título: SNIFFER CAN EN MARCHA !!!
Publicado por: MGLSOFT en 17 de Diciembre de 2008, 14:14:11
Habia prometido trabajar con el Sniffer CAN y poner los adelantos aqui.
Por ahora les pongo una imagen del circuito armado sobre un protoboard, que costo bastante hacerlo funcionar, ya que hay cristales de 20 Mhz montados alli, y no se llevan bien con el protoboard... :mrgreen: :mrgreen: :mrgreen:

La imagen de la placa funcionando junto a mi placa desarrollo CAN.

(http://img120.imageshack.us/img120/4029/1003812im3.jpg)

Y la imagen del programa en PC que registra lo que pasa en el bus.

(http://img262.imageshack.us/img262/5365/pantallacanmonitortf0.png)

Proximamente mas novedades!!! :) :) :)
Título: SNIFFER CAN EN MARCHA !!!
Publicado por: MGLSOFT en 17 de Diciembre de 2008, 14:26:38
Esta basado en esta nueva placa de Microchip:

(http://img241.imageshack.us/img241/1002/mcp2515dmbmoj3.png)

Usa un PIC18F4550, un MCP2515 y un MCP2551, ademas de otros componentes, ya pondre el circuito mio, pero si quieren obtener mas informacion, la encontraran en este link:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537141&part=MCP2515DM-BM (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537141&part=MCP2515DM-BM)

Saludos!! :mrgreen: :mrgreen: :mrgreen:

Título: Re: SNIFFER CAN EN MARCHA !!!
Publicado por: teleko en 19 de Diciembre de 2008, 12:41:31
Esta basado en esta nueva placa de Microchip:

(http://img241.imageshack.us/img241/1002/mcp2515dmbmoj3.png)

Usa un PIC18F4550, un MCP2515 y un MCP2551, ademas de otros componentes, ya pondre el circuito mio, pero si quieren obtener mas informacion, la encontraran en este link:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537141&part=MCP2515DM-BM (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537141&part=MCP2515DM-BM)

Saludos!! :mrgreen: :mrgreen: :mrgreen:



El otro día me llegó un mail con esta placa como novedad. Aún no me ha dado tiempo a mirarlo, llevo unos días bastante ocupado.

En la protoboard, ¿has cargado el firm de microchip?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Diciembre de 2008, 15:02:40
Si, por ahora tiene el firmware original de Microchip.
Estoy viendo como debo hacer para portarlo al CCS.
Mientras tanto planeo hacerle modificaciones a ver como va, porque solo tiene 4 velocidades del Bus CAN (125, 250, 500 y 1000 Kbps) para seleccionar cual vas a utilizar, aunque esta interesante que al hacerlo con el MCP2515 puedes entrar a configurar los registros y usar cualquier velocidad que necesites.

Tuve problemas con la fuente de mi placa desarrollo y por eso me retrase, sino ya habria hecho estas pruebas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ekys en 27 de Diciembre de 2008, 21:03:07
Hola a todos,

actualmente dispongo de una placa con 2 micros 18F4680, y para cada micro; 1 reset, 2 pulsadores,
1 potenciometro y 9 Leds. Solo uno de los 2 micros posee interfaz rs232 para comunicarse con el PC.

La idea es realizar un analizador logico del protocolo CAN de manera que, cada vez que se pulse
algun boton o el potenciometro del micro sin rs232, este envie un mensaje can al micro con rs232 y
que este ultimo envie y muestre la trama can COMPLETA en el Hyperterminal o similar del PC.

El problema es que no se me ocurre de que manera podria mostrar la información de TODA la trama
CAN.

Como todos los que estais siguiendo este hilo sabreis, una trama can se compone de varios campos:
inicio, asignacion, control, datos, CRC, confirmacion y fin de trama. Sin embargo, en todos los
ejemplos expuestos en relacion al sniffer can, la unica informacion que se muestra es el campo de
datos, el identificador, el tipo de trama, el RTR y poco mas.

No habria alguna manera de mostrar por pantalla toda la tira de bits que recibe el nodo con rs232
cuando se le envia una trama can desde el otro micro???

Cualquier tipo de ayuda o sugerencia sera eternamente agradecida.

Saludos.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Diciembre de 2008, 08:56:59
Hola a todos,

actualmente dispongo de una placa con 2 micros 18F4680, y para cada micro; 1 reset, 2 pulsadores,
1 potenciometro y 9 Leds. Solo uno de los 2 micros posee interfaz rs232 para comunicarse con el PC.

La idea es realizar un analizador logico del protocolo CAN de manera que, cada vez que se pulse
algun boton o el potenciometro del micro sin rs232, este envie un mensaje can al micro con rs232 y
que este ultimo envie y muestre la trama can COMPLETA en el Hyperterminal o similar del PC.

El problema es que no se me ocurre de que manera podria mostrar la información de TODA la trama
CAN.

Como todos los que estais siguiendo este hilo sabreis, una trama can se compone de varios campos:
inicio, asignacion, control, datos, CRC, confirmacion y fin de trama. Sin embargo, en todos los
ejemplos expuestos en relacion al sniffer can, la unica informacion que se muestra es el campo de
datos, el identificador, el tipo de trama, el RTR y poco mas.

No habria alguna manera de mostrar por pantalla toda la tira de bits que recibe el nodo con rs232
cuando se le envia una trama can desde el otro micro???

Cualquier tipo de ayuda o sugerencia sera eternamente agradecida.

Saludos.



Buen punto has citado. :mrgreen:
Una cosa que todos tomamos por sabida, pero no se si en realidad es tan sabida, es precisamente lo que comentas...

Si miran por ahi, todos los softwares de Sniffer CAN muestran informacion limitada a la trama recibida, y no muestran el resto de la informacion.   Porque ??? :shock:

Es simple, los demas campos mecionados son parte del protocolo CAN, y el protocolo CAN (Entre ellos la velocidad de comunicacion) se resuelve a nivel fisico, es decir lo resuelve el hardware interno del transceptor CAN que elegimos para comunicar.

En realidad no se si podemos acceder realmente a esta informacion, salvo por los codigos de error y otros valores del BUS, es muy probable que no se acceda a esa informacion normalmente, y esa es la razon por la cual no se muestra.

Estudiemos mas profundamente a ver si esos valores son accesibles.
Estimo que no, pero vale la pena averiguarlo, no es asi??
 :lol: :lol:
Título: Mis experiencias con el BUS CAN
Publicado por: pierno10 en 29 de Diciembre de 2008, 10:37:10
Hola Chic@s!!!

En primer lugar FELICES FIESTAS!!!  :mrgreen: :lol:

Ahora estaba dando una vuelta por aki, y he visto que el tema del Sniffer aun no esta claro del todo...

Yo si no recuerdo mal os deje un esquema que se comunica con el bus mediante un PIC y este a su vez con el PLC por el puerto RS232. Buscare el esquema pero lo que si tengo aki es el código en C de la programación del PIC. Os la remito para que le deis un vistazo a ver si os ayuda en algo. El esquema de conexionado es muy fácil y la idea también. Usaremos para leer el puerto rs232 cualquier consola que lo soporte (hiperterminal x ejemplo).

Buenos os dejo el tema a.C. si hay alguna duda poneos es contacto conmigo.

Un saludo desde Valencia  :-/

                         PERE.

PD: Marcos recuerdas el tema de la consulta de hacer las placas a doble cara, ya me dices algo. Un abrazo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Diciembre de 2008, 11:07:26
Citar
PD: Marcos recuerdas el tema de la consulta de hacer las placas a doble cara, ya me dices algo. Un abrazo.

Te conteste y me dio intriga que no respondieras, Pierno!!! :shock: :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 29 de Diciembre de 2008, 18:29:26
Buenas, Felicitaciones por toda la info recolectada aqui y por el tiempo invertido.... por mi parte ya estoy agotado despues de leer las 27 paginas y archivos anexos !!!

Estoy desarrollando un proyecto sobre Bus CAN, resumiendo es algo parecido a lo comentado sobre la conexion al OBDII del auto, pero creeria mas sencillo como primera medida.

Acceso Fisico al Bus ---> MCP2551 ---> 18F2580  ----> MAX232 --- > Terminal Serie
(ya perdi horas con la simulacion en Proteus...  :( )
CCS C v.4.038 (uso de las librerias incluidas. can-18xxx8)

Basicamente quisiera que me ayuden a realizar algun tipo de filtro (de toda la info recaudada) para obtener un esquematico con esa simple conexion y el programa C para hacer de "snifer" de las tramas del auto.

Entiendo existen a simple vista dos problemas:  1) desconociemiento de los ID's de los dispositivos del auto y 2) las velocidades del Bus.
{ Logre mediante una simple interfaz comunicarme con la ECU (principal) del auto a travez de otro bus y en teoria se la direccion (ID) de la misma. }

Felicitaciones nuevamente y agradezco de antemano las respuestas.
Felices Fiestas !!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Diciembre de 2008, 18:46:54
En las respuestas Nº 507 y 508 del hilo encontraras todo un proyecto sobre ODBII, con la programacion completa... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 29 de Diciembre de 2008, 19:03:38
que velocidad !!! MGLSOFT

Gracias por la pronta respuesta.

Te comento que si habia visto todo ese codigo. Por ahi tendria que limpiarlo y ver de hacer algo mas chiquito asi lo puedo manejar mejor mientras entiendo mas las cosas.

Algun esquematico que me aconsejes, para armar lo mas pronto posible ya que segun lei con la protoboard no voy a lograr que funcione nada.
puedo integrar un ICP ? con que programador ? (ya que lo voy a conectar al serie de la PC)

Gracias.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Diciembre de 2008, 19:16:30
Esquematicos, puedes usar uno de los de Pierno10, que los hace muy bonitos... :lol:
El alli contempla el conector ICSP.
Lo que deberias saber es que programador utilizaras para fabricarte el cable ICSP adaptado a tu programador...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 30 de Diciembre de 2008, 19:12:58
Gente, aca dejo un pequeño aporte espero que a alguien le sirva. Vendria siendo un simulador del Bus CAN del automovil, bajando la demo se pueden ver varios ejemplos con sistemas completos funcionando (timing, datos, eventos)

Link: https://www.vector-worldwide.com/vi_downloadcenter_en.html

Elegir: CANanalyzer - Demo - Show Results: 5 items.

Yo baje el CAN analyzer de 265 MB

Como comente anteriormente estoy armando un circuito que pronto subire para recibir sus consejos...

En este foro no se permite el software ilegal

MGLSOFT: Modificando los valores de los registros a mano en el MPSIM, se podra "simular" un poco el comportamiento del codigo (bus) ?

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Diciembre de 2008, 21:20:40
Amigo Arameo, deberias leer bien las reglas del foro.
Como ya viste los moderadores siempre estan atentos a quienes violan las reglas y como este caso, editan los post para evitar problemas.

Despues entro en la pagina a ver de que se trata, gracias por el link. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ekys en 08 de Enero de 2009, 14:58:56
Citar
En realidad no se si podemos acceder realmente a esta informacion, salvo por los codigos de error y otros valores del BUS, es muy probable que no se acceda a esa informacion normalmente, y esa es la razon por la cual no se muestra.

Quieres decir que podemos acceder al campo CRC de una trama??? o algun otro valor del bus???

Si es así dime cómo porqué llevo unos dias estrujándome la cabeza para conseguir mas información de las tramaas CAN y no lo consigo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Enero de 2009, 15:13:59
Gente, aca dejo un pequeño aporte espero que a alguien le sirva. Vendria siendo un simulador del Bus CAN del automovil, bajando la demo se pueden ver varios ejemplos con sistemas completos funcionando (timing, datos, eventos)

Link: https://www.vector-worldwide.com/vi_downloadcenter_en.html

Elegir: CANanalyzer - Demo - Show Results: 5 items.


En el sitio dice claramente que es un demo que no funciona con un hardware conectado!! :shock: :shock:

Citar
CANalyzer / CANoe 7.0
Fully functional demo including CAN, LIN, MOST, FlexRay, J1939, NMEA 2000, and J1587. The only limitation is that access to any hardware interface is not possible. The time-management is done with Windows timers, so it cannot be assumed that the time behaviour of the full version will be the same as of the demo. This means that the simulation time of the demo version does not necessarily correspond to real time.

Citar

Como comente anteriormente estoy armando un circuito que pronto subire para recibir sus consejos...


Lo esperamos ansiosamente...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Enero de 2009, 15:18:01
Quieres decir que podemos acceder al campo CRC de una trama??? o algun otro valor del bus???


A lo que puedes acceder es a los bits de error que envian los nodos del bus...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ekys en 08 de Enero de 2009, 15:54:48
Citar
A lo que puedes acceder es a los bits de error que envian los nodos del bus...

Perdona mi ignorancia pero a que bits de error te refieres?? forman parte del campo de datos de la trama??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Enero de 2009, 16:16:51
Aqui tienes una idea de que hablo:
Tramas CAN (http://www.todopic.com.ar/foros/index.php?topic=19182.msg139761#msg139761)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ekys en 08 de Enero de 2009, 16:50:42
OK, ya veo lo q dices. Pero como lo harias tu para recoger estos bits de la trama de error??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Enero de 2009, 17:02:33
Lo hace el hardware del receptor CAN, solo tienes que leerlos, que es lo mismo que puedes hacer con el resto de la informacion...
Deberias leer mas profundamente la parte de configuracion del bus can de tu dispositivo, y veras donde obtener cada dato.
El CRC y otros campos de la trama se resuelven a nivel de hardware, no te olvides que una vez recibida la trama, compara el CRC y si todo esta bien, antes de colocar la informacion en alguno de los buffers de recepcion, hace un AND con la mascara programada y con los IDs que hayas puesto.
Si no pasa ese filtrado es porque el dato ni siquiera interesa, asi que nunca llega a la capa de software... :D :D :D

Mira bien las diferentes capas, todo esto que digo esta entre la info colocada en los post de las primeras 4 o 5 paginas del hilo... :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 09 de Enero de 2009, 11:05:36
Hola, ya estoy de nuevo con el tema del canbus. Antes de nada espero que hayan pasado unas buenas navidades.

Ayer estuve intentando conectar al coche, pero no fui capaz de leer ninguna trama. Básicamente lo único que hacía el programa de prueba era leer mensajes del bus y pasarlos por el rs232 al pc. Activando la función de Debug que trae las librerias de CCS.

De un modo parecido lo tenía probado entre esta placa y otro 2580 en la protoboard y había buena comunicación. Era un montaje similar a uno del foro de CCS, enviaba un caracter desde el pc al pic (por rs232), éste lo pasaba al otro pic por can, hacía un eco al caracter recibido y el primero se lo volvía de nuevo al pc. Una especie de gran bucle.

Ahora mismo estoy un poco perdido y no se por donde continuar...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Enero de 2009, 15:07:58
Como era la conexion que hiciste??
Seguro que conectaste a los pines del bus??
Pusiste a tierra la placa del pic??

Que velocidades utilizaste??
Fuiste cambiandolas??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 09 de Enero de 2009, 16:10:51
La conexión fue conectando sólo el CanH y CanL, ya que el cable OBD que tengo no coincide con las conexiones de mi placa. Yo creo que el fallo está ahí, que debo conectar con la masa del coche (hay un pin a masa en el OBD.). La tensión a la placa es con un cable USB (sólo conexión de voltaje) conectado al portatil, con eso queda alimentada a casi 5V. Cierto es que cuando lo conecto a la protoboard, tomo la misma alimentación para ambos PIC.

Las velocidades probé con 250 y 500kbps, que según he leido por ahí, son las 2 posibles a la que trabaja el Can en Toyota. Probé a conectar un polímetro que tengo con la función logic, y detecta cambios de estado muy rápidos (o sea, algo se está transmitiendo por el bus). Aunque lo mejor sería un osciloscopio.

Por cierto, en un hilo de ccsinfo vi tu nick, preguntando lo que yo estaba buscando de "can autobaud". ¿Tienes alguna rutina que haga esto con el modo listen?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Enero de 2009, 16:42:32
Okala tuviera una rutina para hacerlo!! :D :D
Hay que trabajar bastante en software para poder lograrlo, ademas solo podrias acceder a un set de velocidades conocidas, si un fabricante usa velocidades no estandar, nunca podrias encontrarla!!!

Por eso los sniffer que conozco no lo tienen.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 16 de Enero de 2009, 20:16:54
Gente, aca les dejo el esquematico para que me comenten que les parece y recibir sus criticas, cambios, consejos, etc.

Una configuracion que veo cambia bastante a la que figura en el circuito del ELM327, es la salida del MCP2551 al Bus (Adjunto Foto)
La RS propuesta es de 4.7 K  y la planteada de 10 (mucha diferencia)
Al igual que las R y los C conectados de las lineas del bus a tierra.

(http://img258.imageshack.us/img258/8350/dudamcp2551bo2.th.jpg) (http://img258.imageshack.us/my.php?image=dudamcp2551bo2.jpg)

El switchx4 es con la idea de programar el testeo de los pines del PortA en la conf. del bus y segun ellos realizar la configuracion de la velocidad de transferencia del bus (ya que desconozco con cual funciona el auto), esto para no tener que grabar el PIC nuevamente si deseo probar otra velocidad.
Creo que es factible desenchufar los pines del bus, cambiar una conf. del switch y resetear el PIC, al detectar otro valor en estos pines, entra a otra rutina de conf.

Como ven esta idea ?

Bueno, espero comentarios y poder subir algun codigo simple propuesto/probado.

Saludos

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Enero de 2009, 23:04:55
Supongo que con el doble circuito RC intentan filtrar vaya a saber que (el MCP2551 tiene todo ese hardware adentro), y si miras la hoja de datos la resistencia de 4,7K es para velocidades del bus muy bajas...

lo de las llaves para la configuracion de velocidad del bus no esta mal, aunque seria lo mismo cambiar con un pulsador y usar esas entradas como salidas y mostrar cual fue la velocidad seleccionada.
En modo binario tendrias 15 posibilidades, de esa forma sabrias a ciencia cierta cual es la velocidad utilizada...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gustpe en 21 de Enero de 2009, 23:53:12
Hola a todos, este mi primer aporte en el tema del Bus-Can, bueno les cuento, me compre una interface can usb http://www.canusb.com/index.htm, muy buena por cierto te dan un programa para ver los datos y algunos ejemplos con labview y otros, lo probe en un vehiculo y me leyo todos los datos, con esos datos me dispuse a armar mi propia interface usando el dspic 30f4011 con el mcp2551 y cristal de 20Mhz, lo programe con el mikrobasic para dspic, y bueno despues de tanto lidiar logre configurar para enviar y recibir mensajes 500Kbps, y aqui viene mi problema cuando conecto el dspic con la interface usb me envia y recibe bien los datos, pero cuando lo conecto con el vehiculo, este se resetea, si solo programo el dspic para enviar no hay  problema, pero si lo configuro asi sea solo para recibir se me resetea, nose porque si alguien me puede ayudar, les adjunto el programa del dspic. gracias

Código: FreeBasic
  1. program TX_RX_CAN_500Kbs
  2. include "logo"
  3. dim Can_Init_Flags, Can_Send_Flags, Can_Rcv_Flags, MSG_RCVD, RX_DATA_LEN, X as word
  4.     Tx_Data  as byte[8]
  5.     Rx_Data  as byte[8]
  6.     txt as string[3]
  7.     Rx_ID, Tx_ID as longint
  8.  
  9. main:
  10.   ADPCFG = $FFFF
  11.   Can_Init_Flags   = 0
  12.   Can_Send_Flags   = 0
  13.   Can_Rcv_Flags    = 0
  14.  
  15.   Can_Send_Flags   = CAN_TX_PRIORITY_1 and           ' SE UTILIZA PARA
  16.                      CAN_TX_STD_FRAME and            '  CANSendMessage
  17.                      CAN_TX_RTR_FRAME
  18.  
  19.   Can_Init_Flags   = CAN_CONFIG_SAMPLE_THRICE and    ' SE ULILIZA PARA
  20.                      CAN_CONFIG_PHSEG2_PRG_ON and    '  CANInitialize
  21.                      CAN_CONFIG_XTD_MSG and
  22.                      CAN_CONFIG_DBL_BUFFER_ON and
  23.                      CAN_CONFIG_ALL_VALID_MSG  and
  24.                      CAN_CONFIG_LINE_FILTER_OFF
  25.  
  26.   CAN1Initialize(1,2,4,4,1,Can_Init_Flags)           ' configurado a 500kbs con oscilador
  27.                                                       'de 20 MHz
  28.   CAN1SetOperationMode(CAN_MODE_NORMAL, 0x00)         ' set CONFIGURATION mode
  29.  
  30.  
  31.   CAN1SetMask(CAN_MASK_B1, -1, CAN_CONFIG_MATCH_MSG_TYPE and CAN_CONFIG_STD_MSG)   ' set all mask1 bits to ones
  32.   CAN1SetMask(CAN_MASK_B2, -1, CAN_CONFIG_MATCH_MSG_TYPE and CAN_CONFIG_STD_MSG)   ' set all mask2 bits to ones
  33.   CAN1SetFilter(CAN_FILTER_B1_F1, 5,CAN_CONFIG_STD_MSG) ' set id of filter B2_F3 to 3
  34.   CAN1SetOperationMode(CAN_MODE_NORMAL, 0x00)           ' modo Normal ENVIA Y RECIBE
  35.  
  36. ' -----------------configuracion del glcd 128x64
  37.   Glcd_Init(PORTC,13,PORTC,14,PORTE,8,PORTD,1,PORTB,8,PORTD,3,PORTB) 'conf d puertos
  38.   delay_ms(2000)
  39.  
  40.     Glcd_Fill(0x00)  ' Limpiar pantalla
  41.     Glcd_Image(LOGOTIPO_bmp)         'dibujar imagen
  42.     Delay_MS(5000)
  43.     Uart2_Init(9600)                   'INICIALIZAMOS RS232
  44.     Glcd_Fill(0x00)  ' Limpiar pantalla
  45. MOSTAR:
  46.   while TRUE
  47.     Tx_ID=$100
  48.     Tx_Data[0] = $EC
  49.     Tx_Data[1] = $04
  50.     Tx_Data[2] = $00
  51.     Tx_Data[3] = $00
  52.     Tx_Data[4] = $00
  53.     Tx_Data[5] = $A9
  54.     Tx_Data[6] = $0B
  55.     Tx_Data[7] = $6a
  56.     CAN1Write(Tx_ID, Tx_Data, 8, Can_Send_Flags)   ' envio los datos
  57.     Tx_ID=$500
  58.     Tx_Data[0] = $5E
  59.     Tx_Data[1] = $00
  60.     Tx_Data[2] = $F8
  61.     Tx_Data[3] = $02
  62.     Tx_Data[4] = $D2
  63.     Tx_Data[5] = $02
  64.     Tx_Data[6] = $26
  65.     Tx_Data[7] = $02
  66.     CAN1Write(Tx_ID, Tx_Data, 8, Can_Send_Flags)   ' envio los datos
  67.     FOR X=0 TO 100
  68.     DELAY_MS(1)           'PAUSA ENTRE ENVIO RECEPCION
  69.     NEXT X
  70.    
  71.     Msg_Rcvd = CAN1Read(Rx_ID , Rx_Data , Rx_Data_Len, Can_Rcv_Flags)
  72.  
  73.     IF Rx_ID=$112 THEN
  74.     Uart2_Write_TEXT ("112")
  75.     Glcd_Set_Font(@System3x6, 3, 6, 32)
  76.     Glcd_Write_TEXT("RX_ID=112   DLC=", 3, 0, 2)
  77.     ByteToStr(Rx_Data_LEN, txt)
  78.     Glcd_Write_TEXT(TXT, 63, 0, 2)
  79.     ByteToStr(Rx_Data[0], txt)
  80.     Glcd_Write_TEXT(TXT, 3, 1, 0)
  81.     ByteToStr(Rx_Data[1], txt)
  82.     Glcd_Write_TEXT(TXT, 18, 1, 0)
  83.     ByteToStr(Rx_Data[2], txt)
  84.     Glcd_Write_TEXT(TXT, 33, 1, 0)
  85.     ByteToStr(Rx_Data[3], txt)
  86.     Glcd_Write_TEXT(TXT, 48, 1, 0)
  87.     ByteToStr(Rx_Data[4], txt)
  88.     Glcd_Write_TEXT(TXT, 63, 1, 0)
  89.     ByteToStr(Rx_Data[5], txt)
  90.     Glcd_Write_TEXT(TXT, 78, 1, 0)
  91.     ByteToStr(Rx_Data[6], txt)
  92.     Glcd_Write_TEXT(TXT, 93, 1, 0)
  93.     ByteToStr(Rx_Data[7], txt)
  94.     Glcd_Write_TEXT(TXT, 108, 1, 0)
  95.     END IF
  96.  
  97.     IF Rx_ID=$512 THEN
  98.     Uart2_Write_TEXT ("512")
  99.     Glcd_Set_Font(@System3x6, 3, 6, 32)
  100.     Glcd_Write_TEXT("RX_ID=512   DLC=", 3, 2, 2)
  101.     ByteToStr(Rx_Data_LEN, txt)
  102.     Glcd_Write_TEXT(TXT, 63, 2, 2)
  103.     ByteToStr(Rx_Data[0], txt)
  104.     Glcd_Write_TEXT(TXT, 3, 3, 0)
  105.     ByteToStr(Rx_Data[1], txt)
  106.     Glcd_Write_TEXT(TXT, 18, 3, 0)
  107.     ByteToStr(Rx_Data[2], txt)
  108.     Glcd_Write_TEXT(TXT, 33, 3, 0)
  109.     ByteToStr(Rx_Data[3], txt)
  110.     Glcd_Write_TEXT(TXT, 48, 3, 0)
  111.     ByteToStr(Rx_Data[4], txt)
  112.     Glcd_Write_TEXT(TXT, 63, 3, 0)
  113.     ByteToStr(Rx_Data[5], txt)
  114.     Glcd_Write_TEXT(TXT, 78, 3, 0)
  115.     ByteToStr(Rx_Data[6], txt)
  116.     Glcd_Write_TEXT(TXT, 93, 3, 0)
  117.     ByteToStr(Rx_Data[7], txt)
  118.     Glcd_Write_TEXT(TXT, 108, 3, 0)
  119.     END IF
  120.  
  121.      IF Rx_ID=$712 THEN
  122.     Uart2_Write_TEXT ("700")
  123.     Glcd_Set_Font(@System3x6, 3, 6, 32)
  124.     Glcd_Write_TEXT("RX_ID=700   DLC=", 3, 4, 2)
  125.     ByteToStr(Rx_Data_LEN, txt)
  126.     Glcd_Write_TEXT(TXT, 63, 4, 2)
  127.     ByteToStr(Rx_Data[0], txt)
  128.     Glcd_Write_TEXT(TXT, 3, 5, 0)
  129.     ByteToStr(Rx_Data[1], txt)
  130.     Glcd_Write_TEXT(TXT, 18, 5, 0)
  131.     ByteToStr(Rx_Data[2], txt)
  132.     Glcd_Write_TEXT(TXT, 33, 5, 0)
  133.     ByteToStr(Rx_Data[3], txt)
  134.     Glcd_Write_TEXT(TXT, 48, 5, 0)
  135.     ByteToStr(Rx_Data[4], txt)
  136.     Glcd_Write_TEXT(TXT, 63, 5, 0)
  137.     ByteToStr(Rx_Data[5], txt)
  138.     Glcd_Write_TEXT(TXT, 78, 5, 0)
  139.     ByteToStr(Rx_Data[6], txt)
  140.     Glcd_Write_TEXT(TXT, 93, 5, 0)
  141.     ByteToStr(Rx_Data[7], txt)
  142.     Glcd_Write_TEXT(TXT, 108, 5, 0)
  143.     END IF
  144.   wend
  145. GOTO MOSTRAR
  146. end.

MGL. Perdon por la edicion, pero asi se puede ver tu codigo sin tener el editor...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Enero de 2009, 00:15:31
Hola gustpe!!
Felicitaciones por la herramienta y por tu aporte al hilo!!

Podrias agregar una imagen del circuito completo de tu placa??
Eso nos ayudaria a intentar saber si tu reset proviene del hardware o si es del software.
No tengo mucha (nada en realidad) experiencia con los Dspic, pero podremos aprender todos juntos sobre el mismo...

Edito:
Cuando pegue el codigo de tu sniffer me di cuenta que la etiqueta de salida no es igual a donde quieres saltar, la primera es MOSTAR y el GoTo te envia a MOSTRAR..
Deberia darte error el compilador..pero es posible que alli tengas el error.. :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gustpe en 22 de Enero de 2009, 01:06:19
Que error para grande que he cometido, pero lo extrano es que no me daba error al compilar, bueno lo pruebo manana y les comentos, ojala funcione y bueno no lo tengo hecho en placa sino armado en el proto, ahi les subo las fotos del cicuito y de los datos q me muestra en el lcd
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Enero de 2009, 01:42:51
Y si lo dibujas en papel y pegas aqui una imagen te va bien ?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gustpe en 22 de Enero de 2009, 11:51:25
Aqui esta el esquema :), en las lines can-h y can-l, conecto una resistencia de 100ohm cuando lo conecto a mi interface can-usb, pero cuando lo conecto en el vehiculo lo hago sin la resistencia porque este ya trae una, cuando mido las dos lineas me da un valor de 120ohm, tambien en las lineas entre el dspic y el mcp e puesto unos led que me indica que esta funcionando, pero igual funciona con o sin estos, por esta razon no los puse en el esquema, bueno como les dije hoy pruebo haber si ya me funciona el programa con la correcion MGLSOFT, muchas gracias por cierto, ya escribo cualquier avace.
Aqui les dejo unos links, que tienen buena informacion en español.
http://server-die.alc.upv.es/asignaturas/PAEEES/2005-06/A05-A06%20-%20Funcionamiento%20del%20controlador%20CAN%20en%20el%20dsPIC30F4013.pdf
http://bieec.epn.edu.ec:8180/dspace/handle/123456789/986
http://bieec.epn.edu.ec:8180/dspace/handle/123456789/743
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Enero de 2009, 12:31:28
Creo que cometes un error y es que no poner la resistencia de fin de linea te provoca error de Bus override y queda tonto tu receptor, ademas el valor de la resistencia es de 120 ohm no de 100 ohms. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gustpe en 23 de Enero de 2009, 00:04:04
Hola, les cuento que hoy hice las pruebas y me funciono muy bien :P, lo unico q cambie del programa fue que le quite el Mostrar y Goto Mostrar, y me funciono a la perfeccion, mañana voy a continuar con las pruebas para ver si todo esta bien hacerme el pcb, pienso hacerlo todo en montaje superficial, y sobre la resistencia igual me funciona con la de 100ohm, no recuerdo donde pero lei que decia q el bus-can debe tener una resistencia entre 60 y 200, si encuentro la info la subo para que puedan verla.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Enero de 2009, 00:19:01
Me alegro muchisimo que ande tu proyecto.
Ya nos contaras mas sobre el mismo y como funciona.
La coneccion a PC es serial o USB ??
Ya tienes software de PC o usas el mismo del CANUSB ??

Bueno espero puedas contestarnos y mostrar mas a fondo lo que estas haciendo... :P
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gustpe en 23 de Enero de 2009, 00:23:45
Bueno la coneccion a la pc la voy a hacer por serial porque se me facilita, aun no domino el usb, y como hay tantos adaptadores usb serial pues hay q aprovecharlos :lol:, y bueno el programa del pc lo pienso hacer en labview, nose si interesa alguna info de mi proyecto diganme y con gusto la comparto :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Enero de 2009, 00:25:48
Por supuesto que interesa!! :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 07 de Febrero de 2009, 17:22:58
Buenas, lo prometido es deuda. Aca les adjunto las fotitos del circuito y al lado se encuentra el programador que estoy utilizando.

(http://img168.imageshack.us/img168/8453/enefeb2009124ao8.th.jpg) (http://img168.imageshack.us/my.php?image=enefeb2009124ao8.jpg)

Esquematico:
(http://img150.imageshack.us/img150/6827/esquematicofinalposteaddl3.th.jpg) (http://img150.imageshack.us/my.php?image=esquematicofinalposteaddl3.jpg)

http://img14.imageshack.us/my.php?image=esquematicofinalposteadom8.pdf

El codigo utilizado es el siguiente:

Código: [Seleccionar]


#include "main.h"


#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>

#byte porta = 0
#byte portb = 6
#byte portc = 7


void main()
{
   
   struct rx_stat rxstat;
   int32 rx_id;
   int in_data[8];
   int rx_len;

   //send a request (tx_rtr=1) for 8 bytes of data (tx_len=8) from id 24 (tx_id=24)
   int out_data[8];
   int32 tx_id=24;
   int1 tx_rtr=1;
   int1 tx_ext=0;
   int tx_len=8;
   int tx_pri=3;
   int corrida;
   int i;

   for (i=0;i<8;i++) {
      out_data[i]=0;
      in_data[i]=0;
   }
   


   set_tris_a(0b11111111);
   set_tris_b(0b00001000);
   set_tris_c(0b10000000);

   porta=0;
   portb=0;
   portc=0;


   can_init();
   
   can_set_mode(CAN_OP_CONFIG);
   

//Configuracion CAN 500 kbps

      BRGCON1.brp=2;
      BRGCON1.sjw=1;
      BRGCON2.prseg=1;
      BRGCON2.seg1ph=4;
      BRGCON2.sam=FALSE;
      BRGCON2.seg2phts=FALSE; 
      BRGCON3.seg2ph=4;
      BRGCON3.wakfil=TRUE;



   can_set_mode(CAN_OP_NORMAL);
 

 
   corrida = 0;
 
while (corrida < 31)  //Numero aleatorio de corrida para una lectura mas limpia y analisis posterior.
   {


if ( can_kbhit() ) //if data is waiting in buffer...
    { 

if(can_getd(rx_id, &in_data[0], rx_len, rxstat)) //...then get data from buffer
        {
    printf("\r\nGOT: BUFF=%U ID=%LU LEN=%U OVF=%U ", rxstat.buffer, rx_id, rx_len, rxstat.err_ovfl);
            printf("FILT=%U RTR=%U EXT=%U INV=%U", rxstat.filthit, rxstat.rtr, rxstat.ext, rxstat.inv);
            printf("\r\n    DATA = ");
            for (i=0;i<rx_len;i++) {
               printf("%X ",in_data[i]);
            }
           

        }
else
{
            printf("\r\nFallo can_getd()\r\n");
        }
    }



    if ( can_tbe() )
    {
       
         i=can_putd(tx_id, out_data, tx_len,tx_pri,tx_ext,tx_rtr); //put data on transmit buffer
         if (i != 0xFF)
{
            printf("\r\nPUT %U: ID=%LU LEN=%U ", i, tx_id, tx_len);
            printf("PRI=%U EXT=%U RTR=%U\r\n   DATA = ", tx_pri, tx_ext, tx_rtr);
            for (i=0;i<tx_len;i++) {
               printf("%X ",out_data[i]);
            }
            printf("\r\n");
         }
         else
{ //fail, no transmit buffer was open
            printf("\r\nFallo can_putd(); \r\n");
         }
      }


   corrida++;
   }

}



Respuesta del Auto (Clio 1.2 16V año 2007) Conectandola interface a la linea CANH - CANL del conector OBDII
Código: [Seleccionar]

Entro al main...

Previo a can_init();

CAN Inicializado ...

Modo CAN en Configuracion

500 kps...

Modo CAN en Normal

Previo a can_kbhit(); ...

Previo a can_tbe(); - Analisis del buffer de emision - Si esta vacio entra

Entro can_tbe(); - Buffer de Transmision Vacio, puedo escribir - Espero 4seg.

PUT 1: ID=24 LEN=8 PRI=3 EXT=0 RTR=0
   DATA = 00 00 00 00 00 00 00 00

Termino corrida bandera ...

Entro can_tbe(); - Buffer de Transmision Vacio, puedo escribir - Espero 4seg.

PUT 1: ID=24 LEN=8 PRI=3 EXT=0 RTR=0
   DATA = 00 00 00 00 00 00 00 00

Entro can_tbe(); - Buffer de Transmision Vacio, puedo escribir - Espero 4seg.

PUT 1: ID=24 LEN=8 PRI=3 EXT=0 RTR=0
   DATA = 00 00 00 00 00 00 00 00

-----------------------------------------------------------------------------
RESPUESTA DEL AUTO EN MARCHA
-----------------------------------------------------------------------------


Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 00 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=442 LEN=5 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 35 00 3E 09

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1C CC 33 10 00 31 31

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1B 6B 34 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1B EB 32 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1B AE 32 10 00 31 31

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1B 77 33 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1B 1B 33 10 00 31 31

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1B 56 34 10 00 31 31

Entro al main...

Previo a can_init();

CAN Inicializado ...

Modo CAN en Configuracion

500 kps...

Modo CAN en Normal

Previo a can_kbhit(); ...

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1A AD 34 10 00 31 32

Previo a can_tbe(); - Analisis del buffer de emision - Si esta vacio entra

Entro can_tbe(); - Buffer de Transmision Vacio, puedo escribir - Espero 4seg.

PUT 1: ID=24 LEN=8 PRI=3 EXT=0 RTR=0
   DATA = 00 00 00 00 00 00 00 00

Termino corrida bandera ...

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1A 73 34 10 00 32 32

Entro can_tbe(); - Buffer de Transmision Vacio, puedo escribir - Espero 4seg.

PUT 1: ID=24 LEN=8 PRI=3 EXT=0 RTR=0
   DATA = 00 00 00 00 00 00 00 00

-----------------------------------------------------------------------------
RESPUESTA DEL AUTO EN MARCHA Acelerado
-----------------------------------------------------------------------------


Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 1A 69 33 10 00 31 31

Entro can_tbe(); - Buffer de Transmision Vacio, puedo escribir - Espero 4seg.

PUT 1: ID=24 LEN=8 PRI=3 EXT=0 RTR=0
   DATA = 00 00 00 00 00 00 00 00

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 18 DF 33 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 18 D7 33 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 18 D8 34 10 00 31 31

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=442 LEN=5 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 33 00 3D 09

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 17 F2 33 10 00 32 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 18 4B 33 10 00 31 31

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 17 FF 33 10 00 31 31

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=442 LEN=5 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 00 34 00 3D 09

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 17 8A 34 10 00 31 32

Se supero can_kbhit(); - Hay datos en Buffer de entrada esperando...
GOT: BUFF=0 ID=250 LEN=7 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 16 EA 33 10 00 32 32



Problemillas a solucionar:

1) ICSP no lo logro hacer funcionar, testee el cable y todo el patillaje se encuentra bien. WinPic800 no me lo detecta e Icprog no lee el PIC. Algun consejo ?
2) Switch en el puertoA sin funcionar. Probe varias cosas, tampoco insisti mucho. Creeria que es alguna configuracion del puerto. Saben como setearlopara que me lo tome ?
3) Interpretacion correcta de los datos recibidos.

Espero les sirva de algo y sus aportes.

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 07 de Febrero de 2009, 19:42:09
Muy interesante lo que has conseguido, aunque creo que no tiene nada que ver lo que envias para ver lo recibido.

¿En que pines del OBD conectas, el 6 y 14? Es que en esos pines suele estar la BCAN, que generalmente va a menos velocidad (sobre 50, 62.5, 125 kbps). Aquí va la información de confort y otras básicas.
Después el coche tiene otro bus más rápido, (a 250 o 500kbps), pero no suele ir en el conector de diagnosis de un modo fácil de leer. Es el bus principal de motor, ABS, y no se conoce lo que cada fabricante usa para numerar sus centralitas, o el tipo de infromación que se envían entre ellas.

Siempre hay que acceder a traves de los pines 6 y 14. Y enviando una serie de comandos a la dirección 01 (por ejemplo, es el motor), este nos responde. Aunque en realidad no estamos accediendo al bus can de sistema del motor, sino que estamos comunicando con una centralita auxiliar del habitáculo del coche (donde va la información del marcador del coche, por ejemplo).
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 07 de Febrero de 2009, 21:49:27
teleko, si tengo que sentarme a ver que serian esos datos....

Contestando tu pregunta, si me conecto en los pines 6 y 14 (CANH y CANL) a 500 kbps.

Tengo la esperanza que el auto respete el standard y responda a ciertos PID's soportados.

Sigo probando... y les cuento los avances.

Si tenes algunos consejos para que vaya probando y segun las respuestas hagamos algunos analisis mejor...

Gracias.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Febrero de 2009, 22:25:42
Muy buen avance!! :-/ :-/

Justo me encuentran retomando actividades y despues de armar mi rinconcito electronico, estoy armando mi sistema de pruebas, asi que pronto reaparecere poniendo fotos y pruebas de lo que estoy haciendo... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 08 de Febrero de 2009, 09:19:45
Es raro que tenga el can de alta velocidad en el conector de diagnosis. Por ejemplo en el fiat Stilo, viene sólo a 50kbit en el conector, y e de alta velocidad va a 500kbps. En esta página (en inglés) prueban a conectarlo desde la bomba eléctrica de dirección. Stilo can (http://www.fiatforum.com/stilo/174029-stilo-can-bus-question.html)

Hay un esquema que explica lo que yo digo sobre los 2 buses a diferente velocidad.
(http://www.fiatforum.com/attachment.php?attachmentid=55500&d=1230330322)

Aquí tienes el standar de comunicación con el coche: Sae OBD (http://www.4shared.com/file/74089156/77de9073/SAE_OBDII_j1979_200204.html) a partir de la página 63.

Aunque también es recomendable mirar las instrucciones del ELM, viene un ejemplo de comunicación sencilla.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 12 de Febrero de 2009, 14:17:35
Me falta el ISO 15765, lo ando buscando y no lo encuentro por ningún sitio (sólo pagando y muchos $$$).

Aunque buscando y rebuscando he encontrado esto:

Citar
> The PID for MAP is 0B, MAF is $10, intake temp is $0F, RPM is 0C and
> vehicle speed is $0D.
>
> If you send this into a CAN vehicle with OBDII: You use Srvice 01 for this
> request:
>
> 7DF 02 01 0C I think you will get the RPM returned.
>
> It will look like this:
>
> 7E8 04 41 00 xx yy where xx yy is the RPM 1/4 RPM per bit.
>
> 1st line - 7DF - CAN ID - to all OBDII modules. 02 - 2 bytes of data
> following, 01 - service 1, 0C - get RPM
> 2nd line - 7E8 - a OBDII module responding (its adrress is 7E8 - 8 = 7E0),
> 04 - 4 data bytes following, 41 - service 01+40, 00 - RPM, xx yy the two
> byte data.
>
> I think this is correct - if you get no response, msend 8 data bytes with
> rest of frame with $FF in the unused data bytes.
>

Así que puedes probar, envía una trama con el ID 7DF, longitud 2, datos: 01 0C (hex). A ver que te responde el auto.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 16 de Febrero de 2009, 23:08:15
teleko, ahi hice la prueba, te adjunto los resultados.

Sigo sin enteder mucho... cualquier ayuda es bienvenida.

Hice varias pruebas, cambiando los datos de la funcion can_putd(). [ can_putd(tx_id, out_data, tx_len,tx_pri,tx_ext,tx_rtr); ]
tx_id esta definido como entero [ int32 rx_id; ] aqui es donde debo setear el ID que me comentaste ? , pasado a decimal ?
de esta forma: "int32 tx_id=2024;"

La respuesta obtenida es con esa configuracion y cambiando la logitud TX a 2 y en los datos simplemente poniendo 01 0C


En la prueba antes realizada con un numero aleatoreo en tx_id (2000) y armando la trama de datos de la siguiente forma: "DATA = 07 DF 02 01 0C 00 00 00"
Las respuestas obtenidas son muy parecidas a las posteadas en el anterior mensaje.


Saludos. gracias por la ayuda !!!

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Febrero de 2009, 23:12:46
Cuidado como escribes el Id, si usas 2000 solamente esta en decimal, si es interpretado en hexadecimal por la funcion can_putd() estaras escribiendo como si fuera ID 7D0.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 17 de Febrero de 2009, 12:38:58
lo que yo he hecho es poner:

Código: [Seleccionar]
#define tx_id 0x7DF

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 17 de Febrero de 2009, 15:07:30
Si, vi que asi lo habias puesto, solo era advertirles del error, que dicho sea de paso es comun cometerlo... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 18 de Febrero de 2009, 07:56:34
Arameo, viendo las tramas que has recibido, si te fijas en todas vienen con el flag INV en 1. Eso quiere decir que te las están marcando como inválidas.

Si te fijas en la libreria can, viene en el can_getd:

Código: [Seleccionar]
stat.inv=CAN_INT_IRXIF;

Y en el datasheet del 2580, por ejemplo, viene que el Registro PIR3, que el bit IRXIF es:

Código: [Seleccionar]
IRXIF: CAN Invalid Received Message Interrupt Flag bit
1 = An invalid message has occurred on the CAN bus
0 = No invalid message on CAN bus

Así que algo raro está ocurriendo en el bus.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 20 de Febrero de 2009, 12:41:53
Acabo de encontrar una información muy interesante, un extracto del iso 15765-2 iso (http://i3.tucuxi.org/automotive/iso15765-2)

Se define que se deben enviar tramas de 8 bytes de largo (campo de datos). Pero se usa un campo PCI (Protocol Control Information), en donde se marca si la trama es simple o extendida y la longitud de los datos. O sea, la trama CAN siempre es de lonitud 8, y el primer campo (o más si es una multitrama) es un flag que nos marca si la trama es extendida o simple, y la longitud de los datos enviados.

Tipos de tramas:
PDU Type                         PCI Type                   byte
Single Frame                      (SF)                            0
First Frame                         (FF)                           1
Consecutive Frame             (CF)                            2
Flow Control                       (FC)                            3

Para enviar una trama con menos de 7 bytes de datos, se usa el flag SF, o sea, el primer Byte del campo de datos es 0x, donde x es la longitud del campo de datos.

Por ejemplo, queremos pedir a la centralita el valor de las revoluciones del motor, en este caso la petición sería 01 0C, al construir la trama, habría que poner:

ID= 7E0, lenght= 8, data= 02 01 0C 00 00 00 00 00

Y la respuesta será de la forma:

ID= 7E8, length= 8, data= 04 41 0C xx yy 00 00 00

donde xx yy es el valor de las revoluciones del motor en hexadecimal, el valor entero es:

RPM = ((xx*256) + yy)/4
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 21 de Febrero de 2009, 13:27:49
teleko, muchas gracias por la info. Ahi puli bien la trama a enviar. Pero algo raro sucede

1) Al analizar lo recibido, me di cuenta que solamente realiza el can_putd() , 3 veces por corrida [una por cada buffer de TX], investigando en el foro de CSS alguien comento que eso era un comportamiento debido al error de velocidad. Entonces tuve que buscar bien lo del baud rate y configurarlo adecuadamente.

Segun entiendo, actualmente me estoy comunicando a 250 kbps , con la siguiente configuracion:

//250 Kbps - Cristal 20 Mhz - guiandome en la formula:
//baud rate generator prescalar (def: 4) ( Tq = (2 x (PRE + 1))/Fosc )
//Que si el PRE es 1, da 0.2us (500 kbps), PERO leyendo y analizando el programa de Microchip bit timing, al yo utilizar un Cristal de 20 Mhz, este PRE se encuentra multiplicado por 2
//Ademas de restarle a todos los valores una unidad


Código: [Seleccionar]

    BRGCON1.brp=1;                     //prescaler
    BRGCON1.sjw=0;                    //SYNCH_JUMP 0+1
    BRGCON2.prseg=2;                 //propagation 2+1
    BRGCON2.seg1ph=7;              //7+1
    BRGCON2.sam=FALSE;
    BRGCON2.seg2phts=FALSE; 
    BRGCON3.seg2ph=7;             //7+1
    BRGCON3.wakfil=TRUE;


Con esta configuracion logre que el buffer 0 de TX se "vacie" y realice un PUT cada 2 seg. constantemente.

2) Mi segundo problema es el "vacie" antes puesto entre comillas... :-p
Tengo puesto unos LED's tanto en TX y RX del Serie del PIC y en TX y RX del CAN del PIC
EL led de TX del PIC NUNCA prende (ya lo teste y funciona bien)

Asi que imagino que tengo cierto problema con la funcion can_putd() , estoy investigando sobre ello.

La buena noticia es que con la configuracion de baud_rate antes mencionada recibo la siguiente trama una sola vez al principio:

Código: [Seleccionar]

CAN_GETD(): BUFF=0 ID=000007E8 LEN=8 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 03 7F 01 11 AA AA AA AA


Es la primera vez que recibo una trama con ID 7E8, asi que eso me pone contento y pilas para seguir. Tambien tengo que descifrar el significado de la misma.

Bueno, cualquier otra novedad se las comentare a la brevedad.
Agradezco nuevamente por la ayuda brindada.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 21 de Febrero de 2009, 14:02:32
Yo también tuve problemas a la hora de configurar el ccs para la velocidad del bus. me di cuenta que los valores de la librería no son enteros, si no hexadecimales. Mira los registros de configuración del 2580 para ver lo que es cada bit y así configurarlo.

Hay otro programa para configurar los bits, después te paso el enlace, que lo tengo en otro pc.

La respuesta recibida, es de 7E8, o sea, es una respuesta al identificador 7E0. Y el campo datos es de 8 bytes (era de esperar). Si desglosamos la respuesta tenemos:
03 = PCI, son 3 bytes de información.
7F 01 11. Si revisas la norma SAE que yo puse, 7F es una respuesta negativa.

TABLE 9—NEGATIVE RESPONSE MESSAGE FORMAT FOR ISO 14230-4, ISO 15765-4
Data Byte     Parameter Name                                                 Cvt                 Hex Value                 Mnemonic
     #1         Negative Response Service Identifier                       M                           7F                      SIDNR
     #2         Request Service Identifier                                       M                           xx                      SIDRQ
     #3         ResponseCode                                                       M                           xx                        RC_

En este caso, te ha puesto una respuesta negativa al codigo de servicio pedido 01, resultado 11: servicio no soportado.

¿Que has puesto en el mensaje enviado?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 21 de Febrero de 2009, 14:18:53
Supuestamente envie:

CAN_PUTD(): BUFF=0 ID=000007E0 LEN=8 PRI=3 EXT=0 RTR=0
  DATA = 02 01 0C 00 00 00 00 00

Pongo supuestamente por lo antes comentado.

Una duda, esta configuracion del PORTB, esta bien ?
/****

set_tris_b((*0xF93 & 0xFB ) | 0x08);   //b3 is out, b2 is in

*****/

Es realizada en can_init()
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Febrero de 2009, 16:14:12
Arameo.
Te pongo una imagen del resultado del calculo de seteos del BUS CAN a 250 Kbps y 20 MHz de cristal.
Yo normalmente copio los valores directamente a los tres registros BRGCON1, 2 y 3.
Para eso comento todos los seteos de los bits individuales.

(http://img13.imageshack.us/img13/4263/reportecanbusarameopgin.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 22 de Febrero de 2009, 09:33:21
Aquí está disponible el otro programa que yo decia para configurar los registros del Can:

artic can bit time calculator (http://www.articconsultants.co.uk/downloads.htm)

Para mi es más intuitivo que el otro programa.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 23 de Febrero de 2009, 08:15:54

...

2) Mi segundo problema es el "vacie" antes puesto entre comillas... :-p
Tengo puesto unos LED's tanto en TX y RX del Serie del PIC y en TX y RX del CAN del PIC
EL led de TX del PIC NUNCA prende (ya lo teste y funciona bien)

Asi que imagino que tengo cierto problema con la funcion can_putd() , estoy investigando sobre ello.

La buena noticia es que con la configuracion de baud_rate antes mencionada recibo la siguiente trama una sola vez al principio:

Código: [Seleccionar]

CAN_GETD(): BUFF=0 ID=000007E8 LEN=8 OVF=0 FILT=0 RTR=0 EXT=0 INV=1
    DATA = 03 7F 01 11 AA AA AA AA


Es la primera vez que recibo una trama con ID 7E8, asi que eso me pone contento y pilas para seguir. Tambien tengo que descifrar el significado de la misma.

Bueno, cualquier otra novedad se las comentare a la brevedad.
Agradezco nuevamente por la ayuda brindada.

Una pregunta, ¿estaba el motor funcionando en esta petición?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 23 de Febrero de 2009, 18:26:26
teleko, ahi realice varias pruebas y lamentablemente en todos los casos recibo la misma respuesta: 03 7F xx 11 AA AA AA AA

variando XX en:

01, 03, 07, 17

Probe varios tipos de trama, con el auto en contacto, en marcha, etc.
Espero el error este en algun otro lugar. Algo se me esta escapando....

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 24 de Febrero de 2009, 22:05:19
Mas pruebas.... y lamentablemente la misma respuesta.

Probe: 07 01 00 20 40 60 80 A0
al Id: 7DF

y no obtuve respuesta.

realice envio a distintos  ID's 7E2 , 7E6 , 7E7 preguntando por pids soportados y tampoco.

Veo que la trama que me responde 7E8 posee un 1 en INV.
Mas en detalle eso que quiere decir ?

Algun consejo ?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: zagoaristides en 01 de Marzo de 2009, 22:05:39
Hola gente, bueno, terrible post!!! Recién luego de 3 días (entrecortados) leyendo termino con esto. Bueno les cuento que mi proyecto està parado hace tiempo por la selección del método de comunicación.

Básicamente son sensores dispuestos en un brazo robótico para ver su posición espacial (3D). Primero pensé en SMACK pero se me fue complicando el tema velocidad y CRC y demás, luego el I2C tampoco servía por no estar orientado a grandes distancias, luego RS485 pero no me gustaba por el tema de los cables y de nuevo el CRC que nunca entendí bien. Ahora luego de leer todo el hilo creo que este protocolo puede servirme a mis propósitos. Siempre hice proyectos interesantes pero la parte comunicación se la dejaba a otra persona y ahora decidí aprender y me cuesta bastante.

Me gustaría si alguno de los que entienden más que yo (el 90%) de los del hilo puedan resumirme en una respuesta o cita que necesito para practicar seriamente con CanBus.

Puede ser la placa de entrenamiento de CCS? Puede ser otra placa o placas? Las que hicieron algunos de los de aquí, cuál/es? Podrían si es así poner los esquemáticos y los negativos para hacer las placas.

Luego para debbugear, como proceden? Leí sobre los sniffers pero al parecer ninguno está completamente funcional, al menos los seriales.

Sería una especie de resumen para alguien que desea empezar a practicar. No importan que chips hagan falta, los compraré o de ser una placa X también estoy dispuesto a hacerlo.

Muchísimas gracias y espero que sus proyectos sigan adelante.


Aristides - Campana, Bs. As.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Marzo de 2009, 22:14:36
Hola gente, bueno, terrible post!!! Recién luego de 3 días (entrecortados) leyendo termino con esto. Bueno les cuento que mi proyecto està parado hace tiempo por la selección del método de comunicación.

Básicamente son sensores dispuestos en un brazo robótico para ver su posición espacial (3D). Primero pensé en SMACK pero se me fue complicando el tema velocidad y CRC y demás, luego el I2C tampoco servía por no estar orientado a grandes distancias, luego RS485 pero no me gustaba por el tema de los cables y de nuevo el CRC que nunca entendí bien. Ahora luego de leer todo el hilo creo que este protocolo puede servirme a mis propósitos. Siempre hice proyectos interesantes pero la parte comunicación se la dejaba a otra persona y ahora decidí aprender y me cuesta bastante.

Me gustaría si alguno de los que entienden más que yo (el 90%) de los del hilo puedan resumirme en una respuesta o cita que necesito para practicar seriamente con CanBus.

Puede ser la placa de entrenamiento de CCS? Puede ser otra placa o placas? Las que hicieron algunos de los de aquí, cuál/es? Podrían si es así poner los esquemáticos y los negativos para hacer las placas.

Luego para debbugear, como proceden? Leí sobre los sniffers pero al parecer ninguno está completamente funcional, al menos los seriales.

Sería una especie de resumen para alguien que desea empezar a practicar. No importan que chips hagan falta, los compraré o de ser una placa X también estoy dispuesto a hacerlo.

Muchísimas gracias y espero que sus proyectos sigan adelante.


Aristides - Campana, Bs. As.

Creo que lo mejor que podrias hacer es armarte o comprarte una placa como la de CCS o de MikroC.
De la de CCS puedo pasarte los esquematicos.

Mi placa la hice siguiendo en parte la de CCS, mezclada con algunas de Microchip.

De microchip esta interesante la placa que puse unos post antes, tiene buen precio y conecta por USB, tienes una placa para hacer debug y otra para aplicaciones.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: zagoaristides en 03 de Marzo de 2009, 03:42:51
Hola gente, bueno, terrible post!!! Recién luego de 3 días (entrecortados) leyendo termino con esto. Bueno les cuento que mi proyecto està parado hace tiempo por la selección del método de comunicación.

Básicamente son sensores dispuestos en un brazo robótico para ver su posición espacial (3D). Primero pensé en SMACK pero se me fue complicando el tema velocidad y CRC y demás, luego el I2C tampoco servía por no estar orientado a grandes distancias, luego RS485 pero no me gustaba por el tema de los cables y de nuevo el CRC que nunca entendí bien. Ahora luego de leer todo el hilo creo que este protocolo puede servirme a mis propósitos. Siempre hice proyectos interesantes pero la parte comunicación se la dejaba a otra persona y ahora decidí aprender y me cuesta bastante.

Me gustaría si alguno de los que entienden más que yo (el 90%) de los del hilo puedan resumirme en una respuesta o cita que necesito para practicar seriamente con CanBus.

Puede ser la placa de entrenamiento de CCS? Puede ser otra placa o placas? Las que hicieron algunos de los de aquí, cuál/es? Podrían si es así poner los esquemáticos y los negativos para hacer las placas.

Luego para debbugear, como proceden? Leí sobre los sniffers pero al parecer ninguno está completamente funcional, al menos los seriales.

Sería una especie de resumen para alguien que desea empezar a practicar. No importan que chips hagan falta, los compraré o de ser una placa X también estoy dispuesto a hacerlo.

Muchísimas gracias y espero que sus proyectos sigan adelante.


Aristides - Campana, Bs. As.

Creo que lo mejor que podrias hacer es armarte o comprarte una placa como la de CCS o de MikroC.
De la de CCS puedo pasarte los esquematicos.

Mi placa la hice siguiendo en parte la de CCS, mezclada con algunas de Microchip.

De microchip esta interesante la placa que puse unos post antes, tiene buen precio y conecta por USB, tienes una placa para hacer debug y otra para aplicaciones.

Me pasarías los esquemáticos de las que creas me sirvan? zagoaristides algarroba hot...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Marzo de 2009, 09:48:30
En este link puedes bajarte el manual de la placa de CCS y su libro de ejemplos.

Placa CCS (http://www.ccsinfo.com/pdfs/Development_Kit_for_the_CANBus_Exercise_Book.pdf)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 07 de Marzo de 2009, 21:19:16
Gente, a modo informativo por si alguien esta leyendo el foro con propositos de conectarse al bus CAN de algun auto, les comento que en la mayoria de los autos que circulan por la calle no se encuentra implementado.
Los scanners y demas, utilizan el protocolo KWP (Linea k-L) para sacar la info. (en los conectores OBD-II, figuran ambos pines CAN y KWP, supongo por su imp. a futuro)

Recien algunos autos FABRICADOS en el 2006 en adelante cuenta con dicho protocolo implementado. (Honda, Subaru, algunos Ford americanos, entre otros)
La interfaz antes realizada en teoria funciona y va a quedar como un desarrollo para poder ser testeada en coches q lo implementen.

Actualmente voy a desarrollar el protocolo KWP con el PIC para poder comunicarme y adaptarlo a la plaqueta.

Por si alguien quiere seguir este tema, estoy posteando aqui:
http://www.gncusers.com.ar/phpBB2/viewtopic.php?f=8&t=7156&sid=b6900c83269b4caba3ca5e92e540575b&start=640

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Marzo de 2009, 22:12:25
Quien eres en ese foro??
Lo del ELM, sabes donde se consigue??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 08 de Marzo de 2009, 00:19:02
Quien eres en ese foro??

este... entiendo por esa pregunta, con que nick estoy, pues con el mismo que aca, arameo

Lo del ELM, sabes donde se consigue??
aca en Argentina nose, existe la pagina oficial de ELM - > http://www.elmelectronics.com/
Donde creeria que tienen envio a todo el mundo, pagando con tarjeta de credito.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 08 de Marzo de 2009, 09:32:40
Quien eres en ese foro??
Lo del ELM, sabes donde se consigue??

El ELM se puede comprar en esta página: ELM (http://www.elmelectronics.com/)

Hay varios modelos de interfaz, el más conocido es el ELM327, ya que abarca todos los protocolos: CAN (ISO15765) y CAN (SAE J1939), KWP (ISO14230), ISO9141, SAE J1850, PWM y VPW. Y además le puedes programar el CAN a diferentes velocidades (por si quieres leer en otros CAN que traen los coches).

Sale por unos 35$ sólo el chip, aunque si lo buscas por ebay, también venden cables OBD con el elm ya integrado, y un FTDI para conexión USB (aunque sean copias chinas también funcionan).

A mi me han dejado un interfaz ELM ya montado en una caja, y para conectarte con el pc, en lugar de cable serie usa bluetooth. A la hora de usarlo es igual, se hace una conexión serie por bluetooth y luego ya funciona igual que si estuviera por cable.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: hech en 12 de Marzo de 2009, 23:49:03
Hola a todos, este mi primer aporte en el tema del Bus-Can, bueno les cuento, me compre una interface can usb http://www.canusb.com/index.htm, muy buena por cierto te dan un programa para ver los datos y algunos ejemplos con labview y otros, lo probe en un vehiculo y me leyo todos los datos, con esos datos me dispuse a armar mi propia interface usando el dspic 30f4011 con el mcp2551 y cristal de 20Mhz, lo programe con el mikrobasic para dspic, y bueno despues de tanto lidiar logre configurar para enviar y recibir mensajes 500Kbps, y aqui viene mi problema cuando conecto el dspic con la interface usb me envia y recibe bien los datos, pero cuando lo conecto con el vehiculo, este se resetea, si solo programo el dspic para enviar no hay  problema, pero si lo configuro asi sea solo para recibir se me resetea, nose porque si alguien me puede ayudar, les adjunto el programa del dspic. gracias

Código: FreeBasic
  1. program TX_RX_CAN_500Kbs
  2. include "logo"
  3. dim Can_Init_Flags, Can_Send_Flags, Can_Rcv_Flags, MSG_RCVD, RX_DATA_LEN, X as word
  4.     Tx_Data  as byte[8]
  5.     Rx_Data  as byte[8]
  6.     txt as string[3]
  7.     Rx_ID, Tx_ID as longint
  8.  
  9. main:
  10.   ADPCFG = $FFFF
  11.   Can_Init_Flags   = 0
  12.   Can_Send_Flags   = 0
  13.   Can_Rcv_Flags    = 0
  14.  
  15.   Can_Send_Flags   = CAN_TX_PRIORITY_1 and           ' SE UTILIZA PARA
  16.                      CAN_TX_STD_FRAME and            '  CANSendMessage
  17.                      CAN_TX_RTR_FRAME
  18.  
  19.   Can_Init_Flags   = CAN_CONFIG_SAMPLE_THRICE and    ' SE ULILIZA PARA
  20.                      CAN_CONFIG_PHSEG2_PRG_ON and    '  CANInitialize
  21.                      CAN_CONFIG_XTD_MSG and
  22.                      CAN_CONFIG_DBL_BUFFER_ON and
  23.                      CAN_CONFIG_ALL_VALID_MSG  and
  24.                      CAN_CONFIG_LINE_FILTER_OFF
  25.  
  26.   CAN1Initialize(1,2,4,4,1,Can_Init_Flags)           ' configurado a 500kbs con oscilador
  27.                                                       'de 20 MHz
  28.   CAN1SetOperationMode(CAN_MODE_NORMAL, 0x00)         ' set CONFIGURATION mode
  29.  
  30.  
  31.   CAN1SetMask(CAN_MASK_B1, -1, CAN_CONFIG_MATCH_MSG_TYPE and CAN_CONFIG_STD_MSG)   ' set all mask1 bits to ones
  32.   CAN1SetMask(CAN_MASK_B2, -1, CAN_CONFIG_MATCH_MSG_TYPE and CAN_CONFIG_STD_MSG)   ' set all mask2 bits to ones
  33.   CAN1SetFilter(CAN_FILTER_B1_F1, 5,CAN_CONFIG_STD_MSG) ' set id of filter B2_F3 to 3
  34.   CAN1SetOperationMode(CAN_MODE_NORMAL, 0x00)           ' modo Normal ENVIA Y RECIBE
  35.  
  36. ' -----------------configuracion del glcd 128x64
  37.   Glcd_Init(PORTC,13,PORTC,14,PORTE,8,PORTD,1,PORTB,8,PORTD,3,PORTB) 'conf d puertos
  38.   delay_ms(2000)
  39.  
  40.     Glcd_Fill(0x00)  ' Limpiar pantalla
  41.     Glcd_Image(LOGOTIPO_bmp)         'dibujar imagen
  42.     Delay_MS(5000)
  43.     Uart2_Init(9600)                   'INICIALIZAMOS RS232
  44.     Glcd_Fill(0x00)  ' Limpiar pantalla
  45. MOSTAR:
  46.   while TRUE
  47.     Tx_ID=$100
  48.     Tx_Data[0] = $EC
  49.     Tx_Data[1] = $04
  50.     Tx_Data[2] = $00
  51.     Tx_Data[3] = $00
  52.     Tx_Data[4] = $00
  53.     Tx_Data[5] = $A9
  54.     Tx_Data[6] = $0B
  55.     Tx_Data[7] = $6a
  56.     CAN1Write(Tx_ID, Tx_Data, 8, Can_Send_Flags)   ' envio los datos
  57.     Tx_ID=$500
  58.     Tx_Data[0] = $5E
  59.     Tx_Data[1] = $00
  60.     Tx_Data[2] = $F8
  61.     Tx_Data[3] = $02
  62.     Tx_Data[4] = $D2
  63.     Tx_Data[5] = $02
  64.     Tx_Data[6] = $26
  65.     Tx_Data[7] = $02
  66.     CAN1Write(Tx_ID, Tx_Data, 8, Can_Send_Flags)   ' envio los datos
  67.     FOR X=0 TO 100
  68.     DELAY_MS(1)           'PAUSA ENTRE ENVIO RECEPCION
  69.     NEXT X
  70.    
  71.     Msg_Rcvd = CAN1Read(Rx_ID , Rx_Data , Rx_Data_Len, Can_Rcv_Flags)
  72.  
  73.     IF Rx_ID=$112 THEN
  74.     Uart2_Write_TEXT ("112")
  75.     Glcd_Set_Font(@System3x6, 3, 6, 32)
  76.     Glcd_Write_TEXT("RX_ID=112   DLC=", 3, 0, 2)
  77.     ByteToStr(Rx_Data_LEN, txt)
  78.     Glcd_Write_TEXT(TXT, 63, 0, 2)
  79.     ByteToStr(Rx_Data[0], txt)
  80.     Glcd_Write_TEXT(TXT, 3, 1, 0)
  81.     ByteToStr(Rx_Data[1], txt)
  82.     Glcd_Write_TEXT(TXT, 18, 1, 0)
  83.     ByteToStr(Rx_Data[2], txt)
  84.     Glcd_Write_TEXT(TXT, 33, 1, 0)
  85.     ByteToStr(Rx_Data[3], txt)
  86.     Glcd_Write_TEXT(TXT, 48, 1, 0)
  87.     ByteToStr(Rx_Data[4], txt)
  88.     Glcd_Write_TEXT(TXT, 63, 1, 0)
  89.     ByteToStr(Rx_Data[5], txt)
  90.     Glcd_Write_TEXT(TXT, 78, 1, 0)
  91.     ByteToStr(Rx_Data[6], txt)
  92.     Glcd_Write_TEXT(TXT, 93, 1, 0)
  93.     ByteToStr(Rx_Data[7], txt)
  94.     Glcd_Write_TEXT(TXT, 108, 1, 0)
  95.     END IF
  96.  
  97.     IF Rx_ID=$512 THEN
  98.     Uart2_Write_TEXT ("512")
  99.     Glcd_Set_Font(@System3x6, 3, 6, 32)
  100.     Glcd_Write_TEXT("RX_ID=512   DLC=", 3, 2, 2)
  101.     ByteToStr(Rx_Data_LEN, txt)
  102.     Glcd_Write_TEXT(TXT, 63, 2, 2)
  103.     ByteToStr(Rx_Data[0], txt)
  104.     Glcd_Write_TEXT(TXT, 3, 3, 0)
  105.     ByteToStr(Rx_Data[1], txt)
  106.     Glcd_Write_TEXT(TXT, 18, 3, 0)
  107.     ByteToStr(Rx_Data[2], txt)
  108.     Glcd_Write_TEXT(TXT, 33, 3, 0)
  109.     ByteToStr(Rx_Data[3], txt)
  110.     Glcd_Write_TEXT(TXT, 48, 3, 0)
  111.     ByteToStr(Rx_Data[4], txt)
  112.     Glcd_Write_TEXT(TXT, 63, 3, 0)
  113.     ByteToStr(Rx_Data[5], txt)
  114.     Glcd_Write_TEXT(TXT, 78, 3, 0)
  115.     ByteToStr(Rx_Data[6], txt)
  116.     Glcd_Write_TEXT(TXT, 93, 3, 0)
  117.     ByteToStr(Rx_Data[7], txt)
  118.     Glcd_Write_TEXT(TXT, 108, 3, 0)
  119.     END IF
  120.  
  121.      IF Rx_ID=$712 THEN
  122.     Uart2_Write_TEXT ("700")
  123.     Glcd_Set_Font(@System3x6, 3, 6, 32)
  124.     Glcd_Write_TEXT("RX_ID=700   DLC=", 3, 4, 2)
  125.     ByteToStr(Rx_Data_LEN, txt)
  126.     Glcd_Write_TEXT(TXT, 63, 4, 2)
  127.     ByteToStr(Rx_Data[0], txt)
  128.     Glcd_Write_TEXT(TXT, 3, 5, 0)
  129.     ByteToStr(Rx_Data[1], txt)
  130.     Glcd_Write_TEXT(TXT, 18, 5, 0)
  131.     ByteToStr(Rx_Data[2], txt)
  132.     Glcd_Write_TEXT(TXT, 33, 5, 0)
  133.     ByteToStr(Rx_Data[3], txt)
  134.     Glcd_Write_TEXT(TXT, 48, 5, 0)
  135.     ByteToStr(Rx_Data[4], txt)
  136.     Glcd_Write_TEXT(TXT, 63, 5, 0)
  137.     ByteToStr(Rx_Data[5], txt)
  138.     Glcd_Write_TEXT(TXT, 78, 5, 0)
  139.     ByteToStr(Rx_Data[6], txt)
  140.     Glcd_Write_TEXT(TXT, 93, 5, 0)
  141.     ByteToStr(Rx_Data[7], txt)
  142.     Glcd_Write_TEXT(TXT, 108, 5, 0)
  143.     END IF
  144.   wend
  145. GOTO MOSTRAR
  146. end.

MGL. Perdon por la edicion, pero asi se puede ver tu codigo sin tener el editor...


soy nuievo en este tema y estoy haciendo un proyecto con el mencioado bus can utilizando el dspic304013 y quiesiera saber si algruin tiene algunos ejemplos de esta paluicaion con domotica, ante antes mis felisitaciones MGSOFT por abrir este tema que es un poco escaso la informacion pero bastante empleado e interesante y de antemano agradecer buestras respuestas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 13 de Marzo de 2009, 00:09:11
hech, a que vehiculo te conectaste ?

Estas seguro que tiene implementado el Bus-CAN ? , la interface que adquiriste puede estar leyendo los datos de algun otro protocolo (ISO 9141 , ISO 14230 , etc.)

Te lo pregunto pq tengo armada un interfaz con un PIC 18F258 y un MCP2551 , logre la comunicacion y el auto me responde con tramas de PIDs no soportados.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Mossetto en 13 de Marzo de 2009, 12:49:19
Por favor, podria alguien decirme donde conseguir en Argentina un PIC 18F2455, MCP2515, MCZ33290, me urge contar con ellos para finalizar un proyecto.

Muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 13 de Marzo de 2009, 14:00:21
Generalmente este local los consigue:

http://www.cika.com/contacto/

Yo consegui el 18F258 en la sucursal Mendoza.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Marzo de 2009, 23:09:45
En ELEMON y en MCElectronics podras conseguirlos.
lo del ultimo chip, prueba en Electrocomponentes, que son especialistas de Freescale...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: hech en 15 de Marzo de 2009, 21:28:14
hech, a que vehiculo te conectaste ?

Estas seguro que tiene implementado el Bus-CAN ? , la interface que adquiriste puede estar leyendo los datos de algun otro protocolo (ISO 9141 , ISO 14230 , etc.)

Te lo pregunto pq tengo armada un interfaz con un PIC 18F258 y un MCP2551 , logre la comunicacion y el auto me responde con tramas de PIDs no soportados.

Saludos

si arameo estoy seguro que el dspi304013 tiene el controlador de bus can y tambien tengo el transceiver mp5510 , y lo que pasa es que yo i mi compa de la universidad nos propusimos hacer un proyecto con este bus aplicandola a domotica y utilizamos el dspic por que nos costaba casi igual y con el dspic ademas nos podia servir para mas cosas que un pic 18f..
espero que alguien tenga una pgina o ejemplos cion este dspic304013 que es de proposito general . agradesco su atencion.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 15 de Marzo de 2009, 22:13:22
hech, a que vehiculo te conectaste ?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: hech en 17 de Marzo de 2009, 20:13:43
hech, a que vehiculo te conectaste ?
no te te entiendo arameo?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arameo en 18 de Marzo de 2009, 09:03:48
creia que esto lo habias escrito vos:

Citar
Hola a todos, este mi primer aporte en el tema del Bus-Can, bueno les cuento, me compre una interface can usb http://www.canusb.com/index.htm, muy buena por cierto te dan un programa para ver los datos y algunos ejemplos con labview y otros, lo probe en un vehiculo y me leyo todos los datos, con esos datos me dispuse a armar mi propia interface usando el dspic 30f4011 con el mcp2551 y cristal de 20Mhz, lo programe con el mikrobasic para dspic, y bueno despues de tanto lidiar logre configurar para enviar y recibir mensajes 500Kbps, y aqui viene mi problema cuando conecto el dspic con la interface usb me envia y recibe bien los datos, pero cuando lo conecto con el vehiculo, este se resetea, si solo programo el dspic para enviar no hay  problema, pero si lo configuro asi sea solo para recibir se me resetea, nose porque si alguien me puede ayudar, les adjunto el programa del dspic. gracias

Pero "citaste" lo que habia posteado gustpe ---> Cita de: gustpe en 21 de Enero de 2009, 10:53:12 pm

Perdon, yo me equivoque. Por ese motivo te preguntaba a que vehiculo te habias conectado.

Tratando de ayudarte un poco con TU post

Citar
soy nuievo en este tema y estoy haciendo un proyecto con el mencioado bus can utilizando el dspic304013 y quiesiera saber si algruin tiene algunos ejemplos de esta paluicaion con domotica, ante antes mis felisitaciones MGSOFT por abrir este tema que es un poco escaso la informacion pero bastante empleado e interesante y de antemano agradecer buestras respuestas gracias

Yo estoy trabajando en un proyecto para conectarme con el BUS CAN del vehiculo, utilizando un PIC 18F258 + MCP2551 , del dspic no conozco mucho pero si estas programando en CCS tenes muchas librerias que te ayudan y si necesitas especificaciones del BUS te puedo mandar algunos PDF que tengo.
Mandame tu correo por privado.

Saludos.
Título: Sniffer USB para el BUS CAN
Publicado por: MGLSOFT en 29 de Marzo de 2009, 19:53:04
Aqui va una imagen de la nueva adquisicion para hacer analisis del BUS CAN.

Esta metido en una caja para riel DIN.

La conexion a PC es por USB.

(http://img9.imageshack.us/img9/7767/1004964.jpg)
Aqui esta destapado...


(http://img23.imageshack.us/img23/6154/1004956.jpg)
Y aqui ya con su tapa de acrilico rojo...
Título: Sniffer USB para el BUS CAN
Publicado por: MGLSOFT en 29 de Marzo de 2009, 19:56:35
Aca una imagen del software funcionando en PC...

(http://img14.imageshack.us/img14/2316/1004959.jpg)

Y desde aqui podran ver la actividad en la placa...

Y del software en PC...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: fedex en 31 de Marzo de 2009, 14:35:52
Muy buen trabajo. Les cuento que soy nuevo en en foro y estoy por empezar un proyecto de domotica, así que compartiré mis avances...


Saludos a todos...
Fedex

Título: Re: Mis experiencias con el BUS CAN
Publicado por: fedex en 02 de Abril de 2009, 20:02:00
En el sitio de CCS hay un cuaderno de ejercicios que explica muy bien el tema de los filtros... muy bueno para tenerlo a mano...


http://www.ccsinfo.com/pdfs/Development_Kit_for_the_CANBus_Exercise_Book.pdf


Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Abril de 2009, 23:39:25
Puedes contarnos un poco mas acerca de tu idea de como funcionara tu proyecto de Domotica??

Estaba por reprenderte por el enlace, pero veo que es de la pagina oficial de CCS, por lo tanto no viola ninguna regla del foro... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: fedex en 03 de Abril de 2009, 22:02:47
Si, son los libros de ejercicios de CCS, si ponen solo http://www.ccsinfo.com/pdfs les aparece todos los que tienen... y el de CAN me pareció que esta bueno por el tema que explican bien los distintos modos y los filtros...

Bueno yo empece a hacer un proyecto de domótica usando RS-485 y SNAP (http://www.hth.com/snap/) y pude desde una pequeña aplicación en C# mandar tramas SNAP vía serie con CRC y capturarlas con un 16F628 y prender y apagar una luz. El tema es que luego vi esto de CAN y me pareció mucho más fácil de implementar, así que buscando info encontré este foro y ya pedí unas muestras para empezar a programar. Así que ni bien me lleguen compartiré mis experiencias....

Mi idea es hacer nodos que controlen las luces, un nodo que se conecte a la alarma y ya que la alarma tiene un conector serial poder capturar los eventos de la alarma para saber el estado. Me interesaria que el nodo de la alarma transmita por CAN cuando se activa y desactiva, de modo que la casa sepa si estoy en casa o no....

Bueno les mando saludos y ni bien empiece a hacer pruebas las compartire con ustedes...

Saludos




Título: Re: Mis experiencias con el BUS CAN
Publicado por: zagoaristides en 09 de Abril de 2009, 16:15:20
Bueno gente, me compré luego de valorar opciones la placa de ccs para CAN BUS junto con el programador MatchX que ofrecen. Apenas lo tenga les comento que onda. Por ahora estoy renegando con RS485 que me está sacando canas de todos colores con el PIC 18F2553. Abrazo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Abril de 2009, 00:36:21
Creo que has hecho una excelente eleccion.
Comentanos tus avances... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: uc20979 en 18 de Mayo de 2009, 09:07:21
hola

soy nuevo en esto d e los dspic y ando programando el dspic 33F.
Os explico:quiero enviar datos (que cojo de la usart2) y quiero enviarlos a través del analizador LIN BUS de microchip al Pc mediante un programa que traé el mismo y no se como programar el bus lin para tx y rx datos

alguien me puede ayudar por favor??

gracias.un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Mayo de 2009, 09:17:51
El bus LIN no es serial??
Creo que usas la USART del PIC para hacerlo, y un integrado adaptador al bus similar al 2551 que se usa en CAN, es asi??
Estas preguntas son para ponerme en tema, solo lei un poco de ese bus.. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: uc20979 en 19 de Mayo de 2009, 08:15:11
hola MGLSOFT

efectivamente uso la usart2 para coger los datos que recogo a traves del rs232 (al pulsar una tecla del teclado), y quiero pasarselos al bus lin y para ello uso la tarjeta explorer de microchip que tiene el dspic 33fj256gp710 y como integrado para el bus lin , el MCP 2021.

Tengo el serial analyzer de microchip que ya trae un software para recibir y enviar datos pero de momento todavía no consigo recibir datos por el bus lin.

La pregunta es como se programa el bus lin para tx ó rx datos??


un saludo y muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Mayo de 2009, 11:16:21
Podras poner la referencia de Microchip de ese modulo que tienes??
Creo que si no dispones de dos port seriales, no funciona, ya que el LIN usa la Usart del micro para comunicar, por lo tanto ya no podras usarla como serial.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: uc20979 en 20 de Mayo de 2009, 07:01:20
gracias mglsoft

no entiendo lo de la referencia ???

te digo lo que tengo:un tarjeta didáctica de microchip (se llama explorer 16) que tiene incorporado el dspic 33fj256gp710 que tiene dos usart(creo que es eso lo que quieres saber, usart1 y usart2),utilizo el MCP 2021 y el analyzer de microchip que tambien tiene integrado el MCP 2021 (este analizador viene con un software  para enviar y recibir).

Te envío fotos para que  te ayuden un poco más:

Como te decía, no se como programar el bus lin.Independientemente de todo vos sabeís como programarlo en C con el mplab?? es decir si se hace a través de la usart como tengo que hacerlo protocolo ...

muchas gracias

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Mayo de 2009, 16:27:11
En que lenguaje programas??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: uc20979 en 21 de Mayo de 2009, 08:04:30
en lenguaje C

si tienes algún ejemplo y me lo puedes pasar te lo agradecería

un saludo,gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Mayo de 2009, 10:20:53
Te paso los que vienen en CCS C.
Si es otro lenguaje C el que usas es probable lo puedas adaptar sin mayores cambios.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: uc20979 en 23 de Mayo de 2009, 08:26:51
gracias por todo mglsoft

lo hecho un vistazo y ya te cuento vale??


muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: zagoaristides en 29 de Mayo de 2009, 22:19:53
Bueno gente, me compré luego de valorar opciones la placa de ccs para CAN BUS junto con el programador MatchX que ofrecen. Apenas lo tenga les comento que onda. Por ahora estoy renegando con RS485 que me está sacando canas de todos colores con el PIC 18F2553. Abrazo

Me auto-respondo.
El lunes o martes tengo el kit de desarrollo CAN de CCS y su grabador Match X en casa. Ya están en Capital, me los trajo una amiga de una amiga, que también labura en Tenaris.

Después les cuento que onda con esto.

Abrazo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Mayo de 2009, 08:02:28
En Capital??
Crei que eras de alli, de donde sos Zagoaristiades?? :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: zagoaristides en 08 de Junio de 2009, 09:50:01
Si, son los libros de ejercicios de CCS, si ponen solo http://www.ccsinfo.com/pdfs les aparece todos los que tienen... y el de CAN me pareció que esta bueno por el tema que explican bien los distintos modos y los filtros...

Bueno yo empece a hacer un proyecto de domótica usando RS-485 y SNAP (http://www.hth.com/snap/) y pude desde una pequeña aplicación en C# mandar tramas SNAP vía serie con CRC y capturarlas con un 16F628 y prender y apagar una luz. El tema es que luego vi esto de CAN y me pareció mucho más fácil de implementar, así que buscando info encontré este foro y ya pedí unas muestras para empezar a programar. Así que ni bien me lleguen compartiré mis experiencias....

Mi idea es hacer nodos que controlen las luces, un nodo que se conecte a la alarma y ya que la alarma tiene un conector serial poder capturar los eventos de la alarma para saber el estado. Me interesaria que el nodo de la alarma transmita por CAN cuando se activa y desactiva, de modo que la casa sepa si estoy en casa o no....

Bueno les mando saludos y ni bien empiece a hacer pruebas las compartire con ustedes...

Saludos


Hola, qué librería RS485 usaste? Me la pasarías. Gracias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: zagoaristides en 08 de Junio de 2009, 09:54:25
En este link puedes bajarte el manual de la placa de CCS y su libro de ejemplos.

Placa CCS (http://www.ccsinfo.com/pdfs/Development_Kit_for_the_CANBus_Exercise_Book.pdf)

La sacaron ya los mostros! Seguro leyeron este post y se asustaron  8)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Junio de 2009, 08:58:04
Lastima que los sacaron.
Puedo venderselos si los precisan... :mrgreen: :mrgreen: :mrgreen:
Título: Re: Sniffer USB para el BUS CAN
Publicado por: zagoaristides en 03 de Agosto de 2009, 03:11:30
Aca una imagen del software funcionando en PC...


Marcos, te consulto. Como dice adquisición. Compraste este sniffer? De qué firma es? Estoy comenzando con los ejemplos del CanBus con el kit de desarrollo. Otra preg. Para programar los 2505x con el Match X según pispié parece que se puede. Ahora... Tengo que usar esas plantillas de las que hablaste? Las tendrías a mano para subirlas?
Y por último, estaría bueno que hagas al principio del post un listado como índice con links a cada cosa que hay en el hilo, así es fácil para cualquiera leer lo que necesita y no se vuelve a preguntar lo mismo. Yo ya lo leí 2 veces. Algo como un índice general sobre las pruebas, otro punto sobre los sniffers otro sobre los entrenadores, etc.

Un abrazo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Agosto de 2009, 10:57:38
El Sniffer Can que hice yo, con varias modificaciones, esta basado en uno de Microchip, el software que utiliza es de ellos y se puede bajar de su pagina.
En posts anteriores puse el link donde se encuentra esta informacion.

Si, el match programa los 2505x, y las plantillas vienen incluidas en mplab, como cambie de maquina y aqui no lo tengo instalado te debo la explicacion de donde encontrarlas y como usarlas, da para un hilo eso solo, ya que los 2505x son OTP, se programan una sola vez y si pifiaste de una despues es un problema, hay registros que se pueden reprogramar por el bus CAN, pero al perder la tension vuelven a su valor programado original.
Yo pifie en ID de uno y despues no lo podia localizar en la red (no contestaba) y ese registro y los de velocidad de comunicacion no son reprogramables.

Respecto al orden del hilo, es muy buena tu acotacion y voy a implementarla la semana que viene, que ya voy a estar liberado y voy a poder entrar mas al foro.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 25 de Agosto de 2009, 15:59:07
hola

hace tiempo que seguia el hilo y otra vez me lo lei entero, pero no recuerdo si se habia hablado de j1939 y en el buscador no sale nada y como que leermelo entero de una tirada ufff. me toca en el trabajo desarrollar un circuitillo para conectarme al bus can de unos camiones con el protocolo j1939 y habia pensado en un pic para hacerlo (aun tengo pendiente terminar mi desarrollo con pic para crear una red can) y me preguntaba si alguien sabe si con ccs se puede implemenntar este protocolo o es mucho lio. la verdad que tampoco quiero reinventar la rueda basicamente porque a parte de no tener idea, agota que te manden cosas raras ultimamente en el curro, pero habra que apechugar que por la crisis nos toca ahcer de todo jejeje (bueno, casi de todo  :D ). gracias

p.d: cuando recupere tiempo para ponerme con el diseño de la red can con pic, amenazo con mas preguntas jeje

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Agosto de 2009, 18:13:04
Si tienes el protocolo escrito y lo compartes, podremos ayudarte.
Seguramente que un PIC puede correrlo sin problemas.

Buscando en la WEB encontre esto:
http://books.sae.org/book-hs-1939/2009 (http://books.sae.org/book-hs-1939/2009)

Tal vez ayude, pero es pago...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Agosto de 2009, 18:24:54
Rezandole a San Google, encontre esta pagina (http://www.copperhillmedia.com/cannewsletter/j1939references1.html) que me llevo a este (http://ww1.microchip.com/downloads/en/AppNotes/00930a.pdf) documento....
Y  este otro (http://www.vector-group.net/portal/medien/cmc/application_notes/AN-ION-1-3100_Introduction_to_J1939.pdf) documento..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 26 de Agosto de 2009, 13:46:35
hola

si, el appnote de microchip lo encontre hace unos dias pero era para c18 y desconozco si cambia mucho para ccs, pero supongo que tendre que probarlo e ir arreglado hasta que funcione. ¿es mucha la migracion de c18 a ccs? en teoria al ser c deberia ser portable, pero ya me se lo de en teoria... gracias ;)

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Agosto de 2009, 14:28:06
Cual es la aplicacion que debes hacer?? :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 26 de Agosto de 2009, 14:48:15
hola

leer los valores de unos camiones... (no se para que leches quieren esto la verdad, tampoco me han dicho mucho, simplemente que lo haga y me calle...) para temas de velocidad y demas cosas,yo creo que se creen que pueden leer los valores del tacometro o algo.Lo que no se,es si soy capaz de hacer algo,cuando me dejaran un camion para probar si lee la velocidad a la que va y demas...

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Agosto de 2009, 15:05:54
Entonces lo que vas a tener que acceder es a uno o dos registros, por lo tanto no creo que tengas problemas... :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 27 de Agosto de 2009, 02:22:12
hey hola como estan una pregunta necesito mandar una trama de 64 bytes en CAN alguien tiene una idea de como mandar la trama de modo que el  controlador que la recive sepa cual es el primero o segundo hasta el ultimo, si alguien tiene una idea o una seccion de codigo util me ayudan porfa
cuidense
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Agosto de 2009, 08:20:04
Si leíste como funciona CAN, encontraras que cada mensaje puede llevar un máximo de 8 Bytes a transmitir.
Esta pensado para optimizar el uso del Bus.

Sin embargo, los protocolos de mayor nivel, montados sobre CAN, permiten transmitir esa cantidad de bytes con un solo comando.

Si tu aplicación es comercial, te recomiendo estudiar y aplicar CanOpen o DeviceNet, de modo que puedas hacerlo por la vía mas recomendada que dan esos protocolos.

Si lo que quieres hacer es muy customizado, creo que una buena forma es enviarlo en ráfagas de 9 mensajes consecutivos (por el formato del Bus, en algún momento puede entrar un mensaje de otro nodo entre medio), enviando en el primer Byte de cada mensaje el numero de mensaje, para saber donde descargar los datos y cual es su orden y en caso de no recepcionar el orden consecutivo descartar la recepción.
El resto de los bytes sabrás como los ordenas al enviarlos, así que no veo problemas al recepcionarlo.

Si quieres un ejemplo, debería escribirlo y probarlo, ya que no transmito mas de 8 bytes por vez, hasta ahora.
Saludos.

PD: Se puede saber porque debes transmitir tantos bytes??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 28 de Agosto de 2009, 01:10:10
necesito enviar esa cantidad de bytes por que estoy implentando modbus/CAN y la funcion 16 del modbus soporta el envio de 64 bytes por peticion modbus, estoy con ese problema. envio tramas de 8 bytes las que permite el CAN  ago una secuencia de envio de 8 mensajes de de bytes pero el receptor resive los primeros 2 mensajes  y luego sobre escribe los demas, es decir no los revise, ya tengo funcionando el CAN  y tengo el codigo de las funciones modbus implentado pero me falta afinar ese detalle de la transmision secuencial y recepcion secuencial
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Agosto de 2009, 21:55:46
MODBUS sobre CAN ??
Hermosa salsa estas preparando!!! :mrgreen: :mrgreen: :mrgreen:

Sin lugar a dudas Modbus es el protocolo mas usado en el mundo, viejo y persistente, y muy seguro, por eso su supervivencia.
Ha mutado sobre casi todas las redes y medios fisicos conocidos, incluso en Ethernet, como Modbus TCP.
Lo unico que no ha podido hacer es traspasar su condicion de uso como Maestro-Esclavo, ya que aun sobre TCP debe funcionar de esa forma...

El bus CAN es multimaestro y permite mensajeria de cada nodo aun sin solicitud de ningun maestro u otro nodo funcionando como tal...
Porque quieres perder esa particularidad del bus y degradarlo montando Modbus sobre este BUS ???

Alguien te lo ha pedido??
Una exigencia laboral??

Creo que deberias defender un poco mas tu proyecto y ofrecer soluciones mas coherentes y futuristas, como son implementar DeviceNet o CanOpen sobre el Bus Can, ganando en velocidad y potenciando (en vez de perderlas) las particularidades de este bus.
Inclusive en velocidad es difícil ganarle, y como medio físico, probado en el ambiente mas ruidoso del mundo, como es el ambiente interno de los automóviles, para lo cual fue exitosamente desarrollado.

Es mi opinion personal, el Bus sera tuyo y puedes hacer lo que quieras con el. :oops: :oops:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arqui_lester en 29 de Agosto de 2009, 01:41:40
HOLA QUE TAL
la cosa es que es un proyecto de tesis de la universidad, en el momento que se concibio no se tomo en cuenta ese punto, y en estamos en un punto de no retorno y hay que hacer que funcione por eso estamos ocupando el bus CAN, por el momento en mi pais es el primer proyecto desarrollado. por eso no se ocupo devicenet de allen brandy o canopen que son protocolos de mas alto nivel y te dan mas rendimiento.
el sistema es controlado desde una aplicacion web modbus/tcp a diferentes controladores. estos controladores son configurados con la funcion 16 de modbus por lo que necesito enviar hasta 64 bytes de la peticion. esto es lo que me esta dando problemas el envio de esos 64 bytes.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Agosto de 2009, 08:19:48
Lo veo difícil, al dividirlo en 9 mensajes, usando el primer byte de cada uno como  numerador del mensaje, también estas dividiendo el mensaje original Modbus en 9 partes.
Modbus pide confirmación de la recepción del mensaje OK, donde debes enviar la dirección del esclavo que responde y la cantidad de bytes recibidos, junto con la instrucción realizada.

Vas a tener que implementar una rutina en el esclavo que se encargue de rearmar los mensajes, controlar el cheksum (lo estarías haciendo dos veces, ya que CAN tiene su cheksum), y por ultimo respondiendo.
Casi que tu esclavo y tu maestro estarán dedicados a la comunicación, es posible que no te quede tiempo para realizar otras tareas...

No quiero ser aguafiestas, pero lo veo mal.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 09 de Octubre de 2009, 05:59:16
Ya terminé mi proyecto, al final he conseguido comunicarme con el bus CAN del coche. El PIC lee los datos de OBD y muestra los PIDS seleccionados por la pantalla LCD.

Tiene 2 modos de funcionamiento, uno conectado al ordenador por puerto serie, y se le envían comandos para transmitir al vehículo y configurar las opciones. El otro modo, es automático cuando no se le envia nada por el puerto serie, comienza a hacer peticiones de los datos del OBD, según el protocolo ISO 15765 (OBD sobre CAN).

En este video se muestra como funciona la placa del montaje.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 09 de Octubre de 2009, 15:50:50
Ya terminé mi proyecto, al final he conseguido comunicarme con el bus CAN del coche. El PIC lee los datos de OBD y muestra los PIDS seleccionados por la pantalla LCD.

Tiene 2 modos de funcionamiento, uno conectado al ordenador por puerto serie, y se le envían comandos para transmitir al vehículo y configurar las opciones. El otro modo, es automático cuando no se le envia nada por el puerto serie, comienza a hacer peticiones de los datos del OBD, según el protocolo ISO 15765 (OBD sobre CAN).

En este video se muestra como funciona la placa del montaje.



:shocked: plas plas plas !!!

Muy interesante,¿no sabras donde conseguir informacion para hacer algo como esto? algun ejemplo de codigo para pic asi como de otros protocolos,es para saber si puedo leer el kilometraje total y esas cosas.gracias

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Octubre de 2009, 09:36:24
Ya terminé mi proyecto, al final he conseguido comunicarme con el bus CAN del coche. El PIC lee los datos de OBD y muestra los PIDS seleccionados por la pantalla LCD.

Tiene 2 modos de funcionamiento, uno conectado al ordenador por puerto serie, y se le envían comandos para transmitir al vehículo y configurar las opciones. El otro modo, es automático cuando no se le envia nada por el puerto serie, comienza a hacer peticiones de los datos del OBD, según el protocolo ISO 15765 (OBD sobre CAN).

En este video se muestra como funciona la placa del montaje.


Felicitaciones TELEKO !!
Lo has logrado!!

Si quieres despues comentarnos mas sobre tu proyecto, puedes hacerlo aqui, ya que hay seguidores de tu proyecto.
Si abres otro hilo, por favor pon aqui un link asi van directo al hilo tuyo... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 11 de Octubre de 2009, 08:11:26

Felicitaciones TELEKO !!
Lo has logrado!!

Si quieres despues comentarnos mas sobre tu proyecto, puedes hacerlo aqui, ya que hay seguidores de tu proyecto.
Si abres otro hilo, por favor pon aqui un link asi van directo al hilo tuyo... :mrgreen: :mrgreen:


Gracias a vosotros por la ayuda, este foro me ha ayudado mucho.

He basado parte de mi código de librerías que hay publicadas. Como el flex_lcd, o las de can de ccs. La mayoría de lo que es la parte de OBD es mia desde cero, siguiendo la normativa SAE OBDII J1979 y la ISO 15765. Y algunas cosas de la representación de los PIDS por pantalla está basado en este código:

Código: [Seleccionar]
http://code.google.com/p/avrobdii/source/browse/trunk/code/obdii.c
El funcionamiento es sencillo, conectado al puerto serie se puede configurar la placa, desde los parámetros del CAN (velocidad, identificadores,etc...) hasta la configuracion de los PIDS que se desean consultar. También permite enviar tramas OBD directamente al bus, introduciendo por teclado el contenido del campo de datos. Una vez configurado, se almacena todo en la EEPROM, y ya siempre almacena esa configuración. Pudiendo asi desconectarla de alimentación cada vez que se desconecta el cable OBD.

Una vez configurada y conectada al vehículo, lo que realiza es un bucle de una petición contínua de los pids guardados, usando el servicio $01. Hace la petición y muestra por pantalla los datos ya formateados para que se puedan leer bien.

Lo siento, pero no puedo pasar el código completo, ya que el proyecto es de la universidad. Aunque sí puedo resolver las dudas que tengais.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 12 de Octubre de 2009, 10:31:28
Hola muy interezante tu proyecto yo tengo todo lo necesario en casa para empezar con un proyecto similar con mi ford fiesta 2008, de momento seguire tus recomendacion y buscare las normativas que mensionas SAE OBDII J1979 y la ISO 15765.

Lo otro que pienso hacer y tener claro es definir bien la interface a usar en este modelo de carro.

Saludos y estamos en contacto.
atten.
Alexander Santana.
Venezuela-Barcelona
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 12 de Octubre de 2009, 18:41:26
Buenas tardes dandole un poco de color a mi experiencia con el can bus aplicado a mi ford fiesta ya tengo bien definido el pinout de conector obd2 de 16pines que tienes los carros para su comunicacion tambien llamado conector j1962.
OBD 2 CAN pinout
Pin    Signal                   Description
4      CGND                   GND
5      SGND                   GND
6      CAN High              Canal H
14    CAN Low               Canal L
16    +12v                     Battery power

Ahora voy a hacer el esquematico de la interface usando mi placa easypic5 y los modulos can bus.

Saludos y si alguien tiene informacion al respecto bienvenida sea.
Atten.
Alexander Santana.
Venezuela-Barcelona

Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 12 de Octubre de 2009, 22:34:15
por fin termine de leer todos los post de este tema y les dijo que ganas le han puesto mil felicitaciones y espero llegar a su la mitad de su nivel porque seria mucho pedir estar a nivelo de ustedes.

Saludo.
Atten.
Alexander Santana
Venezuela-Barcelona
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 13 de Octubre de 2009, 07:56:25
Aquí pueden descargar la memoria de mi proyecto:

memoria pdf (http://dl.getdropbox.com/u/913254/memoria%20sin%20portada.pdf)


Ahí se explica lo necesario sobre la normativa OBD, aunque no viene nada del código del PIC.

PD: Espero que les sea de ayuda, me ha llevado mucho tiempo hacer este proyecto y su memoria.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 13 de Octubre de 2009, 08:12:06
La verdad es que es una chulada verlo funcionando, pero la memoria es IMPRESIONANTE.

Yo estuve buscando en una ocasión información sobre OBD y no encontré nada que mereciera la pena. Ahora, con tu enciclopedia a mano, va a ser mucho más facil.

Gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Octubre de 2009, 08:18:00
Que suerte Manolo que pudieras ver ese documento, en mi caso es la tercer vez que intento abrirlo y me da error... :oops: :oops: :oops:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: teleko en 13 de Octubre de 2009, 08:33:20
Prueba a darle con el boton derecho del ratón, y pincha en guardar como.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Octubre de 2009, 08:38:04
Ahi fue bien, gracias Teleko!! :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 13 de Octubre de 2009, 15:31:12
hola buenas tardes, yo pude bajar el documento sin problema y en la noche me lo leo con calma y asi me oriento mas para mi proyecto y nuevamente gracias y felicitaciones al colega teleko por su informacion y al amigo MGLSOFT  por hacer  posible este post.

Saludos y estamos en contacto.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: No logro comunicar dos pics mediante Bus CAN
Publicado por: mc_leon en 13 de Octubre de 2009, 23:54:19
Saludos...
Soy nuevo en el foro, por lo que pido paciencia en lo que domino el uso de este foro. Como comenté en el título del post, tengo un extraño problema con el Bus CAN, estoy tratando de realizar una comunicación mediante pics (en este momento solo dos, un nodo y otro como concentrador), por favor, alguien que me ayude, estoy programando en CCS y empleo el PIC 18F2680 y el 18F2480.

Los archivos de cabecera de mi programa son los siguientes:

#include <18F2480.h>
#include <stdlib.h>
#include <math.h>
#fuses HS,NOWDT,NOPROTECT, NOBROWNOUT,NOLVP,NOCPD
#use delay(clock=20M)
#use rs232(baud=19200, xmit=PIN_C6,rcv=PIN_C7)
#define MAX517_SDA PIN_C0 //pin11 pic al pin4 del max517
#define MAX517_CLK PIN_C1 //pin12 pic al pin3 del max517
#use i2c(master, sda=MAX517_SDA, scl=MAX517_CLK, FAST)

#define CAN_DO_DEBUG TRUE
#include <can-18xxx8.c>

// ------------------------- Variables CAN -----------------------------------
int32 rx_id = 5;
int16 buffer[8] = {0, 0, 0, 0, 0, 0, 0, 0};
int rx_len = sizeof(buffer);
struct rx_stat rxstat;
//------------------------------------------------------------------------------


void main (void)
{

while(1)
  {
   setup_adc_ports(ALL_ANALOG|VSS_VDD);
   setup_adc(ADC_CLOCK_INTERNAL);
   can_init();
   enable_interrupts(GLOBAL);

   set_adc_channel(1);
   delay_us(20);
   yk = read_adc();
   buffer[0] = yk;
   can_putd(5, &buffer[0], rx_len, 1, 1, 0);   //
  }
}

para mi concetrador, un PIC18F4680 el codigo es:

#include <18F4680.h>
#include <stdlib.h>
#include <math.h>
#fuses HS,NOWDT,NOPROTECT, NOBROWNOUT,NOLVP,NOCPD
#use delay(clock=20M)
#use rs232(baud=19200, xmit=PIN_C6,rcv=PIN_C7)
#define MAX517_SDA PIN_C0 //pin11 pic al pin4 del max517
#define MAX517_CLK PIN_C1 //pin12 pic al pin3 del max517
#use i2c(master, sda=MAX517_SDA, scl=MAX517_CLK, FAST)

int32 rx_id;
   int16 buffer[8];
   int16 a = 0;
   int rx_len = sizeof(buffer);
   int i;
   struct rx_stat rxstat;

void main (void)
{
printf("CONCENTRADOR 4680_ID5\n\r");

     
   
   enable_interrupts(GLOBAL);
   can_init();
   printf("Running...  receptor\n\r");



   while(TRUE)
   {
   
         can_getd(rx_id, &buffer[0], rx_len, rxstat);
                         
          printf("buffer = %Ld\n\r",buffer[0]);

    }

 }

Por el momento no quiero checar si el identificador corresponde al destinatario, sólo quiero ver si recibe algo

el hardware es el pic y el mcp2551,

          PIC              MCP
CAN_TX (23) -> TX_MCP(1)
CAN_RX (24) -> RX_MCP(4)
                         PIN2_VSS
                         PIN3_VDD
                         PIN5_NO_CONECTADO
                         CAN_H del concentrador con el respectivo CAN_H del nodo
                         CAN_L del concentrador con el respectivo CAN_L del nodo
                          PIN_8_VSS

¿alguien puede descifrar mi error?, !me urge!                         
       
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Octubre de 2009, 08:57:05
Revisado, solo dos observaciones:

Los Buffer de CAN son de maximo 8 bytes, en ambos programas declaras a los buffer como Int16, pasalos a Int...

Para que habilitas las interrupciones si no las utilizas?? Comenta ambas lineas Enable Interrupt (global)

Prueba y nos comentas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 16 de Noviembre de 2009, 17:31:05
Hola! NO se donde poner esta pregunta, en que hilo, es CAN, pero el nivel de pregunta no es para este hilo, si algun moderador lo muebe ok :). beuno ahi voy.
Tenemos esta definicion de variables :
Código: C
  1. void main() {
  2.    struct rx_stat rxstat;
  3.    int32 rx_id;
  4.    int buffer[8];
  5.    int rx_len;
( he quitado algunas que no me interesan). Esto es del archivo ex_can_ccsa.c. Primero, no entiendo muy bien que hace ese struct, si no hay nada metido, para mi un struct seria tal como :
Código: C
  1. struct estructuraMia{
  2. int primera;
  3. byte segunda
  4. }

ese struct lo usa aqui
Código: C
  1. if ( can_kbhit() )
  2.       {
  3.          printf("\r\n");
  4.          if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) {

Donde, segun mi entender, donde aparece rxstat es infromacion tal como decir si es extended can o starndard can ( que es para lo que yo quiero). Si no define nada, como sabe el compilador con
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Noviembre de 2009, 18:02:29
En realidad la estructura original es esta:

Código: C
  1. //PROTOTYPES and MACROS
  2.  
  3. struct rx_stat {
  4.    int1 err_ovfl;
  5.    int filthit:3;
  6.    int1 buffer;
  7.    int1 rtr;
  8.    int1 ext;
  9.    int1 inv;
  10. };

Esa estructura define los bits de status de la recepcion (por eso el nombre) y los filtros utilizados.
En esta operacion:

Código: C
  1. struct rx_stat rxstat;

Se clona (en realidad se llama crear una instancia) esa estructura en otra llamada rxstat, que es la que finalmente utiliza el programa....

Se entiende??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 18 de Noviembre de 2009, 14:35:38
hola

uffff,hace que no toco pic y menos ccs jejeje.voy a implementer bus can en un dspic o pic24 (arquitectura 16bits) ¿tendria algun problema con la libreria de ccs o me toca "retocarla"? gracias.

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Noviembre de 2009, 15:48:07
Desde la version 4.088 (creo) CCS trae las librerias para CAN exclusivas para DSPIC (can-dspic30.c y .h) y para los PIC24 (can-pic24.c y .h).
Si los buscas en la carpeta drivers veras lo que digo.
No los use personalmente, pero se que estan alli... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 20 de Noviembre de 2009, 11:11:36
voy a mirar la versioue tengo y si vienen, muchas gracias.

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: sergio_silva en 06 de Diciembre de 2009, 16:12:58
Boas a todos. Em primeiro, sou portugues logo a regra que diz para escrever em espanhol vai ser dificil para mim, mas com o tempo vou tentar começar a escrever em espanhol.

Eu estudo Electrónica e vou começar agora a programar o PIC18F4580, e tenho que ligar 2 PIC´s ( através de uma rede CAN), um para comunicar com o PC ( terminal ) e outro que está ligado a 2 Led´s e a 2 botões. Então, a partir do PC é possível ligar / desligar os Led´s e saber qual o estado dos botões. Eu já estive a ler este tópico e então já fiz o código para o PIC que está ligado aos Led´s e aos botões. Ainda estou à espera que o programador e os PIC´s cheguem, mas entretanto queria ter o código pronto.

Código do Pic: Relembro que este código liga/desliga Led´s consoante a informação que recebe do outro PIC e se os botões forem pressionados informa o PIC .
Código: [Seleccionar]
//#include <18F4580.h>

#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 BROWNOUT               //Reset when brownout detected   
#FUSES BORV21                 //Brownout reset at 2.1V 
#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 NOIESO                   //Internal External Switch Over mode enabled 
#FUSES FCMEN                 //Fail-safe clock monitor enabled 
//#FUSES PBADEN                 //PORTB pins are configured as analog input channels on RESET 
#FUSES BBSIZ1K               //1K words Boot Block size 
#FUSES NOWRTC                 //configuration not registers write protected 
#FUSES NOWRTB                 //Boot block not write protected 
#FUSES NOEBTR                 //Memory not protected from table reads 
#FUSES NOEBTRB               //Boot block not protected from table reads 
#FUSES NOCPB                 //No Boot Block code protection 
#FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation 
//#FUSES MCLR                   //Master Clear pin enabled 
#FUSES NOXINST               //Extended set extension and Indexed Addressing mode disabled (Legacy mode) 

#include "can-18F4580.c"

#define PIC_ID 26//identificação deste PIC

#define PIN_LED1  PIN_A0
#define PIN_LED2  PIN_A1

#define LED1_LOW  output_low(PIN_LED1)
#define LED1_HIGH output_high(PIN_LED1)
#define LED2_LOW  output_low(PIN_LED2)
#define LED2_HIGH output_high(PIN_LED2)

#define BUTTON1 PIN_A2
#define BUTTON2 PIN_A3

#define BUTTON_PRESSED1 input(BUTTON1)
#define BUTTON_PRESSED2 input(BUTTON2)

void main()
{
    int led=9;
    int cnt1 = 0;
    int cnt2 = 0;
    int cnt3 = 0;
    int cnt4 = 0;

    //recv message
    struct rx_stat rxstat;
    int32 rx_id;
    int in_data[8];
    int rx_len;
   
    int out_data[8];
    int i = 0;
   
    //clear recv buffer
    for(i=0;i<8;i++)
    {
    in_data[i]=0;
    }

    can_init();
    //can_set_mode(CAN_OP_LISTEN);
   
    while(TRUE)
    {
   
        // mensagem recebida
        if ( can_kbhit() )
        {       
           if(can_getd(rx_id, &in_data[0], rx_len, rxstat))   //se existem dados no buffer in_data, guarda os dados recebidos nas variáveis
           {
              if(rx_id == PIC_ID)  // Se a mensagem é para este PIC
              {
                 led =~ (in_data[0]);                 
                 if(bit_test(led, 0))
                    LED1_HIGH;//turn ON Led 1
                 if(bit_test(led, 1))
                    LED1_LOW;//turn OFF Led 1
                 if(bit_test(led, 2))
                    LED2_HIGH;//tunr ON Led 2
                 if(bit_test(led, 3))
                    LED2_LOW;//turn OFF Led 2               
              }
           }
        }//fim do tratamento da mensagem recebida
   
        if( (!BUTTON_PRESSED1) && (cnt1 == 0) )   // if button 1 is OFF
        {
           out_data[0] = 4;
           can_putd(25, &out_data[0], 1, 1, 1, 0);
           cnt1 = 1;
           cnt2 = 0;
        }
        if( (BUTTON_PRESSED1) && (cnt2 == 0) )   //if button 1 is ON
        {
           out_data[0] = 5;
           can_putd(25, &out_data[0], 1, 1, 1, 0);
           cnt2 = 1;
           cnt1 = 0;
        }
        if( (!BUTTON_PRESSED2) && (cnt3 == 0) )   // if button 2 is OFF
        {
           out_data[0] = 6;
           can_putd(25, &out_data[0], 1, 1, 1, 0);
           cnt3 = 1;
           cnt4 = 0;       
        }
        if( (BUTTON_PRESSED2) && (cnt4 == 0) )   // if button 2 is ON
        {
           out_data[0] = 7;
           can_putd(25, &out_data[0], 1, 1, 1, 0);
           cnt4 = 1;
           cnt3 = 0;
        }       
   
   
    }

}

Se alguém puder analisar o código, é provável que tenha alguns erros.

Obrigado e parabéns pelo fórum que está muito bom!

Saludos, Sérgio Silva
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Diciembre de 2009, 22:21:59
Hola Sergio!!
Bienvenido al foro y especialmente a este hilo.

Revisando el codigo, creo que esta bien operativo.
No entiendo lo de los cnt1 a 4.
Supongo es para saber que boton presionaste ultimo, es asi ??

Como comentario, usas la velocidad por defecto que tienen configuradas las librerias de CCS y de Microchip, que es de 125 K, en modo extendido.

Si quieres poner el codigo del otro PIC, podemos analizarlo y ayudar tambien.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 07 de Diciembre de 2009, 13:14:31
Vereis, estoy tratando de enviar datos por can desde mi pic 18f4550 al mcp2510. Veo que se comunica ( aunque después el modulo can no envia nada al transceiver mcp2551). Para ver si mi SPI funciona correctamente, mando unos datos, y por oscilosciopio los puedo leer. De ahí deduzco que mi librería modificada de SPI por hardware es correcta( la can-mcp2510.c).  Pongo eso luego como comentario, y sin mas dilación, envio una trama al Can Controller. Por osciloscopio veo señal de SCK (cada 8 pulsos, pq se envian de 8 en 8 bits) y pretendo ver por la patilla SDO los datos enviados en can. Pues, primero, no veo una señal clara, hay una fija y otra que se va superponiendo ( una guarrada, hablando en plata :)). De ahí deduzco que podría ser acerca de la velocidad, asi que os pongo como determino la velocidad ( y os sonara muuucho a los seguidores de este foro, ya que me baso en él). Uso este circuito :
(http://img121.imageshack.us/img121/9200/dibujokuc.jpg)

Para determinar la velocidad: como veis, el cristal es de 20 Mhz tanto en pic como en modulo can, y usando el programa de determinacion de velocidad del sistema, y de cambio en el programa, hago o siguiente ( para 125K y 48M)
Código: C
  1. #ifdef Set_125_Baud {
  2.      BRGCON1 = 0x07;
  3.      BRGCON2 = 0xBE;      //modificado 7/12/09 para usar CAN a 125 KBps
  4.      BRGCON3 = 0x07;      //con reloj a 48 MHz
  5.    }
  6.   #endif

a continuacion pongo el main que uso, que no es mas que una modificacion del EX_CAN_CCS_A.C a mi convenencia:
Código: C
  1. #include <18F4550.h>
  2. #include <stdlib.h>
  3. #fuses HS,NOPROTECT,NOLVP,NOWDT,XTPLL,PLL5,NOWDT,NOPROTECT,USBDIV,CPUDIV2
  4. #use delay(clock=48000000)
  5. #include <spi-can-mcp2510.c>
  6. #define CAN_DO_DEBUG TRUE
  7. #define Set_125K_Baud TRUE
  8. #byte   porta = 0xf80
  9. #byte   portb = 0xf81
  10. #byte   portc = 0xf82
  11. #byte   portd = 0xf83
  12. #byte   porte = 0xf84
  13. #byte   t1con = 0xfcd
  14. #byte   latd = 0xf8c
  15. #byte   adcon0 = 0xfc2
  16. #byte   adcon1 = 0xfc1
  17. #byte   adcon2 = 0xfc0
  18. #byte   adresl = 0xfc3
  19. #byte   adresh = 0xfc4
  20.  
  21. #use fast_io (D)
  22. #byte PORTD= 0XF83
  23.  
  24. void main() {
  25.    int dato[8];
  26.    struct rx_stat rxstat;
  27.    int32 rx_id;
  28.    int buffer[8];
  29.    int i,rx_len;
  30.  
  31.    set_tris_d(0x01);
  32.    setup_spi(SPI_MASTER | SPI_H_TO_L|spi_clk_div_4);
  33.  
  34.    rx_id=0x01;
  35.    buffer[0]=0x08;
  36.  
  37.  
  38.  
  39.  
  40.    can_init();
  41.    while(TRUE)
  42.    {
  43.     //spi_write(0x25);
  44.      
  45.       if ( can_tbe()){
  46.        output_high(pin_d1);
  47.        can_putd(0x01,&buffer[0],8,3,TRUE,TRUE);
  48.       }
  49.    }
  50. }

Como veis esta quitada toda la parte interesante de ese archivo, simplemente para ver que es lo que envio y reconocerlo ( de momento que no reciba el trasnceiver es un mal menor, quiero saber primero lo que va a recibir éste).
Pretendo ver por osciloscopio el  extended frame como por ejemplo, un primer bit que sea 0(inicio) ver el numero de identificador, que deberia ser 0x01 ( con mas ceros por delante  ya que uso  extended), otros 3 ceros, el dato puesto y un seguido de 1's de end of frame. Pero no veo eso, envia algo distinto y lo peor, la señal de sck se ve fija y hay 8 semiciclos que se intercalan de una forma que hace que al ver la señal de SDO tambien se vea muy poco claro. Es pues acerca de una mala configuración de velocidad ?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Diciembre de 2009, 15:17:12
Antes de seguir con nada, pon el pin Reset del MCP2515 a VDD (5V), ya que no puede quedar al aire, porque tomara un estado indeterminado.
Eso puede ser la causa de tus males...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 07 de Diciembre de 2009, 15:47:06
uhm... vaya, tengo el esquema mal, cuando llegue a casa lo modifico.
El pin de reset lo tengo alimentado a Vcc ( con una resistencia de 3K9) y conectado a un pulsador, que al pulsarlo deriva a masa ( como el circuito del boot del pic).
Ahora estoy probando con distintas velocidades para el pic ( cambiando libreria spi can) y sigue en las mismas.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Diciembre de 2009, 16:54:40
Porque no pones aqui todo el codigo que usas y las librerias??
A ver si encontramos algo...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: sergio_silva en 07 de Diciembre de 2009, 18:46:42
Revisando el codigo, creo que esta bien operativo.
No entiendo lo de los cnt1 a 4.
Supongo es para saber que boton presionaste ultimo, es asi ??

Hola, eu utilizo los cnt´s para que lo PIC sólo envia una vez el estado del boton ( cuando é alterado) , de lo contrario lo PIC enviava sempre el estado del bóton.

Lo codigo del outro PIC, ainda no ha termiando, pero cuando terminar eu lo coloco aquí.

Gracias por la ajuda,

Sérgio Silva.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Diciembre de 2009, 19:21:48
OK, entiendo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 08 de Diciembre de 2009, 11:05:37
Hola MGLSOFT ( y compañia!) he modificado el esquematico. cuelgo el programa en si tal como me pides :

Código: C
  1. ///// programa principal ////
  2.  
  3. #include <18F4550.h>
  4. #include <stdlib.h>
  5. #fuses HS,NOPROTECT,NOLVP,NOWDT,XTPLL,PLL5,NOPROTECT,USBDIV,CPUDIV2
  6. #use delay(clock=48000000)
  7. #include <spi-can-mcp2510.c>
  8.  
  9. #define CAN_DO_DEBUG TRUE
  10. #define Set_125K_Baud TRUE
  11.  
  12. #byte   porta = 0xf80
  13. #byte   portb = 0xf81
  14. #byte   portc = 0xf82
  15. #byte   portd = 0xf83
  16. #byte   porte = 0xf84
  17. #byte   t1con = 0xfcd
  18. #byte   latd = 0xf8c
  19. #byte   adcon0 = 0xfc2
  20. #byte   adcon1 = 0xfc1
  21. #byte   adcon2 = 0xfc0
  22. #byte   adresl = 0xfc3
  23. #byte   adresh = 0xfc4
  24. #use fast_io (D)
  25. #byte PORTD= 0XF83
  26.  
  27. void main() {
  28.    struct rx_stat rxstat;
  29.    int32 rx_id;
  30.    int buffer[8];
  31.    int i,rx_len;
  32.  
  33.    set_tris_d(0x01);
  34.    setup_spi(SPI_MASTER | SPI_H_TO_L|spi_clk_div_4);
  35.  
  36.    rx_id=0x01;
  37.  
  38.   buffer[0]=0x08;
  39.  
  40.    setup_timer_2(T2_DIV_BY_4,79,16);   //setup up timer2 to interrupt every 1ms if using 20Mhz clock
  41.    can_init();
  42.    enable_interrupts(INT_TIMER2);
  43.    enable_interrupts(GLOBAL);
  44.   // can_putd(0x01,dato,8,3,TRUE,TRUE);
  45.    while(TRUE){
  46.      //spi_write(0x25);  //sin habilitar nada de can, esta instruccion se lee correcta en osciloscopio por flanco ascendente de clk
  47.  
  48.       if ( can_tbe()){
  49.        output_high(pin_d1);// para ver si entra dentro del if, enciendo led
  50.        can_putd(0x01,&buffer[0],8,3,TRUE,TRUE);
  51.        }
  52.    }
  53. }

la libreria que modifico para usar por spi por harware ( para el mcp2510) es esta :

Código: C
  1. /////////////////////////////////////////////////////////////////////////
  2. ////                        spi-can-mcp2510.c                            ////
  3. //// CAN Library routines for Microchip's MCP2510 (and compatable)   ////
  4. //// CAN IO expanders.                                               ////
  5. ////                                                                 ////
  6. //// This library provides the following functions:                  ////
  7. ////  (for more information on these functions see the comment       ////
  8. ////   header above each function)                                   ////
  9. ////                                                                 ////
  10. ////    can_init - Configures the MCP2510 CAN peripheral             ////
  11. ////                                                                 ////
  12. ////    can_set_baud - Sets the baud rate control registers          ////
  13. ////                                                                 ////
  14. ////    can_set_mode - Sets the CAN module into a specific mode      ////
  15. ////                                                                 ////
  16. ////    can_set_id - Sets the standard and extended ID               ////
  17. ////                                                                 ////
  18. ////    can_get_id - Gets the standard and extended ID               ////
  19. ////                                                                 ////
  20. ////    can_putd - Sends a message/request with specified ID         ////
  21. ////                                                                 ////
  22. ////    can_getd - Returns specifid message/request and ID           ////
  23. ////                                                                 ////
  24. ////    can_kbhit - Returns true if there is data in one of the      ////
  25. ////                receive buffers                                  ////
  26. ////                                                                 ////
  27. ////    can_tbe - Returns true if the transmit buffer is ready to    ////
  28. ////              send more data                                     ////
  29. ////                                                                 ////
  30. ////    can_abort - Aborts all pending transmissions                 ////
  31. ////                                                                 ////
  32. //// You will need a CAN transeiver to connect CANRX and CANTX       ////
  33. //// pins to CANH and CANL bus lines.                                ////
  34. ////                                                                 ////
  35. //// CCS provides an example, ex_can_ccs_b.c, which shows how to use ////
  36. //// this library with CCS's CAN Prototype board.                    ////
  37. ////                                                                 ////
  38. /////////////////////////////////////////////////////////////////////////
  39. ////                                                                 ////
  40. //// Version History                                                 ////
  41. ////                                                                 ////
  42. ////  Jul 27 04 - can_init() uses CAN_USE_EXTENDED_ID instead of     ////
  43. ////              setting all RX filters to extended.                ////
  44. ////                                                                 ////
  45. ////  Apr 20 04 - Fixed a compling problem.                          ////
  46. ////                                                                 ////
  47. ////  Feb 24 04 - can_get_id() fixed for EID<18:20>.                 ////
  48. ////                                                                 ////
  49. /////////////////////////////////////////////////////////////////////////
  50. ////        (C) Copyright 1996,2003 Custom Computer Services         ////
  51. //// This source code may only be used by licensed users of the CCS  ////
  52. //// C compiler.  This source code may only be distributed to other  ////
  53. //// licensed users of the CCS C compiler.  No other use,            ////
  54. //// reproduction or distribution is permitted without written       ////
  55. //// permission.  Derivative programs created using this software    ////
  56. //// in object code form are not restricted in any way.              ////
  57. /////////////////////////////////////////////////////////////////////////
  58.  
  59. #include <can-mcp2510.h>
  60.  
  61.  
  62.  
  63. //IO pins connected to MCP2510
  64. #ifndef EXT_CAN_CS
  65.    //#define EXT_CAN_CS   PIN_B1 //por defecto estos
  66.    //#define EXT_CAN_SI   PIN_C1
  67.    //#define EXT_CAN_SO   PIN_C0
  68.    //#define EXT_CAN_SCK  PIN_C3
  69.    // cambio para usar en PIC18F4550 modo HW
  70.    #define EXT_CAN_CS   PIN_A5
  71.    #define EXT_CAN_SI   PIN_B0
  72.    #define EXT_CAN_SO   PIN_C7
  73.    #define EXT_CAN_SCK  PIN_B1
  74. //   #define EXT_CAN_RESET   PIN_B5 //CCS library does not use this pin by default
  75. //   #define EXT_CAN_TX0RTS  PIN_C4 //CCS library does not use this pin by default
  76. //   #define EXT_CAN_TX1RTS  PIN_B4 //CCS library does not use this pin by default
  77. //   #define EXT_CAN_TX2RTS  PIN_C2 //CCS library does not use this pin by default
  78. #endif
  79.  
  80. #if CAN_DO_DEBUG
  81.  #define can_debug printf
  82. #else
  83.  #define can_debug
  84. #endif
  85.  
  86.  
  87.  
  88.  
  89. int  prescaler;
  90. int1 clkenable;
  91.  
  92.  
  93. ////////////////////////////////////////////////////////////////////////
  94. //
  95. // can_init()
  96. //
  97. // Initializes MCP2510 CAN peripheral.  Sets the RX filter and masks so the
  98. // CAN peripheral will receive all incoming IDs.  Configures both RX buffers
  99. // to only accept valid valid messages (as opposed to all messages, or all
  100. // extended message, or all standard messages).
  101. //
  102. // The constants (CAN_USE_RX_DOUBLE_BUFFER, CAN_ENABLE_DRIVE_HIGH,
  103. // CAN_ENABLE_CAN_CAPTURE, etc) are given a default define in the can-mcp2510.h file.
  104. // These default values can be overwritten in the main code, but most
  105. // applications will be fine with these defaults.
  106. //
  107. //////////////////////////////////////////////////////////////////////////////
  108. void can_init(void) {
  109.    struct struct_RXB0CTRL b_rxb0ctrl;
  110.  
  111.    mcp2510_init();
  112.  
  113.    can_set_mode(CAN_OP_CONFIG);   //must be in config mode before params can be set
  114.    can_set_baud();
  115.  
  116.    b_rxb0ctrl=0;
  117.    b_rxb0ctrl.rxm=CAN_RX_VALID;
  118.    b_rxb0ctrl.bukt=CAN_USE_RX_DOUBLE_BUFFER;
  119.    mcp2510_write(RXB0CTRL, (int)b_rxb0ctrl);
  120.    mcp2510_write(RXB1CTRL, (int)b_rxb0ctrl);
  121.  
  122.    //if you want to configure the TXnRTS pins, do it here.  default is off
  123.  
  124.    can_set_id(RX0MASK, CAN_MASK_ACCEPT_ALL, CAN_USE_EXTENDED_ID);  //set mask 0 (RX BUFFER 0)
  125.    can_set_id(RX0FILTER0, 0, CAN_USE_EXTENDED_ID);  //set filter 0 of mask 0 (RX BUFFER 0)
  126.    can_set_id(RX0FILTER1, 0, CAN_USE_EXTENDED_ID);  //set filter 1 of mask 0 (RX BUFFER 0)
  127.  
  128.    can_set_id(RX1MASK, CAN_MASK_ACCEPT_ALL, CAN_USE_EXTENDED_ID);  //set mask 1 (RX BUFFER 1)
  129.    can_set_id(RX1FILTER2, 0, CAN_USE_EXTENDED_ID);  //set filter 0 of mask 1 (RX BUFFER 1)
  130.    can_set_id(RX1FILTER3, 0, CAN_USE_EXTENDED_ID);  //set filter 1 of mask 1 (RX BUFFER 1)
  131.    can_set_id(RX1FILTER4, 0, CAN_USE_EXTENDED_ID);  //set filter 2 of mask 1 (RX BUFFER 1)
  132.    can_set_id(RX1FILTER5, 0, CAN_USE_EXTENDED_ID);  //set filter 3 of mask 1 (RX BUFFER 1)
  133.  
  134.    can_set_mode(CAN_OP_NORMAL);
  135. }
  136.  
  137. ////////////////////////////////////////////////////////////////////////
  138. //
  139. // can_set_baud()
  140. //
  141. // Configures the baud rate control registers.  All the defines here
  142. // are defaulted in the can-mcp2510.h file.  These defaults can, and
  143. // probably should, be overwritten in the main code.
  144. //
  145. // Current defaults are set to work with CCS's CAN Prototype board and
  146. // Microchip's MCP250xxx CAN Developers Kit if this PIC is running at 20Mhz.
  147. //
  148. ////////////////////////////////////////////////////////////////////////
  149.  
  150. /* void can_set_baud(void) {   // modificada abajo
  151.    struct struct_CNF1 new_CNF1;
  152.    struct struct_CNF2 new_CNF2;
  153.    struct struct_CNF3 new_CNF3;
  154.  
  155.  
  156.    new_CNF1.brp=CAN_BRG_PRESCALAR;
  157.    new_CNF1.sjw=CAN_BRG_SYNCH_JUMP_WIDTH;
  158.  
  159.    new_CNF2.prseg=CAN_BRG_PROPAGATION_TIME;
  160.    new_CNF2.phseg1=CAN_BRG_PHASE_SEGMENT_1;
  161.    new_CNF2.sam=CAN_BRG_SAM;
  162.    new_CNF2.btlmode=CAN_BRG_SEG_2_PHASE_TS;
  163.  
  164.    new_CNF3.phseg2=CAN_BRG_PHASE_SEGMENT_2;
  165.    new_CNF3.wakfil=CAN_BRG_WAKE_FILTER;
  166.  
  167.    mcp2510_write(CNF1, (int)new_CNF1);
  168.    mcp2510_write(CNF2, (int)new_CNF2);
  169.    mcp2510_write(CNF3, (int)new_CNF3);
  170. }*/
  171.                
  172. void can_set_baud(void) {      
  173.  /* # ifdef Set_125K_Baud {
  174.      BRGCON1 = 0x01;
  175.      BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 125 KBps
  176.      BRGCON3 = 0x07;      //con reloj a 10 MHz
  177.   }
  178.   #endif */
  179.  
  180.   #ifdef Set_250K_Baud {
  181.      BRGCON1 = 0x00;
  182.      BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 250 KBps
  183.      BRGCON3 = 0x07;      //con reloj a 10 MHz
  184.   }
  185.   #endif
  186.   #ifdef Set_500K_Baud {
  187.      BRGCON1 = 0x00;
  188.      BRGCON2 = 0x92;      //modificado 5/11/07 para usar CAN a 500 KBps
  189.      BRGCON3 = 0x02;      //con reloj a 10 MHz
  190.   }
  191.   #endif
  192. #ifdef Set_125_Baud {
  193.      BRGCON1 = 0x07;
  194.      BRGCON2 = 0xBE;      //modificado 7/12/09 para usar CAN a 250 KBps
  195.      BRGCON3 = 0x07;      //con reloj a 48 MHz
  196.    }
  197.   #endif
  198. /*
  199. #ifdef Set_125_Baud {
  200.      BRGCON1 = 0x03;
  201.      BRGCON2 = 0xBA;      //modificado 7/12/09 para usar CAN a 125 KBps
  202.      BRGCON3 = 0x07;      //con cristal a 20 MHz
  203.    }
  204.  #endif
  205. */
  206.  
  207. }
  208.  
  209. void can_set_mode(CAN_OP_MODE mode) {
  210.    struct struct_CANCTRL old_CANCTRL;
  211.  
  212.    old_CANCTRL=mcp2510_read(CANCTRL);
  213.  
  214.    old_CANCTRL.reqop=mode;
  215.  
  216.    mcp2510_write(CANCTRL, (int)old_CANCTRL);
  217.  
  218.    do {
  219.       old_CANCTRL=mcp2510_read(CANCTRL);
  220.    } while (old_CANCTRL.reqop != mode);
  221.  
  222.  }
  223.  
  224.  
  225. ///// void can_set_clk(CAN_OP_MODE prescaler)//////////////////////////////////
  226. ////////////////////////////////////////////////////////////////////////////////
  227. //void can_set_clk(CAN_OP_MODE prescaler) {   // funcio pel presclaer del clock del MCP
  228. void can_set_clk(){     //cambio capçalera perque no vull que retorni res. Crida funcio i executa.
  229.   struct struct_CANCTRL old_CANCTRL;
  230.  
  231.    old_CANCTRL=mcp2510_read(CANCTRL);
  232.   // old_CANCTRL.clkpre=0; // modifica els 2 bits del registre CANCTRL per posar a 1 el escaler
  233.  
  234.   prescaler=0; // 0  es el valor que vull de presclaer (0b00)
  235.  
  236.    old_CANCTRL.clkpre=prescaler;     //********** falta activació del pin!!!!!!!!!!!!!!!!!!!!!!!!!!
  237.  
  238.    mcp2510_write(CANCTRL, (int)old_CANCTRL);
  239.  
  240.    do {
  241.       old_CANCTRL=mcp2510_read(CANCTRL);
  242.    } while (old_CANCTRL.clkpre != prescaler);
  243. }
  244.  
  245. ////////////////////////////////////////////////////////////////////////////////
  246. //void can_set_clken() {   // activar pin clckout del mcp2510 , pero al final no uso esta funcion. de todos modos ahi esta hecha
  247. void can_set_clken(int1 cambiaa){     //cambio capçalera perque no vull que retorni res. Crida funcio i executa.
  248.   struct struct_CANCTRL old_CANCTRL;
  249.  
  250.    old_CANCTRL=mcp2510_read(CANCTRL);
  251.  
  252.   //clkenable=0; // 0  es el valor que vull de presclaer (0b00)
  253.  
  254.    //old_CANCTRL.clken=clkenable;     //********** falta activación del pin!!!!!!!!!!!!!!!!!!!!!!!!!!
  255.      old_CANCTRL.clken=cambiaa;
  256.  
  257.    mcp2510_write(CANCTRL, (int)old_CANCTRL);
  258.  
  259.    do {
  260.       old_CANCTRL=mcp2510_read(CANCTRL);
  261.    } while (old_CANCTRL.clkpre != prescaler);
  262. }
  263.  
  264. ////////////////////////////////////////////////////////////////////////
  265. //
  266. // can_set_id()
  267. //
  268. // Configures the xxxxEIDL, xxxxEIDH, xxxxSIDL and xxxxSIDH registers to
  269. // configure the defined buffer to use the specified ID
  270. //
  271. //   Paramaters:
  272. //     addr - pointer to first byte of ID register, starting with xxxxEIDL.
  273. //            For example, a pointer to RXM1EIDL
  274. //     id - ID to set buffer to
  275. //     ext - Set to TRUE if this buffer uses an extended ID, FALSE if not
  276. //
  277. ////////////////////////////////////////////////////////////////////////
  278. void can_set_id(int addr, int32 id, int1 ext) {
  279.    int converted_id[4];
  280.    int *ptr;
  281.  
  282.    ptr=&converted_id[3];   //3=eidl, 2=eidh, 1=sidl, 0=sidh
  283.  
  284.    if (ext) {  //extended
  285.       //eidl
  286.       *ptr=make8(id,0); //0:7
  287.  
  288.       //eidh
  289.       ptr--;
  290.       *ptr=make8(id,1); //8:15
  291.  
  292.       //sidl
  293.       ptr--;
  294.       *ptr=make8(id,2) & 0x03;   //16:17
  295.       *ptr|=(make8(id,2) << 3) & 0xE0; //18:20
  296.       *ptr|=0x08;
  297.  
  298.  
  299.       //sidh
  300.       ptr--;
  301.       *ptr=((make8(id,2) >> 5) & 0x07 ); //21:23
  302.       *ptr|=((make8(id,3) << 3) & 0xF8);//24:28
  303.    }
  304.    else {   //standard
  305.       //eidl
  306.       *ptr=0;
  307.  
  308.       //eidh
  309.       ptr--;
  310.       *ptr=0;
  311.  
  312.       //sidl
  313.       ptr--;
  314.       *ptr=(make8(id,0) << 5) & 0xE0;
  315.  
  316.       //sidh
  317.       ptr--;
  318.       *ptr=(make8(id,0) >> 3) & 0x1F;
  319.       *ptr|=(make8(id,1) << 5) & 0xE0;
  320.    }
  321.  
  322.    //0=eidl, 1=eidh, 2=sidl, 3=sidh
  323.    mcp2510_write(addr--, converted_id[3]);
  324.    mcp2510_write(addr--, converted_id[2]);
  325.    mcp2510_write(addr--, converted_id[1]);
  326.    mcp2510_write(addr, converted_id[0]);
  327. }
  328.  
  329. ////////////////////////////////////////////////////////////////////////
  330. //
  331. // can_get_id()
  332. //
  333. // Returns the ID of the specified buffer.  (The opposite of can_set_id())
  334. // This is used after receiving a message, to see which ID sent the message.
  335. //
  336. //   Paramaters:
  337. //     addr - pointer to first byte of ID register, starting with xxxxEIDL.
  338. //            For example, a pointer to RXM1EIDL
  339. //     ext - Set to TRUE if this buffer uses an extended ID, FALSE if not
  340. //
  341. //   Returns:
  342. //     The ID of the buffer
  343. //
  344. ////////////////////////////////////////////////////////////////////////
  345. int32 can_get_id(int addr, int1 ext) {
  346.    int32 ret;
  347.    int * ptr;
  348.    int converted_id[4];
  349.  
  350.    ptr=&converted_id[3];   //3=eidl, 2=eidh, 1=sidl, 0=sidh
  351.  
  352.    converted_id[3]=mcp2510_read(addr--);
  353.    converted_id[2]=mcp2510_read(addr--);
  354.    converted_id[1]=mcp2510_read(addr--);
  355.    converted_id[0]=mcp2510_read(addr);
  356.  
  357.    ret=0;
  358.  
  359.  
  360.    if (ext) {
  361.       ret=*ptr;  //eidl
  362.  
  363.       ptr--;     //eidh
  364.       ret|=((int32)*ptr << 8);
  365.  
  366.       ptr--;     //sidl
  367.       ret|=((int32)*ptr & 0x03) << 16;
  368.       ret|=((int32)*ptr & 0xE0) << 13;
  369.  
  370.       ptr--;     //sidh
  371.       ret|=((int32)*ptr << 21);
  372.    }
  373.    else {
  374.       ptr-=2;    //sidl
  375.       ret=((int32)*ptr & 0xE0) >> 5;
  376.  
  377.       ptr--;     //sidh
  378.       ret|=((int32)*ptr << 3);
  379.    }
  380.  
  381.    return(ret);
  382. }
  383.  
  384. ////////////////////////////////////////////////////////////////////////
  385. //
  386. // can_putd()
  387. //
  388. // Puts data on a transmit buffer, at which time the CAN peripheral will
  389. // send when the CAN bus becomes available.
  390. //
  391. //    Paramaters:
  392. //       id - ID to transmit data as
  393. //       data - pointer to data to send
  394. //       len - length of data to send
  395. //       priority - priority of message.  The higher the number, the
  396. //                  sooner the CAN peripheral will send the message.
  397. //                  Numbers 0 through 3 are valid.
  398. //       ext - TRUE to use an extended ID, FALSE if not
  399. //       rtr - TRUE to set the RTR (request) bit in the ID, false if NOT
  400. //
  401. //    Returns:
  402. //       If successful, it will return TRUE
  403. //       If un-successful, will return FALSE
  404. //
  405. ////////////////////////////////////////////////////////////////////////
  406. int1 can_putd(int32 id, int * data, int len, int priority, int1 ext, int1 rtr) {
  407.    int i;
  408.    int port;
  409.  
  410.    int TXRXBaD0;
  411.    int TXBaCTRL;
  412.    int TXRXBaEIDL;
  413.    int TXBaDLC;
  414.  
  415.    struct txbNctrl_struct b_TXBaCTRL;
  416.    struct rxbNdlc_struct b_TXBaDLC;
  417.    struct txbNctrl_struct b_TXB0CTRL, b_TXB1CTRL, b_TXB2CTRL;
  418.  
  419.    b_TXB0CTRL=mcp2510_read(TXB0CTRL);
  420.    b_TXB1CTRL=mcp2510_read(TXB1CTRL);
  421.    b_TXB2CTRL=mcp2510_read(TXB2CTRL);
  422.  
  423.     // find emtpy transmitter
  424.     //map access bank addresses to empty transmitter
  425.    if (!b_TXB0CTRL.txreq) {
  426.       TXRXBaD0=TXB0D0;
  427.       TXBaCTRL=TXB0CTRL;
  428.       TXRXBaEIDL=TXB0EIDL;
  429.       TXBaDLC=TXB0DLC;
  430.       port=0;
  431.    }
  432.    else if (!b_TXB1CTRL.txreq) {
  433.       TXRXBaD0=TXB1D0;
  434.       TXBaCTRL=TXB1CTRL;
  435.       TXRXBaEIDL=TXB1EIDL;
  436.       TXBaDLC=TXB1DLC;
  437.       port=1;
  438.    }
  439.    else if (!b_TXB2CTRL.txreq) {
  440.       TXRXBaD0=TXB2D0;
  441.       TXBaCTRL=TXB2CTRL;
  442.       TXRXBaEIDL=TXB2EIDL;
  443.       TXBaDLC=TXB2DLC;
  444.       port=2;
  445.    }
  446.    else {
  447.       #if CAN_DO_DEBUG
  448.          can_debug("\r\nCAN_PUTD() FAIL: NO OPEN TX BUFFERS\r\n");
  449.       #endif
  450.       return(0);
  451.    }
  452.  
  453.    //set priority.
  454.    b_TXBaCTRL=mcp2510_read(TXBaCTRL);
  455.    b_TXBaCTRL.txpri=priority;
  456.    mcp2510_write(TXBaCTRL, (int)b_TXBaCTRL);
  457.  
  458.    //set tx mask
  459.    can_set_id(TXRXBaEIDL, id, ext);
  460.  
  461.    //set tx data count
  462.    b_TXBaDLC=len;
  463.    b_TXBaDLC.rtr=rtr;
  464.    mcp2510_write(TXBaDLC, (int)b_TXBaDLC);
  465.  
  466.    //write to buffer
  467.     for (i=TXRXBaD0; i<(TXRXBaD0 + len); i++) {
  468.       mcp2510_write(i,*data);
  469.       data++;
  470.     }
  471.  
  472.    //enable transmission
  473.    b_TXBaCTRL=mcp2510_read(TXBaCTRL);
  474.    b_TXBaCTRL.txreq=1;
  475.    mcp2510_write(TXBaCTRL, (int)b_TXBaCTRL);
  476.  
  477.    #if CAN_DO_DEBUG
  478.             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);
  479.             if ((len)&&(!rtr)) {
  480.                data-=len;
  481.                can_debug("  DATA = ");
  482.                for (i=0;i<len;i++) {
  483.                   can_debug("%X ",*data);
  484.                   data++;
  485.                }
  486.                can_debug("\r\n");
  487.             }
  488.    #endif
  489.  
  490.    return(1);
  491. }
  492.  
  493. ////////////////////////////////////////////////////////////////////////
  494. //
  495. // can_getd()
  496. //
  497. // Gets data from a receive buffer, if the data exists
  498. //
  499. //    Returns:
  500. //      id - ID who sent message
  501. //      data - pointer to array of data
  502. //      len - length of received data
  503. //      stat - structure holding some information (such as which buffer
  504. //             recieved it, ext or standard, etc)
  505. //
  506. //    Returns:
  507. //      Function call returns a TRUE if there was data in a RX buffer, FALSE
  508. //      if there was none.
  509. //
  510. ////////////////////////////////////////////////////////////////////////
  511. int1 can_getd(int32 & id, int * data, int & len, struct rx_stat & stat)
  512. {
  513.     int i;
  514.  
  515.    struct struct_RXB0CTRL b_RXB0CTRL;
  516.    struct struct_RXB1CTRL b_RXB1CTRL;
  517.    struct struct_EFLG b_EFLG;
  518.  
  519.    int RXBaDLC;
  520.    struct rxbNdlc_struct b_RXBaDLC;
  521.  
  522.    int TXRXBaSIDL;
  523.    struct struct_TXRXBaSIDL b_TXRXBaSIDL;
  524.  
  525.  
  526.    int RXBaD0;
  527.    struct struct_CANINTF b_CANINTF;
  528.  
  529.    b_CANINTF=mcp2510_read(CANINTF);
  530.  
  531.    b_RXB0CTRL=mcp2510_read(RXB0CTRL);
  532.    b_RXB1CTRL=mcp2510_read(RXB1CTRL);
  533.    b_EFLG=mcp2510_read(EFLG);
  534.  
  535.     if (b_CANINTF.rx0if) {
  536.         stat.buffer=0;
  537.  
  538.         stat.err_ovfl=b_EFLG.rx0ovr;
  539.         b_EFLG.rx0ovr=0;
  540.         mcp2510_write(EFLG, (int)b_EFLG);
  541.  
  542.         if (b_RXB0CTRL.bukt) {
  543.          stat.filthit=b_RXB0CTRL.filhit0;
  544.         }
  545.  
  546.         RXBaDLC=RXB0DLC;
  547.         TXRXBaSIDL=RXB0SIDL;
  548.         RXBaD0=RXB0D0;
  549.     }
  550.     else if (b_CANINTF.rx1if)
  551.     {
  552.         stat.buffer=1;
  553.  
  554.         stat.err_ovfl=b_EFLG.rx1ovr;
  555.         b_EFLG.rx1ovr=0;
  556.         mcp2510_write(EFLG, (int)b_EFLG);
  557.  
  558.  
  559.         stat.filthit=b_RXB1CTRL.filhit0;
  560.         RXBaDLC=RXB1DLC;
  561.         TXRXBaSIDL=RXB1SIDL;
  562.         RXBaD0=RXB1D0;
  563.     }
  564.     else {
  565.       #if CAN_DO_DEBUG
  566.          can_debug("\r\nFAIL ON CAN_GETD(): NO MESSAGE IN BUFFER\r\n");
  567.       #endif
  568.       return (0);
  569.     }
  570.  
  571.    //get count
  572.     b_RXBaDLC=mcp2510_read(RXBaDLC);
  573.     len = b_RXBaDLC.dlc;
  574.     stat.rtr=b_RXBaDLC.rtr;
  575.  
  576.    //was it extended or standard?
  577.     b_TXRXBaSIDL=mcp2510_read(TXRXBaSIDL);
  578.     stat.ext=b_TXRXBaSIDL.ext;
  579.     id=can_get_id(TXRXBaSIDL + 2,stat.ext);
  580.  
  581.    //get data
  582.     for ( i = RXBaD0; i < (RXBaD0 + len); i++ ) {
  583.          *data=mcp2510_read(i);
  584.         data++;
  585.     }
  586.  
  587.     stat.inv=b_CANINTF.merrf;
  588.     if (b_CANINTF.merrf) {
  589.       b_CANINTF.merrf=0;
  590.     }
  591.  
  592.     if (stat.buffer) {
  593.       b_CANINTF.rx1if=0;
  594.     }
  595.     else {
  596.       b_CANINTF.rx0if=0;
  597.     }
  598.     mcp2510_write(CANINTF, (int)b_CANINTF);
  599.  
  600.     #if CAN_DO_DEBUG
  601.        can_debug("\r\nCAN_GETD(): BUFF=%U ID=%LX LEN=%U OVF=%U ", stat.buffer, id, len, stat.err_ovfl);
  602.        can_debug("FILT=%U RTR=%U EXT=%U INV=%U", stat.filthit, stat.rtr, stat.ext, stat.inv);
  603.        if ((len)&&(!stat.rtr)) {
  604.           data-=len;
  605.           can_debug("\r\n    DATA = ");
  606.           for (i=0;i<len;i++) {
  607.             can_debug("%X ",*data);
  608.             data++;
  609.           }
  610.        }
  611.        can_debug("\r\n");
  612.     #endif
  613.  
  614.     return(1);
  615. }
  616.  
  617. ////////////////////////////////////////////////////////////////////////
  618. //
  619. // can_kbhit()
  620. //
  621. // Returns TRUE if there is data in the receive buffers
  622. //
  623. //////////////////////////////////////////////////////////////////////////////
  624. int1 can_kbhit(void) {
  625.    struct struct_CANINTF b_CANINTF;
  626.  
  627.    b_CANINTF=mcp2510_read(CANINTF);
  628.    if (b_CANINTF.rx0if || b_CANINTF.rx1if)
  629.       {return(1);}
  630.  
  631.    return(0);
  632. }
  633.  
  634. ////////////////////////////////////////////////////////////////////////
  635. //
  636. // can_tbe()
  637. //
  638. // Returns TRUE if the transmit buffers are empty and ready to transmit data
  639. //
  640. //////////////////////////////////////////////////////////////////////////////
  641. int1 can_tbe(void) {
  642.    struct txbNctrl_struct b_TXB0CTRL, b_TXB1CTRL, b_TXB2CTRL;
  643.  
  644.    b_TXB0CTRL=mcp2510_read(TXB0CTRL);
  645.    b_TXB1CTRL=mcp2510_read(TXB1CTRL);
  646.    b_TXB2CTRL=mcp2510_read(TXB2CTRL);
  647.  
  648.    if (!b_TXB0CTRL.txreq || !b_TXB1CTRL.txreq || !b_TXB2CTRL.txreq)
  649.       {return(1);}
  650.  
  651.    return(0);
  652. }
  653.  
  654. ////////////////////////////////////////////////////////////////////////
  655. //
  656. // can_abort()
  657. //
  658. // Aborts all pending tranmissions.
  659. //
  660. //////////////////////////////////////////////////////////////////////////////
  661. void can_abort(void) {
  662.    struct struct_CANCTRL b_CANCTRL;
  663.  
  664.    b_CANCTRL=mcp2510_read(CANCTRL);
  665.    b_CANCTRL.abat=1;
  666.    mcp2510_write(CANCTRL, (int)b_CANCTRL);
  667.  
  668.    delay_ms(5);
  669.    b_CANCTRL.abat=0;
  670.    mcp2510_write(CANCTRL, (int)b_CANCTRL);
  671. }
  672.  
  673.  
  674.  
  675.  
  676. ///////////////////
  677. ///
  678. //
  679. // SPI CODE. Antes por sofware, cambiando funciones para usar SPI por HW.
  680. //
  681. ///
  682. //////////////////
  683.  
  684. //data clocked in on rising edge
  685. //data driven out on falling edge
  686.  
  687. /*int mcp2510_read(int address) /////////  Esta es por software ////////
  688.   {
  689.    int command[2];
  690.    int i;
  691.    int data;
  692.  
  693.    command[1]=0x03;
  694.    command[0]=address;
  695.  
  696.  
  697.    output_low(EXT_CAN_CS);
  698.  
  699.    for (i=0;i<16;i++) {
  700.  
  701.     output_bit(EXT_CAN_SI, shift_left(&command[0],2,0));
  702.         output_high(EXT_CAN_SCK);
  703.         output_low(EXT_CAN_SCK);
  704.         }
  705.  
  706.        for (i=0;i<8;i++) {
  707.        shift_left(&data,1,input(EXT_CAN_SO));
  708.        output_high(EXT_CAN_SCK);
  709.        output_low(EXT_CAN_SCK);
  710.        }
  711.  
  712.  
  713.    output_high(EXT_CAN_CS);
  714.  
  715.    return(data);
  716. }*/
  717.  
  718.    /////////////////////////////////////////////////
  719.  
  720. ////////////////////////////////////  Esta es por hardware //////////////////////////////////
  721. int mcp2510_read(int address)
  722. {
  723. //enviar ( o sea escribir) al MCP desde el PIC que se quiere hacer.PIC contesta a la peticion de
  724. //lectura ( y el que hemos dicho) sobre data. Devuelve data
  725.  
  726.  int data;
  727.  
  728.       output_low(EXT_CAN_CS); // pic espera intsrucción. Primero mira cual es:
  729.       spi_write(0x03);    // escribir instrucción 0x03 es instruccion leer.Va a instruccion leer->
  730.       spi_write(address); //escribir dirección de donde se quiere leer
  731.       spi_read(data);     // escribir dato enviado por el pic
  732.       output_high(EXT_CAN_CS);
  733.       return(data);       //devuelbe lo que queremos leer
  734. }
  735.  
  736.    ////////////////////////////////////////////////
  737.  
  738.  
  739.  
  740.  
  741. /*
  742. int mcp2510_status(void) { //////////////////// por software////////////////////////////
  743.    int command;
  744.    int data;
  745.    int i;
  746.  
  747.    command=0xA0;
  748.  
  749.    output_low(EXT_CAN_CS);
  750.  
  751.    for (i=0;i<8;i++) {
  752.       output_bit(EXT_CAN_SI, shift_left(&command,1,0));
  753.       output_high(EXT_CAN_SCK);
  754.       output_low(EXT_CAN_SCK);
  755.    }
  756.    for (i=0;i<8;i++) {
  757.       shift_left(&data,1,input(EXT_CAN_SO));
  758.       output_high(EXT_CAN_SCK);
  759.       output_low(EXT_CAN_SCK);
  760.    }
  761.    for (i=0;i<8;i++) {
  762.       output_high(EXT_CAN_SCK);
  763.       output_low(EXT_CAN_SCK);
  764.    }
  765.  
  766.    output_high(EXT_CAN_CS);
  767.  
  768.    return(data);
  769. }*/
  770.  
  771. /////////////////////////////////////////////////////
  772. ////////////////////////////////////  Esta es por hardware //////////////////////////////////
  773. int mcp2510_status(void) {
  774.    int data;
  775.  
  776.    
  777.    output_low(EXT_CAN_CS);   //podriamos hacer algo par comrpbar error, si la 2a lectura!=1a lectura
  778.    spi_write(0xA0);
  779.    spi_read(data);
  780.    spi_read();
  781.    output_high(EXT_CAN_CS);
  782.  
  783. }
  784.  
  785.  
  786. ////////////////////////////////////////////////////
  787.  
  788. /*
  789. void mcp2510_write(int address, int data) { //////////////////// por software////////////////////////////
  790.    int command[3];
  791.    int i;
  792.  
  793.    command[2]=0x02;
  794.    command[1]=address;
  795.    command[0]=data;
  796.  
  797.    output_low(EXT_CAN_CS);
  798.  
  799.    for (i=0;i<24;i++) {
  800.       output_bit(EXT_CAN_SI, shift_left(&command[0],3,0));
  801.       output_high(EXT_CAN_SCK);
  802.       output_low(EXT_CAN_SCK);
  803.    }
  804.  
  805.    output_high(EXT_CAN_CS);
  806. } */
  807.  
  808. ///////////////////////////////////////////////////////////////////////
  809.  
  810. ////////////////////////////////////  Esta es por hardware //////////////////////////////////
  811. void mcp2510_write(int address, int data) {
  812.  
  813.  
  814.  
  815.    output_low(EXT_CAN_CS);
  816.    spi_write(0x02);           //
  817.    spi_write(address);        //estas 2 siempre es spi_write ya que se ha de decir desde el pic la fun.
  818.    spi_write(data);
  819.    output_high(EXT_CAN_CS);
  820.  
  821. }
  822.    
  823.  
  824.  
  825.  
  826. ////////////////////////////////////////////////////////////////////////
  827.  /*
  828.  
  829. void mcp2510_command(int command) {    /////////// por software  //////////////////////////
  830.    int i;
  831.  
  832.    output_low(EXT_CAN_CS);
  833.  
  834.    for (i=0;i<8;i++) {
  835.       output_bit(EXT_CAN_SI, shift_left(&command,1,0));
  836.       output_high(EXT_CAN_SCK);
  837.       output_low(EXT_CAN_SCK);
  838.    }
  839.  
  840.    output_high(EXT_CAN_CS);
  841. }*/
  842.  
  843. ////////////////////////////////////////////// /por Hardware //////////////////////////////
  844. void mcp2510_command(int command){
  845.  
  846. output_low(EXT_CAN_CS);
  847. spi_write(command);
  848. output_high(EXT_CAN_CS);
  849. }
  850.  
  851.  
  852. ////////////////////////////////////////
  853.  
  854.  
  855.  
  856.  
  857. /*
  858. void mcp2510_init(void) {    /////////////   por software  //////////////////////////
  859.    output_high(EXT_CAN_CS);
  860.    output_low(EXT_CAN_SCK);
  861.  
  862.    #ifdef EXT_CAN_TX0RTS
  863.     output_high(EXT_CAN_TX0RTS);
  864.    #endif
  865.    #ifdef EXT_CAN_TX1RTS
  866.     output_high(EXT_CAN_TX1RTS);
  867.    #endif
  868.    #ifdef EXT_CAN_TX2RTS
  869.     output_high(EXT_CAN_TX2RTS);
  870.    #endif
  871.  
  872.   #ifdef EXT_CAN_TX0RTS
  873.    output_high(EXT_CAN_RESET);
  874.    output_low(EXT_CAN_RESET);
  875.    output_high(EXT_CAN_RESET);
  876.    delay_ms(5);
  877.   #endif
  878.  
  879.    mcp2510_command(0xC0);   //reset
  880.    delay_ms(5);
  881. }   */
  882.  
  883.  
  884. /////////////////////////////////////////////////////////////////
  885.  
  886. /////////////////////////////// por harware  ////////////////////////////////////
  887. void mcp2510_init(void) {
  888.    output_high(EXT_CAN_CS);
  889.  
  890.  
  891.    #ifdef EXT_CAN_TX0RTS
  892.    // output_high(EXT_CAN_TX0RTS);
  893.    spi_write(); orden de escribir
  894.    #endif
  895.    #ifdef EXT_CAN_TX1RTS
  896.     output_high(EXT_CAN_TX1RTS);
  897.    #endif
  898.    #ifdef EXT_CAN_TX2RTS
  899.     output_high(EXT_CAN_TX2RTS);
  900.    #endif
  901.  
  902.   #ifdef EXT_CAN_TX0RTS
  903.    output_high(EXT_CAN_RESET);
  904.    output_low(EXT_CAN_RESET);
  905.    output_high(EXT_CAN_RESET);
  906.    delay_ms(5);
  907.   #endif
  908.  
  909.    mcp2510_command(0xC0);   //reset
  910.    delay_ms(5);
  911. }
  912. /////////////////////////////////////////////////////////////////
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Diciembre de 2009, 16:42:13
Me parece que tu proble surge de usar Use_Fast_IO ()

en lugar de Standard_IO ().

Sugiero que hagas ese cambio primero y es posible que no tengas problemas despues.

No encuentro donde configuras los puertos para usar Fast_IO, y esa puede ser la causa de tus problemas.

Standard_IO () configura en forma automatica los puertos, y eso te saca problemas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Diciembre de 2009, 16:58:55
Definitivamente ese es tu problema...
En esta linea:
Código: C
  1. #define CAN_DO_DEBUG TRUE
Estas declarando que utilizaras el port serie del micro para hacer debug del programa a traves del puerto serie.
Eso configura la velocidad y otros datos y entre ellos, usa el pin C7 como pin de recepcion RX del puerto serie, definido para la USART.

Ese pin a su vez es SDO del bus SPI.
Como la declaracion del puerto serie es posterior a la del bus SPI, prevalece esta ultima.

Eso te anula el SPI y no transmite un solo bit porque el pin es de entrada ahora!!!

Entre las opciones tienes:
:mrgreen: :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Suky en 08 de Diciembre de 2009, 17:14:32
Pero haciendo
Código: C
  1. #define CAN_DO_DEBUG FALSE

soluciona el problema :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Diciembre de 2009, 17:24:43
NI (mezcla de No con sI).
Aun asi no esta declarando las salidas o entradas necesarias, por eso insisto en que retorne a Standard_IO().
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Suky en 08 de Diciembre de 2009, 17:28:05
NI (mezcla de No con sI).
Aun asi no esta declarando las salidas o entradas necesarias, por eso insisto en que retorne a Standard_IO().
A... Si, si! Eso también tiene que solucionarlo. Y en el caso que quiera usar debug puede usar USART por software.


Saludos!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 09 de Diciembre de 2009, 10:54:54
buenas!
hombre, el tema violencia casi que lo descarto :D
Volbiendo a las andadas: he cambiado a probar por soft. Si pruebo por soft, tal como decis, he puesto  la linea
Código: C
  1. #use spi  (MASTER,BITS=32,FORCE_SW)
sin decir que patillas uso, porque para eso ya esta el can-mcp2551.c
( que por cierto, he probado cambiar a las patillas de mi pic, y sin cambiar tambien). Cuando funciona por soft pues, se halla el mismo problema ( tambien he cambiado opciones como #define CAN_DO_DEBUG TRUE y #define CAN_DO_DEBUG FALSE).

Mi pic no se inmuta si es por SW o por HW ( eso si , el cambio de patillas se hace efectivo). Persiste el problema en mi SCK. Parecen interferencias, pero son ya unas cuantas soldaduras para mejorar circuito, y siguen ahí... no se me ocurre que hacer
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Suky en 09 de Diciembre de 2009, 11:40:47
La definición del SPI tienes que hacerla así:

Código: C
  1. //IO pins connected to MCP2510
  2. #ifndef EXT_CAN_CS
  3.   #define EXT_CAN_CS   PIN_A5
  4.   #define EXT_CAN_SI   PIN_B0
  5.   #define EXT_CAN_SO   PIN_C7
  6.   #define EXT_CAN_SCK  PIN_B1
  7. #endif
  8.  
  9. #use spi(MASTER,CLK=EXT_CAN_SCK, DO=EXT_CAN_SO, DI=EXT_CAN_SI, BITS=8, MODE=3, FORCE_SW)

Si no, no se sabe que pines se utiliza. El modo no se si es el correcto para la aplicación, eso revisar.


Saludos!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 09 de Diciembre de 2009, 15:05:26

Hola!
Bueno no era un problema de mi libreria hardware, simplemente es que no sabia leer el osciloscopio digital.Aprendemos con el analogico y luego el digital... pues tiene sus cosas. Al ver la grafica, el osciloscopio ( digital) va muestreando, y en "in time" se solapan las señales. Eso pasa con los analogicos. Pero con el digital existe una teclita ( una teclita !!!) que hace que se muestre el primer muestreo ( o la primera tanda), asi no se ven solapada la señal. Es decir, al menos yo, en un analogico no sabria ver que señal me muestra el osciloscopio.

Ahora me queda averiguar si ese seguido de unos y ceros ( el frame) se corresponde a lo que espero ver en un extended frame de CAN ( lo que sale en el datasheet del mcp), que a pesar de disfrutar del digital, sigue siendo algo complicadillo de ver.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: sergio_silva en 16 de Diciembre de 2009, 20:29:27
Hola!

Finalmente terminei lo codigo del PIC que recibe da CAN-BUS e comunica com el PC ( el terminal).

Código: [Seleccionar]

#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 BROWNOUT               //Reset when brownout detected   
#FUSES BORV21                 //Brownout reset at 2.1V 
#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 NOIESO                   //Internal External Switch Over mode enabled 
#FUSES FCMEN                 //Fail-safe clock monitor enabled 
//#FUSES PBADEN                 //PORTB pins are configured as analog input channels on RESET 
#FUSES BBSIZ1K               //1K words Boot Block size 
#FUSES NOWRTC                 //configuration not registers write protected 
#FUSES NOWRTB                 //Boot block not write protected 
#FUSES NOEBTR                 //Memory not protected from table reads 
#FUSES NOEBTRB               //Boot block not protected from table reads 
#FUSES NOCPB                 //No Boot Block code protection 
#FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation 
//#FUSES MCLR                   //Master Clear pin enabled 
#FUSES NOXINST               //Extended set extension and Indexed Addressing mode disabled (Legacy mode) 
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)

#include "can-18F4580.c"

#define PIC_ID 25//identificação deste PIC

void main()
{

    //recv message
    struct rx_stat rxstat;
    int32 rx_id;
    int in_data[8];
    int rx_len;
   
    int data = 9;
    int out_data[8];
    int i = 0;
    int8 buffer[8];
   
    //clear recv buffer
    for(i=0;i<8;i++)
    {
    in_data[i]=0;
    }

    can_init();
    //can_set_mode(CAN_OP_LISTEN);
   
    while(TRUE)
    {
   
        // mensagem recebida
        if ( can_kbhit() )
        {       
           if(can_getd(rx_id, &in_data[0], rx_len, rxstat))   //se existem dados no buffer in_data, guarda os dados recebidos nas variáveis
           {
              if(rx_id == PIC_ID)  // Se a mensagem é para este PIC
              {
                 data =~ (in_data[0]);                 
                 if(bit_test(data, 4))
                    printf("Botão 1 está OFF.\n");
                 if(bit_test(data, 5))
                    printf("Botão 1 está ON.\n");
                 if(bit_test(data, 6))
                    printf("Botão 2 está OFF.\n");
                 if(bit_test(data, 7))
                    printf("Botão 2 está ON.\n");               
              }
           }
        }//fim do tratamento da mensagem recebida
         
        buffer[0] = getc();
        if(buffer[0] == "0"  )//liga Led 1
        {
           out_data[0] = 0;
           can_putd(26, &out_data[0], 1, 1, 1, 0);
        }
        if(buffer[0] == "1" )//desliga Led 1
        {
           out_data[0] = 1;
           can_putd(26, &out_data[0], 1, 1, 1, 0);
        }
        if(buffer[0] == "2")//liga Led 2
        {
           out_data[0] = 2;
           can_putd(26, &out_data[0], 1, 1, 1, 0);                 
        }
        if(buffer[0] == "3")//desliga Led 2
        {
           out_data[0] = 3;
           can_putd(26, &out_data[0], 1, 1, 1, 0);
        }           
    }
}

Eu quería que cuándo no PC alguien enviar una instrucción para ligar / desligar los leds, el PIC tivesse una funcion qué eran chamada automáticamente, como las interrupciones, pero en mi codigo eu tenho la funcion -  buffer[0] = getc(); - dentro del ciclo while(TRUE).

Saludos, Sérgio Silva
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 18 de Diciembre de 2009, 13:13:50
Buenas!
Llevo ya algunos post, asi que seguramente os será familiar mi circuito. Pretendo comunicar mi PIC18F4550 con su CAN Controller MCP2510, y a su vez éste con el Transeiver MCP2551. Modifiqué la librería can-mcp2510.c/.h para resolverla por hardware (la de CCS es por soft).
De ahí atestiguo que existe comunicación del PIC al Controller, via SPI. Pero... mi gozo en un pozo, ahí termina todo.

 Por las patillas Tx,Rx del controller no hay nada, asi que por CAN_H y CAN_L lo único que puedo ver son alrededor de 3 V permantes, o sea, estado recesivo, que no pincha ni corta el sistema. Bien, dado que tanto el pic como el controller tienen cristal de 20 Mhz (ambos funcionan correctamente, es decir, hay señal de reloj de 20 Mhz), SPI envia correctamente datos por SDO ( del PIC) a SI del controller, no entiendo por que no recibe señal.
Entonces mis preguntas son:
1) Por qué?!!!!
2) Si el medio no está accesible ( no he programado nada a propósito para que controle el sistema), qué situación es la que lo provoca?
3) Mi resistencia de terminacion ( entre CAN_H y CAN_L) es de 56 Ohmios, puede provocar que el controler no envie nada al transceiver? ¿ Influye un valor tan bajo?
4)Y si es asi, en base a que debo poner un valor u otro? ( se que guarda relacion con velocidad de transmision, que la he dejado a 125Kbps).

Pongo mi main(), que en principio el programa solo quiere enviar una trama sin tener en cuenta si está ocupado el bus ( no lo está- o no debería- porqué no hay circuito de recepción).
Código: C
  1. #include <18F4550.h>
  2. #include <stdlib.h>
  3. #fuses HS,NOPROTECT,NOLVP,NOWDT,XTPLL,PLL5,NOPROTECT,USBDIV,CPUDIV2
  4. //#fuses HS,NOPROTECT,NOLVP,NOWDT,NOPROTECT,USBDIV,CPUDIV2
  5. #use delay(clock=48000000)
  6. #include <spi-can-mcp2510.c>
  7. #define CAN_DO_DEBUG TRUE
  8. #define Set_125K_Baud TRUE
  9. #byte   porta = 0xf80
  10. #byte   portb = 0xf81
  11. #byte   portc = 0xf82
  12. #byte   portd = 0xf83
  13. #byte   porte = 0xf84
  14. #byte   t1con = 0xfcd
  15. #byte   latd = 0xf8c
  16. #byte   adcon0 = 0xfc2
  17. #byte   adcon1 = 0xfc1
  18. #byte   adcon2 = 0xfc0
  19. #byte   adresl = 0xfc3
  20. #byte   adresh = 0xfc4
  21. #use fast_io (D)
  22. #byte PORTD= 0XF83
  23.  
  24. void main() {
  25.    struct rx_stat rxstat;
  26.    int32 rx_id;
  27.    int buffer[8];
  28.    int i,rx_len;
  29.  
  30.    set_tris_d(0x01);
  31.    setup_spi(SPI_MASTER | SPI_H_TO_L|spi_clk_div_4);
  32.    rx_id=0x01;
  33.    buffer[0]=0x08;
  34.  
  35.    
  36.    can_init();
  37.    enable_interrupts(GLOBAL);
  38.    can_putd(0x01,&buffer[0],8,3,TRUE,TRUE);
  39.  
  40. while(TRUE){
  41.  
  42.       output_high (pin_d1);
  43.  
  44.       if ( can_tbe()){
  45.           can_putd(0x01,&buffer[0],8,1,TRUE,0);
  46.        }
  47.    }
  48. }
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Diciembre de 2009, 14:49:34
Vamos por partes, como dijo Jack...

Has probado entre CanH y CanL SIN la resistencia de fin de linea??
Porque pones 56 Ohm si el valor de la resistencia debe ser de 120 Ohm??

Prueba ambas cosas y luego comentas..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Diciembre de 2009, 14:58:02
Ahora cortemos a la altura del ombligo, hundiendo el bisturi!!

La resistencia que debes cambiar, segun la velocidad del Bus, es la del pin RS del MCP2551, que por lo visto es muuuyyy alta, de 2,2 k la que pusiste.
Prueba alli con un valor entre 10 a 50 Ohm... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 19 de Diciembre de 2009, 11:47:43
Bueno, MGSOFT, asi como dices, comenzaré rajando y destripando el problema. :D El valor de resistencia que puse, creía que era un valor estándar.

Probaré lo dicho y os cometo ;)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 21 de Diciembre de 2009, 15:02:58
uhmm...todo sigue como lo dejé . De todos modos si habia que cambiar esos valores de r no es tiempo perdido tampoco. Ahora tengo una cuestión. Segun datasheeet de MCP2510,

(http://img685.imageshack.us/img685/5281/dibujotw.jpg)

ese bit de registro del mcp ha de estar a 1 para indicar que está libre de enviar mensajes. Si vamos a CCS, la función que determina esa misma funcion ( valga la redundancia) es can_tbe(). Bien, nos vamos hacia esa función, y sabemos que debería haber un bit llamado TXBnCTRL.TXREQ  ( o lo mas parecido) para poner a 1 en alguna ocasión.  En can-mcp.h vemos esto :
Código: C
  1. struct txbNctrl_struct {
  2.    int  txpri:2;   //0:1   //transmit priority bits
  3.    int1 void2; //2
  4.    int1 txreq;   //3   //transmit request status (clear to request message abort)
  5.    int1 txerr;   //4   //transmission error detected
  6.    int1 mloa;   //5   //message lost arbitration
  7.    int1 abtf;   //6   //message was aborted / or transmitted succesfully
  8.    int1 void7;
Bieen.. se refleja una parte del programa donde ha de aparecer ese registro. Teniendo en cuenta que yo ( como mucha gente supongo) no defino los pines físicos ( a pesar de haber modificado la librería para su uso en HW) de esta parte del .c :

Código: C
  1. #ifndef EXT_CAN_CS
  2.    //#define EXT_CAN_CS   PIN_B1 //por defecto estos
  3.    //#define EXT_CAN_SI   PIN_C1
  4.    //#define EXT_CAN_SO   PIN_C0
  5.    //#define EXT_CAN_SCK  PIN_C3
  6.  
  7.    // cambio para usar en PIC18F4550 modo HW
  8.    #define EXT_CAN_CS   PIN_A5
  9.    #define EXT_CAN_SI   PIN_B0
  10.    #define EXT_CAN_SO   PIN_C7
  11.    #define EXT_CAN_SCK  PIN_B1
  12.  
  13. //   [b]#define EXT_CAN_RESET   PIN_B5 //CCS library does not use this pin by default
  14. //   #define EXT_CAN_TX0RTS  PIN_C4 //CCS library does not use this pin by default
  15. //   #define EXT_CAN_TX1RTS  PIN_B4 //CCS library does not use this pin by default
  16. //   #define EXT_CAN_TX2RTS  PIN_C2 //CCS library does not use this pin by default[/b]
  17. #endif
Quiere decir que solo actuará de forma SW en la librería dada por CCS , pero en que momento lo  hace ? Es decir, como sabe CCS ( la liberia ) que relamente no hay nada en el buffer. Estoy pensando que quizas vayan por ahi los tiros, que en ningun momento se le diga desde can librería que TXBnCTRL.TXREQ  es en efecto 1.
La velocidad también podría ser, pero me ha basado en los cálculos del programa ofrecido por aqui, asi que descarto que ese sea el problema...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Diciembre de 2009, 09:08:50
Creo que te equivocas, Can_TBE() solo verifica si el MCP2515 termino de transmitir.
La funcion que realiza la transmicion es CAN_PUTD()... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 23 de Diciembre de 2009, 09:27:28
hola!
si si es cierto, pero para escribir, primero has de poder, y eso es lo que queria ver, si mi no escritura reflejada en los buffers del MCP es porque no le deja escribir. Ahora estoy probando escribir datos a algun buffer de r/w del controller a ver si me los lee después.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Diciembre de 2009, 09:55:00
Puedes subir todas tus librerias actuales y programas que estas utilizando??
A ver si podemos ayudarte a depurarlos...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 23 de Diciembre de 2009, 15:07:48
ok vamos a ver
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 28 de Diciembre de 2009, 12:20:55
enviaré respuesta en 3 o 4 mensajes
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 28 de Diciembre de 2009, 12:23:44
///////////////////////1r mensaje////////////////////////////////////////////

bueno disculpad el retraso, he ido haciendo otraspruebas fallidas...en fin uno se cansa de morder polvo!
Bueno hay librerías que uso pero que no modifico en abslouto, trate de ponerlas todas y se excedia en gran mesura el limite establecido, asi que las que no use, simplemente las enumeraré y sólo escribiré las que si modifico. Ahí va, tb comento lo que hago en cada uan de ellas. He de decir que para hacerla prueba "tonta" leo por SO ( osciloscopio) y no devuebe nada... ¿ no sabe contestar el pic o no envio bien las ordenes?

1) El main, el principal.
En el main, la única linea que "es importante" es la referente a la construcción de un frame de CAN y su posterior envio. Eso me falla, ya que no veo absolutamente nada por can high ni can low, asi que lo que se ve antes de eso, son simples pruebas que deberian ver donde falla el asunto. Es decir, trato de escribir por SPI ( son en paquetes de 3) lo siguiente :
1. escribir :implica, por SPI orden escribir, escribir direccion y escribir data
leer:implica por SPI orden escribir, escribir direccion y automaticamente el MCP contesta por SO ( a SPI PIC). LA 3a escritura es de relleno.
Muestro:
Código: C
  1. #include <18F4550.h>
  2. #include <stdlib.h>
  3. #fuses HS,NOPROTECT,NOLVP,NOWDT,XTPLL,PLL5,NOPROTECT,USBDIV,CPUDIV2
  4. //#fuses HS,NOPROTECT,NOLVP,NOWDT,NOPROTECT,USBDIV,CPUDIV2
  5. #use delay(clock=48000000)
  6. #include <spi-can-mcp2510.c>
  7. //#define CAN_DO_DEBUG TRUE
  8. #define Set_125K_Baud TRUE
  9. #byte   porta = 0xf80
  10. #byte   portb = 0xf81
  11. #byte   portc = 0xf82
  12. #byte   portd = 0xf83
  13. #byte   porte = 0xf84
  14. #byte   t1con = 0xfcd
  15. #byte   latd = 0xf8c
  16. #byte   adcon0 = 0xfc2
  17. #byte   adcon1 = 0xfc1
  18. #byte   adcon2 = 0xfc0
  19. #byte   adresl = 0xfc3
  20. #byte   adresh = 0xfc4
  21. #use fast_io (D)
  22. #byte PORTD= 0XF83
  23.  
  24.  
  25.  
  26. void main() {
  27.    struct rx_stat rxstat;
  28.    int32 rx_id;
  29.    int buffer[8];
  30.    int i,rx_len,lectura;
  31.  
  32.    set_tris_d(0x01);
  33.    setup_spi(SPI_MASTER | SPI_H_TO_L|spi_clk_div_4);
  34.    rx_id=0x01;
  35.    buffer[0]=0x08;
  36.  
  37.  
  38.  //setup_timer_2(T2_DIV_BY_4,79,16); //setup up timer2 to interrupt every 1ms if using //20Mhz clock
  39.    can_init();
  40.   //enable_interrupts(INT_TIMER2);
  41.    enable_interrupts(GLOBAL);
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48. while(TRUE){
  49.  
  50.   output_high(pin_d1);
  51.   //si diera probelmas por SLEEP,moifico aqui el byte para configurar a que no lo esté
  52.   output_low(pin_a5);
  53.   spi_write(0x02);// orden escribir
  54.   spi_write(0x0f); //direc. de mem. donde hacerlo CANCTRL -CAN CONTROL REGISTER //(ADDRESS: XFh)
  55.   spi_write(0x00); // data a escribir
  56.  
  57. // NOTA: tb he hecho esta prueba abajo en data, ya que leyendo datasheet pone cuidado con...
  58.      //spi_write(0xe0) -->he modificado 0x00 por 0xe0 para ver resultado.
  59.  
  60.   output_high(pin_a5);
  61.  
  62.  
  63.  
  64.   //configurar pines recepcion no interrupcion
  65.  
  66.   output_low(pin_a5);
  67.   spi_write(0x02); //orden escribir
  68.   spi_write(0x0c); //direccion de memmoria de BFPCTRL - RXNBF PIN CONTROL AND //STATUS REGISTER
  69.   spi_write(0x20); //data -configuracion de pines-
  70.   output_high(pin_a5);
  71.  
  72.   //configurar pins enviament, cap sense int ( i/o solament)
  73.  
  74.   output_low(pin_a5);
  75.   spi_write(0x02); //orden escribir
  76.   spi_write(0x0c); //direccion de memoria de TXRTSCTRL - TXNRTS PIN CONTROL AND //STATUS REGISTER
  77.   spi_write(0x00); //data -configuracion de pines-
  78.   output_high(pin_a5);
  79.  
  80.  
  81.  
  82.  
  83.  //prueba escribir
  84.   output_low(pin_a5);
  85.   spi_write(0x02);// orden escribir
  86.   spi_write(0x36); //direccion de memoria donde hacerlo
  87.   spi_write(0x07); // data a escribir
  88.   output_high(pin_a5);
  89.  
  90.   //prueba leer
  91.  
  92.   output_low(pin_a5);
  93.   spi_write(0x03);   // orden leer
  94.   spi_write(0x36);  // direccion de memoria donde hacerlo
  95.   spi_write(0x00);//relleno
  96.   output_high(pin_a5);
  97.      /*if ( can_tbe()){
  98.      can_putd(0x01,&buffer[0],8,1,TRUE,0);
  99.      }*/
  100. }
  101. }
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 28 de Diciembre de 2009, 12:34:50
/////  2  /////////////////////

librerías que uso pero no modifico ( las enumero, no la spongo porque no da cabida el mensaje)


a) 18f4550.h
b) stdlib.h
c) stddef.h
d) string.h
e) ctype.h

Y las que si modifico, son can-mcp2510.c y can-mcp2510.h, que cambio como spi-can-mcp2510.c y can-mcp2510.h ( ésta última se modifica, pero no he cambiado nombre).
Razón de modificación : usar SPI lectura y escritura) por Hardware, ya que mi pic dispone de SPI, al menos la lectura/escritura no ha de simularla. Las demas opciones, es decir, uso de interrupciones y registros si son por SW, es decir, no uso los pines específicos del MCP2510 para interrupciones:



2) spi-can-mcp2510.c
Código: C
  1. #include <can-mcp2510.h>
  2.  
  3.  
  4.  
  5. //IO pins connected to MCP2510
  6. #ifndef EXT_CAN_CS
  7.    //#define EXT_CAN_CS   PIN_B1 //por defecto estos
  8.    //#define EXT_CAN_SI   PIN_C1
  9.    //#define EXT_CAN_SO   PIN_C0
  10.    //#define EXT_CAN_SCK  PIN_C3
  11.  
  12.    // cambio para usar en PIC18F4550 modo HW
  13.    #define EXT_CAN_CS   PIN_A5
  14.    #define EXT_CAN_SI   PIN_B0
  15.    #define EXT_CAN_SO   PIN_C7
  16.    #define EXT_CAN_SCK  PIN_B1
  17.  
  18. //   #define EXT_CAN_RESET   PIN_B5 //CCS library does not use this pin by default
  19. //   #define EXT_CAN_TX0RTS  PIN_C4 //CCS library does not use this pin by default
  20. //   #define EXT_CAN_TX1RTS  PIN_B4 //CCS library does not use this pin by default
  21. //   #define EXT_CAN_TX2RTS  PIN_C2 //CCS library does not use this pin by default
  22. #endif
  23.  
  24. #if CAN_DO_DEBUG
  25.  #define can_debug printf
  26. #else
  27.  #define can_debug
  28. #endif
  29.  
  30.  
  31.  
  32.  
  33. int  prescaler;
  34. int1 clkenable;
  35.  
  36.  
  37. ////////////////////////////////////////////////////////////////////////
  38. //
  39. // can_init()
  40. //
  41. // Initializes MCP2510 CAN peripheral.  Sets the RX filter and masks so the
  42. // CAN peripheral will receive all incoming IDs.  Configures both RX buffers
  43. // to only accept valid valid messages (as opposed to all messages, or all
  44. // extended message, or all standard messages).
  45. //
  46. // The constants (CAN_USE_RX_DOUBLE_BUFFER, CAN_ENABLE_DRIVE_HIGH,
  47. // CAN_ENABLE_CAN_CAPTURE, etc) are given a default define in the can-mcp2510.h file.
  48. // These default values can be overwritten in the main code, but most
  49. // applications will be fine with these defaults.
  50. //
  51. //////////////////////////////////////////////////////////////////////////////
  52. void can_init(void) {
  53.    struct struct_RXB0CTRL b_rxb0ctrl;
  54.  
  55.    mcp2510_init();
  56.  
  57.    can_set_mode(CAN_OP_CONFIG);   //must be in config mode before params can be set
  58.    can_set_baud();
  59.  
  60.    b_rxb0ctrl=0;
  61.    b_rxb0ctrl.rxm=CAN_RX_VALID;
  62.    b_rxb0ctrl.bukt=CAN_USE_RX_DOUBLE_BUFFER;
  63.    mcp2510_write(RXB0CTRL, (int)b_rxb0ctrl);
  64.    mcp2510_write(RXB1CTRL, (int)b_rxb0ctrl);
  65.  
  66.    //if you want to configure the TXnRTS pins, do it here.  default is off
  67.  
  68.    can_set_id(RX0MASK, CAN_MASK_ACCEPT_ALL, CAN_USE_EXTENDED_ID);  //set mask 0 (RX BUFFER 0)
  69.    can_set_id(RX0FILTER0, 0, CAN_USE_EXTENDED_ID);  //set filter 0 of mask 0 (RX BUFFER 0)
  70.    can_set_id(RX0FILTER1, 0, CAN_USE_EXTENDED_ID);  //set filter 1 of mask 0 (RX BUFFER 0)
  71.  
  72.    can_set_id(RX1MASK, CAN_MASK_ACCEPT_ALL, CAN_USE_EXTENDED_ID);  //set mask 1 (RX BUFFER 1)
  73.    can_set_id(RX1FILTER2, 0, CAN_USE_EXTENDED_ID);  //set filter 0 of mask 1 (RX BUFFER 1)
  74.    can_set_id(RX1FILTER3, 0, CAN_USE_EXTENDED_ID);  //set filter 1 of mask 1 (RX BUFFER 1)
  75.    can_set_id(RX1FILTER4, 0, CAN_USE_EXTENDED_ID);  //set filter 2 of mask 1 (RX BUFFER 1)
  76.    can_set_id(RX1FILTER5, 0, CAN_USE_EXTENDED_ID);  //set filter 3 of mask 1 (RX BUFFER 1)
  77.  
  78.    can_set_mode(CAN_OP_NORMAL);
  79. }
  80.  
  81. ////////////////////////////////////////////////////////////////////////
  82. //
  83. // can_set_baud()
  84. //
  85. // Configures the baud rate control registers.  All the defines here
  86. // are defaulted in the can-mcp2510.h file.  These defaults can, and
  87. // probably should, be overwritten in the main code.
  88. //
  89. // Current defaults are set to work with CCS's CAN Prototype board and
  90. // Microchip's MCP250xxx CAN Developers Kit if this PIC is running at 20Mhz.
  91. //
  92. ////////////////////////////////////////////////////////////////////////
  93.  
  94. /* void can_set_baud(void) {   // modificada abajo
  95.    struct struct_CNF1 new_CNF1;
  96.    struct struct_CNF2 new_CNF2;
  97.    struct struct_CNF3 new_CNF3;
  98.  
  99.  
  100.    new_CNF1.brp=CAN_BRG_PRESCALAR;
  101.    new_CNF1.sjw=CAN_BRG_SYNCH_JUMP_WIDTH;
  102.  
  103.    new_CNF2.prseg=CAN_BRG_PROPAGATION_TIME;
  104.    new_CNF2.phseg1=CAN_BRG_PHASE_SEGMENT_1;
  105.    new_CNF2.sam=CAN_BRG_SAM;
  106.    new_CNF2.btlmode=CAN_BRG_SEG_2_PHASE_TS;
  107.  
  108.    new_CNF3.phseg2=CAN_BRG_PHASE_SEGMENT_2;
  109.    new_CNF3.wakfil=CAN_BRG_WAKE_FILTER;
  110.  
  111.    mcp2510_write(CNF1, (int)new_CNF1);
  112.    mcp2510_write(CNF2, (int)new_CNF2);
  113.    mcp2510_write(CNF3, (int)new_CNF3);
  114. }*/
  115.  
  116. void can_set_baud(void) {
  117.  /*# ifdef Set_125K_Baud {
  118.      BRGCON1 = 0x01;
  119.      BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 125 KBps
  120.      BRGCON3 = 0x07;      //con reloj a 10 MHz
  121.   }
  122.   #endif */
  123.  
  124.   #ifdef Set_250K_Baud {
  125.      BRGCON1 = 0x00;
  126.      BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 250 KBps
  127.      BRGCON3 = 0x07;      //con reloj a 10 MHz
  128.   }
  129.   #endif
  130.   #ifdef Set_500K_Baud {
  131.      BRGCON1 = 0x00;
  132.      BRGCON2 = 0x92;      //modificado 5/11/07 para usar CAN a 500 KBps
  133.      BRGCON3 = 0x02;      //con reloj a 10 MHz
  134.   }
  135.   #endif
  136. #ifdef Set_125_Baud {
  137.      BRGCON1 = 0x07;
  138.      BRGCON2 = 0xBE;      //modificado 7/12/09 para usar CAN a 125 KBps
  139.      BRGCON3 = 0x07;      //con reloj a 48 MHz
  140.    }
  141.   #endif
  142. /*
  143. #ifdef Set_125_Baud {
  144.      BRGCON1 = 0x03;
  145.      BRGCON2 = 0xBA;      //modificado 7/12/09 para usar CAN a 125 KBps
  146.      BRGCON3 = 0x07;      //con cristal a 20 MHz
  147.    }
  148.  #endif
  149. */
  150.  
  151. }
  152.  
  153. void can_set_mode(CAN_OP_MODE mode) {
  154.    struct struct_CANCTRL old_CANCTRL;
  155.  
  156.    old_CANCTRL=mcp2510_read(CANCTRL);
  157.  
  158.    old_CANCTRL.reqop=mode;
  159.  
  160.    mcp2510_write(CANCTRL, (int)old_CANCTRL);
  161.  
  162.    do {
  163.       old_CANCTRL=mcp2510_read(CANCTRL);
  164.    } while (old_CANCTRL.reqop != mode);
  165.  
  166.  }
  167.  
  168.  
  169. ///// void can_set_clk(CAN_OP_MODE prescaler)//////////////////////////////////
  170. ////////////////////////////////////////////////////////////////////////////////
  171. //void can_set_clk(CAN_OP_MODE prescaler) {   // funcio pel presclaer del clock del MCP
  172. void can_set_clk(){     //cambio capçalera perque no vull que retorni res. Crida funcio i executa.
  173.   struct struct_CANCTRL old_CANCTRL;
  174.  
  175.    old_CANCTRL=mcp2510_read(CANCTRL);
  176.   // old_CANCTRL.clkpre=0; // modifica els 2 bits del registre CANCTRL per posar a 1 el escaler
  177.  
  178.   prescaler=0; // 0  es el valor que vull de presclaer (0b00)
  179.  
  180.    old_CANCTRL.clkpre=prescaler;     //********** falta activació del pin!!!!!!!!!!!!!!!!!!!!!!!!!!
  181.  
  182.    mcp2510_write(CANCTRL, (int)old_CANCTRL);
  183.  
  184.    do {
  185.       old_CANCTRL=mcp2510_read(CANCTRL);
  186.    } while (old_CANCTRL.clkpre != prescaler);
  187. }
  188.  
  189. ////////////////////////////////////////////////////////////////////////////////
  190. //void can_set_clken() {   // activar pin clckout del mcp2510
  191. void can_set_clken(int1 cambiaa){     //cambio capçalera perque no vull que retorni res. Crida funcio i executa.
  192.   struct struct_CANCTRL old_CANCTRL;
  193.  
  194.    old_CANCTRL=mcp2510_read(CANCTRL);
  195.  
  196.   //clkenable=0; // 0  es el valor que vull de presclaer (0b00)
  197.  
  198.    //old_CANCTRL.clken=clkenable;     //********** falta activació del pin!!!!!!!!!!!!!!!!!!!!!!!!!!
  199.      old_CANCTRL.clken=cambiaa;
  200.  
  201.    mcp2510_write(CANCTRL, (int)old_CANCTRL);
  202.  
  203.    do {
  204.       old_CANCTRL=mcp2510_read(CANCTRL);
  205.    } while (old_CANCTRL.clkpre != prescaler);
  206. }
  207.  
  208. ////////////////////////////////////////////////////////////////////////
  209. //
  210. // can_set_id()
  211. //
  212. // Configures the xxxxEIDL, xxxxEIDH, xxxxSIDL and xxxxSIDH registers to
  213. // configure the defined buffer to use the specified ID
  214. //
  215. //   Paramaters:
  216. //     addr - pointer to first byte of ID register, starting with xxxxEIDL.
  217. //            For example, a pointer to RXM1EIDL
  218. //     id - ID to set buffer to
  219. //     ext - Set to TRUE if this buffer uses an extended ID, FALSE if not
  220. //
  221. ////////////////////////////////////////////////////////////////////////
  222. void can_set_id(int addr, int32 id, int1 ext) {
  223.    int converted_id[4];
  224.    int *ptr;
  225.  
  226.    ptr=&converted_id[3];   //3=eidl, 2=eidh, 1=sidl, 0=sidh
  227.  
  228.    if (ext) {  //extended
  229.       //eidl
  230.       *ptr=make8(id,0); //0:7
  231.  
  232.       //eidh
  233.       ptr--;
  234.       *ptr=make8(id,1); //8:15
  235.  
  236.       //sidl
  237.       ptr--;
  238.       *ptr=make8(id,2) & 0x03;   //16:17
  239.       *ptr|=(make8(id,2) << 3) & 0xE0; //18:20
  240.       *ptr|=0x08;
  241.  
  242.  
  243.       //sidh
  244.       ptr--;
  245.       *ptr=((make8(id,2) >> 5) & 0x07 ); //21:23
  246.       *ptr|=((make8(id,3) << 3) & 0xF8);//24:28
  247.    }
  248.    else {   //standard
  249.       //eidl
  250.       *ptr=0;
  251.  
  252.       //eidh
  253.       ptr--;
  254.       *ptr=0;
  255.  
  256.       //sidl
  257.       ptr--;
  258.       *ptr=(make8(id,0) << 5) & 0xE0;
  259.  
  260.       //sidh
  261.       ptr--;
  262.       *ptr=(make8(id,0) >> 3) & 0x1F;
  263.       *ptr|=(make8(id,1) << 5) & 0xE0;
  264.    }
  265.  
  266.    //0=eidl, 1=eidh, 2=sidl, 3=sidh
  267.    mcp2510_write(addr--, converted_id[3]);
  268.    mcp2510_write(addr--, converted_id[2]);
  269.    mcp2510_write(addr--, converted_id[1]);
  270.    mcp2510_write(addr, converted_id[0]);
  271. }
  272.  
  273. ////////////////////////////////////////////////////////////////////////
  274. //
  275. // can_get_id()
  276. //
  277. // Returns the ID of the specified buffer.  (The opposite of can_set_id())
  278. // This is used after receiving a message, to see which ID sent the message.
  279. //
  280. //   Paramaters:
  281. //     addr - pointer to first byte of ID register, starting with xxxxEIDL.
  282. //            For example, a pointer to RXM1EIDL
  283. //     ext - Set to TRUE if this buffer uses an extended ID, FALSE if not
  284. //
  285. //   Returns:
  286. //     The ID of the buffer
  287. //
  288. ////////////////////////////////////////////////////////////////////////
  289. int32 can_get_id(int addr, int1 ext) {
  290.    int32 ret;
  291.    int * ptr;
  292.    int converted_id[4];
  293.  
  294.    ptr=&converted_id[3];   //3=eidl, 2=eidh, 1=sidl, 0=sidh
  295.  
  296.    converted_id[3]=mcp2510_read(addr--);
  297.    converted_id[2]=mcp2510_read(addr--);
  298.    converted_id[1]=mcp2510_read(addr--);
  299.    converted_id[0]=mcp2510_read(addr);
  300.  
  301.    ret=0;
  302.  
  303.  
  304.    if (ext) {
  305.       ret=*ptr;  //eidl
  306.  
  307.       ptr--;     //eidh
  308.       ret|=((int32)*ptr << 8);
  309.  
  310.       ptr--;     //sidl
  311.       ret|=((int32)*ptr & 0x03) << 16;
  312.       ret|=((int32)*ptr & 0xE0) << 13;
  313.  
  314.       ptr--;     //sidh
  315.       ret|=((int32)*ptr << 21);
  316.    }
  317.    else {
  318.       ptr-=2;    //sidl
  319.       ret=((int32)*ptr & 0xE0) >> 5;
  320.  
  321.       ptr--;     //sidh
  322.       ret|=((int32)*ptr << 3);
  323.    }
  324.  
  325.    return(ret);
  326. }
  327.  
  328. ////////////////////////////////////////////////////////////////////////
  329. //
  330. // can_putd()
  331. //
  332. // Puts data on a transmit buffer, at which time the CAN peripheral will
  333. // send when the CAN bus becomes available.
  334. //
  335. //    Paramaters:
  336. //       id - ID to transmit data as
  337. //       data - pointer to data to send
  338. //       len - length of data to send
  339. //       priority - priority of message.  The higher the number, the
  340. //                  sooner the CAN peripheral will send the message.
  341. //                  Numbers 0 through 3 are valid.
  342. //       ext - TRUE to use an extended ID, FALSE if not
  343. //       rtr - TRUE to set the RTR (request) bit in the ID, false if NOT
  344. //
  345. //    Returns:
  346. //       If successful, it will return TRUE
  347. //       If un-successful, will return FALSE
  348. //
  349. ////////////////////////////////////////////////////////////////////////
  350. int1 can_putd(int32 id, int * data, int len, int priority, int1 ext, int1 rtr) {
  351.    int i;
  352.    int port;
  353.  
  354.    int TXRXBaD0;
  355.    int TXBaCTRL;
  356.    int TXRXBaEIDL;
  357.    int TXBaDLC;
  358.  
  359.    struct txbNctrl_struct b_TXBaCTRL;
  360.    struct rxbNdlc_struct b_TXBaDLC;
  361.    struct txbNctrl_struct b_TXB0CTRL, b_TXB1CTRL, b_TXB2CTRL;
  362.  
  363.    b_TXB0CTRL=mcp2510_read(TXB0CTRL);
  364.    b_TXB1CTRL=mcp2510_read(TXB1CTRL);
  365.    b_TXB2CTRL=mcp2510_read(TXB2CTRL);
  366.  
  367.     // find emtpy transmitter
  368.     //map access bank addresses to empty transmitter
  369.    if (!b_TXB0CTRL.txreq) {
  370.       TXRXBaD0=TXB0D0;
  371.       TXBaCTRL=TXB0CTRL;
  372.       TXRXBaEIDL=TXB0EIDL;
  373.       TXBaDLC=TXB0DLC;
  374.       port=0;
  375.    }
  376.    else if (!b_TXB1CTRL.txreq) {
  377.       TXRXBaD0=TXB1D0;
  378.       TXBaCTRL=TXB1CTRL;
  379.       TXRXBaEIDL=TXB1EIDL;
  380.       TXBaDLC=TXB1DLC;
  381.       port=1;
  382.    }
  383.    else if (!b_TXB2CTRL.txreq) {
  384.       TXRXBaD0=TXB2D0;
  385.       TXBaCTRL=TXB2CTRL;
  386.       TXRXBaEIDL=TXB2EIDL;
  387.       TXBaDLC=TXB2DLC;
  388.       port=2;
  389.    }
  390.    else {
  391.       #if CAN_DO_DEBUG
  392.          can_debug("\r\nCAN_PUTD() FAIL: NO OPEN TX BUFFERS\r\n");
  393.       #endif
  394.       return(0);
  395.    }
  396.  
  397.    //set priority.
  398.    b_TXBaCTRL=mcp2510_read(TXBaCTRL);
  399.    b_TXBaCTRL.txpri=priority;
  400.    mcp2510_write(TXBaCTRL, (int)b_TXBaCTRL);
  401.  
  402.    //set tx mask
  403.    can_set_id(TXRXBaEIDL, id, ext);
  404.  
  405.    //set tx data count
  406.    b_TXBaDLC=len;
  407.    b_TXBaDLC.rtr=rtr;
  408.    mcp2510_write(TXBaDLC, (int)b_TXBaDLC);
  409.  
  410.    //write to buffer
  411.     for (i=TXRXBaD0; i<(TXRXBaD0 + len); i++) {
  412.       mcp2510_write(i,*data);
  413.       data++;
  414.     }
  415.  
  416.    //enable transmission
  417.    b_TXBaCTRL=mcp2510_read(TXBaCTRL);
  418.    b_TXBaCTRL.txreq=1;
  419.    mcp2510_write(TXBaCTRL, (int)b_TXBaCTRL);
  420.  
  421.    #if CAN_DO_DEBUG
  422.             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);
  423.             if ((len)&&(!rtr)) {
  424.                data-=len;
  425.                can_debug("  DATA = ");
  426.                for (i=0;i<len;i++) {
  427.                   can_debug("%X ",*data);
  428.                   data++;
  429.                }
  430.                can_debug("\r\n");
  431.             }
  432.    #endif
  433.  
  434.    return(1);
  435. }
  436.  
  437. ////////////////////////////////////////////////////////////////////////
  438. //
  439. // can_getd()
  440. //
  441. // Gets data from a receive buffer, if the data exists
  442. //
  443. //    Returns:
  444. //      id - ID who sent message
  445. //      data - pointer to array of data
  446. //      len - length of received data
  447. //      stat - structure holding some information (such as which buffer
  448. //             recieved it, ext or standard, etc)
  449. //
  450. //    Returns:
  451. //      Function call returns a TRUE if there was data in a RX buffer, FALSE
  452. //      if there was none.
  453. //
  454. ////////////////////////////////////////////////////////////////////////
  455. int1 can_getd(int32 & id, int * data, int & len, struct rx_stat & stat)
  456. {
  457.     int i;
  458.  
  459.    struct struct_RXB0CTRL b_RXB0CTRL;
  460.    struct struct_RXB1CTRL b_RXB1CTRL;
  461.    struct struct_EFLG b_EFLG;
  462.  
  463.    int RXBaDLC;
  464.    struct rxbNdlc_struct b_RXBaDLC;
  465.  
  466.    int TXRXBaSIDL;
  467.    struct struct_TXRXBaSIDL b_TXRXBaSIDL;
  468.  
  469.  
  470.    int RXBaD0;
  471.    struct struct_CANINTF b_CANINTF;
  472.  
  473.    b_CANINTF=mcp2510_read(CANINTF);
  474.  
  475.    b_RXB0CTRL=mcp2510_read(RXB0CTRL);
  476.    b_RXB1CTRL=mcp2510_read(RXB1CTRL);
  477.    b_EFLG=mcp2510_read(EFLG);
  478.  
  479.     if (b_CANINTF.rx0if) {
  480.         stat.buffer=0;
  481.  
  482.         stat.err_ovfl=b_EFLG.rx0ovr;
  483.         b_EFLG.rx0ovr=0;
  484.         mcp2510_write(EFLG, (int)b_EFLG);
  485.  
  486.         if (b_RXB0CTRL.bukt) {
  487.          stat.filthit=b_RXB0CTRL.filhit0;
  488.         }
  489.  
  490.         RXBaDLC=RXB0DLC;
  491.         TXRXBaSIDL=RXB0SIDL;
  492.         RXBaD0=RXB0D0;
  493.     }
  494.     else if (b_CANINTF.rx1if)
  495.     {
  496.         stat.buffer=1;
  497.  
  498.         stat.err_ovfl=b_EFLG.rx1ovr;
  499.         b_EFLG.rx1ovr=0;
  500.         mcp2510_write(EFLG, (int)b_EFLG);
  501.  
  502.  
  503.         stat.filthit=b_RXB1CTRL.filhit0;
  504.         RXBaDLC=RXB1DLC;
  505.         TXRXBaSIDL=RXB1SIDL;
  506.         RXBaD0=RXB1D0;
  507.     }
  508.     else {
  509.       #if CAN_DO_DEBUG
  510.          can_debug("\r\nFAIL ON CAN_GETD(): NO MESSAGE IN BUFFER\r\n");
  511.       #endif
  512.       return (0);
  513.     }
  514.  
  515.    //get count
  516.     b_RXBaDLC=mcp2510_read(RXBaDLC);
  517.     len = b_RXBaDLC.dlc;
  518.     stat.rtr=b_RXBaDLC.rtr;
  519.  
  520.    //was it extended or standard?
  521.     b_TXRXBaSIDL=mcp2510_read(TXRXBaSIDL);
  522.     stat.ext=b_TXRXBaSIDL.ext;
  523.     id=can_get_id(TXRXBaSIDL + 2,stat.ext);
  524.  
  525.    //get data
  526.     for ( i = RXBaD0; i < (RXBaD0 + len); i++ ) {
  527.          *data=mcp2510_read(i);
  528.         data++;
  529.     }
  530.  
  531.     stat.inv=b_CANINTF.merrf;
  532.     if (b_CANINTF.merrf) {
  533.       b_CANINTF.merrf=0;
  534.     }
  535.  
  536.     if (stat.buffer) {
  537.       b_CANINTF.rx1if=0;
  538.     }
  539.     else {
  540.       b_CANINTF.rx0if=0;
  541.     }
  542.     mcp2510_write(CANINTF, (int)b_CANINTF);
  543.  
  544.     #if CAN_DO_DEBUG
  545.        can_debug("\r\nCAN_GETD(): BUFF=%U ID=%LX LEN=%U OVF=%U ", stat.buffer, id, len, stat.err_ovfl);
  546.        can_debug("FILT=%U RTR=%U EXT=%U INV=%U", stat.filthit, stat.rtr, stat.ext, stat.inv);
  547.        if ((len)&&(!stat.rtr)) {
  548.           data-=len;
  549.           can_debug("\r\n    DATA = ");
  550.           for (i=0;i<len;i++) {
  551.             can_debug("%X ",*data);
  552.             data++;
  553.           }
  554.        }
  555.        can_debug("\r\n");
  556.     #endif
  557.  
  558.     return(1);
  559. }
  560.  
  561. ////////////////////////////////////////////////////////////////////////
  562. //
  563. // can_kbhit()
  564. //
  565. // Returns TRUE if there is data in the receive buffers
  566. //
  567. //////////////////////////////////////////////////////////////////////////////
  568. int1 can_kbhit(void) {
  569.    struct struct_CANINTF b_CANINTF;
  570.  
  571.    b_CANINTF=mcp2510_read(CANINTF);
  572.    if (b_CANINTF.rx0if || b_CANINTF.rx1if)
  573.       {return(1);}
  574.  
  575.    return(0);
  576. }
  577.  
  578. ////////////////////////////////////////////////////////////////////////
  579. //
  580. // can_tbe()
  581. //
  582. // Returns TRUE if the transmit buffers are empty and ready to transmit data
  583. //
  584. //////////////////////////////////////////////////////////////////////////////
  585. int1 can_tbe(void) {
  586.    struct txbNctrl_struct b_TXB0CTRL, b_TXB1CTRL, b_TXB2CTRL;
  587.  
  588.    b_TXB0CTRL=mcp2510_read(TXB0CTRL);
  589.    b_TXB1CTRL=mcp2510_read(TXB1CTRL);
  590.    b_TXB2CTRL=mcp2510_read(TXB2CTRL);
  591.  
  592.    if (!b_TXB0CTRL.txreq || !b_TXB1CTRL.txreq || !b_TXB2CTRL.txreq)
  593.       {return(1);}
  594.  
  595.    return(0);
  596. }
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 28 de Diciembre de 2009, 12:35:43
Código: [Seleccionar]
///// 3  /////////




////////////////////////////////////////////////////////////////////////
//
// can_abort()
//
// Aborts all pending tranmissions.
//
//////////////////////////////////////////////////////////////////////////////
void can_abort(void) {
   struct struct_CANCTRL b_CANCTRL;

   b_CANCTRL=mcp2510_read(CANCTRL);
   b_CANCTRL.abat=1;
   mcp2510_write(CANCTRL, (int)b_CANCTRL);

   delay_ms(5);
   b_CANCTRL.abat=0;
   mcp2510_write(CANCTRL, (int)b_CANCTRL);
}




///////////////////
///
//
// SPI CODE. Antes por sofware, cambiando funciones para usar SPI por HW.
//
///
//////////////////

//data clocked in on rising edge
//data driven out on falling edge

/*int mcp2510_read(int address) /////////  Esta es por software ////////
  {
   int command[2];
   int i;
   int data;

   command[1]=0x03;
   command[0]=address;


   output_low(EXT_CAN_CS);

   for (i=0;i<16;i++) {

    output_bit(EXT_CAN_SI, shift_left(&command[0],2,0));
        output_high(EXT_CAN_SCK);
        output_low(EXT_CAN_SCK);
        }
 
       for (i=0;i<8;i++) {
       shift_left(&data,1,input(EXT_CAN_SO));
       output_high(EXT_CAN_SCK);
       output_low(EXT_CAN_SCK);
       }


   output_high(EXT_CAN_CS);

   return(data);
}*/

   /////////////////////////////////////////////////

////////////////////////////////////  Esta es por hardware //////////////////////////////////
int mcp2510_read(int address)
{
//enviar ( o sea escribir) al MCP desde el PIC que se quiere hacer.PIC contesta a la peticion de
//lectura ( y el que hemos dicho) sobre data. Devuelve data
 
 int data;

      output_low(EXT_CAN_CS); // pic espera intsrucción. Primero mira cual es:
      spi_write(0x03);    // escribir instrucción 0x03 es instruccion leer.Va a instruccion leer->
      spi_write(address); //escribir dirección de donde se quiere leer
      spi_read(data);     // escribir dato enviado por el pic
      output_high(EXT_CAN_CS);
      return(data);       //devuelbe lo que queremos leer
}
 
   ////////////////////////////////////////////////




/*
int mcp2510_status(void) { //////////////////// por software////////////////////////////
   int command;
   int data;
   int i;

   command=0xA0;

   output_low(EXT_CAN_CS);

   for (i=0;i<8;i++) {
      output_bit(EXT_CAN_SI, shift_left(&command,1,0));
      output_high(EXT_CAN_SCK);
      output_low(EXT_CAN_SCK);
   }
   for (i=0;i<8;i++) {
      shift_left(&data,1,input(EXT_CAN_SO));
      output_high(EXT_CAN_SCK);
      output_low(EXT_CAN_SCK);
   }
   for (i=0;i<8;i++) {
      output_high(EXT_CAN_SCK);
      output_low(EXT_CAN_SCK);
   }

   output_high(EXT_CAN_CS);

   return(data);
}*/

/////////////////////////////////////////////////////
////////////////////////////////////  Esta es por hardware //////////////////////////////////
int mcp2510_status(void) {
   int data;

   
   output_low(EXT_CAN_CS);   //podriamos hacer algo par comrpbar error, si la 2a lectura!=1a lectura
   spi_write(0xA0);
   spi_read(data);
   spi_read();
   output_high(EXT_CAN_CS);
   return(data);   ///////////
}


////////////////////////////////////////////////////

/*
void mcp2510_write(int address, int data) { //////////////////// por software////////////////////////////
   int command[3];
   int i;

   command[2]=0x02;
   command[1]=address;
   command[0]=data;

   output_low(EXT_CAN_CS);

   for (i=0;i<24;i++) {
      output_bit(EXT_CAN_SI, shift_left(&command[0],3,0));
      output_high(EXT_CAN_SCK);
      output_low(EXT_CAN_SCK);
   }

   output_high(EXT_CAN_CS);
} */

///////////////////////////////////////////////////////////////////////

////////////////////////////////////  Esta es por hardware //////////////////////////////////
void mcp2510_write(int address, int data) {



   output_low(EXT_CAN_CS);
   spi_write(0x02);           //
   spi_write(address);        //estas 2 siempre es spi_write ya que se ha de decir desde el pic la fun.
   spi_write(data);
   output_high(EXT_CAN_CS);

}
   



////////////////////////////////////////////////////////////////////////
 /*

void mcp2510_command(int command) {    /////////// por software  //////////////////////////
   int i;

   output_low(EXT_CAN_CS);

   for (i=0;i<8;i++) {
      output_bit(EXT_CAN_SI, shift_left(&command,1,0));
      output_high(EXT_CAN_SCK);
      output_low(EXT_CAN_SCK);
   }

   output_high(EXT_CAN_CS);
}*/

////////////////////////////////////////////// /por Hardware //////////////////////////////
void mcp2510_command(int command){

output_low(EXT_CAN_CS);
spi_write(command);
output_high(EXT_CAN_CS);
}


////////////////////////////////////////




/*
void mcp2510_init(void) {    /////////////   por software  //////////////////////////
   output_high(EXT_CAN_CS);
   output_low(EXT_CAN_SCK);

   #ifdef EXT_CAN_TX0RTS
    output_high(EXT_CAN_TX0RTS);
   #endif
   #ifdef EXT_CAN_TX1RTS
    output_high(EXT_CAN_TX1RTS);
   #endif
   #ifdef EXT_CAN_TX2RTS
    output_high(EXT_CAN_TX2RTS);
   #endif

  #ifdef EXT_CAN_TX0RTS
   output_high(EXT_CAN_RESET);
   output_low(EXT_CAN_RESET);
   output_high(EXT_CAN_RESET);
   delay_ms(5);
  #endif

   mcp2510_command(0xC0);   //reset
   delay_ms(5);
}   */


/////////////////////////////////////////////////////////////////

/////////////////////////////// por harware  ////////////////////////////////////
void mcp2510_init(void) {
   output_high(EXT_CAN_CS);


   #ifdef EXT_CAN_TX0RTS
    output_high(EXT_CAN_TX0RTS);
   spi_write(); orden de escribir
   #endif
   #ifdef EXT_CAN_TX1RTS
    output_high(EXT_CAN_TX1RTS);
   #endif
   #ifdef EXT_CAN_TX2RTS
    output_high(EXT_CAN_TX2RTS);
   #endif

  #ifdef EXT_CAN_TX0RTS
   output_high(EXT_CAN_RESET);
   output_low(EXT_CAN_RESET);
   output_high(EXT_CAN_RESET);
   delay_ms(5);
  #endif

   mcp2510_command(0xC0);   //reset
   delay_ms(5);
}
/////////////////////////////////////////////////////////////////

3) can-mcp2510.h ( modificada también)
Código: C
  1. /////////////////////////////////////////////////////////////////////////
  2. ////                        can-mcp2510.h                            ////
  3. ////                                                                 ////
  4. //// Prototypes, definitions, defines and macros used for and with   ////
  5. //// the CCS CAN library for the MCP2510 (and compatable) CAN IO     ////
  6. //// expanders.                                                      ////
  7. ////                                                                 ////
  8. //// (see can-mcp2510.c)                                             ////
  9. ////                                                                 ////
  10. /////////////////////////////////////////////////////////////////////////
  11. ////                                                                 ////
  12. //// Version History                                                 ////
  13. ////                                                                 ////
  14. ////  Apr 20 04 - Fixed a compling problem                           ////
  15. ////                                                                 ////
  16. /////////////////////////////////////////////////////////////////////////
  17. ////        (C) Copyright 1996,2003 Custom Computer Services         ////
  18. //// This source code may only be used by licensed users of the CCS  ////
  19. //// C compiler.  This source code may only be distributed to other  ////
  20. //// licensed users of the CCS C compiler.  No other use,            ////
  21. //// reproduction or distribution is permitted without written       ////
  22. //// permission.  Derivative programs created using this software    ////
  23. //// in object code form are not restricted in any way.              ////
  24. /////////////////////////////////////////////////////////////////////////
  25.  
  26. #ifndef __CCS_CANMCP2510_LIB_DEFINES__
  27. #define __CCS_CANMCP2510_LIB_DEFINES__
  28.  
  29. #ifndef CAN_DO_DEBUG
  30.  #define CAN_DO_DEBUG FALSE
  31. #endif
  32.  
  33. #IFNDEF CAN_USE_EXTENDED_ID
  34.   #define CAN_USE_EXTENDED_ID         TRUE
  35. #ENDIF
  36.  
  37. #IFNDEF CAN_BRG_SYNCH_JUMP_WIDTH
  38.   #define CAN_BRG_SYNCH_JUMP_WIDTH  0  //synchronized jump width (def: 1 x Tq)
  39. #ENDIF
  40.  
  41. #IFNDEF CAN_BRG_PRESCALAR
  42.   #define CAN_BRG_PRESCALAR  4  //baud rate generator prescalar (def: 4) ( Tq = (2 x (PRE + 1))/Fosc )
  43. #ENDIF
  44.  
  45. #ifndef CAN_BRG_SEG_2_PHASE_TS
  46.  #define CAN_BRG_SEG_2_PHASE_TS   TRUE //phase segment 2 time select bit (def: freely programmable)
  47. #endif
  48.  
  49. #ifndef CAN_BRG_SAM
  50.  #define CAN_BRG_SAM 0 //sample of the can bus line (def: bus line is sampled 1 times prior to sample point)
  51. #endif
  52.  
  53. #ifndef CAN_BRG_PHASE_SEGMENT_1
  54.  #define CAN_BRG_PHASE_SEGMENT_1  5 //phase segment 1 (def: 6 x Tq)
  55. #endif
  56.  
  57. #ifndef CAN_BRG_PROPAGATION_TIME
  58.  #define CAN_BRG_PROPAGATION_TIME 2 //propagation time select (def: 3 x Tq)
  59. #endif
  60.  
  61. #ifndef CAN_BRG_WAKE_FILTER
  62.  #define CAN_BRG_WAKE_FILTER FALSE   //selects can bus line filter for wake up bit
  63. #endif
  64.  
  65. #ifndef CAN_BRG_PHASE_SEGMENT_2
  66.  #define CAN_BRG_PHASE_SEGMENT_2 5 //phase segment 2 time select (def: 6 x Tq)
  67. #endif
  68.  
  69. #ifndef CAN_USE_RX_DOUBLE_BUFFER
  70.  #define CAN_USE_RX_DOUBLE_BUFFER TRUE   //if buffer 0 overflows, do NOT use buffer 1 to put buffer 0 data
  71. #endif
  72.  
  73. #ifndef CAN_ENABLE_DRIVE_HIGH
  74.  #define CAN_ENABLE_DRIVE_HIGH 0
  75. #endif
  76.  
  77. #ifndef CAN_ENABLE_CAN_CAPTURE
  78.  #define CAN_ENABLE_CAN_CAPTURE 0
  79. #endif
  80.  
  81. enum CAN_OP_MODE {CAN_OP_CONFIG=4, CAN_OP_LISTEN=3, CAN_OP_LOOPBACK=2, CAN_OP_SLEEP=1, CAN_OP_NORMAL=0};
  82.  
  83. //can control
  84. struct struct_CANCTRL {
  85.    int  clkpre:2; //0:1 //clkout pin prescalar
  86.    int1 clken; //2   //clkout pin enable
  87.    int1 void3; //3
  88.    int1 abat;  //4   //abort all pending transmissions
  89.    CAN_OP_MODE reqop:3; //5:7 //request operation mode
  90. };
  91. #define CANCTRL   0x0F  //or 1f, or 2f, or 3f ... or 7f
  92.  
  93. enum CAN_INT_CODE {CAN_INT_RX1=7, CAN_INT_RX0=6, CAN_INT_TX2=5, CAN_INT_TX1=4, CAN_INT_TX0=3, CAN_INT_WAKEUP=2, CAN_INT_ERROR=1, CAN_INT_NO=0};
  94.  
  95. //can status register READ-ONLY
  96. struct struct_CANSTAT {
  97.    int1 void0;   //0
  98.    CAN_INT_CODE icode:3;   //1:3   //interrupt code
  99.    int1 void4;   //4
  100.    CAN_OP_MODE opmode:3;   //5:7   //operation mode status
  101. };
  102. #define CANSTAT 0x0E //or 1e, or 2e ... or 7e
  103.  
  104. //error flag register
  105. struct struct_EFLG {
  106.    int1 ewarn;      //0 //error warning
  107.    int1 rxwar;      //1 //receiver warning
  108.    int1 txwar;      //2 //transmitter warning
  109.    int1 rxep;   //3 //receive error passive flag
  110.    int1 txep;   //4 //transmit error passive flag
  111.    int1 txbo;   //5   //bus off error flag
  112.    int1 rx0ovr;   //6   //receive buffer 0 overflow
  113.    int1 rx1ovr;   //7   //receive buffer 1 overflow
  114. };
  115. #define EFLG   0x2D
  116.  
  117. //interupt enable register
  118. struct struct_CANINTE {
  119.    int1 rx0ie; //0   //receive buffer 0 full interrupt enable
  120.    int1 rx1ie; //1   //receive buffer 1 full interrupt enable
  121.    int1 tx0ie; //2   //transmit buffer 0 embty interrupt enable
  122.    int1 tx1ie; //3   //transmit buffer 1 embty interrupt enable
  123.    int1 tx2ie; //4   //transmit buffer 2 embty interrupt enable
  124.    int1 errie; //5   //error interrupt enable
  125.    int1 wakie; //6   //wakeup interrupt  enable
  126.    int1 merre; //7   //message error interrupt enable
  127. };
  128. #define CANINTE   0x2B
  129.  
  130. //interupt enable register
  131. struct struct_CANINTF {
  132.    int1 rx0if; //0   //receive buffer 0 full interrupt flag
  133.    int1 rx1if; //1   //receive buffer 1 full interrupt flag
  134.    int1 tx0if; //2   //transmit buffer 0 embty interrupt flag
  135.    int1 tx1if; //3   //transmit buffer 1 embty interrupt flag
  136.    int1 tx2if; //4   //transmit buffer 2 embty interrupt flag
  137.    int1 errif; //5   //error interrupt flag
  138.    int1 wakif; //6   //wakeup interrupt flag
  139.    int1 merrf; //7   //message error interrupt flag
  140. };
  141. #define CANINTF   0x2C
  142.  
  143.  
  144. //error counters
  145. #define TEC    0x1C
  146. #define REC    0x1D
  147.  
  148. //baud rate control register 1
  149. struct struct_CNF1 {
  150.    int brp:6;   //0:5   //baud rate prescalar
  151.    int sjw:2;   //6:7   //synchronized jump width
  152. };
  153. #define CNF1   0x2A
  154.  
  155. //baud rate control register 2
  156. struct struct_CNF2 {
  157.    int prseg:3; //0:2 //propagation time select
  158.    int phseg1:3; //3:5 //phase segment 1
  159.    int1 sam; //6 //sample of the can bus line
  160.    int1 btlmode; //7 //phase segment 2 bit time length
  161. };
  162. #define CNF2   0x29
  163.  
  164. //baud rate control register 3
  165. struct struct_CNF3 {
  166.    int phseg2:3;   //0:2   //phase segment 2 time select
  167.    int void543:3;   //3:5
  168.    int1 wakfil;   //6 //selects can bus line filter for wake-up
  169.    int1 void7;   //7
  170. };
  171. #define CNF3   0x28
  172. //can i/o control register
  173.  
  174. //transmit buffer n control register
  175. struct txbNctrl_struct {
  176.    int  txpri:2;   //0:1   //transmit priority bits
  177.    int1 void2; //2
  178.    int1 txreq;   //3   //transmit request status (clear to request message abort)
  179.    int1 txerr;   //4   //transmission error detected
  180.    int1 mloa;   //5   //message lost arbitration
  181.    int1 abtf;   //6   //message was aborted / or transmitted succesfully
  182.    int1 void7;
  183. };
  184. #define TXB0CTRL  0x30
  185. #define TXB1CTRL  0x40
  186. #define TXB2CTRL  0x50
  187.  
  188. //TXnRTS pin control and status register
  189. struct struct_TXRTSCTRL {
  190.    int1 b0rtsm; //0  //1=request message trans, 0=digital
  191.    int1 b1rtsm; //1  //1=request message trans, 0=digital
  192.    int1 b2rtsm; //2  //1=request message trans, 0=digital
  193.    int1 b0rts; //3   //reads as tx2rts when in digital, 0 when in rts
  194.    int1 b1rts; //4   //reads as tx2rts when in digital, 0 when in rts mode
  195.    int1 b2rts; //5  //reads as tx2rts when in digital, 0 when in rts mode
  196.    int  void67:2; //6:7
  197. };
  198. #define TXRTSCTRL 0x0D
  199.  
  200. //transmit buffer n standard identifier
  201. #define TXB0SIDH 0x31
  202. #define TXB0SIDL 0x32
  203. #define TXB1SIDH 0x41
  204. #define TXB1SIDL 0x42
  205. #define TXB2SIDH 0x51
  206. #define TXB2SIDL 0x52
  207.  
  208. //transmit buffer n extended identifier
  209. #define TXB0EIDH 0x33
  210. #define TXB0EIDL 0x34
  211. #define TXB1EIDH 0x43
  212. #define TXB1EIDL 0x44
  213. #define TXB2EIDH 0x53
  214. #define TXB2EIDL 0x54
  215.  
  216. //transmit buffer n data byte m
  217. #define TXB0D0 0x36
  218. #define TXB0D7 0x3D
  219.  
  220. #define TXB1D0 0x46
  221. #define TXB1D7 0x4D
  222.  
  223. #define TXB2D0 0x56
  224. #define TXB2D7 0x5D
  225.  
  226. //transmit buffer n data length
  227. struct txbNdlc_struct {
  228.    int dlc:4;   //0:3
  229.    int void54:2; //4:5
  230.    int1 rtr; //6 //transmission frame remote tranmission
  231.    int1 void7; //7
  232. };
  233. #define TXB0DLC 0x35
  234. #define TXB1DLC 0x45
  235. #define TXB2DLC 0x55
  236.  
  237. //#byte TXBaDLC=0xF65  //txbXdlc when in the access bank
  238.  
  239.  
  240. //transmit error count register
  241. #byte TXERRCNT=0xF76
  242.  
  243.  
  244. enum CAN_RX_MODE {CAN_RX_ALL=3, CAN_RX_EXT=2, CAN_RX_STD=1, CAN_RX_VALID=0};
  245.  
  246. //receive buffer 0 control register
  247. struct struct_RXB0CTRL {
  248.    int1 filhit0;   //0 //filter hit
  249.    int1 bukt1;   //1 //read only copy of bukt bit (used internally by mcp2510)
  250.    int1 bukt;   //2 //rollover enable
  251.    int1 rxrtr;   //3 //receive remote transfer request
  252.    int1 void4;   //4
  253.    CAN_RX_MODE rxm:2;   //5:6 //receiver buffer mode
  254.    int1 void7;   //7 //receive full status
  255. };
  256. #define RXB0CTRL  0x60
  257.  
  258. //receive buffer 1 control register
  259. struct struct_RXB1CTRL {
  260.    int filhit0:3;   //0:2
  261.    int1 rxrtr;   //3 //receive remote transfer request
  262.    int1 void4;   //4
  263.    CAN_RX_MODE rxm:2;   //5:6 //receive buffer mode
  264.    int1 void7;   //7
  265. };
  266. #define RXB1CTRL 0x70
  267.  
  268. //RXnBF pint control and status register
  269. struct struct_BFPCTRL {
  270.    int1  b0bfm; //0   //1=pin is interrupt when message loaded into rxb0, 0=digital
  271.    int1  b1bfm; //1   //1=pin is interrupt when message loaded into rxb1, 0=digital
  272.    int1  b0bfe; //2   //rx0bf pin function enable
  273.    int1  b1bfe; //3   //rx1bf pin function enable
  274.    int1  b0bfs; //4   //rx0bf pin state
  275.    int1  b1bfs; //5   //rx1bf pin state
  276. };
  277.  
  278. //receive buffer n standard identifier
  279. #define   RXB0SIDH  0x61
  280. #define   RXB0SIDL  0x62
  281.  
  282. #define   RXB1SIDH  0x71
  283. #define   RXB1SIDL  0x72
  284.  
  285. //receive buffer n extended identifier
  286. #define   RXB0EID8  0x63
  287. #define   RXB0EID0  0x64
  288.  
  289. #define   RXB1EID8  0x73
  290. #define   RXB1EID0  0x74
  291.  
  292. struct struct_TXRXBaSIDL {
  293.    int void012:3; //0:2
  294.    int1 ext;      //3 //extendid id
  295.    int1 srr;      //4 //substitute remove request bit
  296.    int void567:3; //5:7
  297. };
  298.  
  299. //receive buffer n data length code register
  300. struct rxbNdlc_struct {
  301.    int dlc:4;   //0:3 //data length code
  302.    int1 rb0;   //4   //reserved
  303.    int1 rb1;   //5   //reserved
  304.    int1 rtr;   //6   //receiver remote transmission request bit
  305.    int1 void7;   //7
  306. };
  307. #define   RXB0DLC   0x65
  308. #define   RXB1DLC   0x75
  309.  
  310. //receive buffer n data field byte m register
  311. #define RXB0D0    0x66
  312. #define RXB0D7    0x6D
  313.  
  314. #define RXB1D0    0x76
  315. #define RXB1D7    0x7D
  316.  
  317.  
  318. //receive acceptance filter n standard indifier
  319. #define RXF0SIDH  0x00
  320. #define RXF0SIDL  0x01
  321. #define RXF1SIDH  0x04
  322. #define RXF1SIDL  0x05
  323. #define RXF2SIDH  0x08
  324. #define RXF2SIDL  0x09
  325. #define RXF3SIDH  0x10
  326. #define RXF3SIDL  0x11
  327. #define RXF4SIDH  0x14
  328. #define RXF4SIDL  0x15
  329. #define RXF5SIDH  0x18
  330. #define RXF5SIDL  0x19
  331.  
  332. //receive acceptance filter n extended indifier
  333. #define RXF0EIDH  0x02
  334. #define RXF0EIDL  0x03
  335. #define RXF1EIDH  0x06
  336. #define RXF1EIDL  0x07
  337. #define RXF2EIDH  0x0a
  338. #define RXF2EIDL  0x0b
  339. #define RXF3EIDH  0x12
  340. #define RXF3EIDL  0x13
  341. #define RXF4EIDH  0x16
  342. #define RXF4EIDL  0x17
  343. #define RXF5EIDH  0x1a
  344. #define RXF5EIDL  0x1b
  345.  
  346. //receive acceptance mask n standard identifer mask
  347. #define RXM0SIDH  0x20
  348. #define RXM0SIDL  0x21
  349. #define RXM1SIDH  0x24
  350. #define RXM1SIDL  0x25
  351.  
  352. //receive acceptance mask n extended identifer mask
  353. #define RXM0EIDH  0x22
  354. #define RXM0EIDL  0x23
  355. #define RXM1EIDH  0x26
  356. #define RXM1EIDL  0x27
  357.  
  358. #define RX0MASK       RXM0EIDL   //rxm0eidl
  359. #define RX1MASK       RXM1EIDL   //rxm1eidl
  360. #define RX0FILTER0    RXF0EIDL   //rxf0eidl
  361. #define RX0FILTER1    RXF1EIDL   //rxf1eidl
  362. #define RX1FILTER2    RXF2EIDL   //rxf2eidl
  363. #define RX1FILTER3    RXF3EIDL   //rxf3eidl
  364. #define RX1FILTER4    RXF4EIDL   //rxf4eidl
  365. #define RX1FILTER5    RXF5EIDL   //rxf5eidl
  366. #define RXB0ID        RXB0EIDL   //rxb0eidl
  367. #define RXB1ID        RXB1EIDL   //rxb1eidl
  368. #define TXB0ID        TXB0EIDL   //txb0eidl
  369. #define TXB1ID        TXB1EIDL   //txb1eidl
  370. #define TXB2ID        TXB2EIDL   //tsb2eidl
  371.  
  372. //value to put in mask field to accept all incoming id's
  373. #define CAN_MASK_ACCEPT_ALL   0
  374.  
  375.  
  376. //PROTOTYPES and MACROS
  377.  
  378. struct rx_stat {
  379.    int1 err_ovfl;
  380.    int filthit:3;
  381.    int1 buffer;
  382.    int1 rtr;
  383.    int1 ext;
  384.    int1 inv;
  385. };
  386.  
  387. void  can_init(void);
  388. void  can_set_baud(void);
  389. void  can_set_mode(CAN_OP_MODE mode);
  390. void can_set_id(int addr, int32 id, int1 ext);
  391. int32 can_get_id(int addr, int1 ext);
  392. int   can_putd(int32 id, int * data, int len, int priority, int1 ext, int1 rtr);
  393. int1  can_getd(int32 & id, int * data, int & len, struct rx_stat & stat);
  394.  
  395. void mcp2510_init();
  396. void mcp2510_command(int command);
  397. void mcp2510_write(int address, int data);
  398. int mcp2510_status(void);
  399. int mcp2510_read(int address);
  400.  
  401. #endif
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 28 de Diciembre de 2009, 12:37:16
 /////////  4   /////////////////////

3) can-mcp2510.h ( modificada también)
Código: C
  1. /////////////////////////////////////////////////////////////////////////
  2. ////                        can-mcp2510.h                            ////
  3. ////                                                                 ////
  4. //// Prototypes, definitions, defines and macros used for and with   ////
  5. //// the CCS CAN library for the MCP2510 (and compatable) CAN IO     ////
  6. //// expanders.                                                      ////
  7. ////                                                                 ////
  8. //// (see can-mcp2510.c)                                             ////
  9. ////                                                                 ////
  10. /////////////////////////////////////////////////////////////////////////
  11. ////                                                                 ////
  12. //// Version History                                                 ////
  13. ////                                                                 ////
  14. ////  Apr 20 04 - Fixed a compling problem                           ////
  15. ////                                                                 ////
  16. /////////////////////////////////////////////////////////////////////////
  17. ////        (C) Copyright 1996,2003 Custom Computer Services         ////
  18. //// This source code may only be used by licensed users of the CCS  ////
  19. //// C compiler.  This source code may only be distributed to other  ////
  20. //// licensed users of the CCS C compiler.  No other use,            ////
  21. //// reproduction or distribution is permitted without written       ////
  22. //// permission.  Derivative programs created using this software    ////
  23. //// in object code form are not restricted in any way.              ////
  24. /////////////////////////////////////////////////////////////////////////
  25.  
  26. #ifndef __CCS_CANMCP2510_LIB_DEFINES__
  27. #define __CCS_CANMCP2510_LIB_DEFINES__
  28.  
  29. #ifndef CAN_DO_DEBUG
  30.  #define CAN_DO_DEBUG FALSE
  31. #endif
  32.  
  33. #IFNDEF CAN_USE_EXTENDED_ID
  34.   #define CAN_USE_EXTENDED_ID         TRUE
  35. #ENDIF
  36.  
  37. #IFNDEF CAN_BRG_SYNCH_JUMP_WIDTH
  38.   #define CAN_BRG_SYNCH_JUMP_WIDTH  0  //synchronized jump width (def: 1 x Tq)
  39. #ENDIF
  40.  
  41. #IFNDEF CAN_BRG_PRESCALAR
  42.   #define CAN_BRG_PRESCALAR  4  //baud rate generator prescalar (def: 4) ( Tq = (2 x (PRE + 1))/Fosc )
  43. #ENDIF
  44.  
  45. #ifndef CAN_BRG_SEG_2_PHASE_TS
  46.  #define CAN_BRG_SEG_2_PHASE_TS   TRUE //phase segment 2 time select bit (def: freely programmable)
  47. #endif
  48.  
  49. #ifndef CAN_BRG_SAM
  50.  #define CAN_BRG_SAM 0 //sample of the can bus line (def: bus line is sampled 1 times prior to sample point)
  51. #endif
  52.  
  53. #ifndef CAN_BRG_PHASE_SEGMENT_1
  54.  #define CAN_BRG_PHASE_SEGMENT_1  5 //phase segment 1 (def: 6 x Tq)
  55. #endif
  56.  
  57. #ifndef CAN_BRG_PROPAGATION_TIME
  58.  #define CAN_BRG_PROPAGATION_TIME 2 //propagation time select (def: 3 x Tq)
  59. #endif
  60.  
  61. #ifndef CAN_BRG_WAKE_FILTER
  62.  #define CAN_BRG_WAKE_FILTER FALSE   //selects can bus line filter for wake up bit
  63. #endif
  64.  
  65. #ifndef CAN_BRG_PHASE_SEGMENT_2
  66.  #define CAN_BRG_PHASE_SEGMENT_2 5 //phase segment 2 time select (def: 6 x Tq)
  67. #endif
  68.  
  69. #ifndef CAN_USE_RX_DOUBLE_BUFFER
  70.  #define CAN_USE_RX_DOUBLE_BUFFER TRUE   //if buffer 0 overflows, do NOT use buffer 1 to put buffer 0 data
  71. #endif
  72.  
  73. #ifndef CAN_ENABLE_DRIVE_HIGH
  74.  #define CAN_ENABLE_DRIVE_HIGH 0
  75. #endif
  76.  
  77. #ifndef CAN_ENABLE_CAN_CAPTURE
  78.  #define CAN_ENABLE_CAN_CAPTURE 0
  79. #endif
  80.  
  81. enum CAN_OP_MODE {CAN_OP_CONFIG=4, CAN_OP_LISTEN=3, CAN_OP_LOOPBACK=2, CAN_OP_SLEEP=1, CAN_OP_NORMAL=0};
  82.  
  83. //can control
  84. struct struct_CANCTRL {
  85.    int  clkpre:2; //0:1 //clkout pin prescalar
  86.    int1 clken; //2   //clkout pin enable
  87.    int1 void3; //3
  88.    int1 abat;  //4   //abort all pending transmissions
  89.    CAN_OP_MODE reqop:3; //5:7 //request operation mode
  90. };
  91. #define CANCTRL   0x0F  //or 1f, or 2f, or 3f ... or 7f
  92.  
  93. enum CAN_INT_CODE {CAN_INT_RX1=7, CAN_INT_RX0=6, CAN_INT_TX2=5, CAN_INT_TX1=4, CAN_INT_TX0=3, CAN_INT_WAKEUP=2, CAN_INT_ERROR=1, CAN_INT_NO=0};
  94.  
  95. //can status register READ-ONLY
  96. struct struct_CANSTAT {
  97.    int1 void0;   //0
  98.    CAN_INT_CODE icode:3;   //1:3   //interrupt code
  99.    int1 void4;   //4
  100.    CAN_OP_MODE opmode:3;   //5:7   //operation mode status
  101. };
  102. #define CANSTAT 0x0E //or 1e, or 2e ... or 7e
  103.  
  104. //error flag register
  105. struct struct_EFLG {
  106.    int1 ewarn;      //0 //error warning
  107.    int1 rxwar;      //1 //receiver warning
  108.    int1 txwar;      //2 //transmitter warning
  109.    int1 rxep;   //3 //receive error passive flag
  110.    int1 txep;   //4 //transmit error passive flag
  111.    int1 txbo;   //5   //bus off error flag
  112.    int1 rx0ovr;   //6   //receive buffer 0 overflow
  113.    int1 rx1ovr;   //7   //receive buffer 1 overflow
  114. };
  115. #define EFLG   0x2D
  116.  
  117. //interupt enable register
  118. struct struct_CANINTE {
  119.    int1 rx0ie; //0   //receive buffer 0 full interrupt enable
  120.    int1 rx1ie; //1   //receive buffer 1 full interrupt enable
  121.    int1 tx0ie; //2   //transmit buffer 0 embty interrupt enable
  122.    int1 tx1ie; //3   //transmit buffer 1 embty interrupt enable
  123.    int1 tx2ie; //4   //transmit buffer 2 embty interrupt enable
  124.    int1 errie; //5   //error interrupt enable
  125.    int1 wakie; //6   //wakeup interrupt  enable
  126.    int1 merre; //7   //message error interrupt enable
  127. };
  128. #define CANINTE   0x2B
  129.  
  130. //interupt enable register
  131. struct struct_CANINTF {
  132.    int1 rx0if; //0   //receive buffer 0 full interrupt flag
  133.    int1 rx1if; //1   //receive buffer 1 full interrupt flag
  134.    int1 tx0if; //2   //transmit buffer 0 embty interrupt flag
  135.    int1 tx1if; //3   //transmit buffer 1 embty interrupt flag
  136.    int1 tx2if; //4   //transmit buffer 2 embty interrupt flag
  137.    int1 errif; //5   //error interrupt flag
  138.    int1 wakif; //6   //wakeup interrupt flag
  139.    int1 merrf; //7   //message error interrupt flag
  140. };
  141. #define CANINTF   0x2C
  142.  
  143.  
  144. //error counters
  145. #define TEC    0x1C
  146. #define REC    0x1D
  147.  
  148. //baud rate control register 1
  149. struct struct_CNF1 {
  150.    int brp:6;   //0:5   //baud rate prescalar
  151.    int sjw:2;   //6:7   //synchronized jump width
  152. };
  153. #define CNF1   0x2A
  154.  
  155. //baud rate control register 2
  156. struct struct_CNF2 {
  157.    int prseg:3; //0:2 //propagation time select
  158.    int phseg1:3; //3:5 //phase segment 1
  159.    int1 sam; //6 //sample of the can bus line
  160.    int1 btlmode; //7 //phase segment 2 bit time length
  161. };
  162. #define CNF2   0x29
  163.  
  164. //baud rate control register 3
  165. struct struct_CNF3 {
  166.    int phseg2:3;   //0:2   //phase segment 2 time select
  167.    int void543:3;   //3:5
  168.    int1 wakfil;   //6 //selects can bus line filter for wake-up
  169.    int1 void7;   //7
  170. };
  171. #define CNF3   0x28
  172. //can i/o control register
  173.  
  174. //transmit buffer n control register
  175. struct txbNctrl_struct {
  176.    int  txpri:2;   //0:1   //transmit priority bits
  177.    int1 void2; //2
  178.    int1 txreq;   //3   //transmit request status (clear to request message abort)
  179.    int1 txerr;   //4   //transmission error detected
  180.    int1 mloa;   //5   //message lost arbitration
  181.    int1 abtf;   //6   //message was aborted / or transmitted succesfully
  182.    int1 void7;
  183. };
  184. #define TXB0CTRL  0x30
  185. #define TXB1CTRL  0x40
  186. #define TXB2CTRL  0x50
  187.  
  188. //TXnRTS pin control and status register
  189. struct struct_TXRTSCTRL {
  190.    int1 b0rtsm; //0  //1=request message trans, 0=digital
  191.    int1 b1rtsm; //1  //1=request message trans, 0=digital
  192.    int1 b2rtsm; //2  //1=request message trans, 0=digital
  193.    int1 b0rts; //3   //reads as tx2rts when in digital, 0 when in rts
  194.    int1 b1rts; //4   //reads as tx2rts when in digital, 0 when in rts mode
  195.    int1 b2rts; //5  //reads as tx2rts when in digital, 0 when in rts mode
  196.    int  void67:2; //6:7
  197. };
  198. #define TXRTSCTRL 0x0D
  199.  
  200. //transmit buffer n standard identifier
  201. #define TXB0SIDH 0x31
  202. #define TXB0SIDL 0x32
  203. #define TXB1SIDH 0x41
  204. #define TXB1SIDL 0x42
  205. #define TXB2SIDH 0x51
  206. #define TXB2SIDL 0x52
  207.  
  208. //transmit buffer n extended identifier
  209. #define TXB0EIDH 0x33
  210. #define TXB0EIDL 0x34
  211. #define TXB1EIDH 0x43
  212. #define TXB1EIDL 0x44
  213. #define TXB2EIDH 0x53
  214. #define TXB2EIDL 0x54
  215.  
  216. //transmit buffer n data byte m
  217. #define TXB0D0 0x36
  218. #define TXB0D7 0x3D
  219.  
  220. #define TXB1D0 0x46
  221. #define TXB1D7 0x4D
  222.  
  223. #define TXB2D0 0x56
  224. #define TXB2D7 0x5D
  225.  
  226. //transmit buffer n data length
  227. struct txbNdlc_struct {
  228.    int dlc:4;   //0:3
  229.    int void54:2; //4:5
  230.    int1 rtr; //6 //transmission frame remote tranmission
  231.    int1 void7; //7
  232. };
  233. #define TXB0DLC 0x35
  234. #define TXB1DLC 0x45
  235. #define TXB2DLC 0x55
  236.  
  237. //#byte TXBaDLC=0xF65  //txbXdlc when in the access bank
  238.  
  239.  
  240. //transmit error count register
  241. #byte TXERRCNT=0xF76
  242.  
  243.  
  244. enum CAN_RX_MODE {CAN_RX_ALL=3, CAN_RX_EXT=2, CAN_RX_STD=1, CAN_RX_VALID=0};
  245.  
  246. //receive buffer 0 control register
  247. struct struct_RXB0CTRL {
  248.    int1 filhit0;   //0 //filter hit
  249.    int1 bukt1;   //1 //read only copy of bukt bit (used internally by mcp2510)
  250.    int1 bukt;   //2 //rollover enable
  251.    int1 rxrtr;   //3 //receive remote transfer request
  252.    int1 void4;   //4
  253.    CAN_RX_MODE rxm:2;   //5:6 //receiver buffer mode
  254.    int1 void7;   //7 //receive full status
  255. };
  256. #define RXB0CTRL  0x60
  257.  
  258. //receive buffer 1 control register
  259. struct struct_RXB1CTRL {
  260.    int filhit0:3;   //0:2
  261.    int1 rxrtr;   //3 //receive remote transfer request
  262.    int1 void4;   //4
  263.    CAN_RX_MODE rxm:2;   //5:6 //receive buffer mode
  264.    int1 void7;   //7
  265. };
  266. #define RXB1CTRL 0x70
  267.  
  268. //RXnBF pint control and status register
  269. struct struct_BFPCTRL {
  270.    int1  b0bfm; //0   //1=pin is interrupt when message loaded into rxb0, 0=digital
  271.    int1  b1bfm; //1   //1=pin is interrupt when message loaded into rxb1, 0=digital
  272.    int1  b0bfe; //2   //rx0bf pin function enable
  273.    int1  b1bfe; //3   //rx1bf pin function enable
  274.    int1  b0bfs; //4   //rx0bf pin state
  275.    int1  b1bfs; //5   //rx1bf pin state
  276. };
  277.  
  278. //receive buffer n standard identifier
  279. #define   RXB0SIDH  0x61
  280. #define   RXB0SIDL  0x62
  281.  
  282. #define   RXB1SIDH  0x71
  283. #define   RXB1SIDL  0x72
  284.  
  285. //receive buffer n extended identifier
  286. #define   RXB0EID8  0x63
  287. #define   RXB0EID0  0x64
  288.  
  289. #define   RXB1EID8  0x73
  290. #define   RXB1EID0  0x74
  291.  
  292. struct struct_TXRXBaSIDL {
  293.    int void012:3; //0:2
  294.    int1 ext;      //3 //extendid id
  295.    int1 srr;      //4 //substitute remove request bit
  296.    int void567:3; //5:7
  297. };
  298.  
  299. //receive buffer n data length code register
  300. struct rxbNdlc_struct {
  301.    int dlc:4;   //0:3 //data length code
  302.    int1 rb0;   //4   //reserved
  303.    int1 rb1;   //5   //reserved
  304.    int1 rtr;   //6   //receiver remote transmission request bit
  305.    int1 void7;   //7
  306. };
  307. #define   RXB0DLC   0x65
  308. #define   RXB1DLC   0x75
  309.  
  310. //receive buffer n data field byte m register
  311. #define RXB0D0    0x66
  312. #define RXB0D7    0x6D
  313.  
  314. #define RXB1D0    0x76
  315. #define RXB1D7    0x7D
  316.  
  317.  
  318. //receive acceptance filter n standard indifier
  319. #define RXF0SIDH  0x00
  320. #define RXF0SIDL  0x01
  321. #define RXF1SIDH  0x04
  322. #define RXF1SIDL  0x05
  323. #define RXF2SIDH  0x08
  324. #define RXF2SIDL  0x09
  325. #define RXF3SIDH  0x10
  326. #define RXF3SIDL  0x11
  327. #define RXF4SIDH  0x14
  328. #define RXF4SIDL  0x15
  329. #define RXF5SIDH  0x18
  330. #define RXF5SIDL  0x19
  331.  
  332. //receive acceptance filter n extended indifier
  333. #define RXF0EIDH  0x02
  334. #define RXF0EIDL  0x03
  335. #define RXF1EIDH  0x06
  336. #define RXF1EIDL  0x07
  337. #define RXF2EIDH  0x0a
  338. #define RXF2EIDL  0x0b
  339. #define RXF3EIDH  0x12
  340. #define RXF3EIDL  0x13
  341. #define RXF4EIDH  0x16
  342. #define RXF4EIDL  0x17
  343. #define RXF5EIDH  0x1a
  344. #define RXF5EIDL  0x1b
  345.  
  346. //receive acceptance mask n standard identifer mask
  347. #define RXM0SIDH  0x20
  348. #define RXM0SIDL  0x21
  349. #define RXM1SIDH  0x24
  350. #define RXM1SIDL  0x25
  351.  
  352. //receive acceptance mask n extended identifer mask
  353. #define RXM0EIDH  0x22
  354. #define RXM0EIDL  0x23
  355. #define RXM1EIDH  0x26
  356. #define RXM1EIDL  0x27
  357.  
  358. #define RX0MASK       RXM0EIDL   //rxm0eidl
  359. #define RX1MASK       RXM1EIDL   //rxm1eidl
  360. #define RX0FILTER0    RXF0EIDL   //rxf0eidl
  361. #define RX0FILTER1    RXF1EIDL   //rxf1eidl
  362. #define RX1FILTER2    RXF2EIDL   //rxf2eidl
  363. #define RX1FILTER3    RXF3EIDL   //rxf3eidl
  364. #define RX1FILTER4    RXF4EIDL   //rxf4eidl
  365. #define RX1FILTER5    RXF5EIDL   //rxf5eidl
  366. #define RXB0ID        RXB0EIDL   //rxb0eidl
  367. #define RXB1ID        RXB1EIDL   //rxb1eidl
  368. #define TXB0ID        TXB0EIDL   //txb0eidl
  369. #define TXB1ID        TXB1EIDL   //txb1eidl
  370. #define TXB2ID        TXB2EIDL   //tsb2eidl
  371.  
  372. //value to put in mask field to accept all incoming id's
  373. #define CAN_MASK_ACCEPT_ALL   0
  374.  
  375.  
  376. //PROTOTYPES and MACROS
  377.  
  378. struct rx_stat {
  379.    int1 err_ovfl;
  380.    int filthit:3;
  381.    int1 buffer;
  382.    int1 rtr;
  383.    int1 ext;
  384.    int1 inv;
  385. };
  386.  
  387. void  can_init(void);
  388. void  can_set_baud(void);
  389. void  can_set_mode(CAN_OP_MODE mode);
  390. void can_set_id(int addr, int32 id, int1 ext);
  391. int32 can_get_id(int addr, int1 ext);
  392. int   can_putd(int32 id, int * data, int len, int priority, int1 ext, int1 rtr);
  393. int1  can_getd(int32 & id, int * data, int & len, struct rx_stat & stat);
  394.  
  395. void mcp2510_init();
  396. void mcp2510_command(int command);
  397. void mcp2510_write(int address, int data);
  398. int mcp2510_status(void);
  399. int mcp2510_read(int address);
  400.  
  401. #endif
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Diciembre de 2009, 15:13:04
Te paso el ejecutable despues de hacer algunos cambios en los diferentes archivos, pruebalo en tu hardware y dime como va.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Diciembre de 2009, 17:11:40
Lo has podido probar??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 30 de Diciembre de 2009, 05:11:31
Hola!
Perdona, hoy mismo pruebo y te digo el resultado de ello ( no disponia de programador ayer).
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 30 de Diciembre de 2009, 08:42:30


Buenas, como va todo?
Notificación:prueba fallida. De nuevo por SPO (del modulo CAN) hay algo parecido a una señal, si, de 0.2 voltios... no era mas que ruido, de nuevo.

PD: he leido datsheet, pero no he encontrado nada al respecto, pero esta es mi pergunta pues : los pines TXORTS y demás han de estar fisicamente conectados a masa? O Vdd?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Diciembre de 2009, 09:52:40
Bueno Penguin.
Hora de barajar y dar de nuevo.

Recomendacion asi no terminamos todos con camisa de fuerza:

Luego nos cuentas.
Una vez obtenido resultados de esta forma recien ahi recomiendo empezar a mudar el uso SPI por software a hardware (solo comenta las instrucciones del hardware).

La unica forma de encontrar tu problema es tomarlo por partes, y esta es la unica forma que conozco de hacerlo.

Feliz año nuevo!! :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 31 de Diciembre de 2009, 09:50:56


ok, entiendo lo de cambiar todos los puertos a digitales como
Código: C
  1. #define NO_ANALOGS
  2. SETUP_ADC_PORTS( NO_ANALOGS );
Hecho.
Tambien lo de usar de momento ( y si me va... ya veremos si lo cambio...) por software , usando la librería original.Ok. Pero lo que no capto muy bien es eso de cambiar C7 que es la Rx?
O sea, a ver si me entiendo, para hacer la prueba por soft, ya no uso SPI en HW claro, entonces, cambiar los pines de SI SO por los de Rx Tx en el pic?

Pero si modifiqué para que saliera datos desde SO, por que no harçia lo msimo por entrada de datos por SI ?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Diciembre de 2009, 10:04:49
Si miras en tu esquema, el hecho de usar SPI por hardware implica que ya no podras utilizar la Usart del micro, porque el pin C7 es compartido con el SPI, en ese caso usas uno u otro.
Ahora ya tienes cableado en tu placa ese pin para usarlo en el bus SPI.
El problema que se presenta es que la libreria usa ese pin como puerto serie, por esa razon usan SPI por software y dejan la Usart por hardware, para hacer Debug del programa.
Por eso recomiendo que lo cablees a otro pin y liberes ese pin (C7) para dejarlo como va, de ese modo no toqueteas nuevamente la libreria, y declaras el pin que realmente conectaste al SPI.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Enero de 2010, 10:35:30
Algun avance, Penguin??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 08 de Enero de 2010, 20:02:07
hola

a mi hace un tiempo cuando empece con el can bus un amigo me enseño a averiguar la velocidad con el osciloscopio(no solo para el can bus) pero ahora tengo una duda,si quiero hacer un circuito para un bus can y no tengo los datos de esta red,puedo averiguar la velocidad,pero ¿el protocolo? gracias

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Enero de 2010, 09:19:19
Eso no se contestarlo.
Son varios los protocolos que pueden ser montados sobre CANBUS...
Es dificil saberlo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 09 de Enero de 2010, 09:45:13
Y una ultima pregunta para no molestaros mas,he estado revisando el hilo desde el principio (bueno saltandome alguna pagina) y he visto lo del sniffer usb ¿donde se puede conseguir el codigo y esquema? o sino alguno por rs232 y el software del pc. es por si es libre no empezar a intentar desarrollar uno desde cero cuando ya lo esta  :D muchas gracias

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Enero de 2010, 09:53:09
Dejame organizarme y subire toda esa informacion aqui.
El codigo es de Microchip, asi que solo voy a subir el hex, para evitar lios con ellos, igual en su pagina esta el codigo fuente, para C18.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Kid_Bengala en 10 de Enero de 2010, 12:21:39
Dejame organizarme y subire toda esa informacion aqui.
El codigo es de Microchip, asi que solo voy a subir el hex, para evitar lios con ellos, igual en su pagina esta el codigo fuente, para C18.

Gracias MGLSoft,he encontrado todo en la pagina de microchip,lo unico que no puedo probarlo porque me faltan componentes ¿sabes hasta que nivel se puede configurar la velocidad?he visto que viene 125.000kb pero no me deja configurarlo (no tengo el pic conectado je) gracias

saludos de antonio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Enero de 2010, 12:56:37
Debes conectarlo, luego lo pasas a modo configuracion y pasas a la pestaña de configuracion de velocidad.
Alli puedes seleccionar entre 125, 250, 500 y 1000 Kbps.
Solo lo hace conectado porque en realidad esta pasandole los datos al MCP2515, eso no se puede hacer fuera de linea...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 11 de Enero de 2010, 15:05:17
he cambiado a uso modo sw, y sigue haciendo lo que le parece. Es posible que esté todo el rato en modo sleep?
1) Si es asi, no encuentro el motivo, ya que segun librería de CCS no está determinado en modo "estándar".

2) Por si acaso fuese asi, he cambiado por estas lineas :
Código: C
  1. //modo sleep on? para no
  2.   output_low(pin_b1);
  3.   spi_write(0x02);// orden escribir
  4.   spi_write(0x0f); //direccion de memoria donde hacerlo CANCTRL - CAN CONTROL REGISTER (ADDRESS: XFh)
  5.   spi_write(0xe0); // data a escribir
  6.   output_high(pin_b1);
alguna idea?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Enero de 2010, 15:09:59
Lo que te indique en modo software es utilizar las librerias ORIGINALES de CCS, esto que pones alli es por hardware, salvo que indiques lo contrario.
La idea es ver si tu sistema funciona o no.
Puedes subir un esquematico de tu circuito??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 13 de Enero de 2010, 10:36:03
si, en efecto, eso lo hice por probar simplemente el envio de datos desde el MCP al PIC ( ne respuesat de éste claro) . He podido solucionarlo, aunque el problema de envio de can persiste.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Enero de 2010, 10:53:16
si, en efecto, eso lo hice por probar simplemente el envio de datos desde el MCP al PIC ( ne respuesat de éste claro) . He podido solucionarlo, aunque el problema de envio de can persiste.
O sea que te comunicas con el MCP2515 pero no sale nada desde este hacia el BUS??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 13 de Enero de 2010, 11:48:41


en efecto. bueno es el mcp2510, pero si, tengo comunicación -via spi- entre el pic y el mcp. Pero solo eso, spi... Ahora puedo leer lo que "grabo" en algun registro suyo. Tenia mala configuración de SPI. Sin embargo por h o por B ( usando sw o hw) no consigo enviar nada por la patilla TX al transceiver. Para verificar si el estado es el correcto, hago esto :
Código: C
  1. can_init();
  2.      if (can_tbe()){
  3.      can_putd(0x01,&buffer[0],8,1,TRUE,0);//id,data,no bits,prio,extended,creates
  4.      output_high(pin_d2);
  5.      }

Ese led conectado a ese pin, no enciende. Esto quiere decir que nunca pasa por el if. Viendo la librería miro que pasa con can_tbe(). en can-mcp2510.c se lee esto :
Código: C
  1. int1 can_tbe(void) {
  2.    struct txbNctrl_struct b_TXB0CTRL, b_TXB1CTRL, b_TXB2CTRL;
  3.    b_TXB0CTRL=mcp2510_read(TXB0CTRL);
  4.    b_TXB1CTRL=mcp2510_read(TXB1CTRL);
  5.    b_TXB2CTRL=mcp2510_read(TXB2CTRL);
  6.    if (!b_TXB0CTRL.txreq || !b_TXB1CTRL.txreq || !b_TXB2CTRL.txreq)
  7.       {return(1);}
  8.    return(0);
  9. }
Bien, se lee TXBnCTRL directamente. ¿ Directamente? Si, porque si vamos a can-mcp2510.h, vemos esto otro :
Código: C
  1. #define TXB0CTRL  0x30
  2. #define TXB1CTRL  0x40
  3. #define TXB2CTRL  0x50
que es define los 3 registros como variables, en las direcciones reales ( claro..) del mcp. de hecho en datasheet del mcp podemos verlo :
Código: C
  1. TXBNCTRL Transmit Buffer N Control Register
  2. (ADDRESS: 30h, 40h, 50h)
Se pone en unas variables "modificables" el resultado de la lectura, y se va concretamente al bit especificado "txreq" de cada uno de los 3 buffers de transmision. Si alguno de ellos esta libre para enviar, pone un 1 . Como yo tengo el mcp, es direccion existe. Tengo pensado enviar datos tal como lo pongo, y para verifiar qu no hay nada ( porque no hay ninguna conexión mas a ese pin, solo desde el pic claro). SPi si comunica con mcp, pero por que con CAN no le hace tanta gracia ? Ahora cabe preguntarme por que dice mi MCP que no está preparado para enviar datos fuera ( al transceiver, y desde este al eterior, se entiende).
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Enero de 2010, 12:04:31
Repito:
Sube un esquema de como esta realmente conectado tu circuito, un esquematico aunque sea a mano.
Puede ser de hardware el problema.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 13 de Enero de 2010, 12:15:36
es el mismo que ya subí hace unas semanas. Hice esa prueba que me dijiste,  de cambiar el pin c7 y no resolvio nada, asi que lo dejé todo tal estaba. Voy cambiando el uso entre HW o SW para ver si en algun momento modifiqué mal la libreria normal ( por SW)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Enero de 2010, 15:09:44
Segun me dices, este es tu circuito:

(http://img121.imageshack.us/img121/9200/dibujokuc.jpg)

No es asi??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Enero de 2010, 15:15:18
Entonces ya habras quemado tu MCP2551 , recien me doy cuenta que esta alimentado exactamente al reves.
En el pin VDD debes aplicar +5V y en el pin VSS la masa del circuito o 0VCC, como lo conozcas tu.
La resistencia de 2K2 ohm en el pin RS cambiarla por 10 ohm y la resistencia de fin de linea ponla de 120 ohms.

Luego cuentame como va...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 14 de Enero de 2010, 07:27:43
no no, es un error de esquema. Los pines de alimentación están correctos. Lo que si que es cierto es que el valor de la resiistencia de terminacion deberia ser mas grande. Estoy leyendo que ha de ser 120 ohmios. la tengo hacui la mitad de eso, pero que fórmula o qué parámetros indican el tipo de resistencia de fin de linea a poner? se que depende de la longitud del bus ( 500m, 1Km...) de la velocidad ( que a su vez esta intrisecamente relacionada con la distancia), pero en varios sitios he visto valores diferentes, y he cambiado cerca de tres veces. Eso es lo que estoaba precisamente mirando hace un momento antes de ingreasdr en el foro. Bueno provaré este nuevo valor de resistencia, aunque me suena ya haberlo puesto con anterioridad, ya comentaré la jugada
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Enero de 2010, 07:59:37
Error!!
La resistencia que depende del largo del bus y su velocidad es la que esta conectada al pin RS del MCP2551.
La resistencia de fin de linea sacala o cortala, pero siempre sera de 120 Ohms, porque lo que hace es mantener la impedancia del tramo del bus y evitar el retorno o eco de los mensajes.
Yo tengo aplicaciones donde no la pongo y anda igual.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 14 de Enero de 2010, 08:11:35
uhm... de todos modos, he hecho unos calculillos basandome en el datasheet, para poner ese valor de Rs. Yo quiero que "ande" en slope control, y en el cuadro de tensiones e intensidades de trabajo, veo esto :
Código: C
  1. ---------------------------------------------------------------
  2.                    |                                 |
  3. Slope-control | 10 µA < -IRS < 200 µA   |  0.4 VDD < VRS < 0.6 VDD
  4. ----------------------------------------------------------------

Mi Vdd son entre 4.9 y 5 voltios. Pongo que son 5. Como no se que parámetros fijar, pongo que mi grado de libertad está en la intensidad. Pongo que trabaje a una media de lo que me advierte la tabla, por ejemplo a 100 uA. Pues con la simple ley de ohm veo que obtengo la R de 50 KOhmios.

Uhm..es grande, pero basándome en lo que me dice el datasheet..debería ser buena. Luego tu me dices que ponga una de 10 Ohmios ( creo que alguna vez la hepuesto, aunque no estoy seguro). Eso significa, que teniendo la Vdd que no puedo modificar, de 5 voltios, la intensidad que puede pasar por ahí es de 500 mA. 500 mA es muucho mayor que 200 uA. Qué otra cosa se ha de tener en cuenta? O ...si 10 Ohmios puede estar bien, esa tabla para que es, que significa ese valor de intensidad ( el margen mínimo y máximo)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Enero de 2010, 08:15:41
Haz esta prueba y me dices:
No saques la resistencia RS, solo puenteala por debajo soldando un alambre, de forma tal que quede conectada directo a masa.
Luego prueba a ver como va...
Deberias leer algo en el bus.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 14 de Enero de 2010, 08:27:07

Bueno primero dcir que he errado en el cálculo, no he tenido en cuenta el porcentaje de Vdd, sino el valor absoluto de ésta. Eso dice que el cálculo de la resistencia determinada está en 2 valores, al final me salian 20 y 30 KOhmios.

he probado lo que me has dicho, que es lo mismo que decir que el bus va a High Speed. Bueno, no debería ser en HS teniendo en cuenta que lo quiero controlar a 125 Kbps y es de "clase B". Pero bueno, he probado y  si..he visto algo... he visto más desespero y la nada de nuevo. Me tendré que meter con la madre del chip, pa ver si reacciona con algo...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Enero de 2010, 08:36:46
Probaste de cambiarlo??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 14 de Enero de 2010, 09:00:05
si con todos los valores, 10, 30 k...todos...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Enero de 2010, 09:05:17
Me referia a si probaste de cambiar el mcp2551... :mrgreen:
Antes verifica la tension de alimentacion y el conexionado al bus y al MCP2515..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 14 de Enero de 2010, 09:17:19
ah ! jeje, bueno , he cambiado los demas chips, creiendo que estaban fastidiados...los pics 3 y el can controller 2...asi que por etadística..no va a ser eso...no he conexionado mal ni puenteado...no se. Lo extraño es que mando mensaje can ( solo mando) y por la patilla SO del can controller hay contestacion de algo ( un monton de bits que vete tu a saber lo que es). Pero bueno, me imagino yo que eso es como si le dijese al pic " ey aqui no esta ni el lechero, envia de nuevo" o una trama de error. Vamos, que el sistema no esta fallido al 100 %. Al menos hay un par de amigos que quieren jugar..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jalzueta en 14 de Enero de 2010, 12:23:14
Aquí pueden descargar la memoria de mi proyecto:

memoria pdf (http://dl.getdropbox.com/u/913254/memoria%20sin%20portada.pdf)


Ahí se explica lo necesario sobre la normativa OBD, aunque no viene nada del código del PIC.

PD: Espero que les sea de ayuda, me ha llevado mucho tiempo hacer este proyecto y su memoria.


Hola a todos.

Estoy empezando ahora un proyecto consistente en realizar lecturas y escrituras del CAN-Bus con un PIC. Parece ser que hace cosa de unos 4 meses un miembro del foro colgó una memoria sobre un proyecto que tenía mucho que ver con esto. He intentado acceder a ella a través del link pero ya no se encuentra disponible...
Sería posible que algún miembro que disponga del documento lo volviera a colgar para que pudiera echarle un vistazo.

Muchísimas gracias de antemano.

Un cordial saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 14 de Enero de 2010, 14:48:39

q tal jalzueta..pues no se nada de esa memoria ( al mernos yo) y eso que estoy bastante por aqui.

Anda que si la pudiera catar yo también... seria como uno de esas respuestas a .." que es primero el huevo o la gallina?" o " que hay despues de la muerte?" o " es el espacio finito pero ilimtiado - o al rebes-). Que co ño...seria mejor que todo eso, al menos esa memoria si serviria para algo en la vida! ( en la mia desdelugo)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Enero de 2010, 15:49:29
Aquí pueden descargar la memoria de mi proyecto:

memoria pdf (http://dl.getdropbox.com/u/913254/memoria%20sin%20portada.pdf)


Ahí se explica lo necesario sobre la normativa OBD, aunque no viene nada del código del PIC.

PD: Espero que les sea de ayuda, me ha llevado mucho tiempo hacer este proyecto y su memoria.


Hola a todos.

Estoy empezando ahora un proyecto consistente en realizar lecturas y escrituras del CAN-Bus con un PIC. Parece ser que hace cosa de unos 4 meses un miembro del foro colgó una memoria sobre un proyecto que tenía mucho que ver con esto. He intentado acceder a ella a través del link pero ya no se encuentra disponible...
Sería posible que algún miembro que disponga del documento lo volviera a colgar para que pudiera echarle un vistazo.

Muchísimas gracias de antemano.

Un cordial saludo.

No lo se, prueba de escribirle a Teleko un mensaje personal a ver si el lo saco o si es un server que borra archivos de cierto tiempo sin actividad...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Enero de 2010, 15:11:19
Dejame organizarme y subire toda esa informacion aqui.
El codigo es de Microchip, asi que solo voy a subir el hex, para evitar lios con ellos, igual en su pagina esta el codigo fuente, para C18.

Pongo este esquema para cumplir con mi promesa.

(http://img192.imageshack.us/img192/3473/placausbpic18f4550.jpg)

Es segun el esquema de Microchip parecida (no igual) aunque funciona con su software y firmware original.


Penguin:

Mira este esquema y comparalo con el tuyo, yo encuentro que hay algunas diferencias (no muchas) y que seria muy bueno que usaras los pines de interrupcion y marcadores de bufferes llenos, tanto de recepcion como de transmicion.
Ocuparas mas lineas del PIC18F4550, pero seguramente vas a simplificar tus librerias al utilizarlos.

Espero que sirva...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 22 de Enero de 2010, 15:25:01

pretendo hacer una libreria nueva ya que usar ka que tenia por HW da problemas que nadie sabemos resolver. Bueno lo mas facil es lo tipico, spi_write, spi_read....y paro ahí porque ya con esas me da problemas.
Si miramos datasheet vemos esto :

(http://img693.imageshack.us/img693/6794/dibujospq.jpg)
o sea, para escribir " 3 escrituras" y para leer " escrituras"
que las hago de la siguiente forma( la funciones) :
Código: C
  1. void write_MCP2510(int direccion, int dato){
  2.  
  3.    output_low(PIN_A5);
  4.    spi_write(0x02);     // orden esribir
  5.    spi_write(direccion);     // direccion
  6.    spi_write(dato);     //  dato
  7.    output_high(PIN_A5);

Para la de lectura, tengo varias opciones
1)
Código: C
  1. int read_returns_Data_MCP2510(int direccion){
  2.    int lectura;
  3.    output_low(PIN_A5);
  4.    spi_write(0x03);      // orden leer
  5.    spi_write(direccion);
  6.    lectura=spi_read(direccion);
  7.    output_high(PIN_A5);
  8.    return (lectura);
2)
Código: C
  1. read_returns_Data_MCP2510(int direccion){
  2.    output_low(PIN_A5);
  3.    spi_write(0x03);      // orden leer
  4.    spi_write(direccion);
  5.    output_high(PIN_A5);

3)
Código: C
  1. int read_returns_Data_MCP2510(int direccion){
  2.    int lectura;
  3.    output_low(PIN_A5);
  4.    spi_write(0x03);      // orden leer
  5.    spi_write(direccion);
  6.    lectura=spi_read(); // no haria falta porque ya se ma mandado desde el spi_write
  7.    output_high(PIN_A5);
  8.    return (lectura);
  9.     }

Uso mas bien esta ultima tercera, pero el osciloscopio solo me sale una cosa que no mando en asboluto, deberia leer unicamente del pin del MCP SO el dato que escribo.
Si me remitis al datasheet... lo tengo ya mas que sobao, la cuestion es saber en que me pierdo. Quizas el problema que tenia con la modificacion de la libreria can-mcp2510 venia de este mismo problema tambien.


leiendo el help del ccs, veo que spi_write lo que hace es escribir dato, e inmediatamente saca un dato por SO ( PIC) esta parte me pierde... si yo no quiero que saque nada...Es como si spi read fuera para poder guardar la lectura en una variable. Supongo que todo el problema viene por ahi, yo quiero usar mi propia libreria de escritura, usando spi_write().
alguien ve que sucede ahi extraño ?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 22 de Enero de 2010, 15:30:53
ah perdona MGLSOFT, no he hecho referencia a tu ultimo post desde el mio. Bueno, de momento no usaré esos pines... y si me es posible hacerlo por soft, o sea, desde el registro ( q ahora no me acuerdo cual es...) específico donde te dice las interrupciones acerca de buffer lleno  lo hare, mas que nada porque el trabajo ya lo tengo hecho.
Como he dicho antes, estoy haciendo una librería nueva de momento para transmision que es mas facil. Aunque ya tengo problemas con lo mas basico, el read, como puedes ver. Espero que las demás que ya tengo hechas el "cuerpo" quitando reads y writes esté bien ( aunque read  y write sea la panacea de todas las funciones se puede decir)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Enero de 2010, 15:38:01
Yo lo veo correcto el tercer ejemplo de read.
Creo que estas muy preocupado por el software y no te preocupaste aun por el hardware.
Deberias hacer una rutina (metida en el mismo Main() actual, con todas las declaraciones de hardware actuales, que se ocupe de probar pin por pin de los comprendidos en el Bus SPI y probar que cada uno hace lo propio, es decir que pueda activarse y descativarse correctamente cada uno, cuanto mas velocidad puedas darle al proceso mejor.
Una buena opcion es toggle_bit()...

Prueba tu hardware solo comentando las lineas del main que ejecutan el programa actual, una vez hachas las pruebas descomentas tu viejo programa y comentas el segmento de programa nuevo.

Haz esas pruebas y nos comentas, con cada bit de salida ocupado en el bus SPI con el MCP2515.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 22 de Enero de 2010, 16:10:20
bueno la funcion que veo parecida es output_toggle(pin)

Lo que entiendo con eso es que testea el pin ( nviando un 1??) es como un output_high y luego lo pone a output_low?

de todos modos, los unicos pines que tengo realmente referenciados son los del pic. al pic le ordeno " ves a esta direccion", referiendome a direccion del mcp y asumo que ccs no tiene por que saber si el pin 14 del MCP es el SI...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Enero de 2010, 16:22:38
Si, esa es la instruccion, cambia de estado el pin enviandolo al opuesto.
Si haces un lazo temporizado, activandolo una y otra vez, podrias leer con el osciloscopio si esos pines estan siendo activados correctamente.

Yo uso mi debugger para hacer esto.

Especialmente ya que en tu programa no utilizas standard_io para configurar tus pines y dado que muchos pines pueden quedar mal configurados si no prestas la debida atencion.
Eso mismo trate de decirte con el hecho de usar el pin C7 que esta asignado por hardware a la Usart.

Probandolos uno por uno alejas el fantasma que pueda estar ocurriendo algo extraño, y poder corregirlo si sucede algo raro...

Desde que comenzaste a consultar no veo grandes lios, solo que al usar fast_io hay que tener muchisimo cuidado como uno va configurando cada port y sus bits respectivos, igual que si trabajaras en assembler.
CCS tiene entre sus fortalezas el tener el standard_io pero se transforma en debilidad cuando te pasas al fast_io y no tienes en cuenta estos "detalles".

La prueba de hardware es lo mas recomendado...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 25 de Enero de 2010, 08:11:07

uhm, es interesante esto que me dices acerca de standard io. La verdad es que mirando el help no da muchas explicaciones acerca de la diferencia entre standard y fast_io, a lo que opté por esta última ya que segun he leido es mas recomendable para cambios rápidos en el pin, y permite el uso de delay's.

Bien tengo implementada -no he hecho grandes lios- una función dentro del main que probara los pines que se corresponden al SPI en el PIC, y cuando vea los resultados de este test ( espero que positivos) cambiaré parasiempre a standard_io, ademas ya he declarado como quiero los 2 o 3 puertos que realmente uso. Probaré lo siguiente y comento resultados:

Código: C
  1. #use fast_io (D)
  2. /// estos #use seran para hacer un test del estado de los pines
  3. #use fast_io (A)
  4. #use fast_io (B)
  5. #use fast_io (C)
  6. #use fast_io (E)
  7.  
  8. /*
  9.  
  10.  
  11.  
  12. #USE STANDARD_IO (B)
  13. #USE STANDARD_IO (C)
  14. #USE STANDARD_IO (D)
  15.  
  16. //set_tris_A(0x00);//      XXOXXXXX
  17.  
  18. set_tris_B(0xF9);          //  XXX1X001 ->1111 1001 -> 0xF9
  19. set_tris_C(0x10);        // |SD0|Tx|D+|D-|--|X|X|X|-> 00010000=0x10
  20.  
  21. set_tris_D(0x00);     // estan los dos leds en D0 y D1
  22.  
  23.  
  24. */
  25. /// declaracion de cabeceras de funciones
  26. void test_pins_SPI(void);
  27.  
  28.  
  29.  
  30. void main(){
  31. setup_spi (SPI_MASTER|SPI_L_TO_H|SPI_CLK_DIV_16);
  32.  
  33.  
  34.  
  35.  
  36.    while(1){
  37.    
  38.    
  39.  
  40.  // prueba de los pines ocupados por SPI/////
  41.        //   pin_C7 -> SDO
  42.        //   pin_B0 -> SDI
  43.        //   pin_A5 -> !CS
  44.  
  45.  test_pins_SPI();
  46.  
  47.    } // fin while
  48.  
  49. }// fin main
  50.  
  51. //// cuerpo funcion  test de los pins ///////
  52.  
  53. void test_pins_SPI(void){
  54.    output_toggle( pin_C7);
  55.    delay_ms(400);
  56.    output_toggle( pin_B0);
  57.    delay_ms(400);
  58.    output_toggle( pin_A5);
  59.    delay_ms(400);
  60.    }
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 25 de Enero de 2010, 13:15:13
bueno he hecho un cambio a la slineas del programa, que son
Código: C
  1. #include <18F4550.h>
  2. #include <stdlib.h>
  3. #include "spi_MCP2510.c"
  4. #use delay(clock=48000000) //clock a 48 MHz
  5. #fuses XTPLL,PLL5,NOWDT,NOPROTECT,USBDIV,CPUDIV2
  6. #byte  porta = 0xf80
  7. #byte   portb = 0xf81
  8. #byte   portc = 0xf82
  9. #byte   portd = 0xf83
  10. #byte   porte = 0xf84
  11.  
  12.  
  13.  
  14.  
  15. /// estos #use seran para hacer un test del estado de los pines
  16. #use fast_io (A)
  17. #use fast_io (B)
  18. #use fast_io (C)
  19. #use fast_io (D)
  20. #use fast_io (E)
  21.  
  22.  
  23. // quizas el problema ha estado aqui siempre, el no usar pines como input/output especifico
  24. /*
  25. #use standard_io (E)
  26.  
  27. #USE STANDARD_IO (A)
  28. #USE STANDARD_IO (B)
  29. #USE STANDARD_IO (C)
  30. #USE STANDARD_IO (D)
  31. #USE STANDARD_IO (E)
  32. */
  33.  
  34.  
  35. void main(){
  36. setup_spi (SPI_MASTER|SPI_L_TO_H|SPI_CLK_DIV_16);
  37.  
  38. set_tris_B(0x00);          //  XXX1X001 ->1111 1001 -> 0xF9
  39. set_tris_C(0x00);        // |SD0|Tx|D+|D-|--|X|X|X|-> 00010000=0x10
  40. set_tris_D(0x00);     // estan los dos leds en D0 y D1
  41.  
  42.  
  43.  
  44.    while(1){
  45.    
  46. // prueba de los pines ocupados por SPI/////
  47. //   pin_C7 -> SDO//
  48. //   pin_B0 -> SDI//
  49. //   pin_A5 -> !CS//  */
  50.  
  51.    output_toggle( pin_C7);
  52.    delay_ms(400);
  53.    output_toggle( pin_B0);
  54.    delay_ms(400);
  55.    output_toggle( pin_A5);
  56.    delay_ms(400);
  57.  
  58.  
  59.    } // fin while
  60. }// fin main


y no obtengo resultado ninguno, o sea, el estado es siempre en cero del pin, por ejemplo, SDO ( quizas no esta bien configurado el test??) o que el pic realmente esta mal...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Enero de 2010, 15:09:04
Prueba tus pines con este programa, no otro.... :mrgreen: :mrgreen:

Código: C
  1. #include <18F4550.h>
  2. #include <stdlib.h>
  3. //#include "spi_MCP2510.c"
  4. #use delay(clock=48000000) //clock a 48 MHz
  5. #fuses XTPLL,PLL5,NOWDT,NOPROTECT,USBDIV,CPUDIV2
  6.  
  7. void main(){
  8.  
  9.    while(1){
  10.  
  11.    output_toggle( pin_C7);
  12.    delay_ms(400);
  13.    output_toggle( pin_B0);
  14.    delay_ms(400);
  15.    output_toggle( pin_A5);
  16.    delay_ms(400);
  17.  
  18.  
  19.    } // fin while
  20. }// fin main

Luego dime que pasa.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 26 de Enero de 2010, 13:22:25

uhm, he tenido un susto porque habia puesto el inicio de spi. Bueno, después de probar, veo que el pic está correcto, es decir, se suceden los 1's y los 0's en cada pin. Bien, no es problema de HW pués.

Cuando hago un SPI_write(), según leo aquí, espera dar una respuesta por el pin SDI (PIC) desde el SDO(MCP). Yo no quiero eso, simplemente quiero que solo escriba, y que sólo lea cuando se lo mando. ¿ He de hacerpues  esas 2 ordenes mediante ensamblador ? ( dios, dime que no...:D )
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Enero de 2010, 15:09:33
Hagas lo que hagas, no declares mas :


#use fast_io (A)
#use fast_io (B)
#use fast_io (C)
#use fast_io (D)
#use fast_io (E)

Tampoco lo hagas con standard_io()

No declares la direccion de los puertos tampoco con set_tris_B(0x00) o los otros puertos.

Es absolutamente INNECESARIO si vas a usar standard_io() en todos tus puertos.
Incluso tampoco necesitas declararlo a standard_io() ya que es el modo por defecto como arranca el compilador...


Respecto a lo otro, cuando haces un pedido de un dato, debes quedarte esperando que el MCP te conteste.

La unica forma de evitar tanto ida y vuelta es CABLEAR todas las señales e interrupciones del MCP. :mrgreen: :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 26 de Enero de 2010, 16:42:22
vaya, cuando hacia set_tris() "sabia lo que hacia" jeje. Entonces, que una entrada sea (funcione) como input/output, al no poner esa instrucción, ¿ queda como está configurada automaticamente por el propio hardware? Es decir, si en el data pone que es I/O, en efecto será I/O a no se que le digamos lo contrario ( o sólo I, o sólo O).

Una nota curiosa: si pongo delay junto con declaracion de #use standard_io() o #use fast_io() solo me leia, o sacaba por SDO (MCP) 5 pulsos de SCK con sus correspondientes bits de datos ( que no se que eran).

Otra nota curiosa: la única vez que logro que parpadeen los leds, es al usar output_toggle(), y claro esá, sin definir ninguna #use x_io(). Si hago esto :
Código: C
  1. while(1){
  2.    write_MCP2510(direccion_buffer0_tx,dato1);  // OK
  3.    lectura=read_returns_Data_MCP2510(direccion_buffer0_tx);       //OK
  4.    if (lectura==dato1)
  5.       output_high(pin_d0);
  6.    else output_high(pin_d1);
  7.         output_low(pin_d1);
  8.    } // fin while
no parpadea el led conectado a pin D1. Si, se enciende pq ni de largo el dato que meto es el que lee, pero...¿ por que no parpadea?  a ver si eso guarda relación con el problema...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Enero de 2010, 16:55:08
Aun en el caso que el programa pasara por el encendido del led en:

Código: C
  1. #
  2.   if (lectura==dato1)
  3.      output_high(pin_d0);
  4.   else output_high(pin_d1);
  5.        output_low(pin_d1);
  6.   } // fin while

Solo tarda unos pocos microsegundos en apagarlo nuevamente, salvo que le agregues como prueba un delay_ms(300) antes del encendido ni el led se va a enterar que tenia que encender... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Enero de 2010, 16:59:08
Si le sacas los retardos o los comentas en el programa con los output_toggle() tampoco deberias ver que se enciendan leds, incluso no podrias verificarlo con el osciloscopio, por la alta frecuencia del encendido y apagado.
Encima el ojo humano tiene retardo visual y memoria optica, por lo tanto aun haciendo retardos de 10 mseg no verias nada aun, aunque si podrias registrarlo con el osciloscopio en este caso... :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 27 de Enero de 2010, 07:49:42
Si exacto, asi lo hacia, pero si pongo ese o esos delay...se lia gorda. Es decir, si no pongo el delay, mi led no parpadea ( que es lo que me gustaria, aunque realmente no es necesario) y por SCK veo que manda 5 pulsos correspondientes a las 5 instrucciones.

Si le pongo dichos delay_ms(), en efecto, parpadea, pero cuando digo que la lia gorda ... se queda ahí, el programa entero esta en delay, se fastidia el envio repetitivo de bytes...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Enero de 2010, 08:13:12
Es que ya no puede cumplir con la velocidad de comunicacion predeterminada del Bus SPI!!!
Lo de la temporizacion del led era solo para que veas que funciona, no para que lo dejes en el programa!!

Acostumbrate a la idea que cuando manejas comunicaciones por algun bus de datos, sea SPI, I2C, Can o cualquier otro, debes RESPETARSE las velocidades o nada va a funcionar.

Para darte una idea, el bus SPI puede llegar a velocidades de hasta 1 megabit por segundo.
Dime como verias aun con osciloscopio cuanto de bien o mal anda ese bus, salvo que dispongas de un osciloscopio especializado en comunicaciones.

Saca el manejo de ese led de alli, de otra forma no funcionara nada.
Te recomiendo que compres o te armes un debugger ICD, podria ser el ICDs-40 o el ICDU-40 que andan los circuitos por el foro, usa el buscador y lo encontraras.

Si tienes 2 pines libres del pic, deberias conectarlos a un port serie a traves de un MAX232 y hacer debug utilizandolos, solo recibirias lo que esta pasando en el bus y que va y que viene en el, mirandolo en pantalla.
Si utilizaras la libreria original de CCS podrias aprender a usarlo y luego recien podrias aprender a hacer la tuya.

Si no estableces una comunicacion por CAN estable dudo que aprendas a utilizarla y mas aun dudo que tengas exito en tu primer intento.

En este hilo hubo un usuario (Electrolinux) que estuvo haciendo su propia libreria para el compilador GCC, podrias buscar esa documentacion y utilizarla, incluso tradujo todo al español. :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 29 de Enero de 2010, 12:47:36
respecto la velocidad de acuerdo, pero lo de poner un max 32... no me convence nada esa solucion, ha de ser algo asi como una gran chorrada que esta escondida. Sigo los pasos ( o eso creo) que propone el data..los datasheet.

Estoy viendo algo, si quiero elejir el pic como esclavo, el pin A5 es entrada. Ese pin lo uso como mi chip select ( coincidencias...) pero... vamos a ver...deberia ser una entrada input/output normal y corriente, ya que segun data:

SSPM3:SSPM0: Master Synchronous Serial Port Mode Select bits
(...)
0001 = SPI Master mode, clock = FOSC/16

eso quiere decir que no activo el slave, sino que esta activado como master
Hay problemas con eso?? Ya es lo unico que se me ocurre.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Enero de 2010, 15:06:29
Creo que estas agotando lo que me queda de paciencia... :5] :5] :5]

No te han enseñado a trabajar con Metodo??   :shock: :shock: :shock: :x :x

Ya lograste comunicarte y funcionar con las librerias de CCS??   :x :x

NO?? Entonces hazlo.  :huh: :huh: :z) :z)

Cuando hayas hecho eso recien alli puedes seguir con el desarrollo de tu libreria propia, rompiendote el coco porque SABES que lo tuyo ya funciono con lo que todos sabemos que anda.   ;-) ;-) ;-) ;-)

Cuando tengas avances en ese sentido sigue consultando, de otro modo desperdicias mi tiempo que podria dedicarselo a ayudar a otro que si haga caso... :5] :5] :5]
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 29 de Enero de 2010, 18:13:40


uhm, es interesante esto que me dices acerca de standard io. La verdad es que mirando el help no da muchas explicaciones acerca de la diferencia entre standard y fast_io, a lo que opté por esta última ya que segun he leido es mas recomendable para cambios rápidos en el pin, y permite el uso de delay's.

Bien tengo implementada -no he hecho grandes lios- una función dentro del main que probara los pines que se corresponden al SPI en el PIC, y cuando vea los resultados de este test ( espero que positivos) cambiaré parasiempre a standard_io, ademas ya he declarado como quiero los 2 o 3 puertos que realmente uso. Probaré lo siguiente y comento resultados:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: penguin en 29 de Enero de 2010, 18:14:24

bueno he hecho un cambio a la slineas del programa, que son



y no obtengo resultado ninguno, o sea, el estado es siempre en cero del pin, por ejemplo, SDO ( quizas no esta bien configurado el test??) o que el pic realmente esta mal...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 07 de Febrero de 2010, 14:10:37
 Hola estimados colegas del can bus, quiero comprarme una herramienta para analizar el bus can y si es posible simularlo y seria demas pedir que tambien tenga analizador de serial asincronico, espero sus gentil recomendacion para tan valiosa herramienta y el futuro analicis del protocolo aplicado a los carros que soportan can bus. Yo estuve viento la herramienta que tiene disponible microchip para can bus pero no es simula es solo analizador  y tampoco tiene analizador de serial asincronico que eso seria en segundo plano lo que mas me intereza es la parte de can bus.

Saludos y como ya les mensione espero su recomentaciones al respecto.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 20 de Marzo de 2010, 02:38:59
Que avanzado este foro.. como no me entere antes de este hilo.. TREMENDO! me parece excelente esta labor.... a ver chicos tengo una duda muy basica para el nivel que se encuentra esto , pero no quiero quedarme con ella..

veo que trabajan el Bus Can con la serie 18F  y 16F (creo haber visto), pero ¿¿que modificaciones debo hacer yo si tengo a la mano DSPIC30F4011??? .. ¿¿¿solamente cambiarle el encabezado y colocarle
#include <dsPic30f4011.h>???

ayudenme estoy 99,9% perdido :?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Marzo de 2010, 08:26:50
Seguramente deberia funcionar de esa forma.

Si miras el resultado del calculo de Can Bit Timing Calculator, podras ver como setea los bits de los archivos de configuracion para los DSPIC:

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

Dos consejos:

Que pondras en el otro lado del bus??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 21 de Marzo de 2010, 00:47:18
Ok.. otro DSPIC30f4011, Nodo B, ahora mismo estoy en busca del transceptor MCP2551 para poder codificar y probar sobre el proto, ya lei que el proto disminuye la velocidad del Bus Can, es solo para testear. Si alguno tiene a la mano codigos extras de redes CAN de 2 nodos; ademas del que trae CCS se lo agradeceria, asi tengo mas fuente de info.... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Marzo de 2010, 12:59:20
Tengo unos DSPICs de ese modelo, apenas pueda me pongo a probarlos y vemos juntos como avanzar.
Nunca le entre a los DSPICs (todavia)  :) :) :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 21 de Marzo de 2010, 17:33:45
Me parece buena idea trabajar en equipo... Ya estare presentando avances con mi experiencias con los Dspic, por ahora estoy buscando los transceiver para poder arrancar...  8)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 23 de Marzo de 2010, 10:55:45
Me parece buena idea trabajar en equipo... Ya estare presentando avances con mi experiencias con los Dspic, por ahora estoy buscando los transceiver para poder arrancar...  8)

Hola buenos dias estimado colega, oye un placerver colegas de mi pais en el foro y mas en el tema de can bus, lastima que yo aun no toco los Dspic aun estoy en los pic18 esa gama aun para mi es uy avanzada pero todo a su tiempo espero proton trabajar con ellos; ahora encuanto a los trasceiver  MCP2551  yo dispongo de varios cualquier cosa t puedo facilitar uno para que vayas trabajando en el tema y esta demas decirte que podemos hacerlo en conjunto.

Saludos y cualquier cosa me contactas amigo que estamos a la orden aunque estos dias estoy un poco alejado del tema pero por cuestion de animo solo no es facil uno se ladilla como decimos aca los enezolanos no hay nada mejor que tener conquien hablar del tema y presentarle tus ideas y avance y asi ambos se llenan de animo para continuar y como lo hacia yo en la universidad onerme retos para ver quien lo hacia mejor son retos sanos y dan mucho fruto ajajaja.

Atten.
Alexander Santana
Barcelona-Venezuela.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Marzo de 2010, 10:59:16
Me parece buena idea trabajar en equipo... Ya estare presentando avances con mi experiencias con los Dspic, por ahora estoy buscando los transceiver para poder arrancar...  8)

Hola buenos dias estimado colega, oye un placerver colegas de mi pais en el foro y mas en el tema de can bus, lastima que yo aun no toco los Dspic aun estoy en los pic18 esa gama aun para mi es uy avanzada pero todo a su tiempo espero proton trabajar con ellos; ahora encuanto a los trasceiver  MCP2551  yo dispongo de varios cualquier cosa t puedo facilitar uno para que vayas trabajando en el tema y esta demas decirte que podemos hacerlo en conjunto.

Saludos y cualquier cosa me contactas amigo que estamos a la orden aunque estos dias estoy un poco alejado del tema pero por cuestion de animo solo no es facil uno se ladilla como decimos aca los enezolanos no hay nada mejor que tener conquien hablar del tema y presentarle tus ideas y avance y asi ambos se llenan de animo para continuar y como lo hacia yo en la universidad onerme retos para ver quien lo hacia mejor son retos sanos y dan mucho fruto ajajaja.

Atten.
Alexander Santana
Barcelona-Venezuela.

Je..Je... :mrgreen: :mrgreen:
Con uno no hace nada!! :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 24 de Marzo de 2010, 11:12:38
Me parece buena idea trabajar en equipo... Ya estare presentando avances con mi experiencias con los Dspic, por ahora estoy buscando los transceiver para poder arrancar...  8)

Hola buenos dias estimado colega, oye un placerver colegas de mi pais en el foro y mas en el tema de can bus, lastima que yo aun no toco los Dspic aun estoy en los pic18 esa gama aun para mi es uy avanzada pero todo a su tiempo espero proton trabajar con ellos; ahora encuanto a los trasceiver  MCP2551  yo dispongo de varios cualquier cosa t puedo facilitar uno para que vayas trabajando en el tema y esta demas decirte que podemos hacerlo en conjunto.

Saludos y cualquier cosa me contactas amigo que estamos a la orden aunque estos dias estoy un poco alejado del tema pero por cuestion de animo solo no es facil uno se ladilla como decimos aca los enezolanos no hay nada mejor que tener conquien hablar del tema y presentarle tus ideas y avance y asi ambos se llenan de animo para continuar y como lo hacia yo en la universidad onerme retos para ver quien lo hacia mejor son retos sanos y dan mucho fruto ajajaja.

Atten.
Alexander Santana
Barcelona-Venezuela.

Je..Je... :mrgreen: :mrgreen:
Con uno no hace nada!! :D :D :D
ok entonce seran dos.

Saludos y estamos en contacto aunque si el colega ya quiere comunicarse con una red ya establecidad como es mi caso no tiene porque usar dos ya que la red debe tener el otro transceiver.

Atten.
Alexander Santana.
Barcelona-Venezuela.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Marzo de 2010, 12:44:34
Es cierto.
Comentanos un poco mas de que red establecida estas hablando, a ver que practicas podriamos hacer...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 24 de Marzo de 2010, 15:00:04
Esta diversidad de compatriotas sur americanos unidos por una misma causa , si que me da animo de surmgirme en el mundo de los dsPIC , mi conocimiento en ellos es de 1% asi que ASTROCAR podemos comenzar a explotarlos al maximo.. por el momento necesitaremos algunos transceivers, asi que si te sobra alguno por alli , yo lo recibiria aqui con mucho gusto, el envio corre por mi cuenta. estoy en Pto Ordaz... Si tu proyecto es la comunicacion bus can con una red ya establecida de seguro si necesitaras un solo transceiver. quisiera comenzar con una comunicacion de dos nodos. ... AH!! se me olvidaba darle el credito a MGLSOFT, precursor de tan buen hilo... sin este no estariamos compartiendo conocimiento. :) :lol: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 25 de Marzo de 2010, 14:35:58
alguien me podria aclarar si puedo usar el transceiver MAX485 en reemplazo por el MCP2551.. es para hacer una conexion bus CAN......  :?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Marzo de 2010, 14:41:02
NO!!!!
Imposible!!
El MCP2551 tiene el hardware implementado para recibir el bus y hay cosas que se definen en el chip.
Si no tienes muestras o facilidad para conseguirlos, hay unos transceiver de Texas que andan muy bien, en el mismo encapsulado.
En este hilo hay una referencia a ellos... :mrgreen:

Aqui encontre la data:
http://www.todopic.com.ar/foros/index.php?topic=19182.msg139977;topicseen#msg139977 (http://www.todopic.com.ar/foros/index.php?topic=19182.msg139977;topicseen#msg139977)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 26 de Marzo de 2010, 02:09:59
No lo puedo creer!! no hay 1 solo MCP2551 en mi pueblo(ni ningun chip analogo de otra casa fabricante)..... si alguno sabe donde conseguirlos a traves de un proveedor , que me lo notifique por este medio... por favorrr. si quisieran ustedes mismos venderme unos tambien los acepto.... GRACIAS  :mrgreen:.......................... :-/(necesito dos) :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 27 de Marzo de 2010, 18:56:36
No lo puedo creer!! no hay 1 solo MCP2551 en mi pueblo(ni ningun chip analogo de otra casa fabricante)..... si alguno sabe donde conseguirlos a traves de un proveedor , que me lo notifique por este medio... por favorrr. si quisieran ustedes mismos venderme unos tambien los acepto.... GRACIAS  :mrgreen:.......................... :-/(necesito dos) :-/

oye colega te dije que yo tengo de esos disponible pero como que no quieres mi ofrecimiento porque no me comentastes ni como hacertelo llegar yo tengo ya esos ic en mi modulo can bus que compre a la gente de mikroe.

saludos y aun esta el ofrecimiento jajajaja.  ojo no  te lo estoy vendiendo es solo que los tengo de mas y asi tengo un compañero conquien trabajar y hablar del tema en mi pais.

Atten.
Alexander Santana.
Barcelona-Venezuela.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Marzo de 2010, 20:19:03
Me parece barbaro que apoyes asi a tu compatriota!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 28 de Marzo de 2010, 02:41:02
 Colega te anotaste 20 Puntos por ese altruismo !!  no perdere mas tiempo... Mi direccion te la estare dejando en un privado mañana en la tarde . Espero esten trabajando las empresas de envio de paquetes para estos dias... GRACIAS AMIGO.  :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 28 de Marzo de 2010, 17:51:50
Colega te anotaste 20 Puntos por ese altruismo !!  no perdere mas tiempo... Mi direccion te la estare dejando en un privado mañana en la tarde . Espero esten trabajando las empresas de envio de paquetes para estos dias... GRACIAS AMIGO.  :mrgreen:

tranquilo vale enviame tu direccion y te envio a la brevedad y lo mas seguro es que trabajen lunes y marte ya para el miercoles si es tarde jajaja.


Saludos.
Atten.
Alexander Santana.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 29 de Marzo de 2010, 15:24:29
Hola, soy nuevo en el foro y en esto del CAN BUS, de hecho conseguí un CAN BUS Monitor Demo Board de Microchip, he estado jugando con el, muy divertido por cierto  ;-), el pequeño detalle es que el manual de usuario es algo limitado en su explicación, dirijido a personas con experiencia y no para novatos =(. Por desgracia no he podido identificar los headers, es decir tengo una idea de conectar un módulo de sensor de lluvia a la tarjeta para leer su header id y el resto de la trama, sólo que no estoy seguro de como hacer las conexiones en la placa.
De acuerdo al manual austero, este cuenta con una función de Sniffer, por lo cual en teoría podría leer las tramas del sensor al conectarlo a la placa por medio de los cuatro pines:
Can Bus +, Can Bus -, Tierra y Corriente

Alguien tendría alguna idea o experiencia de como hacerlo, se los agradecería, cualquier documento de lectura también es bienvenido, aun soy nuevo en esto  :oops: pero conforme vaya aprendiendo con gusto lo compartiré :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Marzo de 2010, 17:56:40
Hagamos al reves.
Porque no publicas la hoja de datos de tu sensor y luego podremos ayudarte mejor en como conectarlo y que recibirias en la trama del sniffer.

Bienvenido al foro!! :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 29 de Marzo de 2010, 22:54:19
Gracias MGLSOFT, lo más cercano a un diagrama que tengo del sensor es esto.(http://sensor.JPG)

Ahorita no cuento con el sensor, mañana le tomaré una foto, el sensor trae un chip de Freescale Semiconductor dentro.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Marzo de 2010, 23:02:49
Y hoja de datos tienes??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 29 de Marzo de 2010, 23:15:02
Con respecto al chip Freescale no cuento con hoja de datos, y  en cuanto al sensor busqué por muchas partes y no pude conseguir una hoja de datos  :?
si, la situación es algo complicada  :shock:

Las hojas de datos de la placa de pruebas, no hay problema estan aqui (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537141) y aqui (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010405)

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Marzo de 2010, 23:25:10
La verdad es que es todo un problema...
Sin datos, como sabrias que velocidad del bus elegir?
Cuales y como serian los datos a leer??
Que ID tendria ese nodo en el bus??

Etcetera, etcetera.

Lo veo mal...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 29 de Marzo de 2010, 23:38:00
El ID sería extendido, el baud rate es de 9600 de acuerdo al estándar ISO15765-4,11898 y el ID... bueno es lo que quisiera identificar  :oops:, la idea es saber el ID y la información que manda el sensor para después simular dicha respuesta y su ID (header) en un PIC18F4580 y que pueda substituirlo  :shock:

me emociona la idea de poder hacerlo  :-/

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Marzo de 2010, 23:48:35
Entonces es un sensor de automovil lo que tienes alli??
9600 bps no existe en CANBUS, debe ser la velocidad de comunicacion entre el modulo que lee este sensor y el PC, por conexion serial...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 30 de Marzo de 2010, 00:12:50
asi es, me sorprendes!!
y si es serial la comunicación, eres bueno  ;-)

creo que por eso la dificultad para encontrar hojas de datos del sensor de lluvia  :?
la idea que tenia para mañana era: conectar el sensor al carro (obvio jaja) y puentear el can bus + y - del sensor hacia la placa de prueba en modo Listen esperando poder leer el ID (header) y la trama que este le manda a la PC del carro, eso lo hare con algo de luz.

Poooorque si conecto la placa directo al carro tendré una cantidad inmensa de información y no podré detectar la info. del sensor, que es lo que me interesa, la idea principal era conectar el sensor directo a la placa y ver que pasa, el problema es que no pasó algo :? de sguro estaré lo conectando mal -lo más probable- o simplemente el sensor necesita ser activado por la PC del carro...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Marzo de 2010, 00:20:32
Una vez hagas esas pruebas comenta resultados, arranca con 125 Kbps y luego 250 KBPS, la velocidad de 500 casi no es utilizada en automoviles, salvo encendido, por lo que lei por alli.
Mi interes en el BUS CAN es mas industrial que otra cosa.

Saludos y suerte!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 30 de Marzo de 2010, 00:30:57
Gracias, mañana tras las pruebas les doy a conocer los resultados  :-/

se ve que eres bueno en esto  :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 30 de Marzo de 2010, 03:19:24
Amigos de verdad que no se la razon por la que no compila este codigo, es el nodo1 de una red bus CAN de tres nodos, echenle un vistazo a ver que tal.............

Código: [Seleccionar]
char Can_Init_Flags, Can_Send_Flags, Can_Rcv_Flags;                           // can flags
char Rx_Data_Len;                                                             // received data length in bytes
char RxTx_Data[8];                                                            // can rx/tx data buffer
char Msg_Rcvd;                                                                // reception flag
long Tx_ID, Rx_ID;                                                            // can rx and tx ID
char ErrorCount;
// CANSPI module connections
sbit CanSpi_CS at PORTB.B0;                                                   // Chip select (CS) pin for CANSPI board
sbit CanSpi_CS_Direction at DDRB.B0;                                          // Direction register for CS pin
sbit CanSpi_Rst at PORTB.B2;                                                  // Reset pin for CANSPI board
sbit CanSpi_Rst_Direction at DDRB.B2;                                         // Direction register for Reset pin
// End CANSPI module connections
void main(){
  ADCSRA.B7 = 0;                                                              // Configure analog pins as digital I/O
  PORTB  = 0; DDRB = 255;                                                     // Initialize ports
  PORTD  = 0; DDRD = 255;
  PORTC  = 0; DDRC = 255;

  ErrorCount     = 0;                                                         // Error flag
  Can_Init_Flags = 0; Can_Send_Flags = 0; Can_Rcv_Flags = 0;                  // clear flags

  Can_Send_Flags = _CANSPI_TX_PRIORITY_0 &                                    // form value to be used
                   _CANSPI_TX_XTD_FRAME &                                     // with CANSPIWrite
                   _CANSPI_TX_NO_RTR_FRAME;

  Can_Init_Flags = _CANSPI_CONFIG_SAMPLE_THRICE &                             // form value to be used
                   _CANSPI_CONFIG_PHSEG2_PRG_ON &                             // with CANSPIInit
                   _CANSPI_CONFIG_XTD_MSG &
                   _CANSPI_CONFIG_DBL_BUFFER_ON &
                   _CANSPI_CONFIG_VALID_XTD_MSG;

  SPI1_Init();
  Spi_Rd_Ptr = SPI1_Read;                                                     // initialize SPI module
  CANSPIInitialize(1, 3, 3, 3, 1, Can_Init_Flags);                            // Initialize external CANSPI module
  CANSPISetOperationMode(_CANSPI_MODE_CONFIG, 0xFF);                          // set CONFIGURATION mode
  CANSPISetMask(_CANSPI_MASK_B1, -1, _CANSPI_CONFIG_XTD_MSG);                 // set all mask1 bits to ones
  CANSPISetMask(_CANSPI_MASK_B2, -1, _CANSPI_CONFIG_XTD_MSG);                 // set all mask2 bits to ones

  CANSPISetFilter(_CANSPI_FILTER_B2_F4, 0x12, _CANSPI_CONFIG_XTD_MSG);        // Node1 accepts messages with ID 0x12
  CANSPISetFilter(_CANSPI_FILTER_B1_F1, 0x13, _CANSPI_CONFIG_XTD_MSG);        // Node1 accepts messages with ID 0x13

  CANSPISetOperationMode(_CANSPI_MODE_NORMAL,0xFF);                           // set NORMAL mode
  RxTx_Data[0] = 0x40;                                                        // set initial data to be sent

  Tx_ID = 0x10;                                                               // set transmit ID for CAN message

  CANSPIWrite(Tx_ID, &RxTx_Data, 1, Can_Send_Flags);                          // Node1 sends initial message

  while (1)                                                                   // endless loop
    {
      Msg_Rcvd = CANSPIRead(&Rx_ID, RxTx_Data, &Rx_Data_Len, &Can_Rcv_Flags); // attempt receive message
      if (Msg_Rcvd) {                                                         // if message is received then check id

          if (Rx_ID == 0x12)                                                  // check ID
              PORTC = RxTx_Data[0];                                           // output data at PORTC
          else
              PORTD = RxTx_Data[0];                                           // output data at PORTD
          Delay_ms(50);                                                       // wait for a while between messages
          CANSPIWrite(Tx_ID, RxTx_Data, 1, Can_Send_Flags);                   // send one byte of data
          Tx_ID++;                                                            // switch to next message
          if (Tx_ID > 0x11) Tx_ID = 0x10;                                     // check overflow


        }
      else {                                                                  // an error occured, wait for a while

          ErrorCount++;                                                       // increment error indicator
          Delay_ms(10);                                                       // wait for 10ms
          if (ErrorCount > 10) {                                              // timeout expired - process errors
            ErrorCount = 0;                                                   // reset error counter
            Tx_ID++;                                                          // switch to another message
            if (Tx_ID > 0x11) Tx_ID = 0x10;                                   // check overflow
            CANSPIWrite(Tx_ID, RxTx_Data, 1, Can_Send_Flags);                 // send new message
          }

        }
    }
}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 30 de Marzo de 2010, 03:22:58
Aqui les dejo una imagen adjunta donde se observa el error arrojado por mikroC... La adjunte porque no se aun como pegar imagenes en el foro.  sorry:D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Marzo de 2010, 08:46:15
Segun lo que dice el error que marca el compilador, busca un ; y encuentra CanSpiCS.
Seguramente se quedo un caracter de terminacion de una instruccion en el camino, suele ocurrir al escribir el codigo.

En el codigo que adjuntaste no se encuentra ese error, pero puede ser una libreria o algo asi...

respecto a pegar imagenes en el cuerpo de los mensajes, levanta tus imagenes a imageshack o algun lugar por el estilo y luego con el boton Image de la barra de herramientas pegas el link que te da imageshack dentro de sus corchetes, de esa forma se visualiza tu imagen dentro del mensaje.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 31 de Marzo de 2010, 12:12:38
Hola ayer hice una pequeña conexión, el módulo del sensor de lluvia conectado a la PC del carro y el CAN BUS High y Low puenteados a la placa de prueba..... comenzó a salir algo de humo, no pasó nada grave, después opté por la conexión sencilla del módulo a la placa de prueba y me arrojo algunos resultados interesantes, al menos un ID, el detalle es que no puedo replicar le experimento  :? -el screenshot de esto lo deje en la lap, lo publicaré al rato-

Así que, el siguiente camino a seguir será.... tratar de reproducir lo anterior, si no se puede, bueno tendré que modificar un conectar OBD-II a serial y leer la avalancha de datos.

PD. gracias por el tip para postear imágenes  :D

(http://img696.imageshack.us/img696/1396/sensorl.jpg)
El módulo de sensor de lluvia

(http://img38.imageshack.us/img38/1186/demoboard.jpg)
Las placas funcionando  :-/

(http://img208.imageshack.us/img208/4126/conexiones.jpg)
El cablerio para hacer la conexión.... hace falta un poco de orden  :oops:


....creo que salieron exageradamente grandes
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 31 de Marzo de 2010, 23:48:39
Aquí esta el posible ID del sensor, solo que no he podio reproducir la respuesta  :( así que dudo el resultado.

(http://img143.imageshack.us/img143/1130/headerfg.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Abril de 2010, 00:14:53
Mira la ventana de abajo, donde te muestra los errores en una ventana Debug, solo son errores....
Minimamente deberas probar 250 Kbps, pero me inclino a que trabaja en menos que 125 Kbps, que creo que no existe en el software del sniffer de Microchip, no es asi??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 01 de Abril de 2010, 00:21:37
así es el mínimo es 150kbit/s
de hecho creo que funciona a 75-85kbit/s según alguna vez leí sobre el CAN BUS B que utiliza el carro, de hecho estoy comenzando a dudar un poco en la forma como lo conecte  :?

Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 01 de Abril de 2010, 05:39:45
Existe algun simulador de modulo CAN??? especificamente para los dspic o para cualquier otra gama??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Abril de 2010, 08:01:43
Si alguno encuentra un simulador que sirva, por favor postearlo, porque yo no lo encontre, ni siquiera en versiones pagas.. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 01 de Abril de 2010, 10:48:23
Intentaste con el Proteus??
su nombre completo es Proteus Design Suite, puede simular varios pics y según tengo entendido tiene una librería de dspics, mas no sé si se tenga que descargar aparte, no pierdes nada con revisarlo, ojalá te sirva ;-).
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Abril de 2010, 10:51:16
Proteus NO simula CAN, no tiene libreria del MCP2551 ni algun otro Transceiver de CAN.
Como el transceiver resuelve una buena parte del protocolo, es imposible simularlo en Proteus.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 01 de Abril de 2010, 10:53:33
demonios!! con el planeaba simular el PIC18F4580 y el MCP2551 ya teniendo el ID y la trama del módulo  :(
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Abril de 2010, 11:08:53
Si encuentran el MCP2551 me avisan, por favor!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 09 de Abril de 2010, 18:29:04
Les pido su ayuda escribi estos codigos para establecer una red de 2 nodos, cada nodo deberia enviar y recibir, y no tengo transceiver asi que conecte el TX de un DSPIC30f4011 con el RX del otro y viceversa. Pero no me funciona!!!!! no entiendo, que puedo hacer para saber si el pin Tx esta enviando algo ?? porque el mio siempre esta activado. :?

NODO 1

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

void int_INT1 () org 0x34  //Funcion de INT1
{
  PORTFbits.RF4=1;
  delay_ms(3000);
  data=PORTEbits.RE1;
  delay_ms(1000);
  PORTB=data;
  delay_ms(1000);
  id=2;
  CAN1Write(id,data,1,aa1);
  IFS1bits.INT1IF = 0;     //Desahabilitar bandera de INT1
}

void int_INT2 () org 0x42  //Funcion de INT2
{
  PORTFbits.RF5=1;
  delay_ms(3000);
  data=PORTEbits.RE2;
  delay_ms(1000);
  PORTB=data;
  delay_ms(1000);
  id=2;
  CAN1Write(id,data,1,aa1);
  IFS1bits.INT2IF = 0;     //Desahabilitar bandera de INT2
}

void main()
{
  ADPCFG=0xFFFF;           //Configurar E/S como digitales
  TRISB=0;                 //Puert B como salida
  TRISD=3;                 //RD1-RD0 como entradas
  TRISE=0xFF;             //RE como entrada
  TRISF = 0;

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

  INTCON1bits.NSTDIS = 1;  //Deshabilitar interrupciones anidadas
  INTCON2bits.ALTIVT = 0;  //Deshabilitar la AIVT

  INTCON2bits.INT1EP = 1;  //Activacion de INT1 por flanco de bajada
  INTCON2bits.INT2EP = 1;  //Activacion de INT2 por flanco de bajada

  IEC1bits.INT1IE = 1;     //Habilitar INT1
  IFS1bits.INT1IF = 0;     //Desactivar bandera de INT1

  IEC1bits.INT2IE = 1;     //Habilitar INT2
  IFS1bits.INT2IF = 0;     //Desactivar bandera de INT2

  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_MATCH_MSG_TYPE &
          CAN_CONFIG_ALL_VALID_MSG &
          CAN_CONFIG_LINE_FILTER_OFF;


  data = 0;
  CAN1Initialize(1,3,3,3,1,aa);   // initialize CAN
  CAN1SetOperationMode(CAN_MODE_CONFIG,0x00);   // set CONFIGURATION mode
  id = -1;
  CAN1SetMask(CAN_MASK_B1,id,CAN_CONFIG_MATCH_MSG_TYPE & CAN_CONFIG_XTD_MSG);   // set all mask1 bits to ones
  CAN1SetMask(CAN_MASK_B2,id,CAN_CONFIG_MATCH_MSG_TYPE & CAN_CONFIG_XTD_MSG);   // set all mask2 bits to ones
  CAN1SetFilter(CAN_FILTER_B1_F1,1,CAN_CONFIG_XTD_MSG);  // set id of filter B1_F1 to 3
  CAN1SetOperationMode(CAN_MODE_NORMAL,0x00);   // set NORMAL mode

  while(1)
  {
    PORTB=0;
    PORTF=0;
    zr = CAN1Read(&id , data , &len, &aa2);
    if ((id == 1) && zr) {
      PORTB = data;                          // output data at portC
      Delay_ms(8000);
            }
  }
}


NODO 2

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

void int_INT1 () org 0x34  //Funcion de INT1
{
  PORTFbits.RF4=1;
  delay_ms(3000);
  data=PORTEbits.RE1;
  delay_ms(1000);
  PORTB=data;
  delay_ms(1000);
  id=1;
  CAN1Write(id,data,1,aa1);
  IFS1bits.INT1IF = 0;     //Desahabilitar bandera de INT1
}

void int_INT2 () org 0x42  //Funcion de INT2
{
  PORTFbits.RF5=1;
  delay_ms(3000);
  data=PORTEbits.RE2;
  delay_ms(1000);
  PORTB=data;
  delay_ms(1000);
  id=1;
  CAN1Write(id,data,1,aa1);
  IFS1bits.INT2IF = 0;
}

void main()
{
  ADPCFG=0xFFFF;           //Configurar E/S como digitales
  TRISB=0;                 //Puert B como salida
  TRISD=3;                 //RD1-RD0 como entradas
  TRISE=0xFF;             //RE como entrada
  TRISF = 0;

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


  INTCON1bits.NSTDIS = 1;  //Deshabilitar interrupciones anidadas
  INTCON2bits.ALTIVT = 0;  //Deshabilitar la AIVT

  INTCON2bits.INT1EP = 1;  //Activacion de INT1 por flanco de bajada
  INTCON2bits.INT2EP = 1;  //Activacion de INT2 por flanco de bajada

  IEC1bits.INT1IE = 1;     //Habilitar INT1
  IFS1bits.INT1IF = 0;     //Desactivar bandera de INT1

  IEC1bits.INT2IE = 1;     //Habilitar INT2
  IFS1bits.INT2IF = 0;     //Desactivar bandera de INT2

  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_MATCH_MSG_TYPE &
          CAN_CONFIG_LINE_FILTER_OFF;

  data = 0;
  CAN1Initialize(1,3,3,3,1,aa);   // initialize CAN
  CAN1SetOperationMode(CAN_MODE_CONFIG,0x00);   // set CONFIGURATION mode
  id = -1;
  CAN1SetMask(CAN_MASK_B1,id,CAN_CONFIG_MATCH_MSG_TYPE & CAN_CONFIG_XTD_MSG);   // set all mask1 bits to ones
  CAN1SetMask(CAN_MASK_B2,id,CAN_CONFIG_MATCH_MSG_TYPE & CAN_CONFIG_XTD_MSG);   // set all mask2 bits to ones
  CAN1SetFilter(CAN_FILTER_B2_F3,2,CAN_CONFIG_XTD_MSG);  // set id of filter B1_F1 to 3
  CAN1SetOperationMode(CAN_MODE_NORMAL,0x00);   // set NORMAL mode


  while(1)
  {
    PORTB=0;
    PORTF=0;
    zr = CAN1Read(&id , data , &len, &aa2);
    if ((id == 2) && zr) {
      PORTB = data;                          // output data at portC
      Delay_ms(8000);

     }
  }
}

Estoy usando un oscilador de 10Mhz
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Abril de 2010, 18:59:49
Citar
Les pido su ayuda escribi estos codigos para establecer una red de 2 nodos, cada nodo deberia enviar y recibir, y no tengo transceiver asi que conecte el TX de un DSPIC30f4011 con el RX del otro y viceversa. Pero no me funciona!!!!! no entiendo, que puedo hacer para saber si el pin Tx esta enviando algo ?? porque el mio siempre esta activado. Confused

La respuesta estaba antes hecha... :mrgreen:

Proteus NO simula CAN, no tiene libreria del MCP2551 ni algun otro Transceiver de CAN.
Como el transceiver resuelve una buena parte del protocolo, es imposible simularlo en Proteus.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 10 de Abril de 2010, 01:43:47
No amigo, yo NO lo simule en proteus sino en fisico sobre un protoboard, pregunte y busque en google y no existe simulador para este protocolo, asi que nos toca montar todo, y como  no tengo ningun transceiver a la mano, estoy conectando dos nodos unicamente , aunque no se si funciona de la manera que lo hago, que es uniendo el TX de un dspic con el RX del otro y viceversa. ¿¿¿¿ alguien lo ha conectado anteriormente de esta manera ????
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Abril de 2010, 18:49:19
Por lo mismo explicado anteriormente, no solo no se puede simular, sino que sin los MCP2551 NO hay forma que funcione el bus...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 11 de Abril de 2010, 00:48:49
Con razon.... gracias por la aclaratoria y no hacerme perder mas el tiempo sin el transceiver..... :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 17 de Abril de 2010, 17:30:43
Con razon.... gracias por la aclaratoria y no hacerme perder mas el tiempo sin el transceiver..... :D

Hola robert con cuestiones de tiempo no te he enviado los transceiver pero luego esta semana estoy mas libre y con seguridad te contacto para que me reenvies la direccion y asi poder enviartelos y mil disculpas por eso hermano lo otro es que tamnbien puedes usar los tja1040 de la casa philips.

Saludos y estamos en contacto.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: InfectedDAS en 21 de Abril de 2010, 10:54:05
Hola otra vez, ya comencé a hacer un programilla en C, ahorita ando leyendo los ejemplos en mikroC sobre la librería CAN y me ha surgido una gran duda sobre las banderas y los filtros, estos se dejan en default? o que cambios se necesitan hacer para que se pueda comunicar con el carro?

Las banderas y filtros en que afectarían en caso de moverle??

Esto ha resultado ser algo complicado, en especial cuando no se sabía mucho del tema, pero es emcionante  ;-)

Código: [Seleccionar]
unsigned char Can_Init_Flags, Can_Send_Flags, Can_Rcv_Flags; // can flags
unsigned char Rx_Data_Len;                                   // received data length in bytes
char RxTx_Data[8];                                           // can rx/tx data buffer
char Msg_Rcvd;                                               // reception flag
const long ID_1st = 12111, ID_2nd = 3;                       // node IDs
long Rx_ID;

void main() {

  PORTC = 0;                                                // clear PORTC
  TRISC = 0;                                                // set PORTC as output

  Can_Init_Flags = 0;                                       //
  Can_Send_Flags = 0;                                       // clear flags
  Can_Rcv_Flags  = 0;                                       //

  Can_Send_Flags = _CAN_TX_PRIORITY_0 &                     // form value to be used
                   _CAN_TX_XTD_FRAME &                      //     with CANWrite
                   _CAN_TX_NO_RTR_FRAME;

  Can_Init_Flags = _CAN_CONFIG_SAMPLE_THRICE &              // form value to be used
                   _CAN_CONFIG_PHSEG2_PRG_ON &              // with CANInit
                   _CAN_CONFIG_XTD_MSG &
                   _CAN_CONFIG_DBL_BUFFER_ON &
                   _CAN_CONFIG_VALID_XTD_MSG;
 
  CANInitialize(1,3,3,3,1,Can_Init_Flags);                  // Initialize CAN module
  CANSetOperationMode(_CAN_MODE_CONFIG,0xFF);               // set CONFIGURATION mode
  CANSetMask(_CAN_MASK_B1,-1,_CAN_CONFIG_XTD_MSG);          // set all mask1 bits to ones
  CANSetMask(_CAN_MASK_B2,-1,_CAN_CONFIG_XTD_MSG);          // set all mask2 bits to ones
  CANSetFilter(_CAN_FILTER_B2_F4,ID_2nd,_CAN_CONFIG_XTD_MSG);// set id of filter B2_F4 to 2nd node ID

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

  RxTx_Data[0] = 9;                                         // set initial data to be sent

  CANWrite(ID_1st, RxTx_Data, 1, Can_Send_Flags);           // send initial message

  while(1) {                                                               // endless loop
    Msg_Rcvd = CANRead(&Rx_ID , RxTx_Data , &Rx_Data_Len, &Can_Rcv_Flags); // receive message
    if ((Rx_ID == ID_2nd) && Msg_Rcvd) {                                   // if message received check id
      PORTC = RxTx_Data[0];                                                // id correct, output data at PORTC
      RxTx_Data[0]++;                                                     // increment received data
      Delay_ms(10);
      CANWrite(ID_1st, RxTx_Data, 1, Can_Send_Flags);                      // send incremented data back
    }
  }
}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Abril de 2010, 21:36:05
Si te refieres a estas banderas:

Citar
  Can_Send_Flags = _CAN_TX_PRIORITY_0 &                     // form value to be used
                   _CAN_TX_XTD_FRAME &                      //     with CANWrite
                   _CAN_TX_NO_RTR_FRAME;

Lo que estan haciendo es que la prioridad de los mensajes sea 0 (ver prioridad en modulo ECAN de la hoja de datos), la trama es estandar y no usa el bit RTR.

Lo de los filtros no entiendo a donde apunta la pregunta.
Los filtros son utilizados para recibir solamente desde una direccion especificada o contestar solamente cuando el id corresponde a uno especifico.
Esto permite que un nodo se transforme por momentos en una especie de Master y luego vuelva al modo de escucha...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 22 de Mayo de 2010, 08:46:28

   
CAN BUS
« : 21 de Mayo de 2010, 03:04:47 »
   Responder con cita Modificar mensaje
Hola a tods!!!

Quiero iniciarme en la comunicación serie entre dos pics, concretamente me ha llamado la atención la flexibilidad del CAN y mi primera gran duda es ¿que targeta de desarrollo puedo utilizar?, ya que iniciar realizando yo una propia resulta pesado. he

Ya he visto varios hilos sobre este bus, cuya información ha sido estupenda para un neofito en el tema, y veo que hablais del
MCP2515 CAN BusMonitor Demo Board Kit.

¿Os parece apropiado? ¿Es compatible con mi compilador de CCS?

He planteado este tema en el subforo general de programación en C y además de djarme un poko de código para saciar mi inquietud, me han remitido aqui.

Gracias de antemano, necesito una board para comenzar a probar programitas.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 23 de Mayo de 2010, 10:10:34

   
CAN BUS
« : 21 de Mayo de 2010, 03:04:47 »
   Responder con cita Modificar mensaje
Hola a tods!!!

Quiero iniciarme en la comunicación serie entre dos pics, concretamente me ha llamado la atención la flexibilidad del CAN y mi primera gran duda es ¿que targeta de desarrollo puedo utilizar?, ya que iniciar realizando yo una propia resulta pesado. he

Ya he visto varios hilos sobre este bus, cuya información ha sido estupenda para un neofito en el tema, y veo que hablais del
MCP2515 CAN BusMonitor Demo Board Kit.

¿Os parece apropiado? ¿Es compatible con mi compilador de CCS?

He planteado este tema en el subforo general de programación en C y además de djarme un poko de código para saciar mi inquietud, me han remitido aqui.

Gracias de antemano, necesito una board para comenzar a probar programitas.


Hola buenos dias, aca te dejo un link de la pagina del colega Jim miembro de este foro, yo dispongo de uno m0odulo de la gente de mikroelektronika pero este al cual hago referencia lo mejor es que contamos con su creador en este mismo foro ladtima que no la vi antes para comprarlo y lo otro es que aun no no me dedico por completo al can bus tengo ya material y documentacion para empézar el tema pero simple poc¿r cuestiones de tiempo y ocupaciones laborales y personales no arranco de una ves en el tema pero te guste y nos comente tu opinion sobre este modulo can.

Saludos y estamos en contacto.
Atten.
Alexander Santana.
Venezuela-Barcelona.
link--- http://www.microingenia.com/electronics/product.php?id_product=5
http://www.microingenia.com/electronics/product.php?id_product=5 (ftp://http://www.microingenia.com/electronics/product.php?id_product=5)
Título: hola amigos
Publicado por: robertdanyel en 23 de Mayo de 2010, 15:50:48
hola compañeros aparezco de nuevo, y de nuevo con nuevas dudas...

estoy trabajando con un cristal de 10Mhz, esto afectaria este codigo que saque de "mikroC for dspic"

Código: [Seleccionar]
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_MATCH_MSG_TYPE &
          CAN_CONFIG_LINE_FILTER_OFF;

  data[0] = 9;
  CAN1Initialize(1,3,3,3,1,aa);   
   

en realidad no entiendo muy el significado de cada bit.... esos (1,3,3,3,1,aa)???? porque???

que significan??

tienen que ver con el cristal que uso???, como lo configuro para un cristal de 10Mhz???

les pido ayuda         
Título: Re: hola amigos
Publicado por: MGLSOFT en 23 de Mayo de 2010, 16:12:26
hola compañeros aparezco de nuevo, y de nuevo con nuevas dudas...

estoy trabajando con un cristal de 10Mhz, esto afectaria este codigo que saque de "mikroC for dspic"

Código: [Seleccionar]
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_MATCH_MSG_TYPE &
          CAN_CONFIG_LINE_FILTER_OFF;

  data[0] = 9;
  CAN1Initialize(1,3,3,3,1,aa);   
   

en realidad no entiendo muy el significado de cada bit.... esos (1,3,3,3,1,aa)???? porque???

que significan??

tienen que ver con el cristal que uso???, como lo configuro para un cristal de 10Mhz???

les pido ayuda         
Hola.
Si miras en el indice del hilo, podras llegar a este y otros mensajes que permiten entender y configurar el formato de comunicacion segun el cristal que utilizes.

Configurar el bus CAN (http://www.todopic.com.ar/foros/index.php?topic=19182.msg137512#msg137512)
Título: Proyecto CAN open
Publicado por: conilete en 09 de Junio de 2010, 06:52:36
Hola a todos.
Trabajo en un departamento de investigacion, y estamos trabanjando con un robot con una serie de sensores controlados mediante bus CAN.
Me han encargado realizar el siguiente trabajo:
Me han pasado una libreria de comunicaciones basada en CANOpen, y debo programar el controlador de una placa para controlar una serie de sensores. Estoy a la espera de que me den el PIC sobre el que se va a realizar el trabajo.
Dispongo de dos herramientas: el CAN Analyzer y el CAN Case XL.
No tengo experiencia en la programacion de PIC's, por lo que os pido consejo sobre cuales serian los primeros pasos que debo realizar y que documentacion debo ir mirando primero.
Segun he visto por Internet, es necesario usar el software CANOpen Design Tool y el CANOpen Device Manager...¿me equivoco?
Otro aspecto que me gustaria aclarar, es si el compilador que debo usar es el CCS.
Un saludo, y espero vuestra ayuda en forma de comentarios.
Muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Junio de 2010, 08:28:35
Hola!!
Bienvenido al foro y en especial al hilo de CAN!!

Respecto a tus dudas:
Citar
Me han pasado una libreria de comunicaciones basada en CANOpen, y debo programar el controlador de una placa para controlar una serie de sensores. Estoy a la espera de que me den el PIC sobre el que se va a realizar el trabajo.

Cuales son esas librerias??
Si son las de Microchip son para armar un dispositivo CanOpen Slave.
En caso que no sepas cuales son, podras compartirlas por privado asi vemos de que se trata?? (eso si es que no te permiten publicarlas, ya que pueden pertenecer a tu universidad)

Citar
Dispongo de dos herramientas: el CAN Analyzer y el CAN Case XL.
Que envidia!!  :mrgreen: :mrgreen: :mrgreen:
Hermosas herramientas te han dado.!!

Citar
No tengo experiencia en la programacion de PIC's, por lo que os pido consejo sobre cuales serian los primeros pasos que debo realizar y que documentacion debo ir mirando primero.
En este hilo puedes aprender los conceptos de CAN, que va a ser la capa fisica de tu proyecto, sugiero que intentes guiarte con el Indice del primer Post, ya que leerlo completo te llevaria bastante y en el indice intente llevar la tematica mas importante sobre CAN Bus.
Respecto a CanOpen sugiero que busque bibliografia en la pagina de Can CIA, que es quien describe la norma de CanOpen, alli con solo registrarte vas a poder acceder a bastante informacion gratuita para entender tu aplicacion.
Hay una nota de aplicacion en Microchip que te puede servir de introduccion a CanOpen, esa nota deberias bajarla y leerla por completo, te introducira a CanOpen sobre microcontroladores PIC.
Aqui vamos a hacer una salvedad, solo la linea PIC18Fxx80 permite programar y usar una aplicacion de este tipo, ya que hacen uso de del modulo ECAN (Extended CAN), este modulo soporta DeviceNet y CanOpen, con otros PICs menores ni lo intentes, ademas la memoria y recursos utilizados son bien importantes en estas aplicaciones.

Citar
Segun he visto por Internet, es necesario usar el software CANOpen Design Tool y el CANOpen Device Manager...¿me equivoco?
Otro aspecto que me gustaria aclarar, es si el compilador que debo usar es el CCS.
Seguramente esas herramientas te garantizaran hacer una aplicacion seria y sin olvidarte detalles importantes de diseño.
Respecto a CCS, y muy a mi pesar, no creo que sea la mejor opcion para usar, ya que todo lo que hay en uso esta hecho en C18 y C30 o en PICC de Hitech, va a ser mas facil usarlo en esos compiladores que portarlo a CCS.

Ojala puedas compartir tus experiencias y avances aqui en el hilo, asi podras enriquecerlo.

Saludos!! :mrgreen:


Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 16 de Junio de 2010, 08:51:52
Hola
Ante todo, muchas gracias por contestar, he buscado mucho por internet, y sin duda este es el mejor foro (y casi puedo decir unico) que trata Bus CAN que he encontrado.

Bien, en estos dias he progresado bastante sobre la programacion de PIC's en C. Buscando tutoriales sobre programacion en C de PIC's y practicas resueltas, he conseguido avanzar bastante sobre el uso de los puertos, transmision serie (USART), interrupciones, etc
Hablando con mi profesor, me recomendo usar el CCS, por lo que creo que ya es un poco tarde para cambiar de compilador :S, sin embargo, espero que esto no sea una gran trava para conseguir el objetivo!!
Todos las practicas que he hecho para familiarizarme con los PIC's las he realizado en CCS y usando el simulador PROTEUS.
Pero aun veo bastante lejos el poder programar un protocolo de comunicaciones basado en CAN sobre la placa.

Bien, empiezo a contarte:
La libreria que tengo es una que se ha comprado a la empresa alemana PORT, y me ha comentado que vale una pasta, por lo que aunque a mi no me importaria, comprenderas que me es imposible pasarla.

El objetivo global de nuestro proyecto, es controlar todos los sensores mediante CAN de un robot autonomo que realiza las funciones de un camion de bomberos.
Actualmente ya hay implementado un protocolo sobre J1939, por lo que lo primero que he hecho ha sido pedir dicho programa, para ver aspectos comunes que puedan ser reutilizados. Ya tengo este programa en mis manos.

Lo siguiente ha sido pedir el diseño de la placa sobre la que va a ir montado CANOpen, en formato electronico, para poder realizar simulaciones con el PROTEUS, ya que la placa, fisicamente hablando aun no esta terminada. Aun estoy a la espera de que me lo pasen. El pic que se va a utilizar es un PIC 18f2680, que cumple con los requisitos que me indicastes.

La norma CANOPen ya me la he leido, fue lo primero que hice.

Pues bien, voy a seguir tus indicaciones, y en los proximos dias voy a mirarme los post que considero que pueden ser mas interesantes. En cuanto a la nota que me dices de Microchip, he estado buscando, pero no se muy bien a cual te refieres...si pudieses pasarme el enlace...

Muchas gracias, y espero que sigamos en contacto.

Un saludo
Miguel Angel
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Junio de 2010, 09:18:00
Lastima lo de la libreria, seguramente podria ayudarte mas si pudiera ver de que se trata..

Respecto a la nota de aplicacion de Microchip, podras encontrarla aqui:
http://ww1.microchip.com/downloads/en/AppNotes/00945a.pdf (http://ww1.microchip.com/downloads/en/AppNotes/00945a.pdf)

Espero te sirva, esta hecha para C18, aunque en el foro de CCS haciendo una busqueda, tal vez consigas alguien que la haya portado a CCS. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Junio de 2010, 09:28:13
Creo que nadie le contesto al usuario del foro de CCS, ya que solo esta su pregunta...

http://www.ccsinfo.com/forum/viewtopic.php?t=32132&highlight=canopen+stack (http://www.ccsinfo.com/forum/viewtopic.php?t=32132&highlight=canopen+stack)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: f0raster0 en 20 de Junio de 2010, 16:20:45
Hola a todos y gracias por sus aportes que en conjunto forman una valiosa información..

Debo investigar el protocola CAN con el fin de leer datos de un Vehículo de transporte de pasajeros Mercedes Benz (autobus), he visto en el foro, primero un diseño para trabajar con CAN y un sistema para leer datos mostrandolos en un display..

¿Qué necesito del conector o del CAN BUS del vehículo para comenzar a pensar en lograr leer los datos en mi pc?

Claro que es una locura para un principiante, pero ya está a intentarlo.. ah¡¡¡ es recomendable la tarjeta de microchip  "MCP2515 CAN Bus Monitor Demo Board  Part Number: MCP2515DM-BM" ya la mostraron en el foro e inclusive un diseño basado en ella.. creo que la voy a pedir para comenzar a trabajar..

Gracias desde ya.. y espero pronto comenzar a aportar..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Junio de 2010, 18:55:39
Amigo.
Tu tema esta bien planteado, y si miras en detalle el hilo hubo aqui un forero que hizo esto que necesitas, incluso esta dando vueltas por alli el manual de uso de su equipo, que puede darte mucha ayuda a desarrollar el tuyo.

Se un poco paciente, no hay problema en plantear una pregunta, pero no te apures a esperar una respuesta inmediata ya que todos los foreros aqui contestan y aportan sobre los temas que pueden leer en sus ratos libres.

Si bien somos muchos, los temas que hay exceden la capacidad de lectura de cualquier persona.

Bienvenido al foro y te recomiendo leer bien las reglas del foro. :mrgreen:

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: fusaka en 05 de Julio de 2010, 17:38:35
MGLSOFT me gustaria que resolviera una duda estoy empezando a estudiar el can bus para hacerme un tarjeta de adquisición de datos y  estoy volviendo ha estudiar la programación y me gustaría saber si esas librerías que usas son solo para programar el pic e c
o sin pueden servir directamente el compiladores c para el ordenador
mi idea es  conectar los transceptores directamente en el rs-232 del pc y trabajar con el

y si sabes de algún sitio para bajarme librerías de can para c y visual basic

un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Julio de 2010, 17:59:30
Los transceptores en el puerto serie no funcionan, pero si podrias hacer una placa conectada al port paralelo.

Una pagina que tiene un SDK para PC es Kvaser, alli hay librerias para desarrollar con el MCP2515 del lado del PC.
Puedes encontrarlo aqui:
http://www.kvaser.com/index.php?option=com_php&Itemid=288&swprod=eae5254261d5021aef7b14601e756283&ean=0000000000000 (http://www.kvaser.com/index.php?option=com_php&Itemid=288&swprod=eae5254261d5021aef7b14601e756283&ean=0000000000000)

Deberas registrarte, pero te aseguro que no molestan luego con molestos mails. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 15 de Julio de 2010, 16:09:33
Hola amigos.

Llevo un tiempo leyendo este hilo y sinceramente os felicito, por lo profesionales, por lo ingeniosos y por lo mucho que sabeis y como lo compartis.

Mi objetivo en esta ocasión y como primera prueba para realizar futuros y más ambiciosos proyectos es el de comunicar dos PIC 18F4550 por una linea CAN.
Para ello dispongo de 2 entrenadoras de Microingenia con sus correspondientes targetas CAN donde se albergan el transceptor y controlador CAN.

Pretendo que se comuniquen del siguiente modo:

Nodo A: maestro.
Nodo B: esclavo.

Funcionamiento: En el momento que en el nodo A se accione un pulsador se enviará por CAN un byte que hará encerder 8 leds asociados a un puerto del nodo B.

Transcurridos unos segundos el nodo B enviará un bit al nodo A donde se prenderá un led verde como confirmación del envío.
Si esto no ocurriese se encerá un led rojo.

Bien, por ahora he escrito el código del MASTER, os pido vuestra colaboración para saber si estoy enviando y recepcionando correctamente.


//CANMASTER.C

#include "18F4550.h"
#include "can-mcp251x.c"
#define "can-18F4580.c"
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,NOBROWNOUT,PLL2,CPUDIV1,VREGEN,PUT,MCLR
#use delay(clock=48000000)
#define ON output_high
#define OFF output_low
#define BUTTON_PRESSED !input(BUTTON)
#define LEDV pin_B0
#define LEDR pin_B1
#define CAN_DO_DEBUG TRUE
#define set_250k_Baud TRUE


// Variables send can bus
struct rx_stat rxstat;
int32 rx_id;
int8 rx_len;
int buffer [8];

// Variables reception can bus
int32 tx_id;
int1 tx_rtr=0;
int1 tx_ext=1;
int8 tx_len=8;
int8 tx_pri=3;
int32 id=0;
int32 rx_id_resp=0;
int8 datos_slave=0;

// Other variables
int1 flag_rcvtrama=false;
int8 rcvchar=0;
int i;

void main()
{
   disable_interrupts(GLOBAL);
   disable_interrupts(INT_TIMER0);
   
   setup_timer_0(RTCC_DIV_2);
   
   enable_interrupts(GLOBAL);
   
   rx_id=id;
   tx_id=id;
   
   
   
   ON(LedR);
   OFF(LedV);
   delay_ms(1000);
   can_init();    // Init can bus
   ON(LedV);
   OFF(LedR);
   
   delay_ms(1000);
   OFF(LedV);
   OFF(LedR);
   
   for(i=0;i<8;i++){
   buffer=0;
   }
   
   while(TRUE)
   {
     
 
      if(can_kbhit())
      {
         can_getd(rx_id_resp, &datos_slave, rx_len, rxstat); // read data can bus
         
         if(rx_id_resp==rx_id)
         {
         disable interrupts(INT_TIMER0);
         OFF (LedR);
         ON (LedV);
         delay_ms(1000);
         OFF (LedV);
         }
      } 
     
     
      if(BUTTON_PRESSED)
      {
      while(BUTTON_PRESSED){}
      delay_ms(200);
      int32id=3;//id slave
     
      can_putd(int32id,0xFF,1,1,0,0);//send a byte=0xFF
      }
     
     
     

#int_Timer0    // if after 10ms from the sending no data is received, indicate the failure of communications lighting the red LED
void timer0(void)
{
   disable_interrupts(INT_TIMER0);
   ON(LedR);
}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Julio de 2010, 17:13:40
Código: C#
  1. //CANMASTER.C
  2.  
  3. #include "18F4550.h"
  4. #include "can-mcp251x.c"
  5.  
  6. #define "can-18F4580.c"                                      
  7. <<<<<<<<<<<<<<<<<<<<<<<<<<<<< que es esto ??
  8.  
  9. #fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,NOBROWNOUT,PLL2,CPUDIV1,VREGEN,PUT,MCLR
  10. #use delay(clock=48000000)
  11. #define ON output_high
  12. #define OFF output_low
  13. #define BUTTON_PRESSED !input(BUTTON)
  14. #define LEDV pin_B0
  15. #define LEDR pin_B1
  16. #define CAN_DO_DEBUG TRUE
  17. #define set_250k_Baud TRUE
  18.  
  19.  
  20. // Variables send can bus
  21. struct rx_stat rxstat;
  22. int32 rx_id;
  23. int8 rx_len;
  24. int buffer [8];
  25.  
  26. // Variables reception can bus
  27. int32 tx_id;
  28. int1 tx_rtr=0;
  29. int1 tx_ext=1;
  30. int8 tx_len=8;
  31. int8 tx_pri=3;
  32. int32 id=0;
  33. int32 rx_id_resp=0;
  34. int8 datos_slave=0;
  35.  
  36. // Other variables
  37. int1 flag_rcvtrama=false;
  38. int8 rcvchar=0;
  39. int i;
  40.  
  41. void main()
  42. {
  43.    disable_interrupts(GLOBAL);
  44.    disable_interrupts(INT_TIMER0);
  45.    
  46.    setup_timer_0(RTCC_DIV_2);
  47.    
  48.    enable_interrupts(GLOBAL);
  49.    
  50.    rx_id=id;
  51.    tx_id=id;  
  52. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  los dos id NO PUEDEN ser iguales !!!
  53.    
  54.    
  55.    
  56.    ON(LedR);
  57.    OFF(LedV);
  58.    delay_ms(1000);
  59.    can_init();    // Init can bus
  60.    ON(LedV);
  61.    OFF(LedR);
  62.    
  63.    delay_ms(1000);
  64.    OFF(LedV);
  65.    OFF(LedR);
  66.    
  67.    for(i=0;i<8;i++){
  68.    buffer[i]=0;
  69.    }
  70.    
  71.    while(TRUE)
  72.    {
  73.      
  74.  
  75.       if(can_kbhit())
  76.       {
  77.          can_getd(rx_id_resp, &datos_slave, rx_len, rxstat); // read data can bus  
  78. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< no encuentro el array datos en la declaracion !!
  79.          
  80.          if(rx_id_resp==rx_id)
  81.          {
  82.          disable interrupts(INT_TIMER0);
  83.          OFF (LedR);
  84.          ON (LedV);
  85.          delay_ms(1000);
  86.          OFF (LedV);
  87.          }
  88.       }  
  89.      
  90.      
  91.       if(BUTTON_PRESSED)
  92.       {
  93.       while(BUTTON_PRESSED){}
  94.       delay_ms(200);
  95.       int32id=3;//id slave
  96.      
  97.       can_putd(int32id,0xFF,1,1,0,0);//send a byte=0xFF  
  98. <<<<<<<<<<<<<  deberias cargar el dato a enviar en la primer posicion de un array de datos tipo byte, sino no funciona !!
  99.       }
  100.      
  101.      
  102.      
  103.  
  104. #int_Timer0    // if after 10ms from the sending no data is received, indicate the failure of communications lighting the red LED
  105. void timer0(void)
  106. {
  107.    disable_interrupts(INT_TIMER0);
  108.    ON(LedR);
  109. }


Creo que deberias arreglar estas cosas que son a primera vista las que pueden estar fallando.
Ademas te recomiendo poner el codigo del esclavo.

Saludos y adelante con el CAN !! :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 16 de Julio de 2010, 12:10:33
Hola; muchísimas gracias  :-/ :-/ MGLSOFT.

Estoy trabajando en el código del SLAVE pero antes he de retocar al MASTER.

Sobre lo escrito ayer;

La directiva #define "can-18F4580.c", , la coloco pues es la que trae el compilador de CCS por defecto y donde se encuentra la función can_set_baud(), la cual he modificado tal y como describias al principio del hilo para poder desde el main() poder escoger entre 125kb, 250 o 500kb. ¿Què hago, incluyo can_set_baud() modificada en 18f4550.h?

En cuánto a los id; ha sido un despiste, un gran despiste! :5] :5]. Correjizme si no estoy en lo cierto:
rx_id es el id de del NODO del que recibo la información.
tx_id es el id del NODO que envía la información.

En cuanto a las funciones can_getd() y can_putd() he leido la explicación que dabas pero tengo alguna duda:

can_getd(rx_id, &datos_slave, rxlen, rxstat)

"&datos_slave" es el puntero a los datos entrantes (recibo bit a bit) y lo tngo que declarar como variable de recepción: int8 datos_slave=0¿?¿?.
"rxlen": cantidad de datos a recibir.Yo recibo 1 byte. ¿Qé coloco aqui? ¿1 o 8?.

can_putd((tx_id , &datos_master, 1,1,0,0)

Por ejemplo si deseo enviar 0xFF  con el fin de activar la totalidad de un puerto del esclavo. Entonces primero declaro el array:

int8datos_master=0;
Después pongo el dato en la primera posición:

datos_master[0]=1;

La función can_getd() devuelve un "1" si hay datos en el BUS del rx_id correspondiente y "0" sino los hay.

La  función putd() devuelve "1" si se envía y "0" sino se hace el envío.

Esos flag si quiero utilizarlos en mi programa, ¿Cómo los consigo?, ¿Puedo preguntar directamente por can_putd, y can_getd como por cualquier otro int1 declarado por mi?, pejemplo:

if(can_getd==1)//hay datos en el bus
{..........}
else{....}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Julio de 2010, 15:06:50
Hola.
Vamos por partes, como dijo Jack...

La directiva deberias ponerla DENTRO de can-mcp251x.c , reemplazando el resto de la seleccion en Can_Set_Baud().

Quedaria algo asi:

Código: C
  1. #ifdef Set_125K_Baud {
  2.       BRGCON1 = 0x01;
  3.       BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 125 KBps
  4.       BRGCON3 = 0x07;      //con reloj a 10 MHz
  5.    }
  6.    #endif
  7.    
  8.    #ifdef Set_250K_Baud {
  9.       BRGCON1 = 0x00;
  10.       BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 250 KBps
  11.       BRGCON3 = 0x07;      //con reloj a 10 MHz
  12.    }
  13.    #endif
  14.    
  15.    #ifdef Set_500K_Baud {
  16.       BRGCON1 = 0x00;
  17.       BRGCON2 = 0x92;      //modificado 5/11/07 para usar CAN a 500 KBps
  18.       BRGCON3 = 0x02;      //con reloj a 10 MHz
  19.    }
  20.    #endif

Cuidado que esto es para usar un cristal de 10 Mhz llevando al pic a 40 Mhz con el bit de configuracion H4 activo.

Si usas el MCP2515 deberias calcular los valores de los bytes BRGCON1, 2 y 3 nuevamente segun el cristal que utilizes.
Recomiendo leer las hojas de datos de tus modulos CAN para saber cuales serian esos valores dependiendo del cristal con que esten equipados.


Respecto a tu siguiente pregunta:
can_getd(rx_id, &datos_slave, rxlen, rxstat)

"&datos_slave" es el puntero a los datos entrantes (recibo bit a bit) y lo tngo que declarar como variable de recepción: int8 datos_slave=0¿?¿?.
"rxlen": cantidad de datos a recibir.Yo recibo 1 byte. ¿Qé coloco aqui? ¿1 o 8?.

Depende en realidad de cuanto bytes envia el esclavo (eso lo programas vos), el minimo es un byte y el maximo es 8.
Solo hay un mensaje sin ningun byte y es cuando un dispositivo se arranca y envia un mensaje para avisar que esta listo.

En la funcion Can_Getd no puedes seleccionar cuantos bytes recibes, solo recibes y haces el conteo segun lo que viene en RxLen, se entiende??

La funcion que devuelve un 1 si hay trafico en el bus es:
 if ( can_kbhit() )

Si no se quiere utilizar se deben activar las interrupciones pero ese es un tema bastante mas complejo...

Respecto a como usar bits en este modo, te pongo un ejemplo de recepcion de un byte y el uso de cada bit de ese byte por separado.  (precisamente enciende tres leds dependiento del estado de cada bit.)  Es un ejemplo de CCS.

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) {  
  9.     //node C is an mcp250x0 which sends out a message upon edge detection on IO
  10.                printf("Chaning LEDs\r\n");            
  11.                //in_data[0]=iointfl, in_data[1]=gpio
  12.                a_leds=~(buffer[1]);
  13.                if (bit_test(a_leds,4)) {LED1_HIGH;} else {LED1_LOW;}
  14.                if (bit_test(a_leds,5)) {LED2_HIGH;} else {LED2_LOW;}
  15.                if (bit_test(a_leds,6)) {LED3_HIGH;} else {LED3_LOW;}
  16.             }
  17.          }
  18.       }

Aqui las definiciones de que es cada bit de esos:

Código: C
  1. #define PIN_LED1  PIN_A5
  2. #define PIN_LED2  PIN_B5
  3. #define PIN_LED3  PIN_B4
  4.  
  5. #define LED1_HIGH output_low(PIN_LED1)
  6. #define LED1_LOW  output_high(PIN_LED1)
  7. #define LED2_HIGH output_low(PIN_LED2)
  8. #define LED2_LOW  output_high(PIN_LED2)
  9. #define LED3_HIGH output_low(PIN_LED3)
  10. #define LED3_LOW  output_high(PIN_LED3)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 17 de Julio de 2010, 12:56:24
Hola MGLSOFT y a todos los que lean...

Hice lo que me dijiste de cambiar la función original can_set_baud() y con el bittiming calculé el valor de los registros BRGCON1, BRGCON2, BRGCON3 para las distintas velocidades. Lo hice a 125kbs, 250 y 500kbsy y 8MHz que es la frecuencia a la que trabaja el controlador MCP2515 de mi placa.
Queda así:
Código: [Seleccionar]
void can_set_baud(void){

#ifdef Set_125K_Baud {

     BRGCON1 = 0x01;

     BRGCON2 = 0xB8;      //modificado 17/07/10 para usar CAN a 125 KBps

     BRGCON3 = 0x05;      //con reloj a 8 MHz

  }

  #endif

 

  #ifdef Set_250K_Baud {

     BRGCON1 = 0x00;

     BRGCON2 = 0xB8;      //modificado 17/07/10 para usar CAN a 250 KBps

     BRGCON3 = 0x05;      //con reloj a 8 MHz

  }

  #endif

 

  #ifdef Set_500K_Baud {

     BRGCON1 = 0x00;

     BRGCON2 = 0x90;      //modificado 17/07/10 para usar CAN a 500 KBps

     BRGCON3 = 0x02;      //con reloj a 8 MHz

  }

  #endif
 
}

Me dices que tengo que intruducir la directiva #define"can-18F4580" dentro de can-mcp251x.c?????
Por otro lado cuando habro can-mcp251x.c me aparecé con el nombre can-mcp2510.c.  Yo traabajo con un MCP2515; vale la libreria???

El código del maestro lo tengo así, pero me sigue dando errores al compilar; ecahzle un vistazo, por favor:

Código: [Seleccionar]
//CANMASTER.C

#include "18F4550.h"
#include "can-mcp251x.c"
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,NOBROWNOUT,PLL2,CPUDIV1,VREGEN,PUT,MCLR
#use delay(clock=8000000)

#define ON output_high
#define BUTTON PIN_B2
#define OFF output_low
#define BUTTON_PRESSED !input(BUTTON)
#define LEDV pin_B0
#define LEDR pin_B1
#define CAN_DO_DEBUG TRUE
#define set_250k_Baud TRUE


// Variables send can bus
struct rx_stat rxstat;
int32 rx_id;
int8 rx_len;

// Variables reception can bus
int32 tx_id;
int1 tx_rtr=0;
int1 tx_ext=1;
int8 tx_len=8;
int8 tx_pri=3;
int32 id=0;
int32 rx_id_resp=0;
int8 datos_slave=0;
int8 datos = 1
// Other variables
//int1 flag_rcvtrama=0;
//int8 rcvchar=0;
int u;
int e;


void main()
{
   disable_interrupts(GLOBAL);
   disable_interrupts(INT_TIMER0);
   
   setup_timer_0(RTCC_DIV_2);
   
   enable_interrupts(GLOBAL);
   
   rx_id_resp=3; //id del esclavo, del que quiero recibir datos (para el ejmplo el único que hay)
   tx_id=1;//id del maestro
 
   ON(LedR);
   OFF(LedV);
   delay_ms(1000);
   can_init();    // Init can bus
   ON(LedV);
   OFF(LedR);
   
   delay_ms(1000);
   OFF(LedV);
   OFF(LedR);
   
  for(e=0;e<8;e++){
   datos[e]=1;
   }
   
  for(u=0;u<8;u++){
   datos_slave[i]=1;
   }
   ///////////////////////////////////////main
   while(TRUE)
   {
     
      if(can_kbhit())
      {
         can_getd(rx_id, &datos_slave[0], rx_len, rxstat); // read data can bus
         
         if(rx_id_resp==rx_id)
         {
         disable interrupts(INT_TIMER0);
         OFF (LedR);
         ON (LedV);
         delay_ms(2000);
         OFF (LedV);
         }
      } 
     
     
      if(BUTTON_PRESSED)
      {
      while(BUTTON_PRESSED){}
      delay_ms(200);
   
      can_putd(tx_id,&datos[0],1,1,0,0);//send a byte=0xFF
      }
     
   }//while
}//main
     
     
   

#int_Timer0    // if after 10ms from the sending no data is received, indicate the failure of communications lighting the red LED
void timer0(void)
{
   disable_interrupts(INT_TIMER0);
   ON(LedR);
}


Gracias, amigos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Julio de 2010, 08:52:07
Dejame ver y probar algunas cosas de tus ejemplos, que ahora caigo que los bajaste del sitio de Microingenia.
Como no se puede simular en Proteus, voy a tener que armar el hardware aunque sea en una proto, para ver donde estan los bugs.

Has probado los ejemplos tal cual vienen en su pagina, sin quitar ni agregar nada??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 19 de Julio de 2010, 10:42:55
Hola MGLSOFT!!!!

Mis protoboards son de "Microingenia", fabulosas, por cierto.

No probe los ejemplos tal cual, ya que es para una comunicación usb-can.

Lo que pretendo es hacerla, can-can.

Más tarde, en cuanto el trabajo me lo permita, pongo el código del SLAVE y por supuesto desde aquí seguiré probando y probando.
Muchas gracias por tu interés.... Seré el ser más feliz del mundo cuando vea prender esos leds.

Atentamente, un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Julio de 2010, 12:17:08
Hola MGLSOFT!!!!

Mis protoboards son de "Microingenia", fabulosas, por cierto.

No probe los ejemplos tal cual, ya que es para una comunicación usb-can.

Lo que pretendo es hacerla, can-can.

Más tarde, en cuanto el trabajo me lo permita, pongo el código del SLAVE y por supuesto desde aquí seguiré probando y probando.
Muchas gracias por tu interés.... Seré el ser más feliz del mundo cuando vea prender esos leds.

Atentamente, un saludo

El ejemplo reemplaza lo que seria una comunicacion a PC serial por una USB, pero por lo que leo escribe en el modulo esclavo usando el BUS CAN.

Pruebalo completo asi como viene, no deberias tener problemas.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 21 de Julio de 2010, 10:42:20
hola; estoy probando, pero tengo algún que otro problemilla. En cuanto salga algo, lo comparto.

Saludos y muchas gracias MGLSOFT
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Julio de 2010, 11:10:14
hola; estoy probando, pero tengo algún que otro problemilla. En cuanto salga algo, lo comparto.

Saludos y muchas gracias MGLSOFT
Que tipo de problemitas??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 21 de Julio de 2010, 11:35:15
Nada relacionado con el CAN.

Alguna de las entrenadoras no va bien; ando reinstalando los drivers en otro equipo para probarlo de nuevo.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 22 de Julio de 2010, 12:39:03
Hola!!! :-/

Solucione los problemillas de mis entrenadoras. Me había "cargado" el bootloader; lo programe de nuevo por el ICSP con mi Winpic800 y listo. Probe el ejmplo de Microingenia y va bien.

Seguiré con el ejemplo de comunicación CAN entre dos nodos; que me había planteado.

Cuando salga algo, o no salga daré noticias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Julio de 2010, 14:20:07
Deberas prestar atencion al tema de los ID de los esclavos, ya que me parece que por alli hay un problema.
En la conexion 1 a 1 (1 Maestro y 1 esclavo) anda bien, porque el maestro es cero y el no va a contestar su propio requerimiento, pero cuando haya mas de un esclavo en el bus, ahi ya no podria funcionar de ningun modo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: kR105 en 23 de Julio de 2010, 00:48:33
Estimados, odio cuando mi primer post en un foro es pidiendo ayuda jaja pero este tema me tiene intrigadisimo y necesito un empujoncito  :)

Tengo un PIC 18F4685 y quiero comunicarlo con el puerto CAN/OBDii de mi auto, he visto que se puede hacer, pero lo que quiero no es pasarle los datos al PC sino que manejarlos directamente en el pic (dependiendo de los datos leidos, manejar un relay, leds, lcd, etc). ¿Es posible hacer eso solo usando el pic? (Estoy tratando de no usar la elm327). ¿Puedo hacer eso con pics mas pequeños o necesito uno con ecan?

Muchas gracias y disculpen por desviar el tema, pero como aca hablan de esto, consideré que es el mejor lugar :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 23 de Julio de 2010, 11:53:16
Hola kR105; yo también soy principiante en la comunicaión CAN y te aseguro que en este foro aclararás muchas dudas (da un vistazo al post, es extenso hasta llegar a las líneas que ahora escribo).

Por lo que he leído aquí, si el PIC no dispone de CAN integrado has de utilizar un controlador (p.e:MCP2515) y un trasnceptor (p.e:MCP2551). En caso contrario has de utilizar al menos el trasceptor. No olvides colocar en paralelo una resistencia de 120ohmios en los extremos de la línea.

Att,
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 26 de Julio de 2010, 15:39:44
Hola amigos; después de poner todo en marcha; me costo por la poca experiencia he conseguido que funcione el siguiente ejemplo:

<COMUNICACION CAN 2 NODOS>

NODO A->ID=0 MAESTRO
NODO B->ID=1 ESCLAVO

Cuando se pulse una tecla en NODO A (b2) se envia un byte(0xFF) al NODO B lo que hace encender durante 4 segundos los leds asociados al puerto D (nodo B).

El NODO B envía un acuse de recibo al NODO A encenciendo un led asociado a un puerto de dicho nodo.


El código para CCS:

Código: [Seleccionar]
//CANMASTER.C


#include "config18F4550Trainer.c"
#include "usb/usb_cdc.h"
#include "usb/usb_bootloader.h"
#include "can/can-mcp251x.c"

#define BUTTON PIN_B2
#define BUTTON_PRESSED !input(BUTTON)

// Variables send can bus
struct rx_stat rxstat;
int32 rx_id;
int8 rx_len;

// Variables reception can bus
int32 tx_id;
int1 tx_rtr=0;
int1 tx_ext=1;
int8 tx_len=7;
int8 tx_pri=3;
int32 id=0;//del maestro
int32 rx_id_esclavo=1;
int8 datos=0;
int8 datos_slave=0;




void main()
{
   tx_id=id;
   
   disable_interrupts(GLOBAL);
   disable_interrupts(INT_TIMER0);
   
   setup_timer_0(RTCC_DIV_2);
   
   enable_interrupts(GLOBAL);
   datos=0xFF;
   ON(LEDV);
   OFF(LEDR);
   delay_ms(800);
   ON(LedR);
   OFF(LedV);
   delay_ms(800);
   ON(LedV);
   OFF(LedR);
   can_init();    // Init can bus
 
     
   while(TRUE)
   {
     
      if(can_kbhit())
      {
         can_getd(rx_id, &datos_slave, rx_len, rxstat); // read data can bus
         
         if(rx_id_esclavo==rx_id)
         {
         disable_interrupts(INT_TIMER0);
         ON (LedR);
         ON (LedV);//verde&rojo=amarillo
         delay_ms(2000);
         OFF (LedR);
         OFF (LedV);
         
         }
      } 
     
     
      if(BUTTON_PRESSED)
      {
      while(BUTTON_PRESSED){}
      delay_ms(200);
   
      can_putd(tx_id,&datos,tx_len,tx_pri,tx_ext,tx_rtr);//send a byte=0xFF
      }
     
   }//while
}//main
     
     
   

#int_Timer0    // if after 10ms from the sending no data is received, indicate the failure of communications lighting the red LED
void timer0(void)
{
   disable_interrupts(INT_TIMER0);
   ON(LedR);
}

Código: [Seleccionar]
//CANSLAVE


#include "config18F4550Trainer.c"
#include "usb/usb_cdc.h"
#include "usb/usb_bootloader.h"
#include "can/can-mcp251x.c"
//#use fast_io(D)




// Variables send can bus
struct rx_stat rxstat;
int32 rx_id;
int8 rx_len;

// Variables reception can bus
int32 tx_id;
int1 tx_rtr=0;
int1 tx_ext=1;
int8 tx_len=7;
int8 tx_pri=3;
int32 rx_id_maestro=0;
int32 id = 1;//del esclavo
int8 datos = 0;
int8 datos_slave=0;

void main()
{
 
   tx_id=id;
   datos_slave=0x01;
   can_init(); // Init can bus
   
   ON(LedV);
   OFF(LedR);
   
   while(TRUE)
   {
      if ( can_kbhit() ) // check for data on the can bus
      {
         can_getd(rx_id, &datos, rx_len, rxstat); // read data can bus
         
         if (rx_id_maestro == rx_id)
         {
           OFF(LedV);
           ON (LedR);
       
           ON (pin_D0);
           ON (pin_D1);
           ON (pin_D2);
           ON (pin_D3);
           ON (pin_D4);
           ON (pin_D5);
           ON (pin_D6);
           ON (pin_D7);
           
           delay_ms(4000);
           OFF (LedR);
       
           OFF (pin_D0);
           OFF (pin_D1);
           OFF (pin_D2);
           OFF(pin_D3);
           OFF (pin_D4);
           OFF (pin_D5);
           OFF (pin_D6);
           OFF (pin_D7);
           
         }
         can_putd(tx_id, &datos_slave, tx_len,tx_pri,tx_ext,tx_rtr); //acuse de recibo
      }
   }
}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Julio de 2010, 15:57:19
No esta mal, deberia funcionar OK.
El unico detalle es que transmites y recibes 7 Bytes, no uno.
Como en la funcion de recepcion recibes los mismos bytes no te dara error, pero debes practicar enviando y recibiendo con diferentes cantidad de bytes (entre 1 y 8) para ver como se comporta la cosa.

No importa si los datos son diferentes, en un solo mensaje puedes enviar y recibir hasta 8 Bytes de diferente origen o 4 words o 2 doble words, y rearmar en la interpretacion de tu respuesta nuevamente los datos.
Hasta una flotante podrias enviar.. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 27 de Julio de 2010, 08:19:28
Bien, así lo haré... prácticaré a enviar mensajes con mayor o menor cantidad de bytes.

Me surge una duda y no encontré la información necesaria en el datasheet.

Trabajando con el primitivo 16f84 si pongo la directiva #byte PORTB=0X06

puedo luego manejar todo el puerto de un plumazo y en este caso me interesaria mucho, ya que en el momento de recibir el byte puedo volcarlo directamente sobre el puerto, sin ir uno a uno:

PORTD=*datos;

Gracias, saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Julio de 2010, 08:33:05
Recuerda que la variable datos alli esta manejada por un puntero, que lee hasta la posicion que tu le mandas leer, en este caso 7.

La mejor forma es manejarse con el byte especifico que quieres mostrar, ya que si manejas el puntero vas a mostrar el ultimo byte leido y eso cambiara segun la cantidad usada.

lo mejor sera usar esta forma de mostrarlo:
Código: C
  1. PortB=datos[0] // en caso de usar el primer byte
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 27 de Julio de 2010, 15:48:26
Hola, he probado lo que me dices, pero el compilador me dice que "datos debe ser definida como puntero"; yo defino datos como int8; como un byte en memoria.

El único modo de cargar lo que llega al esclavo a través del bus es con:

Código: [Seleccionar]
output_D(datos);

Por otro lado aunque compila, no hace efecto en todo lo referente a manejar el puerto D con la siguente instrucción:

Código: [Seleccionar]
PORTD=0XFF; // un ejemplo
PORTD=datos;//otro ejemplo que con output_D() si tiene efecto

Al principio ya no compilaba Y daba error en "PORTD" como no definido.

Al principio del programa añadí:

Código: [Seleccionar]
#use standard_io(D)
#byte PORTD = 0x00
no se si es correcto;

Gracias; toda ayuda se agradece para manejar eficientemente lo que llega por el bus.

Att,
 :-/ :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Julio de 2010, 15:54:54
 :D :D :D :D :D :D :D

El 16f84 no tiene portD, no interesa si lo defines o no !!! :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: daltonico82 en 28 de Julio de 2010, 03:58:49
Hola; en efecto, sé que el 16f84 no tiene puerto D. Tiene 6 pines de A y el puerto B completo.

Mi pregunta es como defino el pueto D para el 18f4550 para manejarlo entero.

Y más concretamente me refiero a que:

Código: [Seleccionar]
PORTD=datos[0], no va.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Julio de 2010, 08:15:00
Ahhh!!
Bien , entendi mal, crei que te referias al 16f84...

Los puertos de la linea PIC18 estan en otras direcciones.

Una forma que permite configuracion automatica seria usando getenv()

Quedaria mas o menos asi:
Código: C
  1. #byte PORTD =  getenv("SFR:PORTD")     //portd

Citar
SFR:name
 Returns the address of the specified special file register. The output format can be used with the preprocessor command #bit. name must match SFR denomination of your target PIC (example: STATUS, INTCON, TXREG, RCREG, etc)
 

La otra es ir a la hoja de datos y leer cual es la direccion donde esta PortD.
La primera es mejor porque si el puerto existe automaticamente devuelve la direccion del mismo. (no hay que trabajar tanto) :mrgreen: :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: sergio_silva en 19 de Agosto de 2010, 20:26:37
Hola, tengo una pregunta:

en la funcion: can_getd(): ----> int1 can_getd(int32 & id, int * data, int & len, struct rx_stat & stat)

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.

si el id contiene el ID del PIC que enviou el mensaje, entonces está mal hacer:

if(can_kbhit())
      {
         can_getd(rx_id, &datos_slave, rx_len, rxstat); // read data can bus
         
         if(rx_id == id_PIC)
         {

porque id_PIC es el id del PIC que recebe el mensaje, no del PIC que envia, pero en mi codigo funciona bien assim  :huh: :huh: :huh:.

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Agosto de 2010, 22:12:37
Hola Sergio.
Si funciona es porque el PIC que envia el mensaje esta solo en el bus, junto al master que lo recibe.
Como la comparacion la pasa bien, es normal que lo reciba...

Mira lo que hace el codigo:

Eso da bien en la comparacion del tercer punto, por lo tanto no constata otra cosa...

Preguntame si eso esta bien, te dire que no, ya que no debe haber dos ID iguales en el BUS, porque contestarian ambos a la vez, sin funcionar el arbitraje, que precisamente lo que hace es discriminar entre dos ID muy parecidos para saber cual puede responder, por lo tanto es un error grave tener dos ID iguales!!!

Como se hace en la practica??
Es mas facil que esto ni siquiera llegue al PIC, o sea que la decision de cual ID se recibe o no, se hace a traves de los filtros (mascaras logicas) aplicadas a los bufferes de recepcion.

O sea que en un PIC determinado ni siquiera necesito saber si el mensaje es de un ID determinado, ya que puedo filtrarlo sin que ese mensaje llegue siquiera a un buffer de recepcion.

Se entiende?? :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: sergio_silva en 20 de Agosto de 2010, 07:51:02
Hola MGLSOFT, gracias por la explicación.

Quanto a los filtros, sei que há una funcion para isso, a can_set_id();

Si yo quiero que el ID de PIC seja 200, para activar los filtros está correcto hacer:
( yo uso el modo extendido)


#define ID 200;

void main()
{

 can_init();       
   
 can_set_mode(CAN_OP_CONFIG);

 can_set_id(RX0MASK, 0x1FFFFFFF, 1);  //set mask 0
 can_set_id(RX0FILTER0, ID, 1);  //set filter 0 of mask 0
 can_set_id(RX0FILTER1, ID, 1);  //set filter 1 of mask 0

 can_set_id(RX1MASK, 0x1FFFFFFF, 1);  //set mask 1
 can_set_id(RX1FILTER2, ID, 1);  //set filter 0 of mask 1
 can_set_id(RX1FILTER3, ID, 1);  //set filter 1 of mask 1
 can_set_id(RX1FILTER4, ID, 1);  //set filter 2 of mask 1
 can_set_id(RX1FILTER5, ID, 1);  //set filter 3 of mask 1

 can_set_mode(CAN_OP_NORMAL);

(...)

Saludos

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Agosto de 2010, 08:48:35
Los filtros son para la recepcion de mensajes, para filtrar mensajes en un bus complicado con mucha mensajeria.
En una aplicacion hasta 5 dispositivos es mejor filtrar por ID como estabas haciendo antes, ya que de otro modo es dificil que puedas hacer un buen debug de tu aplicacion (los mensajes que son filtrados ni siquiera se ven).
Título: Comunicacion CANOpen
Publicado por: conilete en 26 de Agosto de 2010, 07:36:11
Muy buenas a los usuarios de este magnifico foro,

Citar
Hola a todos.
Trabajo en un departamento de investigacion, y estamos trabanjando con un robot con una serie de sensores controlados mediante bus CAN.
Me han encargado realizar el siguiente trabajo:
Me han pasado una libreria de comunicaciones basada en CANOpen, y debo programar el controlador de una placa para controlar una serie de sensores. Estoy a la espera de que me den el PIC sobre el que se va a realizar el trabajo.
Dispongo de dos herramientas: el CAN Analyzer y el CAN Case XL.
No tengo experiencia en la programacion de PIC's, por lo que os pido consejo sobre cuales serian los primeros pasos que debo realizar y que documentacion debo ir mirando primero.
Segun he visto por Internet, es necesario usar el software CANOpen Design Tool y el CANOpen Device Manager...¿me equivoco?
Otro aspecto que me gustaria aclarar, es si el compilador que debo usar es el CCS.
Un saludo, y espero vuestra ayuda en forma de comentarios.
Muchas gracias


Este mensaje lo escribi hace un par de meses.

Citar
Hola
Ante todo, muchas gracias por contestar, he buscado mucho por internet, y sin duda este es el mejor foro (y casi puedo decir unico) que trata Bus CAN que he encontrado.

Bien, en estos dias he progresado bastante sobre la programacion de PIC's en C. Buscando tutoriales sobre programacion en C de PIC's y practicas resueltas, he conseguido avanzar bastante sobre el uso de los puertos, transmision serie (USART), interrupciones, etc
Hablando con mi profesor, me recomendo usar el CCS, por lo que creo que ya es un poco tarde para cambiar de compilador :S, sin embargo, espero que esto no sea una gran trava para conseguir el objetivo!!
Todos las practicas que he hecho para familiarizarme con los PIC's las he realizado en CCS y usando el simulador PROTEUS.
Pero aun veo bastante lejos el poder programar un protocolo de comunicaciones basado en CAN sobre la placa.

Bien, empiezo a contarte:
La libreria que tengo es una que se ha comprado a la empresa alemana PORT, y me ha comentado que vale una pasta, por lo que aunque a mi no me importaria, comprenderas que me es imposible pasarla.

El objetivo global de nuestro proyecto, es controlar todos los sensores mediante CAN de un robot autonomo que realiza las funciones de un camion de bomberos.
Actualmente ya hay implementado un protocolo sobre J1939, por lo que lo primero que he hecho ha sido pedir dicho programa, para ver aspectos comunes que puedan ser reutilizados. Ya tengo este programa en mis manos.

Lo siguiente ha sido pedir el diseño de la placa sobre la que va a ir montado CANOpen, en formato electronico, para poder realizar simulaciones con el PROTEUS, ya que la placa, fisicamente hablando aun no esta terminada. Aun estoy a la espera de que me lo pasen. El pic que se va a utilizar es un PIC 18f2680, que cumple con los requisitos que me indicastes.
La norma CANOPen ya me la he leido, fue lo primero que hice.

Pues bien, voy a seguir tus indicaciones, y en los proximos dias voy a mirarme los post que considero que pueden ser mas interesantes. En cuanto a la nota que me dices de Microchip, he estado buscando, pero no se muy bien a cual te refieres...si pudieses pasarme el enlace...

Este fue mi ultimo mensaje escrito en este foro.
Me fui de vacaciones, y la verdad que estaba bastante desanimado, pero he vuelto con energias renovadas.
Lo que me da rabia es que no puedo aprovechar al maximo las posibilidades que me da este foro, puesto que casi todos los proyectos que aqui aparecen se basan en librerias de CAN publicas, y la comunicacion se basa en el envio de mensajes a traves de mascaras y filtros.
En CANOpen, toda las comunicaciones se realizan a traves del diccionario de objetos, en el que se encuentran todos los nodos de la red, y los servicios asociados.
La herramienta que he encontrado para diseñar dicho diccionario de objetos es la CANOpen Design Tool. Yo tengo la version demo, que me descargado de la pagina de Port. Con esta version, se pueden crear 10 objetos. Si queremos ampliarlo, debemos hacerlo ya a mano.

¿Podriais ayudarme a crear un diccionario de objetos lo mas simple posible, unicamente para poder enviar una trama a traves de la red CANOpen?

Si quereis, puedo dejar el esquematico del nodo CAN que va a controlar los sensores de la red, que es el que dispongo.


Espero vuestros comentarios, y aver si entre todos avanzamos un poco en este protocolo.
Muchas gracias de antemano

Miguel Angel
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Agosto de 2010, 08:09:30
El diccionario de objetos del cual hablas no es mas ni menos que un conjunto de parametros y valores a leer del dispositivo CanOpen que vas a crear.
Claro que lo que hace ese software es mapear esas variables a direcciones CanOpen validas, para que no tengas que leerte una parva de libros sobre CanOpen.

Respecto al uso de librerias, es dificil ayudarte sin conocer que cosas tiene.
Seguramente debe haber un ejemplo funcional junto a esa libreria, el sentido comun indica que arranques usando esos ejemplos hasta aprender como es la cosa...

El esquematico de la placa servira para aclararte si hay algun error de diseño en tu esclavo CanOpen.

Bienvenido de nuevo al foro... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 26 de Agosto de 2010, 08:32:38
Pero es que la comunicacion mediante CANOpen se basa en aspectos muy diferentes a los que se habla a lo largo de las 42 paginas de este foro.
El modelo de comunicaciones CANOpen define 4 tipos de mensajes (objetos de comunicacion):
- Objetos administrativos: mensajes para la configuracion de las distintas capas de la red asi como la inicializacion.
- Service Data Objetcts (SDO): leer o escribir cualquiera de las entradas del diccionario de objetos
- Process Data Object (PDO): para el intercambio de datos de proceso
- Mensajes predefinidos: de sincronizacion, de emergencia y de time stamp.

La placa de la que dispongo consta de un PIC18F2680, un transceiver MCP2551, la interfaz RS-232: MAX3232, un regulador de voltaje, etc
Tengo el diseño imprimido en una pagina, pero no en formato electronico...pero podria conseguirlo

Una pregunta...si mi placa es la que va a controlar los sensores y recoger la informacion que estos den, sera un master CANOpen, no un esclavo no?

Lo que quiero es empezar a programar algo ya, por lo tanto te pediria que me indicases por favor, que seria lo que haria falta para realizar una simple comunicacion CANOpen entre mi placa y el sensor, y entonces vemos las funciones de la libreria que serian necesarias.

Miguel Angel
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Agosto de 2010, 08:51:40
Pero es que la comunicacion mediante CANOpen se basa en aspectos muy diferentes a los que se habla a lo largo de las 42 paginas de este foro.
El modelo de comunicaciones CANOpen define 4 tipos de mensajes (objetos de comunicacion):
- Objetos administrativos: mensajes para la configuracion de las distintas capas de la red asi como la inicializacion.
- Service Data Objetcts (SDO): leer o escribir cualquiera de las entradas del diccionario de objetos
- Process Data Object (PDO): para el intercambio de datos de proceso
- Mensajes predefinidos: de sincronizacion, de emergencia y de time stamp.

La placa de la que dispongo consta de un PIC18F2680, un transceiver MCP2551, la interfaz RS-232: MAX3232, un regulador de voltaje, etc
Tengo el diseño imprimido en una pagina, pero no en formato electronico...pero podria conseguirlo

Una pregunta...si mi placa es la que va a controlar los sensores y recoger la informacion que estos den, sera un master CANOpen, no un esclavo no?

Lo que quiero es empezar a programar algo ya, por lo tanto te pediria que me indicases por favor, que seria lo que haria falta para realizar una simple comunicacion CANOpen entre mi placa y el sensor, y entonces vemos las funciones de la libreria que serian necesarias.

Miguel Angel

Si ya lo se, el BUS CAN es solo el medio fisico de CanOpen, lo que hace CanOpen es encargarse de la capa de software del modelo ISO.

Si quieres puedes escanearlo y ponerlo aqui o subirlo a imageshack y aqui pegar el link marcado con direct link.
Para pegar la imagen usas el cuarto icono de la barra que ves arriba al escribir un mensaje, que sirve para pegar imagenes de otros sitios.

Respecto a si es Master, por supuesto sera un Master si va a comunicarse con un esclavo, y respecto al esclavo, no se que tipo de sensor sera en que tienes...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 30 de Agosto de 2010, 06:47:07
Aqui tienes el esquematico de mi placa:
(http://img339.imageshack.us/img339/7334/p100830104800.th.jpg) (http://img339.imageshack.us/i/p100830104800.jpg/)

El problema es que no dispongo del conexionado de los elementos de los que consta.

Te mando una foto de la placa en cuestion, para aclarar cualquier tipo de duda sobre los componentes.
(http://img838.imageshack.us/img838/8109/image171330722.th.jpg) (http://img838.imageshack.us/i/image171330722.jpg/)


Estoy ocupado ahora con generar un diccionario de objetos para la comunicacion.
Como te dije, uso el CANOpen Design Tool.
Para crear el diccionario de objetos, debemos rellenar los siguientes apartados:
- General Settings: sin problemas...
- General EDS/XDD Settings: tengo dudas...parece que son datos administrativos...
- Hardware comunications: referente al hardware implicado en la comunicacion, sin problemas...
Linea CAN:
- EDS/XDD Settings: ¿?
- Aditional Settings: Mirando ejemplos que se incluyen al instalar la demo, en todos aparece vacio
- Objetct Dictionary: Necesitaria algo de ayuda para rellenar todos los campos...

Asi pues, si pudieses ayudarme a crear un pequeño diccionario de objetos para unicamente comunicar mi nodo con un sensor, enviandole unicamente una trama de datos...seria fantastico.

Posteriormente, con la ayuda de la libreria, dispongo de funciones para la lectura y escritura de esos elementos del diccionario de objetos.

Bueno, espero vuestros comentarios

Muchas graciasss!!

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Agosto de 2010, 08:02:59
Ok, debere bajar nuevamente el software ya que la maquina que lo tiene magicamente le dejo de funcionar el monitor por lo que fue a reparacion, deberas tener un poco de paciencia, si?? :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 31 de Agosto de 2010, 06:41:57
Por supuesto Marcos...pero eso te pasa por comprar monitores tan baratos  :lol: :lol:

Te cuento, lo que buscamos es unicamente que nuestro nodo mande tramas de datos.
Dispongo de varias herramientas, el CANcaseXL y el CANAnalyzer para luego monitorizar esas tramas y ver si se esta haciendo de forma correcta.
Ya los tengo instalados en mi equipo.
Pero tengo una duda, el hardware que trae estas herramientas, tiene un conector con el mismo tipo de salida CANL y CANH que trae la placa. ¿Como lo conecto entonces para monitorizar las tramas que voy a estar mandando?

Te mando una foto de dicho hardware.
(http://img411.imageshack.us/img411/4209/p100831113854.th.jpg) (http://img411.imageshack.us/i/p100831113854.jpg/)


Como siempre, muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2010, 08:10:09

Pero tengo una duda, el hardware que trae estas herramientas, tiene un conector con el mismo tipo de salida CANL y CANH que trae la placa. ¿Como lo conecto entonces para monitorizar las tramas que voy a estar mandando?


Es simple, siempre en el Bus se conecta CanH con CanH y CanL con CanL de cada dispositivo, los dos hilos (que deberian ser retorcidos para mantener su inmunidad electromagnetica) viajan solos en todo el recorrido.
Para pruebas y con cableados cortos no importa si el cable esta retorcido o no, ni siquiera molesta si estan o no puestas las resistencias de fin de linea, al menos cuando es una conexion punto a punto.
Para conexiones multipunto, aunque sean cortas, ya empieza a tomar todas las precauciones.... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 31 de Agosto de 2010, 08:16:26
No te he entendido bien Marcos...el conector no me permite unir CANH con CANH y CANL con CANL. Debo quitar el conector del hardware que te mostre anteriormente y retorcer los cables en las salidas del conector CAN de la placa??

No se muy bien lo que quieres decir....

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2010, 09:18:53
No te he entendido bien Marcos...el conector no me permite unir CANH con CANH y CANL con CANL. Debo quitar el conector del hardware que te mostre anteriormente y retorcer los cables en las salidas del conector CAN de la placa??

No se muy bien lo que quieres decir....



Esto:

(http://a.imageshack.us/img413/1471/conexioncanbus.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 31 de Agosto de 2010, 09:44:38
Lo he entendido, quitare el conector que trae el hardware de monitorizacion de tramas CAN para poder conectarlo a la salida CAN de mi placa.

En cuanto al diccionario de objetos para hacer el envio de una trama por parte de mi placa que te comente en mensajes pasados, he pensado en usar el ejemplo s1 que viene con el software CANOpen Design Tool.

http://www.gigasize.com/get.php?d=3yrm8751vmb

¿Que te parece? Pienso que podria valernos para empezar...

¿Has visto el diagrama electrico de los componentes de la placa y la foto de la placa en cuestion? ¿Que te parece?

Un saludo y gracias por la dedicacion.



Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2010, 11:17:59
No hay forma, no lo puedo descargar de esa pagina, esta bloqueada en mi proxy...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 31 de Agosto de 2010, 12:05:40
Aver si puedes por aki:

http://www.megaupload.com/?d=NVLOLXLN
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2010, 12:08:58
Esta es la contestacion de Megaupload:

Citar
El archivo al que está intentando acceder está temporalmente desactivado.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2010, 12:10:12
Esta es la contestacion de Megaupload:

Citar
El archivo al que está intentando acceder está temporalmente desactivado.

Olvide decir que en ambos casos de refiere a s1.html, que no se porque es un html... :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 31 de Agosto de 2010, 12:21:35
Tienes razon, te paso el archivo .can que general el diccionario de objetos

http://rapidshare.com/files/416258666/s1.can

Echale un vistazo y cuentame aver que tal te parece
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2010, 21:47:12
Al fin pude abrirlo!!
En realidad ese ejemplo es sobre la linea de Freescale, lo has adaptado para tu linea??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 01 de Septiembre de 2010, 06:06:01
Bueno, simplemente habria que cambiar la configuracion de hardware, en la pestaña correspondiente, no? En vez de un freescale, habria que poner en CPU Settings  la familia Microchip PIC...

¿Que te parecen los objetos que se crean para el diccionario? ¿Son suficientes para realizar una rutina CANOpen con un minimo de funcionalidad?

¿Has generado los archivos necesarios que habra que incluir en el codigo a realizar?

Tengo otra pregunta, que es necesaria para aclarar conceptos:
Yo anteriormente habia realizado una aplicacion que corre en el PC para monitorizar las tramas de un protocolo J1939 que ya estaba implementado por otra persona. Cuando termine de implementar el protocolo CANOpen, debere ampliar esa aplicacion para que tambien monitorice las tramas enviadas usando este protocolo. Esta aplicacion se comunica con los sensores y la placa donde estaba montado el j1939 por puerto serie, y de la misma forma lo hara con la placa sobre la que va a ir montada CANOpen.

Entonces, la pregunta es: ¿Quien es aqui el esclavo, y quien es el maestro?
Es una cuestion que no tengo clara totalmente y me gustaria conocer para evitar cualquier tipo de confusion.

Weno Marcos, espero tu respuestaaa!!
Un saludoo desde España
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Septiembre de 2010, 08:59:14
Bueno, simplemente habria que cambiar la configuracion de hardware, en la pestaña correspondiente, no? En vez de un freescale, habria que poner en CPU Settings  la familia Microchip PIC...

¿Que te parecen los objetos que se crean para el diccionario? ¿Son suficientes para realizar una rutina CANOpen con un minimo de funcionalidad?

¿Has generado los archivos necesarios que habra que incluir en el codigo a realizar?

Tengo otra pregunta, que es necesaria para aclarar conceptos:
Yo anteriormente habia realizado una aplicacion que corre en el PC para monitorizar las tramas de un protocolo J1939 que ya estaba implementado por otra persona. Cuando termine de implementar el protocolo CANOpen, debere ampliar esa aplicacion para que tambien monitorice las tramas enviadas usando este protocolo. Esta aplicacion se comunica con los sensores y la placa donde estaba montado el j1939 por puerto serie, y de la misma forma lo hara con la placa sobre la que va a ir montada CANOpen.

Entonces, la pregunta es: ¿Quien es aqui el esclavo, y quien es el maestro?
Es una cuestion que no tengo clara totalmente y me gustaria conocer para evitar cualquier tipo de confusion.

Weno Marcos, espero tu respuestaaa!!
Un saludoo desde España

Lo primero no es tan facil, ya lo intente y saltan mil problemas que no se como se solucionan...

Lo segundo y tercero si y si.

El esclavo sera el sensor (placa de aplicacion) y el Maestro va a ser el software en PC, seguramente.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 01 de Septiembre de 2010, 09:12:14
¿Que es lo que te da exactamente problemas? ¿Generar los archivos con el Design Tool?

Tengo un pequeño programa que unicamente inicializa el bus, informa sobre si se ha producido algun error en dicha operacion, y finaliza la comunicacion. Usa el diccionario de objetos que te he pasado anteriormente.
Lo que ocurre es que me da errores de compilacion, por que no puede acceder al archivo cal_conf.h que genera el diccionario de objetos. Pero no se por que, puesto que este archivo se encuentra en mi carpeta de proyecto.
Llevo un dia intentando detectar cual es el error, pero no lo consigo, y la verdad que estoy un poco desesperado...

Marcos, no conoces a nadie que haya participado en este foro y que haya hecho algun proyecto con CANOpen.
Es que si tu tienes problemas y no sabes solucionarlos, que tienes mucha experiencia en bus CAN, pues muy mal lo llevo para continuar con mi proyecto...



 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Septiembre de 2010, 15:04:12
Deberias estudiar bien como se direcciona el C18 y MPLAB para poder encontrar cada libreria y programa generado, especialmente si no estan instalados en las carpetas por defecto.

Creo que antes hubo alguien consultando por CanOpen, pero rapidamente desaparecio y no hubo nuevas consultas (sucede a menudo cuando entiendes que los tiempos del foro no son manejables si hay apuro en un proyecto, ya que aqui casi todos colaboramos en lo que sabemos en forma desinteresada).
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 03 de Septiembre de 2010, 06:02:57
No uso C18 ni MPLAB, sino el compilador de CCS.

En el mi caso de mi proyecto, no hay apuro de tiempo. Simplemente, estoy trabajando en ello cada dia, y por eso contesto pronto, pero no exigo nada a los miembros de este foro, ni mucho menos.

Se que CANOpen es un protocolo complejo, y que no es trivial implementar algo que sea funcional. Si no te interesa continuar aportando tus consejos, lo entendere.

Un saludo
Miguel Angel
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Septiembre de 2010, 09:59:45
No uso C18 ni MPLAB, sino el compilador de CCS.

En el mi caso de mi proyecto, no hay apuro de tiempo. Simplemente, estoy trabajando en ello cada dia, y por eso contesto pronto, pero no exigo nada a los miembros de este foro, ni mucho menos.

Se que CANOpen es un protocolo complejo, y que no es trivial implementar algo que sea funcional. Si no te interesa continuar aportando tus consejos, lo entendere.

Un saludo
Miguel Angel
Creo que malinterpretaste mi respuesta.
No se trata de falta de interes de mi parte, ni temor a fracasar en el intento de aprender CanOpen (siempre esta asegurado tener varios fracasos y decepciones en el intento de aprender algo nuevo, pero con teson siempre obtendras el resultado que buscas), es mas si no me interesara era mas simple no responderte desde el principio, se entiende??

Lo que digo respecto al C18 y Mplab es que los archivos que genera el ejemplo estan hechos para ese compilador y ambiente.
Para usarlo en CCS vas a tener que hacer varias traducciones y cambios.

El sentido comun indica que primero deberias usar los ejemplos como vienen, obtener seguridad de funcionamiento asi y cuando ya tienes una aplicacion funcional recien alli empezar la mudanza a CCS.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ALE1973 en 05 de Septiembre de 2010, 23:01:46
Buenas... Estoy queriendo empezar a hacer algunas maldades en CAN, simple, un maestro PC con uno o 2 esclavos por ahora, la interface con la pc la quiero hacer por USB, asi que  voy a poner un 18F250, un mcp 2551 y un mcp 2515, les pongo un esquema de lo que pense hasta ahora, quiero que me sugieran, los que tienen mas experiencia en CAN, si falta algo, o como lo ven.

Desde ya Gracias.
Alejandro
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 06 de Septiembre de 2010, 06:29:51
De acuerdo. Me bajado el IDE y el compilador de MPLAB C18. Lo voy a compilar y te cuento resultados.

¿Quieres que suba el main.c para que le eches un vistazo?

Bueno, pues muchas gracias por tus ganas y por no desesperarte conmigo  :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Septiembre de 2010, 22:21:27
De acuerdo. Me bajado el IDE y el compilador de MPLAB C18. Lo voy a compilar y te cuento resultados.

¿Quieres que suba el main.c para que le eches un vistazo?

Bueno, pues muchas gracias por tus ganas y por no desesperarte conmigo  :D

Subelo y lo revisamos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Septiembre de 2010, 22:30:08
Buenas... Estoy queriendo empezar a hacer algunas maldades en CAN, simple, un maestro PC con uno o 2 esclavos por ahora, la interface con la pc la quiero hacer por USB, asi que  voy a poner un 18F250, un mcp 2551 y un mcp 2515, les pongo un esquema de lo que pense hasta ahora, quiero que me sugieran, los que tienen mas experiencia en CAN, si falta algo, o como lo ven.

Desde ya Gracias.
Alejandro
La parte de CAN esta bien, solo me aseguraria de entrar con el pin de interrupcion del MCP2515 a algun pin con interrupcion del PIC, asi se te puede simplificar la tarea en vez de hacer poolling simplemente cada vez que interrumpe vas a leer.

respecto al USB, si no entiendo mal, te falta un capacitor que hace de bomba para la tension del USB, revisa y pregunta en los otros subforos que hay muchos especialistas en el tema...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ALE1973 en 06 de Septiembre de 2010, 23:36:16
Gracias MGLSOFT  por la molestia de revisar, la parte de USB, no la termine, ya que como hice varias, ahi va un copy paste, jeje, me interesaba mas la parte de can, la interrupcion esta puesta, este micro tiene INT0, INT1 e INT2, que funcionan igual que la int0.
Voy a ver cuanto avanzo, ahora voy por el esclavo.

Saludos y gracias.

Alejandro.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 07 de Septiembre de 2010, 07:51:40
Aqui tienes el main.c que estamos probando:

http://rapidshare.com/files/417601013/main.c

Hemos compilado con la version de MPLAB IDE v8.46 y la del compilador MCC18 v3.36
Esta es la salida de Output que aparece:

Código: [Seleccionar]
Debug build of project `C:\Documents and Settings\Administrador\Escritorio\otro\otro.mcp' started.
Language tool versions: mpasmwin.exe v5.37, mplink.exe v4.37, mcc18.exe v3.36, mplib.exe v4.37
Preprocessor symbol `__DEBUG' is defined.
Tue Sep 07 11:59:08 2010
----------------------------------------------------------------------
Clean: Deleting intermediary and output files.
Clean: Done.
Executing: "C:\MCC18\bin\mcc18.exe" -p=18F2680 /i"C:\Documents and Settings\Administrador\Escritorio\CANOPEN (Controller Area Network)\CD LIBRERIA CANOPEN\3_DPMicroChipPIC18F2680\drivers\pic18f" -I"C:\port\CANopenLibrary\canopen\include" "co_init.c" -fo="co_init.o" -D__DEBUG -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
MPLAB C18 v3.36 (evaluation)
Copyright 2000-2010 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  60
Executing: "C:\MCC18\bin\mcc18.exe" -p=18F2680 /i"C:\Documents and Settings\Administrador\Escritorio\CANOPEN (Controller Area Network)\CD LIBRERIA CANOPEN\3_DPMicroChipPIC18F2680\drivers\pic18f" -I"C:\port\CANopenLibrary\canopen\include" "main.c" -fo="main.o" -D__DEBUG -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
MPLAB C18 v3.36 (evaluation)
Copyright 2000-2010 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  60
C:\Documents and Settings\Administrador\Escritorio\otro\main.c:215:Warning [2103] default startup code expects main function declared as 'void main (void)'
C:\Documents and Settings\Administrador\Escritorio\otro\main.c:251:Warning [2066] type qualifier mismatch in assignment
C:\Documents and Settings\Administrador\Escritorio\otro\main.c:260:Warning [2058] call of function without prototype
C:\Documents and Settings\Administrador\Escritorio\otro\main.c:271:Warning [2066] type qualifier mismatch in assignment
C:\Documents and Settings\Administrador\Escritorio\otro\main.c:281:Warning [2066] type qualifier mismatch in assignment
C:\Documents and Settings\Administrador\Escritorio\otro\main.c:289:Warning [2058] call of function without prototype
Executing: "C:\MCC18\bin\mcc18.exe" -p=18F2680 /i"C:\Documents and Settings\Administrador\Escritorio\CANOPEN (Controller Area Network)\CD LIBRERIA CANOPEN\3_DPMicroChipPIC18F2680\drivers\pic18f" -I"C:\port\CANopenLibrary\canopen\include" "objects.c" -fo="objects.o" -D__DEBUG -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
MPLAB C18 v3.36 (evaluation)
Copyright 2000-2010 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  60
Executing: "C:\MCC18\bin\mplink.exe" /p18F2680 /l"C:\MCC18\lib" /k"C:\MCC18\bin\LKR" "co_init.o" "main.o" "objects.o" /u_CRUNTIME /u_DEBUG /z__MPLAB_BUILD=1 /z__MPLAB_DEBUG=1 /o"otro.cof" /M"otro.map" /W
MPLINK 4.37, Linker
Copyright (c) 1998-2010 Microchip Technology Inc.
Error - could not find definition of symbol 'createNodeReq' in file './co_init.o'.
Errors    : 1

Link step failed.
----------------------------------------------------------------------
Debug build of project `C:\Documents and Settings\Administrador\Escritorio\otro\otro.mcp' failed.
Language tool versions: mpasmwin.exe v5.37, mplink.exe v4.37, mcc18.exe v3.36, mplib.exe v4.37
Preprocessor symbol `__DEBUG' is defined.
Tue Sep 07 11:59:09 2010
----------------------------------------------------------------------
BUILD FAILED

Aver si entre todos podemos hacerlo funcionar.

Muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: conilete en 14 de Septiembre de 2010, 07:36:00
Weno señores...despues de un tiempo de pruebas, he de decir que ha compilado el programita. Faltaban una serie de archivos necesarios para el main.c y que generaba el CANOpen Design Tool. Tampoco estaba bien configurado las caracteristicas hardware.

Bueno, el programa enviaba un par de PDO's, por lo que estamos ya en disposicion de analizar el trafico que se genera en la red. Para ello, dispongo de la herramienta CANAnalyzer y CANSetter. Estoy en fase de estudio de dicho software, en cuanto obtenga resultados os pongo las graficas y el seguimiento de tramas por aqui en el foro.

Hasta pronto!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: arielperez en 21 de Septiembre de 2010, 21:53:49
Hola.
Ante todo gracias por la información compartida!. Especialmente a Marcos, mi felicitación por el inmenso aporte y dedicación.
Hechas las menciones, me largo a consultar.
El tema es el siguiente, estoy haciendo un tablero para handball, de esos que controlan tiempo, tanteador de un equipo y otro, etc. Por una cuestión de distancia entre la consola de la mesa de control y el propio tablero, pensé en utilizar CAN.
A partir de lo que estuve leyendo armé dos unidades, cada una posee un PIC18F4585 y un MCP2551. El hardware es extremadamente sencillo y lo he recibido muchas veces para descartar errores en el mismo.
Por lo que les paso el código, muuuy simple pero recién empiezo a meterme en este tema.
Básicamente se presiona un pulsador en una de las unidades, se envía un mensaje y lo debería recibir la otra unidad para así encender un led en consecuencia.
En el programa del tablero utilizo el led para ver en que parte del código estoy. Lamentablemente ni siquiera enciende por 200ms, por lo que no está detectando ningún mensaje.
Si pueden darme una mano se los voy a agradecer infinitamente.
Utilizo un cristal de 10MHz.
Saludos cordiales,
Ariel.

Código: C
  1. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  2. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  3. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  4. /////////////////////////////////////////////////////////////////////////
  5. ////                         TABLERO.C                                       ////
  6. ////                                                                              ////
  7. /////////////////////////////////////////////////////////////////////////
  8.  
  9. #include <18F4585.h>
  10. #define CAN_USE_EXTENDED_ID FALSE
  11. #FUSES NOWDT                    //No Watch Dog Timer
  12. #FUSES WDT128                   //Watch Dog Timer uses 1:128 Postscale
  13. #FUSES HS                       //High speed Osc (> 4mhz)
  14. #FUSES NOPROTECT                //Code not protected from reading
  15. #FUSES BROWNOUT                 //Reset when brownout detected
  16. #FUSES BORV21                   //Brownout reset at 2.1V
  17. #FUSES PUT                      //Power Up Timer
  18. #FUSES NOCPD                    //No EE protection
  19. #FUSES STVREN                   //Stack full/underflow will cause reset
  20. #FUSES NODEBUG                  //No Debug mode for ICD
  21. #FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
  22. #FUSES NOWRT                    //Program memory not write protected
  23. #FUSES NOWRTD                   //Data EEPROM not write protected
  24. #FUSES NOIESO                     //Internal External Switch Over mode enabled
  25. #FUSES FCMEN                    //Fail-safe clock monitor enabled
  26. #FUSES PBADEN                   //PORTB pins are configured as analog input channels on RESET
  27. #FUSES BBSIZ1K                  //1K words Boot Block size
  28. #FUSES NOWRTC                   //configuration not registers write protected
  29. #FUSES NOWRTB                   //Boot block not write protected
  30. #FUSES NOEBTR                   //Memory not protected from table reads
  31. #FUSES NOEBTRB                  //Boot block not protected from table reads
  32. #FUSES NOCPB                    //No Boot Block code protection
  33. #FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
  34. #FUSES MCLR                     //Master Clear pin enabled
  35. #FUSES NOXINST                  //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
  36.  
  37. #use delay(clock=10000000)
  38.  
  39. #define CAN_DO_DEBUG TRUE
  40. #define Set_250K_Baud
  41. #include "can-18F4580.c"
  42.  
  43.  
  44.  
  45. // Variables send can bus
  46. struct rx_stat rxstat;
  47. int32 rx_id;
  48. int8 rx_len;
  49.  
  50. // Variables reception can bus
  51. int32 tx_id;
  52. int1 tx_rtr=0;
  53. int1 tx_ext=1;
  54. int8 tx_len=1;
  55. int8 tx_pri=3;
  56. int32 rx_id_maestro=5;
  57. int32 id = 1;//del esclavo
  58. int8 datos = 0;
  59. int8 datos_slave=0;
  60.  
  61. void main()
  62. {
  63.    set_tris_d(0x00);  
  64.    tx_id=id;
  65.    datos_slave=0x01;
  66.    can_init(); // Init can bus
  67.    
  68.    
  69.    
  70.    while(TRUE)
  71.    {
  72.       if ( can_kbhit() ) // check for data on the can bus
  73.       {
  74.          output_high(PIN_D0);
  75.          delay_ms(200);
  76.          output_low(PIN_D0);
  77.          delay_ms(200);
  78.          
  79.          can_getd(rx_id, &datos, rx_len, rxstat); // read data can bus
  80.          
  81.          
  82.          if (rx_id_maestro == rx_id)
  83.          {
  84.           output_high(PIN_D0);
  85.           delay_ms(1000);
  86.           output_low(PIN_D0);
  87.           delay_ms(1000);
  88.          }
  89.        //  can_putd(tx_id, &datos_slave, tx_len,tx_pri,tx_ext,tx_rtr); //acuse de recibo
  90.       }
  91.    }
  92. }

Código: C
  1. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  2. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  3. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  4. /////////////////////////////////////////////////////////////////////////
  5. ////                         CONSOLA.C                          ////
  6. ////                                                                 ////
  7. /////////////////////////////////////////////////////////////////////////
  8.  
  9. #include <18F4585.h>
  10. #define CAN_USE_EXTENDED_ID FALSE
  11. #FUSES NOWDT                    //No Watch Dog Timer
  12. #FUSES WDT128                   //Watch Dog Timer uses 1:128 Postscale
  13. #FUSES HS                       //High speed Osc (> 4mhz)
  14. #FUSES NOPROTECT                //Code not protected from reading
  15. #FUSES BROWNOUT                 //Reset when brownout detected
  16. #FUSES BORV21                   //Brownout reset at 2.1V
  17. #FUSES PUT                      //Power Up Timer
  18. #FUSES NOCPD                    //No EE protection
  19. #FUSES STVREN                   //Stack full/underflow will cause reset
  20. #FUSES NODEBUG                  //No Debug mode for ICD
  21. #FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
  22. #FUSES NOWRT                    //Program memory not write protected
  23. #FUSES NOWRTD                   //Data EEPROM not write protected
  24. #FUSES NOIESO                     //Internal External Switch Over mode enabled
  25. #FUSES FCMEN                    //Fail-safe clock monitor enabled
  26. #FUSES PBADEN                   //PORTB pins are configured as analog input channels on RESET
  27. #FUSES BBSIZ1K                  //1K words Boot Block size
  28. #FUSES NOWRTC                   //configuration not registers write protected
  29. #FUSES NOWRTB                   //Boot block not write protected
  30. #FUSES NOEBTR                   //Memory not protected from table reads
  31. #FUSES NOEBTRB                  //Boot block not protected from table reads
  32. #FUSES NOCPB                    //No Boot Block code protection
  33. #FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
  34. #FUSES MCLR                     //Master Clear pin enabled
  35. #FUSES NOXINST                  //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
  36.  
  37. #use delay(clock=10000000)
  38. #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
  39.  
  40. #define CAN_DO_DEBUG TRUE
  41. #define Set_250K_Baud
  42. #include "can-18F4580.c"
  43.  
  44.  
  45. #define PRESIONO_PULS_SUBIR  0x201
  46. #define PRESIONO_PULS_BAJAR  0x202  
  47.  
  48. #define BUTTON PIN_D0
  49. #define BUTTON_PRESSED !input(BUTTON)
  50.  
  51.  
  52. // Variables send can bus
  53. struct rx_stat rxstat;
  54. int32 rx_id;
  55. int8 rx_len;
  56.  
  57. // Variables reception can bus
  58. int32 tx_id;
  59. int1 tx_rtr=0;
  60. int1 tx_ext=1;
  61. int8 tx_len=1;
  62. int8 tx_pri=3;
  63. int32 id=5;//del maestro
  64. int32 rx_id_esclavo=1;
  65. int8 datos=0;
  66. int8 datos_slave=0;
  67.  
  68.  
  69.  
  70.  
  71. void main()
  72. {
  73.    tx_id=id;
  74.    
  75.    disable_interrupts(GLOBAL);
  76.    disable_interrupts(INT_TIMER0);
  77.    
  78.    setup_timer_0(RTCC_DIV_2);
  79.    
  80.    enable_interrupts(GLOBAL);
  81.    datos=0xFF;
  82.    
  83.    can_init();    // Init can bus
  84.  
  85.    set_tris_d(0xff);  
  86.    while(TRUE)
  87.    {
  88.      
  89.      
  90.      
  91.       if(BUTTON_PRESSED)
  92.       {
  93.       while(BUTTON_PRESSED){}
  94.       delay_ms(200);
  95.    
  96.       can_putd(tx_id,&datos,tx_len,tx_pri,tx_ext,tx_rtr);//send a byte=0xFF
  97.       }
  98.      
  99.    }//while
  100. }//main

Título: Re: Mis experiencias con el BUS CAN
Publicado por: arielperez en 21 de Septiembre de 2010, 22:20:27
Perdón por agregar a lo bestia el código en mi mensaje anterior...
La próxima utilizaré las opciones para hacerlo correctamente.
Saludos cordiales,
Ariel
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Septiembre de 2010, 23:01:40
No hay perdon... :mrgreen: :mrgreen: :mrgreen:

Deberias poner la libreria que usas can-18F4580.c asi vemos si es compatible.
lo mas probable es que no respete la configuracion de velocidad, y este usando la del ejemplo, que si mal no recuerdo es con un cristal de 20 MHz y no deberia funcionar con uno de 10 MHZ.

En estos temas hay que tener cuidado, ya que puede traer problemas... encima inexplicables.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: arielperez en 22 de Septiembre de 2010, 23:54:01
Hola, les dejo el archivo can-18F4580.c sacando algunas funciones que calculo que no interesaban para el análisis.
Yo estoy usando un 18F4585, esto conlleva alguna modificación?.
Muchas gracias por la paciencia y predisposición.
Saludos cordiales,
Ariel.

Código: [Seleccionar]
/////////////////////////////////////////////////////////////////////////
////                        can-18F4580.c                             ////
/////////////////////////////////////////////////////////////////////////
////                                                                 ////
//// 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>.                 ////
////                                                                 ////
/////////////////////////////////////////////////////////////////////////

#include <can-18F4580.h>
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)


#if CAN_DO_DEBUG
 #define can_debug printf
#else
 #define can_debug
#endif


//macros
#define can_kbhit() (RXB0CON.rxful || RXB1CON.rxful || B0CONR.rxful || B1CONR.rxful || B2CONR.rxful || B3CONR.rxful || B4CONR.rxful || B5CONR.rxful)
#define can_tbe() (!TXB0CON.txreq || !TXB1CON.txreq || !TXB2CON.txreq || !B0CONT.txreq || !B1CONT.txreq || !B2CONT.txreq || !B3CONT.txreq || !B4CONT.txreq || !B5CONT.txreq)
#define can_abort()                 (CANCON.abat=1)

// current mode variable
// used by many of the device drivers to prevent damage from the mode
//
int curmode;
int curfunmode;

////////////////////////////////////////////////////////////////////////
//
// can_init()
//
//////////////////////////////////////////////////////////////////////////////
void can_init(void) {
   can_set_mode(CAN_OP_CONFIG);   //must be in config mode before params can be set
   can_set_baud();
   curfunmode=0;

   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(RXFILTER0, 0, CAN_USE_EXTENDED_ID);  //set filter 0 of mask 0
   can_set_id(RXFILTER1, 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(RXFILTER2, 0, CAN_USE_EXTENDED_ID);  //set filter 0 of mask 1
   can_set_id(RXFILTER3, 0, CAN_USE_EXTENDED_ID);  //set filter 1 of mask 1
   can_set_id(RXFILTER4, 0, CAN_USE_EXTENDED_ID);  //set filter 2 of mask 1
   can_set_id(RXFILTER5, 0, CAN_USE_EXTENDED_ID);  //set filter 3 of mask 1

   // set dynamic filters
   can_set_id(RXFILTER6, 0, CAN_USE_EXTENDED_ID);
   can_set_id(RXFILTER7, 0, CAN_USE_EXTENDED_ID);
   can_set_id(RXFILTER8, 0, CAN_USE_EXTENDED_ID);
   can_set_id(RXFILTER9, 0, CAN_USE_EXTENDED_ID);
   can_set_id(RXFILTER10, 0, CAN_USE_EXTENDED_ID);
   can_set_id(RXFILTER11, 0, CAN_USE_EXTENDED_ID);
   can_set_id(RXFILTER12, 0, CAN_USE_EXTENDED_ID);
   can_set_id(RXFILTER13, 0, CAN_USE_EXTENDED_ID);
   can_set_id(RXFILTER14, 0, CAN_USE_EXTENDED_ID);
   can_set_id(RXFILTER15, 0, CAN_USE_EXTENDED_ID);

   set_tris_b((*0xF93 & 0xFB ) | 0x08);   //b3 is out, b2 is in

   can_set_mode(CAN_OP_NORMAL);
}

////////////////////////////////////////////////////////////////////////
//
// can_set_baud()
////////////////////////////////////////////////////////////////////////
   void can_set_baud(void) {       
 # ifdef Set_125K_Baud {
    BRGCON1 = 0x01;
    BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 125 KBps
    BRGCON3 = 0x07;      //con reloj a 10 MHz
 }
 #endif
 
 #ifdef Set_250K_Baud {
    BRGCON1 = 0x00;
    BRGCON2 = 0xBA;      //modificado 5/11/07 para usar CAN a 250 KBps
    BRGCON3 = 0x07;      //con reloj a 10 MHz
 }
 #endif
 
 #ifdef Set_500K_Baud {
    BRGCON1 = 0x00;
    BRGCON2 = 0x92;      //modificado 5/11/07 para usar CAN a 500 KBps
    BRGCON3 = 0x02;      //con reloj a 10 MHz
 }
 #endif
   
}


////////////////////////////////////////////////////////////////////////
//
// can_set_mode
////////////////////////////////////////////////////////////////////////
void can_set_mode(CAN_OP_MODE mode) {
   CANCON.reqop=mode;
   while( (CANSTAT.opmode) != mode );
}

////////////////////////////////////////////////////////////////////////
//
// can_set_functional_mode
////////////////////////////////////////////////////////////////////////////////
void can_set_functional_mode(CAN_FUN_OP_MODE mode)
{
   can_set_mode(CAN_OP_CONFIG);   //must be in config mode before params can be set
   ECANCON.mdsel=mode;
   curfunmode=mode;
   can_set_mode(CAN_OP_NORMAL);
}

////////////////////////////////////////////////////////////////////////
//
// can_set_id()
////////////////////////////////////////////////////////////////////////
void can_set_id(int* addr, int32 id, int1 ext) {
   //int *ptr;

   //ptr=addr;

   if (ext) {  //extended
      //eidl
      *addr=make8(id,0); //0:7

      //eidh
      addr--;
      *addr=make8(id,1); //8:15

      //sidl
      addr--;
      *addr=make8(id,2) & 0x03;   //16:17
      *addr|=(make8(id,2) << 3) & 0xE0; //18:20
      *addr|=0x08;


      //sidh
      addr--;
      *addr=((make8(id,2) >> 5) & 0x07 ); //21:23
      *addr|=((make8(id,3) << 3) & 0xF8);//24:28
   }
   else {   //standard
      //eidl
      *addr=0;

      //eidh
      addr--;
      *addr=0;

      //sidl
      addr--;
      *addr=(make8(id,0) << 5) & 0xE0;

      //sidh
      addr--;
      *addr=(make8(id,0) >> 3) & 0x1F;
      *addr|=(make8(id,1) << 5) & 0xE0;
   }
}

////////////////////////////////////////////////////////////////////////////////
//
// can_set_standard_id
////////////////////////////////////////////////////////////////////////////////

void can_set_standard_id(int * addr, int32 id)
{
   //eidl
   *addr=0;

   //eidh
   addr--;
   *addr=0;

   //sidl
   addr--;
   *addr=(make8(id,0) << 5) & 0xE0;

   //sidh
   addr--;
   *addr=(make8(id,0) >> 3) & 0x1F;
   *addr|=(make8(id,1) << 5) & 0xE0;
}

////////////////////////////////////////////////////////////////////////////////
//
// can_set_extended_id
////////////////////////////////////////////////////////////////////////////////

void can_set_extended_id(int * addr, int32 id)
{
   //eidl
   *addr=make8(id,0); //0:7

   //eidh
   addr--;
   *addr=make8(id,1); //8:15

   //sidl
   addr--;
   *addr=make8(id,2) & 0x03;   //16:17
   *addr|=(make8(id,2) << 3) & 0xE0; //18:20
   *addr|=0x08;


   //sidh
   addr--;
   *addr=((make8(id,2) >> 5) & 0x07 ); //21:23
   *addr|=((make8(id,3) << 3) & 0xF8);//24:28
}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Septiembre de 2010, 20:22:37
Je..je la veo conocida... :D :D
deberia funcionarte aun con un 4585, ya que los registros son identicos...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: reddragon en 17 de Octubre de 2010, 08:55:33
Hola a todos.
Despues de 2 dias, al final he terminado de leer las 44 pagina de este post :-/ .
Mi intencion es montar el esquema que MGLSOFT ha puesto en el mensaje 716 ya que se ve mas sencillo que el de microchip, pero tengo algunas dudas.
MGLSOFT comentas que con este esquema el software y firmware de microchip es completamente compatible, pero con las diferencias que he visto en tu esquema y el de microchip, ¿has tendo que modificar el codigo de microchip para adaptarlo?.
Voy a poner un ejemplo, he visto que usas un dip switch en los pines rc0, rc1 y rc2 del pic, y en el esquema de microchip he visto que rc0 se utiliza para seleccionar la resistencia de fin de linea del can bus(en tu esquema se selecciona con un jumper).

Otra cosa que no entiendo son las dos resistencias que hay colocadas en los pines d+ y d- del usb(r3 y r4) y que no tienen ningun valor colocado, en el esquema de microchip estan marcadas como "DO NOT POPULATE", pero no se que significa.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 17 de Octubre de 2010, 22:06:39
Hola a todos.
Despues de 2 dias, al final he terminado de leer las 44 pagina de este post :-/ .
Mi intencion es montar el esquema que MGLSOFT ha puesto en el mensaje 716 ya que se ve mas sencillo que el de microchip, pero tengo algunas dudas.
MGLSOFT comentas que con este esquema el software y firmware de microchip es completamente compatible, pero con las diferencias que he visto en tu esquema y el de microchip, ¿has tendo que modificar el codigo de microchip para adaptarlo?.
Voy a poner un ejemplo, he visto que usas un dip switch en los pines rc0, rc1 y rc2 del pic, y en el esquema de microchip he visto que rc0 se utiliza para seleccionar la resistencia de fin de linea del can bus(en tu esquema se selecciona con un jumper).

Otra cosa que no entiendo son las dos resistencias que hay colocadas en los pines d+ y d- del usb(r3 y r4) y que no tienen ningun valor colocado, en el esquema de microchip estan marcadas como "DO NOT POPULATE", pero no se que significa.

Despues que vuelva a repasar ambos circuitos te contesto. Comprenderas que no lo tengo fresco, ya paso algun tiempo... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: reddragon en 18 de Octubre de 2010, 08:40:04
De acuerdo mglsoft, sin prisas.
Gracias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 24 de Octubre de 2010, 16:35:46
Hola buenas tardes, les comento mi inquietud tengo dos placas de arduino la mega y el Duemilanove para las cual quiero usarlas con can bus y tambien dispongo de un modulo can bus que lo compre en mikroelektronika, ahora mi consulta alguien ha usado can bus con arduino y el modulo can de mikroelektronika; en lo personal estoy trabajando en hacer un shield con el modulo de can bus de mikroelektronika para asi usarlo con arduino ya sea el mega o el Duemilanove.

Pero encuanto a expeiencia con can bus y arduino nose como manejarlo pero ya estoy leyendo como controlar el modulo can via protocolo spi.

Saludos y si alguien tiene algun tipo de informacion sobre can bus y arduino bienvenida sea.

Atten.
Alexander Santana.
Barcelona-Venezuela.

Nota: pronto subo mi shield para arduino y modulo can bus de mikroelektronika.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 26 de Octubre de 2010, 11:39:29
Hola buenos dias continuando con mi practica con can bus aca subo el hard que pienso usar ya lo tengo todo conmigo y estoy es definiendo detaller.

Saludos y pronto les subo el diagrama de conecciones.
Atten.
Alexander Santana.
Venezuela-Barcelona.


(http://img835.imageshack.us/img835/7238/shieldfisicocanbusconar.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 31 de Octubre de 2010, 14:15:40
Buenas tardes, aca subo el diagrama de conexion entre mi arduino Duemilanove (Atmega328p) y el modulo CAN-SPI de mikroelektronika.
Vale destacar que el arduino tiene comunicacion rs232 usando el integrado FT232 y asi crear puerto viartual; esto lo mensiono para estar claro con comunicate el arduino con la pc y la aplicacion pienso hacerla en delphi y en una futura practica hare una version con lcd y asi mostrare todo en la lcd y asi no usare la pc para mostrar la informacion con la cual interactuo con can bus.
(http://img80.imageshack.us/img80/4569/conexioncanarduino.jpg)

Saludos y cualquier otra duda estare al pendiente. luego subo el esquema del modulo Can-spi de mikroelektronika para dejar todo bien definido y ahora lo que resta es hacer el codigo para el arduino y la pc para darle vida al proyecto.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: r_romeo en 04 de Noviembre de 2010, 09:30:50
Buenos días a todos, Los felicito por el cursillo de CAN, me he tomado un par de días para leer el foro y estoy pensando en montarme un circuito con nodos CAN para experimentar en casa.
 Una aportación , quizás es que trabajaba en una empresa que utilizaba una conexión compuesta por dos pequeños cables coaxiales para transmitir el CAN y otros dos gruesos para la alimentación
 Seguiré posteando, porque tengo algunas pequeñas dudas

GRACIAS !!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: r_romeo en 04 de Noviembre de 2010, 10:10:58
Estimados Maestros,  tengo una duda en el ejemplo de aplicación de filtro


una cosa que no entendí con respecto al ejemplo, es que en binario 6F0 = 11011110000

entonces para mi el filtro seria = 110 1111 XXXX, en vez de     101 1111 XXXX

estoy haciendo algo mal?





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


Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 05 de Noviembre de 2010, 09:04:10
Hola buenos dias, Aca coloco el link del esquema del mudulo CAN-SPI que uso con el arduino es de la gente de mikroelektronika.
link esquema (http://www.mikroe.com/pdf/can2_board_schematic.pdf)

Saludos y cualquier cosa estamos en contacto.
Atten.
alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: reddragon en 06 de Noviembre de 2010, 06:28:22
Astrocar no funciona el enlace.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 06 de Noviembre de 2010, 08:27:50
Astrocar no funciona el enlace.

Hola buenos dias, oye mil disculpa no lo habia probado ya lo revise y hice su modificacion y ya esta funcionando.

Saludos y gracias por el dato.
Atten.
Alexander Santana.
Venezuela-Barcelona
Título: Re: Mis experiencias con el BUS CAN
Publicado por: natxo03 en 10 de Noviembre de 2010, 09:28:05
Hola a todos,

Después de leer todos los mensajes, veo que tenis mus experiencia y sabiduría sobre el bus CAN y espero que me echéis una mano.
Estoy realizando una interfase entre varios sistemas de comunicaciones y uno de ellos es el CAN. Estoy diseñando el hardware, la verdad que no es muy complicado ya que con un simple trasceiber y una opción de introducir resistencia de terminación es suficiente. Mis preguntas son:

1- No hay que añadir algún sistema de protección contra emisiones ESD y EMI? por ejemplo estabilizadores o algo parecido?
2- He visto dos formas de poner la resistencia de terminación: una simple resistencia o con dos resistencias y enganchando en el medio con un condensador a tierra. Cual me recomendáis? yo voy a usar el rango de 10Kbs asta 1Mbs, esto influye en la decisión?
3- Dependiendo de la velocidad de trasmisión se necesita alguna protección mas?
4- Me aconsejaríais introducir octocopladores como he visto en alguna hoja de características?

Personar por tantas preguntas pero tengo algunas dudillas.

En un principio voy añadir un TVS (NUP2105L) y puede ser que los octocopladores, que os parece?.

Muchas gracias y un saludo

Título: Re: Mis experiencias con el BUS CAN
Publicado por: beingenier_dj en 13 de Diciembre de 2010, 00:25:00
Hola ...... me interesa bastante el hilo .... soy nuevo en el foro pero con algunas buenas experiencias en desarrollos con PIC dsPIC FPGA y otros ....

De hecho estoy en el desarrollo de un proyecto parecido ...... pero para aplicacion automotriz (donde CAN fue concebido) ....... estoy usando el dsPIC 30F4011 .......

Saludos desde Colombia
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Diciembre de 2010, 09:12:51
Bienvenido al Foro y por supuesto a este hilo!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Diciembre de 2010, 09:17:17
Hola a todos,

Después de leer todos los mensajes, veo que tenis mus experiencia y sabiduría sobre el bus CAN y espero que me echéis una mano.
Estoy realizando una interfase entre varios sistemas de comunicaciones y uno de ellos es el CAN. Estoy diseñando el hardware, la verdad que no es muy complicado ya que con un simple trasceiber y una opción de introducir resistencia de terminación es suficiente. Mis preguntas son:

1- No hay que añadir algún sistema de protección contra emisiones ESD y EMI? por ejemplo estabilizadores o algo parecido?
2- He visto dos formas de poner la resistencia de terminación: una simple resistencia o con dos resistencias y enganchando en el medio con un condensador a tierra. Cual me recomendáis? yo voy a usar el rango de 10Kbs asta 1Mbs, esto influye en la decisión?
3- Dependiendo de la velocidad de trasmisión se necesita alguna protección mas?
4- Me aconsejaríais introducir octocopladores como he visto en alguna hoja de características?

Personar por tantas preguntas pero tengo algunas dudillas.

En un principio voy añadir un TVS (NUP2105L) y puede ser que los octocopladores, que os parece?.

Muchas gracias y un saludo



Muchos de los transceiver CAN tienen incorporada las protecciones ESD y EMI.
Tambien vi que algunos ademas ponen optoacopladores entre los micros y los transceiver.
Respecto a como aterrizar el Bus, te recomiendo leer bien la hoja de datos del/los transceiver que vayas a utilizar, de modo de no olvidar en tu placa las posiciones que a futuro deban ocupar esos componentes, aunque inicialmente uses un transceiver que no los necesite.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Agustina en 28 de Diciembre de 2010, 16:55:20
Hola! les hago una pregunta ya que saben mucho de CAN BUS.

Esoty intentando conectarme con un vehiculo que tiene CAN supuestamente (honda civic si 2008), la pregunta concretamente es que protocolo utilizan para transmitir los datos.

He armado 2 placas, una envia datos permanentemente por el bus can y otra los recibe a 250kbps y 500kbps.

Entre estas dos placas anda todo perfecto. Pero la pregunta es, si conecto este "logger" al puerto CAN del automovil, deberia ver cuales son los datos que estan en el bus en ese momento a 500 kbps?

Tambien debo hacerlo para vehiculos de carga pesada, donde el protocolo es J1939, que es a 250 kbps.

gracias!!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Diciembre de 2010, 17:12:47
En realidad para esto seguramente te deberian funcionar bien.
Para interpretar las tramas deberas conocerlas bien, para ello solo sirven los manuales del protocolo.

Hay proyectos mas sencillos, como el del maestro Nocturno en su pagina web, en el siguiente link:

http://www.micropic.es/index.php?option=com_content&view=article&id=29:conversor--adaptador-serie-rs232-a-vag-com-obd2-para-vw-passat&catid=3:proyectos&Itemid=62 (http://www.micropic.es/index.php?option=com_content&view=article&id=29:conversor--adaptador-serie-rs232-a-vag-com-obd2-para-vw-passat&catid=3:proyectos&Itemid=62)

Esta hecho para otro modelo y marca de automovil, pero como idea puede servirte bien.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Agustina en 28 de Diciembre de 2010, 17:18:10
Gracias MGLSOFT, el problema es que la capa fisica y el protocolo son totalmente diferentes a lo que planeo hacer. Lo que ando buscando es para BUS CAN.


muchas gracias!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 01 de Enero de 2011, 11:56:55
Hola! les hago una pregunta ya que saben mucho de CAN BUS.

Esoty intentando conectarme con un vehiculo que tiene CAN supuestamente (honda civic si 2008), la pregunta concretamente es que protocolo utilizan para transmitir los datos.

He armado 2 placas, una envia datos permanentemente por el bus can y otra los recibe a 250kbps y 500kbps.

Entre estas dos placas anda todo perfecto. Pero la pregunta es, si conecto este "logger" al puerto CAN del automovil, deberia ver cuales son los datos que estan en el bus en ese momento a 500 kbps?

Tambien debo hacerlo para vehiculos de carga pesada, donde el protocolo es J1939, que es a 250 kbps.

gracias!!!
Hola agustina, muy interezantes lo que planteas sobre la comunicacion via can con un honda civic, lo primero es saber los ID que le vas enviar al carro para obtener tus respuestas y para eso tienes que tener contacto directo con el fabricante honda si son parametros generales si hay nomas para eso y puede obtener el ID ejemplo ver las revolucion del motor y esas cosa pero si le vas a solicitar al vehiculos cosas mas restringidas como el VIN del vehiciulo que no es mas que el serial o parametros de seguridad para la programacion de llaves y cosas asi no es muy comun tener los ID de can para esas cosas pero de igual forma es un proyecto muy bueno seria cuestion de ver tu alcance en teste proyecto y cualquier cosa me permites unirme a tu proyecto o por lo menos seguirte muy de cerca en los avances.

Saludos y Felez año nuevo 2011.
Atten.
Alexander Santana.
Barcelona-Venezuela.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Agustina en 03 de Enero de 2011, 08:41:16
Gracias por la respuesta! logre conectarme, obtuve algunos datos... ni idea que significan... pero parecen ser validos! Lo que necesito terminar antes es una aplicacion donde pueda leer los datos de un camion en protocolo j1939 (tambien CAN).

gracias!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 03 de Enero de 2011, 15:00:24
Gracias por la respuesta! logre conectarme, obtuve algunos datos... ni idea que significan... pero parecen ser validos! Lo que necesito terminar antes es una aplicacion donde pueda leer los datos de un camion en protocolo j1939 (tambien CAN).

gracias!!
oye que interfaces estas usando porque dices que si te conectastes y que le estas solicitando al carro explicate un poco mejor.

Saludos.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Agustina en 03 de Enero de 2011, 15:26:30
Me conecte a un honda civic si, en modo LISTEN ONLY, lei algunos datos, NO SOLICITE NADA. Esto lo hice a modo de prueba, para verificar que el bus CAN. Lo que necesito en realidad es algo sobre como conectarme a camiones con protocolo j1939.

gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Enero de 2011, 15:29:22
Muestranos algunas imagenes de lo que lograste hacer...
Buen avance!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 03 de Enero de 2011, 20:23:10
exacto, muestra los datos que te envio el carro que interface como que enviastes para que el can te responda.

Saludos.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: scientist en 04 de Enero de 2011, 01:51:04
por que no checan este proyecto con arduino
http://code.google.com/p/opengauge/wiki/OBDuinoInterface (http://code.google.com/p/opengauge/wiki/OBDuinoInterface)

yo lo estoy haciendo con un mbed, ya existen proyectos de este tipo, del protocolo que menciona agustina, ni idea, es protocolo cerrado? de ser asi, creo que tendras que pagar para que te den los documentos acerca de como comunicarte, todos los camiones usan este protocolo? saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 04 de Enero de 2011, 08:31:19
por que no checan este proyecto con arduino
http://code.google.com/p/opengauge/wiki/OBDuinoInterface (http://code.google.com/p/opengauge/wiki/OBDuinoInterface)

yo lo estoy haciendo con un mbed, ya existen proyectos de este tipo, del protocolo que menciona agustina, ni idea, es protocolo cerrado? de ser asi, creo que tendras que pagar para que te den los documentos acerca de como comunicarte, todos los camiones usan este protocolo? saludos

Hola buenos dias, oye muy buena opcion hacer interface can bus con la placa MDEB, y lo mejor es que ya esta tiene hardware can bus por lo que solo usarias un transcerver y ya tendrias la interface listo el resto seria el codigo.

Saludos y muestras tus avances hermano.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: vitocho en 29 de Enero de 2011, 20:49:51
hola estoy haciendo un pryecto con el can bus de peugeot 206 año 2003 motor 1.4 y necesito saber que protocolo de multiplexacion( CAN, KWP, ISO) usa este modelo lo he buscado y o encuentro  :(.

Fisicamente el conector debajo del tablero es un tipo OBDII 16 pines color verde con negro y tiene la siguiente pineria en uso: pin 1,4,5,7,10,11,15,16. Espero su ayuda . Gracias y excelente tema :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 14 de Febrero de 2011, 13:44:27
Hola amigos, me ha ido super bien con la implementacion del modulo BusCan en el dsPIC30f4011, en mi proximo mensaje le es estare enviando el codigo y mis experiencias con este dsPIC. les escribo porque quiero colocarle uin tercer nodo a mi red y no tengo la posibilidad de un transceiver mcp2551 mas. si hay alguno que tenga un transceiver de estos por favor estaria muy agradecido si me lo vende o me lo aporta, yo lo recibo con agradecimiento igual. estoy residenciado en Puerto ordaz,Estado Bolivar,Venezuela. GRACIAS MUCHACHOS ... FELIZ DIA DE EL AMOR Y LA AMISTAD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 14 de Febrero de 2011, 14:35:33
Hola amigos, me ha ido super bien con la implementacion del modulo BusCan en el dsPIC30f4011, en mi proximo mensaje le es estare enviando el codigo y mis experiencias con este dsPIC. les escribo porque quiero colocarle uin tercer nodo a mi red y no tengo la posibilidad de un transceiver mcp2551 mas. si hay alguno que tenga un transceiver de estos por favor estaria muy agradecido si me lo vende o me lo aporta, yo lo recibo con agradecimiento igual. estoy residenciado en Puerto ordaz,Estado Bolivar,Venezuela. GRACIAS MUCHACHOS ... FELIZ DIA DE EL AMOR Y LA AMISTAD

hermano como te comente yo tengo otro mas y te lo puedo hacer llevar asi como te hice llegar los dos primeros pero estoy un poco delicado de salud en lo que tenga las posibilidades me comunico contigo.

Saludos.
Atten.
Alexander Santana.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 14 de Febrero de 2011, 14:43:20
hola estoy haciendo un pryecto con el can bus de peugeot 206 año 2003 motor 1.4 y necesito saber que protocolo de multiplexacion( CAN, KWP, ISO) usa este modelo lo he buscado y o encuentro  :(.

Fisicamente el conector debajo del tablero es un tipo OBDII 16 pines color verde con negro y tiene la siguiente pineria en uso: pin 1,4,5,7,10,11,15,16. Espero su ayuda . Gracias y excelente tema :)

hola buenas tardes aca te subo un link con las descripcion de pines del obd2 asi puedes deducir que protocolo esta usando el carro que estas trabajando pero por lo que revise no es can bus ya que los pines de can bus son 6 y 14 y dichos pines no lo tienen en la pineria que indicastes.

Saludos y estamos en contaro. Haaa y segun tus pines verifica el conexionado de ISO and KWP Protocol Pins  es el que mas atina a tu carro.
Atten.
Alexander santana.
Venezuela-Barcelona.

http://www.auterraweb.com/obdiipinout.html
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2011, 15:01:13
El link ya no existe, debe haber algún problema...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 14 de Febrero de 2011, 15:22:16
El link ya no existe, debe haber algún problema...

gracias hermano ya lo subir bien
Título: Re: Mis experiencias con el BUS CAN
Publicado por: robertdanyel en 14 de Febrero de 2011, 15:32:06
hermano como te comente yo tengo otro mas y te lo puedo hacer llevar asi como te hice llegar los dos primeros pero estoy un poco delicado de salud en lo que tenga las posibilidades me comunico contigo

Ok mi hermano... Gracias por la ayuda... Y que te mejores pronto !!!! estamos hablando
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 14 de Febrero de 2011, 18:42:18
hermano como te comente yo tengo otro mas y te lo puedo hacer llevar asi como te hice llegar los dos primeros pero estoy un poco delicado de salud en lo que tenga las posibilidades me comunico contigo

Ok mi hermano... Gracias por la ayuda... Y que te mejores pronto !!!! estamos hablando

tranquilo vale no te preocupes lo que si te pediria es que hagamos un equipo de trabajo asi no pierdo el animo ya que solo uno se descuida y si hay reto es mejor asi que vamos a ver quien lo hace mejor es un reto sano pero por la perfeccion saludos y es broma pero los reto si son buenos.

Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 17 de Febrero de 2011, 07:41:44
Buenos dias, que cable trensado me recomiendan para hacer pruebas con mi red can bus a larga distancia a diferentes velocidades.

saludos y espero su gentil colaboracion.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 17 de Febrero de 2011, 08:05:17
Yo utilizo el cable UTP, el de redes de cómputos, que tiene 4 pares balanceados con características parecidas al estándar de CAN.
Por uno de los pares transmito y por otros dos llevo tensión para alimentar placas.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 17 de Febrero de 2011, 09:03:04
Yo utilizo el cable UTP, el de redes de cómputos, que tiene 4 pares balanceados con características parecidas al estándar de CAN.
Por uno de los pares transmito y por otros dos llevo tensión para alimentar placas.

yo aca nodo le hice su fuente de alimentacion para evitar eso, es mi punto de vista porque 5volti a largas distancia se atenua.

Saludos y ya un colega me recomento ese cable pero queria saber mas opiones; probare y les comento.

Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 17 de Febrero de 2011, 10:52:53
Por el cable llevo 12VCC, en cada placa regulo a 5 VCC, por la caída de tensión.
En síntesis, no es mas que lo que se hace en un automóvil, para lo que fue diseñado el BUS CAN en su origen.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 17 de Febrero de 2011, 14:44:57
Por el cable llevo 12VCC, en cada placa regulo a 5 VCC, por la caída de tensión.
En síntesis, no es mas que lo que se hace en un automóvil, para lo que fue diseñado el BUS CAN en su origen.

Ok entendido esa parte entonce experimento y les comento como me fue.

Saludos y gracias por los datos.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nacho84 en 23 de Febrero de 2011, 15:10:41
Hola, saludos a todos:
Lo primero queria dar las gracias a la ayuda desinteresada de todos los participantes del Foro, comportamientos como el vuestro este son difíciles de encontrar en la sociedad actual. Acabado el peloteo voy a pasar a exponer mi problema.
Estoy desarrollando varias placas basadas en el PIC 18F4685 las cuales pretendo q se comuniquen mediante el bus can. Las placas ya las tengo montadas y en principio para otras funciones básicas (Interrupciones, LCD,ect) no tengo ningún problema y todo funciona como cabe esperar. Mi problema es al intentar comunicarlas entre ellas. Mi desgracia ha sido enterarme tarde del hilo de este Foro creo q me hubiese ayudado mucho en los principios. El caso es q me baso en los ejemplos q proporciona CCS para la comunicacion CAN al igual q vosotros pero sin los mismos resultados. Como "transciver" utilizo el MCP2551 y entiendo q los únicos cambios q tengo q hacer al código del ejemplo es cambiar #include por mi modelo de PIC y la libreria de comunicación por la can-mcp251x.c. Por otro lado no sé q tan importante es la resistencia de 10 Ohmnios entre la patilla Rs del MCP2551 y masa según la datasheet parece q tb valdria con conectarla directamente a masa (Modo High-Speed) de todas maneras he probado ambas opciones sin éxito. Otra de mis dudas son los LEDs en serie con la resistencia colocadas en las patillas RX y TX del micro no se si al no recibir un nivel alto de primeras provoca q falle el MCP2551. Por otro lado si q parece q el micro envia señal a traves de TX, eso me dice el osciloscopio pero despues del MCP2551 ya no hay señal. Como veis tengo muchas dudas q agradecería mucho si alguien me pudiese ayudar.

Muchas gracias a todos, un saludo
Título: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Febrero de 2011, 20:49:14
Citar
Como "transciver" utilizo el MCP2551 y entiendo q los únicos cambios q tengo q hacer al código del ejemplo es cambiar #include por mi modelo de PIC y la libreria de comunicación por la can-mcp251x.c.

Esta mal la parte de la libreria usada, esa que comentas es para el controlador CAN MCP2515.
Con ese PIC lo que debes usar es Can.18Fxx.c o algo asi, ya que aqui no tengo nada a mano para darte el nombre correcto.
Buscala en la carpeta de los ejemplos y en la de drivers y la encontraras seguramente, en el encabezado esplica como usarla... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: juaukosta en 26 de Febrero de 2011, 13:48:51
Hola a todos!

Ahora estoy empezando a trabajar con la red CAN y tieno la necesidad de elegir un cable de 100 metros a una red CAN en una fábrica. ¿Qué me aconseja? Hice una investigación de largo y que se encuentran estos cables:

1. http://pt.farnell.com/pro-power/pd1002/cable-scrn-2pair-7-0-203mm-100m/dp/1219358

2. http://pt.farnell.com/pro-power/tem0038-2009/cable-cw1311-6core-100m/dp/1202605

3.  http://www.hitechcontrols.com/cables/data_network_bus/helukabel_bus_cables/fieldbus_without_ground.html

4. http://pt.farnell.com/pro-power/2192-0-5mmblk100m/cable-flex-2192-black-0-5mm-100m/dp/1333036?crosssellid=1333036&crosssell=true&in_merch=true y

Le agradecería su ayuda, es muy importante para mí.

Saludos,
João Costa
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 26 de Febrero de 2011, 14:39:51
Hola a todos!

Ahora estoy empezando a trabajar con la red CAN y tieno la necesidad de elegir un cable de 100 metros a una red CAN en una fábrica. ¿Qué me aconseja? Hice una investigación de largo y que se encuentran estos cables:

1. http://pt.farnell.com/pro-power/pd1002/cable-scrn-2pair-7-0-203mm-100m/dp/1219358

2. http://pt.farnell.com/pro-power/tem0038-2009/cable-cw1311-6core-100m/dp/1202605

3.  http://www.hitechcontrols.com/cables/data_network_bus/helukabel_bus_cables/fieldbus_without_ground.html

4. http://pt.farnell.com/pro-power/2192-0-5mmblk100m/cable-flex-2192-black-0-5mm-100m/dp/1333036?crosssellid=1333036&crosssell=true&in_merch=true y

Le agradecería su ayuda, es muy importante para mí.

Saludos,
João Costa

Hola buenas, oye refirientome a las caracteristicas de can bus y su cableado tienen como norma y estudio de atenuacion en la red cable trenzado para disminuir ruido, vi los link y no veo un cable con las caracteristicas de par trenzado y mas  para esa distancia de 100 metros.

Saludos.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Febrero de 2011, 15:45:56
Como seguramente en una instalacion industrial el CanBus va a ser inmediatamente reemplazado por un bus basado en CanBus pero bien industrial, te recomiendo usar cables para DeviceNet o CanOpen, que son los estandares industriales.

Aqui algunos ejemplos de ambos...
http://www.odva.org/Home/CIPSUPPLIERDIRECTORY/DeviceNetProducts/ProductDetails/tabid/151/ctl/Detail/mid/512/xmid/17219/xmfid/7/lng/en-US/language/en-US/Default.aspx (http://www.odva.org/Home/CIPSUPPLIERDIRECTORY/DeviceNetProducts/ProductDetails/tabid/151/ctl/Detail/mid/512/xmid/17219/xmfid/7/lng/en-US/language/en-US/Default.aspx)
Para CanOpen - Marca Belden (http://www.belden.com/07Markets/07_Industrial/07_Industrial_Network_Protocol_Solutions/Can_Open.cfm)
Para DeviceNet -  Marca Belden (http://www.belden.com/07Markets/07_Industrial/07_Industrial_Network_Protocol_Solutions/DeviceNet.cfm)


Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nacho84 en 27 de Febrero de 2011, 12:48:21
Muchas gracias MGLSOFT!!!

La librería de la q hablas es <can-18xxx8.c> pero al parecer este no es el único fallo q tengo pq sigue sin funcionar no obstante muchas gracias por tu interés seguiré buscando mi error.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Febrero de 2011, 22:47:38
Es esa, precisamente...
Porque no publicas tu esquematico, tal vez por alli viene algun fallo..

Todos tus nodos tienen la misma velocidad, no??
No se repite ningun ID , no??

Busca esos fallos, que son los mas comunes..
Título: analizador BUS CAN
Publicado por: ASTROCAR en 01 de Marzo de 2011, 00:40:14
Hola buenas  noches, les presento mi nueva herramienta que no es mas que el analizador can bus de microchip les adjunto una foto y si alguien ha tenido experiencia con dicho analizador que por favor las comente; yo de momento lo voy a probar en una red simple de dos nodos y les comento.

Saludos y cualquier experiencia es buena conocerla.
Atten.
Alexander Santana.
Venezuela-Barcelona.

(http://img543.imageshack.us/img543/449/analizadorcan.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Marzo de 2011, 08:10:39
Linda herramienta!!
Ya les has entrado?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 02 de Marzo de 2011, 06:05:27
Linda herramienta!!
Ya les has entrado?? :mrgreen:

Hola buenops dias gracias por sus palabras, ahora en cuanto a si ya lo probe si en una red de un carro y solo mostro usa traza es decir un trama  y luego se perdio la comunicacion lo estuve con el conector obd2 del carro y un scaner que tengo para ver el vin del carro y lo que ocurrio fue que cuando le di en el scanner leer informacion en el analizador vi la trama que envia el scaner pero luego no luego se cae la comunicacion y en el scanner no se ver el vin con el analizador pegado pero si quito el analizado si veo la informacion solicitada por el scanner. lo que si es que si vuelvo a colocar el analizador y pido nuevamente informacion desde el scanner el analizador me muestra la trama que envia el scanner pero ya de ese punto no pasa; tambien probe scanner y analizador y desde el scanner hice lo mismo medir informacion al carro sin estar conectado y vi la misma trama pero logicamente no vi respuesta porqwue no esta conectado a la red del carro.

Saludos y si alguienm lo ha usado y tiene experienci en su uso bienvenida sea.
Atten.
Alexander Santana.
Barcelona-Venezuela.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Marzo de 2011, 08:02:44
Es que deberias usar un solo scanner por vez, ya que es posible que tengan el mismo ID y no reciban los mensajes juntos...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 02 de Marzo de 2011, 23:03:49
Es que deberias usar un solo scanner por vez, ya que es posible que tengan el mismo ID y no reciban los mensajes juntos...
No entendi esa parte y de hecho yo uso solo un scanner.

Saludos y si puedes explicarme un poco mejor.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Eldudas en 14 de Marzo de 2011, 12:52:48
Hola, felicidades por este estupendo hilo :-/,  la vedad es que es una pasada, despues de mirarmelo un poco me surgen algunas dudas, no me extrañaría que ya estuviesen resueltas en el hilo, pero no lo supe encontrar :5], espongo mis dudas y si me podeis aclarar o indicar donde se encuentran dentro del hilo os lo agradecería.

No tengo claro como se programan los registros  específicos del MCP2510, como los buffers de recepción, las mascaras o los filtros, con la librerías de CCS, si que vi como configurar el baud rate, pero veo que siempre se llama a "can_init();" y no se ver como se le pasan los parámetros a configurar.

También veo que se comenta que se tiene que programar el MCP2550, yo creía que solo se programaba el MCP2510 /MCP2515, si utilizo un MCP2515 y un MCP2550 debo de programar alguna cosa en el MCP2550?  

Y la ultima duda en los ejemplos no veo que se configure el modulo SPI, yo suelo usar esta "setup_spi(SPI_MASTER|SPI_L_TO_H|SPI_CLK_DIV_4);" directiva de CCS para configurarlo, pero no veo como lo hacéis en los ejemplos.
encontré la respuesta al asunto de SPI en http://www.todopic.com.ar/foros/index.php?topic=19182.660

Bueno se agradece cualquier aclaración.


Gracias y saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Marzo de 2011, 15:13:39
Citar
No tengo claro como se programan los registros  específicos del MCP2510, como los buffers de recepción, las mascaras o los filtros, con la librerías de CCS, si que vi como configurar el baud rate, pero veo que siempre se llama a "can_init();" y no se ver como se le pasan los parámetros a configurar.

Tal como están hechas las librerías, no se pasan parámetros para la librería de CCS, igual que en las de Microchip, asumen una velocidad de comunicación de 125.000 bps.
Aparentemente es un estándar, porque en librerías de freescale también asumen esa misma velocidad inicial.

Hay que pasar muchos parámetros juntos, a diferentes registros, por eso lo simplifican. Ademas, como también se afecta por el cristal del oscilador que uno pone, hay que modificar los registros según lo que uno usa.

Citar
También veo que se comenta que se tiene que programar el MCP2550, yo creía que solo se programaba el MCP2510 /MCP2515, si utilizo un MCP2515 y un MCP2550 debo de programar alguna cosa en el MCP2550?   

El MCP2550 es un dispositivo OTP (One Time Programming, o programable por única vez) que solo unos pocos programadores lo soportan, y permite ejecutar acciones interesante en el bus Can sin disponer de un microcontrolador.

Para algunas funciones esta muy interesante, como tomar valores y enviarlos, manejar pwm en forma remota, y varias cosas mas que ya describimos en algún momento.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Eldudas en 14 de Marzo de 2011, 19:17:20
OK MGLSOFT, me quedó todo claro, creo que para comenzar a realizar pruebas no modificaré la configuración que realiza por defecto las librerías de CCS, solo el baud rate para poder ajustar diferentes velocidades según el XT, la idea es usar un 18f2550 para poder crear un control domótico, bueno cuando realice alguna cosa ya lo reportare por estos lares. Gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Eldudas en 15 de Marzo de 2011, 19:09:19
Hola de nuevo, encontré esta página http://mcp2515ccs.sourceforge.net/ donde hay unas librerías que si permiten pasarles parámetros y además en castellano, me lo miré un poco y comencé a entender por que lo simplifican :shock:, hay un MONTÓN de registros.... :?... y la verdad que me tiene algo liado, intente ver como se gestiona la configuración de la velocidad y no tengo claro que valor o valores le tendría que pasar a config, coloqué algún comentario más para poder entender mejor como se gestiona, pero no lo tengo del todo claro os pongo  solo la parte del código para configurar la velocidad.

/************************http://mcp2515ccs.sourceforge.net/*******************************/
//
// CONFIGURACIÓN DE LA VELOCIDAD DEL BUS: Configura los parámetros de velocidad
// y sincronización del bus
//    Parámetros:
//       config: especifica alguna de las opciones de velocidad y de
//          sincronización
//       BRP (Baud rate Prescaler): Preescalado de la velocidad,registro CNF1 (2Ah) bits de 0 al 5
//       PRSEG (Propagation Segment Length): Longitud del segmento de
//          propagación, registro CNF2 (29h) bit 0 al 2
//       PHSEG1 (phase segment 1): segmento de fase 1, se utiliza para compensar
//          los retrasos de línea, registro CNF2 (29h)  del bit 3 al 5
//       PHSEG2 (phase segment 2): segmento de fase 2, se utiliza para compensar
//          los retrasos de línea, registro CNF3 (28h) del bit 0 al 2
//    Devuelve: true si los parámetros son correctos, y false en caso contrario
//
// Calculo para XT de 8Mhz y CAN a 125Khz Baud  250K_Baud  500K_Baud
//   Baud Rate Prescaler (BRP)       = 1           1            0
//     Propagation Delay (PRSEG))     = 1                        1            1
//     Phase Segment 1 (PRSEG)       = 8                        3            3
//     Phase Segment 2 (PRSEG)       = 6                        3            3
/******************************************************************************/
int1 can_set_baud(int32  config,unsigned int8 BRP,unsigned int8 PRSEG,unsigned int8 PHSEG1,unsigned int8 PHSEG2){
   int8 CNF1_b, CNF2_b, CNF3_b;
  
   // Comprobando los parametros
   if( (BRP > 0x3F )|| (PRSEG > 0x08) || (PHSEG1 > 0x08) || (PHSEG2 > 0x08)) return FALSE;
  
   // Cambiando a modo Configuracion
   while(!( can_set_mode(CAN_OP_CONFIG)));
  
   // Configurando registros
   CNF1_b = make8(config,0) | (BRP);
   CNF2_b = make8(config,1) | ((PHSEG1-1) << 3) | (PRSEG-1);
   CNF3_b = make8(config,2) | (PHSEG2-1);
  
   // Escribiendo en los registros
   mcp2510_write(CNF1, CNF1_b);
   mcp2510_write(CNF2, CNF2_b);
   mcp2510_write(CNF3, CNF3_b);
  
   while(!( can_set_mode(CAN_OP_NORMAL)));
  
   return TRUE;
}

Para configurar a 125KBs con un xt de 8Mhz creo que tendría que ser algo asi?

can_set_baud (???,1, 1, 8, 6); // no tengo claro que le tengo que pasar a config


Saludos

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Marzo de 2011, 20:30:25
Citar
Para configurar a 125KBs con un xt de 8Mhz creo que tendría que ser algo asi?

can_set_baud (???,1, 1, 8, 6); // no tengo claro que le tengo que pasar a config

Yo uso una herramienta que permite obtener los valores correctos a poner en los registros de configuracion, que menciono aquí. (http://www.todopic.com.ar/foros/index.php?topic=19182.msg137961#msg137961)

Si quieres entender como es la seleccion de los correctos valores de configuracion, puedes leerte la nota de aplicacion de Microchip AN754 que la encuentras aquí. (http://ww1.microchip.com/downloads/en/AppNotes/00754.pdf)

Estuve mirando y me han borrado varias imágenes de imageshak.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Eldudas en 16 de Marzo de 2011, 11:14:25
Me lo miraré. Gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dravenar en 31 de Marzo de 2011, 15:25:38
Hola a todos.

He topado con este foro porque estoy en un haciendo un proyecto basado en BUS CAN usando J1939 y estoy buscando información sobre este protocolo.

El problema que tengo es que no se como interpretar el campo de datos que me da mi analizador. El mensaje del campo de datos es este: 46 C4 FF 00 FF FF FF FF

Buscando por internet no he encontrado como intrepretarlo. ¿Cómo se yo que valores me está dando este mensaje?

Espero haberme explicado bien. Muchas gracias a todos!
Saludos Sergio.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Marzo de 2011, 15:49:37
Deberás tener el manual donde dice que son esos valores, ya que pueden ser solo bytes o words o flotantes los valores, y deberás saber que es cada uno...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dravenar en 01 de Abril de 2011, 05:04:24
Deberás tener el manual donde dice que son esos valores, ya que pueden ser solo bytes o words o flotantes los valores, y deberás saber que es cada uno...

Esos valores los tengo. Según el manual, para este mensaje: 46 FF E0 25 FF FF FF FF, los posibles valores son:
* Byte 1 --> Temperatura agua (Factor: 1ºC, Offset: -40ºC, Rango: -40º a 210º).
* Byte 2 --> Temperatura combustible  (Factor: 1ºC, Offset: -40ºC, Rango: -40º a 210º).
* Byte 3-4 --> Temperatura aceite (Factor: 0,03125, Offset: -273ºC, Rango: -273º a 1735º)

Pienso que el Byte 1 = 46. ¿Estoy en lo cierto?

Haciendo cálculos 46 en decimal = 70. Si le restamos el Offset, nos queda una temperatura de 30ª. Así lo he hecho con el resto de byte de tal forma que para el Byte 3-4 la temperatura me sale 1520,15 ºC. La temperatura del Byte 2 parace que no la ha leido bien.

¿He realizado bien los cálculos?

Gracias y Saludos, Sergio
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Abril de 2011, 08:07:32
Seguro que hay que restar el Offset a cada medida o ya viene hecho??
Por otro lado, no entiendo de donde obtienes el valor que dices en el byte 3 y 4, no encuentro forma de llegar al mismo valor.
Lo del byte 2 en FF, posiblemente lo hayas leído mal, aunque sospecho que es muy remota la posibilidad, yo me inclino a pensar que el sensor en cuestión se rompió y fue a sobrerrango la lectura.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dravenar en 01 de Abril de 2011, 08:27:23
Seguro que hay que restar el Offset a cada medida o ya viene hecho??

Pienso que hay que restar el Offset al valor obtenido de pasar hexadecimal a decimal.

Por otro lado, no entiendo de donde obtienes el valor que dices en el byte 3 y 4, no encuentro forma de llegar al mismo valor.

El bit 3-4 es E025. Pasándolo a Decimal me sale 57381.  Este valor lo multiplico por 0,03125 y me sale 1793,15. Le resto el Offset que es 273 y me sale 1520,16

Lo del byte 2 en FF, posiblemente lo hayas leído mal, aunque sospecho que es muy remota la posibilidad, yo me inclino a pensar que el sensor en cuestión se rompió y fue a sobrerrango la lectura.

Al igual que tú, pienso que ha sido una mala lectura del sensor.

¿Es correcto el orden en el cual cojo los bits, es decir el bit 1 = 65, el bit 2 = FF y así sucesivamente?

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Abril de 2011, 08:37:32
Citar
El bit 3-4 es E025. Pasándolo a Decimal me sale 57381.  Este valor lo multiplico por 0,03125 y me sale 1793,15. Le resto el Offset que es 273 y me sale 1520,16

Y que es el 0,03125 ese, una conversión a ºC ??
Porque las otras temperaturas están en ºC entonces??

El orden de los bytes que tomas es correcto.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Abril de 2011, 08:39:00
Que aceite trabaja a esa temperatura?? :shock: :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dravenar en 01 de Abril de 2011, 08:49:25
Que aceite trabaja a esa temperatura?? :shock: :shock:

Por ese motivo, no se si estoy haciendo bien los cálculos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Abril de 2011, 08:55:26
Ordena los bytes al revés y obtendrás un valor mas creíble.
Es normal transmitir el byte de mayor peso primero...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dravenar en 01 de Abril de 2011, 09:04:21
Ordena los bytes al revés y obtendrás un valor mas creíble.
Es normal transmitir el byte de mayor peso primero...

Cierto es!!! Si en vez de E025 pongo 25E0, al pasarlo a decimal me sale 9696. Aplicándole el factor 0,03125 me sale 303 y quitándole el Offset, me da 30ºC.

Este si es un valor mucho más creíble, y sobre todo posible.

Gracias por la observación. Saludos Sergio.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Abril de 2011, 09:07:11
Tienes lectura real de las temperaturas esas??
Yo creo que no hay que restar el offset.
Me suena que ese motor esta parado, si tiene lecturas de 30 grados... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dravenar en 01 de Abril de 2011, 20:19:28
Tienes lectura real de las temperaturas esas??
Yo creo que no hay que restar el offset.
Me suena que ese motor esta parado, si tiene lecturas de 30 grados... :mrgreen: :mrgreen:

Lecturas reales no tengo. Sólo tengo los datos del mensaje que el analizador de tramas me muestra.

El motor estaba parado, es decir, sin encender. Por eso veo lógico que sean 30º. Si no le restariamos el Offset, nos saldría una tempreatura de 70º y eso si que no tiene sentido con un motor sin encender.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Abril de 2011, 00:30:38
Como dice el chavo, Lo supe desde un principio...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 04 de Abril de 2011, 07:28:08
Tienes lectura real de las temperaturas esas??
Yo creo que no hay que restar el offset.
Me suena que ese motor esta parado, si tiene lecturas de 30 grados... :mrgreen: :mrgreen:

Lecturas reales no tengo. Sólo tengo los datos del mensaje que el analizador de tramas me muestra.

El motor estaba parado, es decir, sin encender. Por eso veo lógico que sean 30º. Si no le restariamos el Offset, nos saldría una tempreatura de 70º y eso si que no tiene sentido con un motor sin encender.

Hola buenos dias , una consulta con que analizador estas observando las tramas y discilpa.


Saludos y estamos en contacto.
Atten.
Alexander Santana.
Venezuela-Barcelona.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dravenar en 26 de Abril de 2011, 09:01:22
Citar

Hola buenos dias , una consulta con que analizador estas observando las tramas y discilpa.


Para analizar las tramas uso el software CanAnalyzer y el hardware CanCase XL.

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dravenar en 26 de Abril de 2011, 09:04:40
Hola.

Tengo un sensor que tiene cuatro cables (rojo, negro, blanco, amarillo). Dos de ellos son GND y V (negro y rojo) y los otros dos son CAN-H y CAN-L.

Hemos alimentado a este sensor con 11V, y hemos medido la tensión en los otros dos cables, y se tienen 9.1V en el amarillo y 8.3V en el blanco. El de mayor tensión tendría que ser el CAN-H y el de menor tensión el CAN-L.

¿CAN-H y CAN-L pueden tener tanta tensión? 

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Abril de 2011, 09:17:29
Hola.

Tengo un sensor que tiene cuatro cables (rojo, negro, blanco, amarillo). Dos de ellos son GND y V (negro y rojo) y los otros dos son CAN-H y CAN-L.

Hemos alimentado a este sensor con 11V, y hemos medido la tensión en los otros dos cables, y se tienen 9.1V en el amarillo y 8.3V en el blanco. El de mayor tensión tendría que ser el CAN-H y el de menor tensión el CAN-L.

¿CAN-H y CAN-L pueden tener tanta tensión? 

Saludos.

Esas tensiones referidas a que las tomas??
El bus es diferencial, deberias tomarlas entre los hilos del bus y a masa cada uno de ellos.
Por lo que se, esas tensiones no son normales, creo que en este hilo hace un tiempo puse una idea de las tensiones que deben ser las usuales.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dravenar en 26 de Abril de 2011, 10:14:58
Esas tensiones referidas a que las tomas??
El bus es diferencial, deberias tomarlas entre los hilos del bus y a masa cada uno de ellos.
Por lo que se, esas tensiones no son normales, creo que en este hilo hace un tiempo puse una idea de las tensiones que deben ser las usuales.

Buscando en el hilo, he visto una captura donde pone que en el nivel Dominante, la tensión diferencial (CAN_H - CAN_L) es del orden de 2.0 V con CAN_H = 3.5V y CAN_L = 1.5V (nominales), y en el nivel Recesivo, la tensión diferencial (CAN_H - CAN_L) es del orden de 0V con CAN_H = CAN_L = 2.5V (nominales).

¿Estas son las máximas y mínimas tensiones que pueden tomar el CAN-H y CAN-L?

Cuando dices que deberia de tomar las medidas "entre los hilos del bus y a masa cada uno de ellos", ¿a que te refieres? ¿medir por un lado del CAN-L a masa? y por el otro CAN-H a masa?

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Abril de 2011, 10:33:59
Esas tensiones referidas a que las tomas??
El bus es diferencial, deberias tomarlas entre los hilos del bus y a masa cada uno de ellos.
Por lo que se, esas tensiones no son normales, creo que en este hilo hace un tiempo puse una idea de las tensiones que deben ser las usuales.

Buscando en el hilo, he visto una captura donde pone que en el nivel Dominante, la tensión diferencial (CAN_H - CAN_L) es del orden de 2.0 V con CAN_H = 3.5V y CAN_L = 1.5V (nominales), y en el nivel Recesivo, la tensión diferencial (CAN_H - CAN_L) es del orden de 0V con CAN_H = CAN_L = 2.5V (nominales).

¿Estas son las máximas y mínimas tensiones que pueden tomar el CAN-H y CAN-L?

Cuando dices que deberia de tomar las medidas "entre los hilos del bus y a masa cada uno de ellos", ¿a que te refieres? ¿medir por un lado del CAN-L a masa? y por el otro CAN-H a masa?

Saludos.

Si quieres saber cuanto mide CAN H por su lado debes referirlo a masa, igual para CAN L.
La tensión diferencial se mide entre ambos hilos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Omarsan en 27 de Abril de 2011, 22:59:25
Hola a todos alguien podría ayudarme, por favor.
Soy mecánico y mi problema es este: adapte un motor ISBe de Cummins en una camioneta Ford 350 que tenia anteriormente un motor powerstroke navistar, ya arranca el motor con la llave del vehículo, pero no encuentro la manera de que la información de presiones, temperaturas y revoluciones del motor, sean desplegadas en el tablero de instrumentos.
El diagramado del motor anterior indica que el computador del motor enviaba la información a través del par trenzado can1 (can1H y can1L) ó J2284 y el diagramado del motor actual envía la información por el par trenzado J1939. ¿cómo podría hacer funcionar el tablero de instrumentos que utilizaba J2284, con el J1939?.
Gracias por su ayuda.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 28 de Abril de 2011, 07:39:54
Citar

Hola buenos dias , una consulta con que analizador estas observando las tramas y discilpa.


Para analizar las tramas uso el software CanAnalyzer y el hardware CanCase XL.

Saludos.
Haa ok gracias por el dato ¡he oido del software can Analyzer pero del hardware can case Xl no es una interface construida por usted o es paga de ser asi pude subir mas informacion al respecto yo por mi parte investigo al rato sobre la misma.

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Abril de 2011, 08:05:54
Hola a todos alguien podría ayudarme, por favor.
Soy mecánico y mi problema es este: adapte un motor ISBe de Cummins en una camioneta Ford 350 que tenia anteriormente un motor powerstroke navistar, ya arranca el motor con la llave del vehículo, pero no encuentro la manera de que la información de presiones, temperaturas y revoluciones del motor, sean desplegadas en el tablero de instrumentos.
El diagramado del motor anterior indica que el computador del motor enviaba la información a través del par trenzado can1 (can1H y can1L) ó J2284 y el diagramado del motor actual envía la información por el par trenzado J1939. ¿cómo podría hacer funcionar el tablero de instrumentos que utilizaba J2284, con el J1939?.
Gracias por su ayuda.

Busca en las paginas de los fabricantes, seguramente debe existir una electrónica que oficie de Gateway (traductor entre protocolos) que se programe para hacer el traslado de variables entre uno y otro.
No es un problema sencillo el tuyo, pero debe existir una solución, seguramente.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Abril de 2011, 08:08:00
Citar

Hola buenos dias , una consulta con que analizador estas observando las tramas y discilpa.


Para analizar las tramas uso el software CanAnalyzer y el hardware CanCase XL.

Saludos.
Haa ok gracias por el dato ¡he oido del software can Analyzer pero del hardware can case Xl no es una interface construida por usted o es paga de ser asi pude subir mas informacion al respecto yo por mi parte investigo al rato sobre la misma.

Saludos.

Aquí tienes la información de ese producto:

http://www.vector.com/vi_cancase_xl_en.html (http://www.vector.com/vi_cancase_xl_en.html)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Omarsan en 28 de Abril de 2011, 23:23:35
Hola a todos alguien podría ayudarme, por favor.
Soy mecánico y mi problema es este: adapte un motor ISBe de Cummins en una camioneta Ford 350 que tenia anteriormente un motor powerstroke navistar, ya arranca el motor con la llave del vehículo, pero no encuentro la manera de que la información de presiones, temperaturas y revoluciones del motor, sean desplegadas en el tablero de instrumentos.
El diagramado del motor anterior indica que el computador del motor enviaba la información a través del par trenzado can1 (can1H y can1L) ó J2284 y el diagramado del motor actual envía la información por el par trenzado J1939. ¿cómo podría hacer funcionar el tablero de instrumentos que utilizaba J2284, con el J1939?.
Gracias por su ayuda.

Busca en las paginas de los fabricantes, seguramente debe existir una electrónica que oficie de Gateway (traductor entre protocolos) que se programe para hacer el traslado de variables entre uno y otro.
No es un problema sencillo el tuyo, pero debe existir una solución, seguramente.
O.k gracias por el consejo, buscaré con el fabricante.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: danyferchu en 20 de Mayo de 2011, 17:51:11
MUY BUENO este hilo :-/ apenas voy leyendo 5 paginas y estoy entuciasmadisimo por ver en q punto del proyecto estaran ahora
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Mayo de 2011, 21:50:29
Ahora aprendiendo CanOpen.... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marco2287 en 20 de Junio de 2011, 17:05:16
Hola MGLSOFT te felicito por tu labor como moderador de este tema.. Mi pregunta es sencilla ahi manera de simular una red CANBUS con X nodos a travez del proteus, multisim, Labview, etc.. Me interesa muchisimo xq estudio telecom y en la catedra transmision de datos estamos empezando a manejar este protocolo y una de las evaluaciones es simular una red CANBUS.. Estuve revisando por mis experiencias con canbus y lamento haber llegado tarde al foro me hubiese gustado apreciar desde el principio el desarrollo del tema xq en una sentanda no estan facil de apreciar el desarrollo del mismo.. Muchas Gracias..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Junio de 2011, 19:14:49
Proteus hasta ahora no lo simula.
No conozco si multisim o Labview pueden hacerlo, porque no los manejo.
Igualmente, en una universidad que si las piden tienen muestras gratis, yo armaría las placas y hago mucho mas que solo simularlo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marco2287 en 21 de Junio de 2011, 04:33:24
Gracias MGLSOFT...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 21 de Junio de 2011, 07:44:48
Hola buenos dias a todo la comunidad forista y en particular a los miembros de este foro; ahora en cuanto al tema de simulacion primero que nada me da gusto ver colegas de venezuela o el tema y mas cuando dices que en universidades lo estan explicando como catedra pensaba que estamos atrasado pero ya veo que no; en fin como ya lo dijo el colega marco hasta ahora no se conoce una aplicacion que permita simular canbus pero es cuestion de armar pequeñas placa y hacer pruebas.

Saludos y cualquier cosas estamos en contacto.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: marco2287 en 22 de Junio de 2011, 02:55:36
Q tal astrocar y si se ven estos temas.. por ahora me he conformado con el Xtm/can 3.8 en http://recursos3.planetaclix.pt/canuart/index.html (cap 4,5,6 muy interesantes) y el CANOE/CANALYZER 7 en  https://www.vector.com/vi_index_en.html pues ahí versiones demos que no necesitan hardware externo y simulan ciertos ejemplos utiles para la compresión del protocolo claro enfocados al ámbito automotriz.. Aunque algunos ejemplos observados solo muestran la red can.. Ahora me toca empezar a entretenerme con ellos y ver que cosas se pueden hacer alli (crear nodos, ID nodos, tramas, velocidades, etc) xq  por lo visto el canoe es tremenda herramienta muy poderosa..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 24 de Junio de 2011, 10:26:21
Hola buenos dias; una consulta que les tengo, estoy analizando can bus en un carro para un principio de seguridad que aplican en los nuevos reproductores de pantalla tactil. El cual consite en que cuando el carro este en pare(P) el video del reproductor se pueda ver sin problema y es logico porque asi el carro esta parado y el conductor si puede estar viendo la pantalla ahora cuando el carro entra en marcha es decir (D) el video se cancela y solo queda el audio con el fin de que el conductor no se distraiga y puedo causar accidentes. El tema de can bus en este sistema de segurida se maneja atreves de can bus es decir cuando ve ese cambios en la palanca de velocidades atraves de can bus le informa al reproductor que hacer si activar o desactivar el video y mi es estudiar todo ese principio y emular la señal de pare(P) y enviarla al reproductor via can bus por eso estoy analizando la trazas de can bus que pasan por eso nodo pero en el analizador que uso que es el de michochip (Can Bus Analyzer) cuando captura la trama me indica un DLC=24 y eso me resulta raro ya que el DLC indica es la cantidad de byte que va a tener la trama que es de 0 .. 8 byte.

Saludos y luego le subo una imagente de la captura de la trama con el analizador.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 24 de Junio de 2011, 10:33:18
Hola buenos dias; una consulta que les tengo, estoy analizando can bus en un carro para un principio de seguridad que aplican en los nuevos reproductores de pantalla tactil. El cual consite en que cuando el carro este en pare(P) el video del reproductor se pueda ver sin problema y es logico porque asi el carro esta parado y el conductor si puede estar viendo la pantalla ahora cuando el carro entra en marcha es decir (D) el video se cancela y solo queda el audio con el fin de que el conductor no se distraiga y puedo causar accidentes. El tema de can bus en este sistema de segurida se maneja atreves de can bus es decir cuando ve ese cambios en la palanca de velocidades atraves de can bus le informa al reproductor que hacer si activar o desactivar el video y mi idea es estudiar todo ese principio y emular la señal de pare(P) y enviarla al reproductor via can bus por eso estoy analizando la trazas de can bus que pasan por eso nodo pero en el analizador que uso que es el de michochip (Can Bus Analyzer) cuando captura la trama me indica un DLC=24 y eso me resulta raro ya que el DLC indica es la cantidad de byte que va a tener la trama que es de 0 .. 8 byte.

Saludos y luego le subo una imagente de la captura de la trama con el analizador.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Junio de 2011, 21:26:34
Y la imagen?? :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 24 de Junio de 2011, 21:52:35
Hola buenas noches aca subo la captura.

Saludos y gracias por tu atencion
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 28 de Junio de 2011, 22:34:24
Hola buenas noches; les comento que he estado investigando mas el tema del DLC y por mas que leo y busco no le encuento explicacion del porque el analizador ve 24 si lo maxima cantidad es 8 byte ademas que el DLC es de 4 bits y 24 seria 100100 que es 6 bits lo otro es que tanto en formato hex como en decimal muestra 24 si alguien tiene hago que comentar al respecto se lo agradesco.

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Junio de 2011, 08:55:25
Creo que deberías consultar con Microchip, porque ademas es extraño que tanto en Hex como en decimal ponen el mismo numero, para mi es un error del software.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 29 de Junio de 2011, 09:34:13
Creo que deberías consultar con Microchip, porque ademas es extraño que tanto en Hex como en decimal ponen el mismo numero, para mi es un error del software.

 como voy a probar con otro analizador y te comento.

Saludos y estamos en contacto.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 03 de Julio de 2011, 10:33:49
Hice las pruebas y la sospecha es cierta al parecer el soft de microchip tiene  ese error porque con mi interface y el codigo que prepare para recibir can bus la captura fue igual pero en el DLC si me marco 1000 que eso es 8 mientras que con el analizador de microchip siempre marca 24.

Saludos y seguire con mi avance y les comento.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: viejoypelado en 04 de Julio de 2011, 13:08:51
Un amigo me pidió que armaramos una interface can y me pareció buena idea, pero luego de leer las páginas de su foro quedé fasinado con CAN BUS. no me imaginaba cuan grande podía ser. Soy totalmente nuevo en este tema así que estoy muy entusiasmado con la lectura de este foro
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 04 de Julio de 2011, 14:09:03
Un amigo me pidió que armaramos una interface can y me pareció buena idea, pero luego de leer las páginas de su foro quedé fasinado con CAN BUS. no me imaginaba cuan grande podía ser. Soy totalmente nuevo en este tema así que estoy muy entusiasmado con la lectura de este foro

Bienvenido al tema y nos gustaria que nos explicaras a que piensas aplicar can bus en que rema, automovil, domotica o que cosa.

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: preficetor en 13 de Julio de 2011, 05:12:53
Hola a todos.

He buscado por internet y he dado con este foro donde hablais sobre el BUS CAN.

Tengo que investigar sobre el protocolo CAN y más concretamente sobre J1939.

Estoy trabajando con un camión y para comenzar a trabajar lo único que me han dado ha sido dos cables (CAN-H y CAN-L) que me han sacado del vehículo, los cuales estan conectados por un extremo al camión y por el otro extremo a un conector DB9.

También me han suministrado un analizador de CAN. Una vez instalado el software y conectado todo (el conector macho DB9 al conector hembra DB9 del analizador), consigo ver tramas J1939 y haciendo cálculos consigo sacar los datos que contienen esas tramas. Estos datos son coherentes con todas las pruebas que hicimos, por lo tanto he de pensar que todo funciona perfectamente.

Como soy nuevo en este tema pues hay muchas cosas que no se como son ni como se harían. Mi objetivo sería hacer una pequeña interfaz gráfica a través de la cual pueda yo representar los resultados de los datos.

Como todo en la vida hay que ir paso por paso, la duda que tengo es si ¿puedo conectar el DB9 (del camión) a mi puerto serie y hacer un pequeño programa que me capture los datos por el puerto serie?

A ver si me podeis hechar un cable porque estoy un poco verde en estos temas. Si teneis alguna dudas no dudeis en plantearlas.

Muchas gracias y saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Julio de 2011, 08:03:05
OK, por lo visto estas mas avanzado que muchos que llegan aqui...
El conector DB9 es uno de los estándares de CanBus, si bien es similar al port serial, no es lo mismo.
No lo puedes conectar directo a tu puerto serie en el PC.

Si vas a programar tu interfaz gráfica, siempre deberá estar en medio el analizador CanBus.
Lo que te sugiero es que entres a la pagina del fabricante de tu analizador, ya que muchos fabricantes permiten bajar librerías o complementos para los distintos entornos de programación, que te permiten desarrollar una aplicación sin tener que escribir toda la interfaz con tu hardware analizador.
En algunos casos suelen dejar algunos ejemplos de utilización, para acelerar el proceso de análisis.

Espero te sirva de utilidad.  :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: preficetor en 13 de Julio de 2011, 09:12:57
He visto este aparato http://www.can232.com/ que parece como si fuera un conversor de Can a puerto serie. Pienso que me puede ser útil pero tampoco estoy seguro si con este aparato y un hyperterminal (bien configurado) podré ver las tramas. ¿Esto me podría ser útil?

Estoy buscando lo que me has dicho de las librerias en la web del fabricante a ver si encuentro algo. El analizador que me han dado es un CanCaseXL, que por lo que dicen es uno de los mejores.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Julio de 2011, 09:34:55
Ese que mencionas tiene librerias que te permiten hacer tu propia interfase.
De todos modos, tienes uno de los mejores productos del mercado en tus manos, porque cambiarlo??

En la pagina de Vector puedes bajar las librerias que te comente, en esta dirección y usando el filtro por productos asi:

Vector Downloads CanCaseXL (https://www.vector.com/vi_downloadcenter_en.html?type=Driver&formular_treffer_submit=1)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: preficetor en 14 de Julio de 2011, 05:32:50
He estado viendo lo que me comentaste, y la verdad es que tiene bastantes posibilidades.

El único problema es que creo que este aparato (CANcaseXL) sólo quieren usarlo para visualizar tramas, sin darle más utilidad. Por lo que yo sé el objetivo es hacer una aplicacion en C#. Es por esto por lo que necesitaria que los datos me vinieran por puerto serie, de manera que a través de unas líneas de código yo leyera lo que esta llegando por el puerto serie.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Julio de 2011, 08:31:20
Entonces si ve por el CAN232, que también te da librerías para el desarrollo de tu aplicación.
Otra opción es el de ADFWEB, que te da librerías y tiene interfase 232 o USB.
Y ahora veo que tienen por ethernet también.
http://www.adfweb.com/home/products/CAN_BUS_analyzers.asp?frompg=nav1_10 (http://www.adfweb.com/home/products/CAN_BUS_analyzers.asp?frompg=nav1_10)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 14 de Julio de 2011, 12:58:41
Hola a todos, os llevo siguiendo bastante tiempo, y estoy empezando a poner en práctica un proyecto CAN, para eso este hilo me ha venido fenomenal, pero me ha surgido un problemilla... Vereis, para ir iniciandome, he decidido hacer un receptor de mensajes CAN, y lo que reciba que lo envíe por RS232, al otro lado del bus can tengo una placa del trabajo que envía mensajes can cada 5sg a una velocidad de 50kb. Siguiendo con breakpoints, veo que no me entra al "if ( can_kbhit() )", alguien me puede echar una mano? El código es el siguiente:

Código: [Seleccionar]
#include <18F2580.h>

#device ICD=TRUE
#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 BROWNOUT              //Reset when brownout detected
#FUSES BORV21                //Brownout reset at 2.1V
#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 NOIESO                  //Internal External Switch Over mode enabled
#FUSES FCMEN                  //Fail-safe clock monitor enabled
#FUSES PBADEN                //PORTB pins are configured as analog input channels on RESET
#FUSES BBSIZ1K                //1K words Boot Block size
#FUSES NOWRTC                //configuration not registers write protected
#FUSES NOWRTB                //Boot block not write protected
#FUSES NOEBTR                //Memory not protected from table reads
#FUSES NOEBTRB                //Boot block not protected from table reads
#FUSES NOCPB                  //No Boot Block code protection
#FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
#FUSES MCLR                  //Master Clear pin enabled
#FUSES NOXINST                //Extended set extension and Indexed Addressing mode disabled (Legacy mode)

#use delay(clock=22110000)

#define CAN_DO_DEBUG TRUE
#define set_50k_baud
#include <can-18F4580.c>

void main()
{
struct rx_stat rxstat;
int32 rx_id;
int buffer[8];
int rx_len;
  int i;

for(i=0;i<8;i++)
{
buffer[i]=0;
}

printf("\r\n\r\nCCS CAN EXAMPLE\r\n");

can_init();

while(TRUE)
{
if ( can_kbhit() )
{
printf("\n\rEntro al kbhit\n\r");
printf("\r\n");
if(can_getd(rx_id, &buffer[0], rx_len, rxstat))
{
  printf("Byte 0: %X\r\n",buffer[0]);
}
}
}

}



Muchas gracias!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Julio de 2011, 14:52:25
Es extraña la frecuencia del cristal que pones allí:

Citar
#use delay(clock=22110000)

No encuentro cristales de 22110000 hz, es raro...

Ademas estas seguro que la sentencia:

Citar
#define set_50k_baud

 tiene bien hecha la configuración del baudrate para 10 Kb y ese cristal??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 14 de Julio de 2011, 15:26:57
Una duda: ¿es posible optoacoplar el bus can?, ¿se suele hacer?, ¿hay optoacopladores que soporten 1mbit/s?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Julio de 2011, 15:31:37
Si se suele hacer, lo vi escrito en varias hojas de datos de diferentes equipos.
Que optoacoplador usan no se, pero por lo que vi se hace entre el transceiver y el PIC (o controlador CAN que se use).
El transceiver va siempre conectado al bus y se optoacoplan las señales.
esto es porque el transceiver tiene todas las protecciones por sobretensiones y otras yerbas... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 14 de Julio de 2011, 15:42:41
Ah, claro, si lo pongo en la salida USART del PIC hacia el MCP2551 necesitaré un par de optos que aguanten 115Kbps. Gracias por la info Don Marcos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Julio de 2011, 15:47:44
No se conecta el MCP2551 a la USART del PIC, sino a los pines CAN TX y CAN RX respectivos, y si deben soportar hasta 1 mbit/seg... :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 14 de Julio de 2011, 15:52:10
Touché  :mrgreen:

En qué estaría yo pensando  :D

Pues va a tocar buscar optoacopladores muy rápidos, ya tuve problemas con un bus RS485 optoacoplado a 115Kbps.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 14 de Julio de 2011, 17:14:03
Es extraña la frecuencia del cristal que pones allí:

Citar
#use delay(clock=22110000)

No encuentro cristales de 22110000 hz, es raro...

Ademas estas seguro que la sentencia:

Citar
#define set_50k_baud

 tiene bien hecha la configuración del baudrate para 10 Kb y ese cristal??

Hola MGSLSOFT, si es rara, pero es esa frecuencia seguro, además lo pone en el mismo cristal, y justamente es el mismo de la placa emisora de mensajes. Supongo que esa parte está bien, la transmisión de mensajes por la UART me va bien.

Respecto a "#define set_50k_baud", he realizado los siguientes cambios en la función can_set_baud de can-18f4580.c:
Código: [Seleccionar]
void can_set_baud(void)
{
#ifdef set_50k_baud
{
BRGCON1 = 0x09;
BRGCON2 = 0xBC;      //CAN a 50 KBps     
BRGCON3 = 0x07;      //Reloj a 22,11MHz   
}#endif

#ifdef set_250k_baud
{
BRGCON1 = 0x01;
BRGCON2 = 0xBC;      //CAN a 250 KBps
BRGCON3 = 0x07;      //Reloj a 22,11 MHz 
}#endif   
}


Esos valores son los que he obtenido con el Bit Time Calculator.

Gracias por tu ayuda!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Julio de 2011, 17:49:12
Hay un problema, no le has puesto un Id al receptor, de todos modos deberia haber entrado en la linea
Citar
   if ( can_kbhit() )

Con que haces el debug??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 15 de Julio de 2011, 02:06:39
Pues va a tocar buscar optoacopladores muy rápidos, ya tuve problemas con un bus RS485 optoacoplado a 115Kbps.

He encontrado esta nota de aplicación de Analog sobre optoacopladores para CAN:
http://www.analog.com/static/imported-files/application_notes/396914861238030599415561924AN770_0.pdf

y estos optoacopladores de NEC que garantizan el ancho de banda necesario:
http://www.nuhorizons.com/xrefs/CEL/selguides/HiSpeed.pdf

Son muy caros, pero voy a pedir algunos para probar.

Amplío información: he descubierto que hay transceptores CAN que ya garantizan el aislamiento eléctrico:
ISO1050 de TI (http://focus.ti.com/lit/ds/symlink/iso1050.pdf)
ADM3053 de Analog (http://www.analog.com/en/interface/can/adm3053/products/product.html)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 15 de Julio de 2011, 04:10:33
Hay un problema, no le has puesto un Id al receptor, de todos modos deberia haber entrado en la linea
Citar
   if ( can_kbhit() )

Con que haces el debug??

Lo hago con un ICD3.

Me acabo de dar cuenta, el bus can no tiene 60 ohm... :?, solo tengo la terminación en una parte del bus :cry:. Ya hasta el lunes no puedo probarlo, pero en cuanto lo pruebe te comento que tal me ha ido.

Gracias de nuevo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 18 de Julio de 2011, 19:37:24
Hola.

Tengo un sensor que tiene cuatro cables (rojo, negro, blanco, amarillo). Dos de ellos son GND y V (negro y rojo) y los otros dos son CAN-H y CAN-L.

Hemos alimentado a este sensor con 11V, y hemos medido la tensión en los otros dos cables, y se tienen 9.1V en el amarillo y 8.3V en el blanco. El de mayor tensión tendría que ser el CAN-H y el de menor tensión el CAN-L.

¿CAN-H y CAN-L pueden tener tanta tensión? 

Saludos.
Buenas...
Estoy buscando información acerca del bus y la verdad es que estoy enganchado al hilo.
Pese a que soy totalmente neófito en lo que al Bus Can se refiere, quizás has medido la tensión sin carga en las líneas. No te olvídes de que el bus tienen resistencias de terminación y puede que con ellas esa tensión se vea reducida.

Saludos,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 19 de Julio de 2011, 13:14:01
Hay un problema, no le has puesto un Id al receptor, de todos modos deberia haber entrado en la linea
Citar
   if ( can_kbhit() )

Con que haces el debug??

Lo hago con un ICD3.

Me acabo de dar cuenta, el bus can no tiene 60 ohm... :?, solo tengo la terminación en una parte del bus :cry:. Ya hasta el lunes no puedo probarlo, pero en cuanto lo pruebe te comento que tal me ha ido.

Gracias de nuevo.

Bueno, pues aquí estoy de nuevo. Acabo de probarlo con una impedancia correcta en el bus, en modeo debbuger y sigue igual, no me entra en can_kbhit()... Se os ocurre que me puede estar pasando?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Julio de 2011, 09:10:23
Es posible que hayas conectado algo mal, puedes poner el esquema de tu circuito a ver si vemos algo??
Es normal equivocar el pin tx y rx de can en la conexión al MCP2551.
Ahí no anda nada.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 20 de Julio de 2011, 14:22:23
Es posible que hayas conectado algo mal, puedes poner el esquema de tu circuito a ver si vemos algo??
Es normal equivocar el pin tx y rx de can en la conexión al MCP2551.
Ahí no anda nada.

El HW debe de estar bien, estoy utilizando dos placas que hemos tenido en obra, es decir, que han estado funcionando, yo solamente he realizado el ramal para unir los 2 can. De todas formas mañana cojo esquemas y enseño como está. Otra cosa, yo no utilizo el MCP2551, uso el TJA1050, pero da igual, no? Por último, no se si tiene que ver, pero los mensajes de la placa emisora son extendidos y con "protocolo propio", eso influiría en algo?

Gracias,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Julio de 2011, 15:06:23
Eso no debiera influir, siempre y cuando el protocolo propietario ya estuviese en funcionamiento desde antes de realizar estas pruebas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 21 de Julio de 2011, 08:50:01
Si si, en funcionamiento está, eso es seguro, lo he comprobado. Es más, podría coger el código de la empresa y hacerlo con ello, pero no es CCS, y me gustaría hacerlo en CCS. Seguiré probando a ver si doy con la causa. Si se os ocurre algo por favor, decidmelo!!!

Gracias!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Julio de 2011, 09:37:55
Si es otro lenguaje C, para que molestarse en cambiarlo??
Si es assembler, difícilmente puedas mejorarlo en C.
Si tuviera que portarlo a C, lo haría a un C que cumpla la norma ANSI C, como el C18 de Mchip.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 21 de Julio de 2011, 21:21:31
Ya terminé mi proyecto, al final he conseguido comunicarme con el bus CAN del coche. El PIC lee los datos de OBD y muestra los PIDS seleccionados por la pantalla LCD.

Tiene 2 modos de funcionamiento, uno conectado al ordenador por puerto serie, y se le envían comandos para transmitir al vehículo y configurar las opciones. El otro modo, es automático cuando no se le envia nada por el puerto serie, comienza a hacer peticiones de los datos del OBD, según el protocolo ISO 15765 (OBD sobre CAN).

Muy buenas a todos,
Mi mas sincera enhora buena por tu placa Teleko....

En cuanto al bus can, mi intención es usar una placa de INGENIA que hace tiempo que tengo (ICM4011) y conectarla al ordenador por puerto USB, usando un hipertérminal, pero no se como se identifican los diferentes dispositivos e informaciones, se como es el bus can, pero no los valores de ID y los rangos de datos.
¿Está eso especificado en la norma ISO 15765 (OBD sobre CAN)? lo que a mi me interesa, mas que el OBD, que no se si está filtrado, es pinchar directamente sobre el bus CAN de datos y estar plenamente interconectado. De esta forma, si quieres comprobar algún componente por separado, puedes conectarte directamente a el.

Saludos y nuevamente enhora buena por el tema, mientras mas leo mas me engancho...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 26 de Julio de 2011, 13:02:34
Aquí está la normativa de comunicación con las centralitas del coche:

sae OBD (http://www.4shared.com/file/74089156/77de9073/SAE_OBDII_j1979_200204.html)

Y aquí se explica el funcionamiento del ELM, más o menos lo que yo quiero hacer, se entiende bastante bien cómo es el proceso de comunicación, enviando comandos y recibiendo las respuestas (pag 20):

(http://dc107.4shared.com/img/74089537/518aafbf/ELM327DS.pdf) (http://www.4shared.com/file/74089537/518aafbf/ELM327DS.html)


Hola Teleko,

He intentado bajar esta información que decías del link, pero me indica que ya no está disponible.

Estoy muy interesado en ella, ya que quiero gobernar una dirección asistida a través del bus y necesito el identificador y los valores de los códigos de velocidad para controlar su dureza.

Te agradecería me indicaras como conseguirlos o me los enviaras al correo.

muchas gracias de antemano por tu ayuda.

Ya he visto que al final has conseguido tu proyecto. Enhora buena.

Saludos, handpic.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 28 de Julio de 2011, 14:08:29
Si es otro lenguaje C, para que molestarse en cambiarlo??
Si es assembler, difícilmente puedas mejorarlo en C.
Si tuviera que portarlo a C, lo haría a un C que cumpla la norma ANSI C, como el C18 de Mchip.

Hola de nuevo, a ratos que puedo sigo intentando hacer correr el programa. He estado leyendo por ahí que hay que insertar por lo menos un mensaje en el bus para "despertar" mi TJA1050, por eso he añadido dos líneas nuevas, un "can_putd" y un "delay" justo debajo de can_init(). Pero me pasa una cosa curiosa y es que en el hyperterminal me sale lo siguiente:

CCS CAN EXAMPLE                                                                                    
                                                                                                    
CAN_PUTD(): BUFF=0 ID=00000100 LEN=1 PRI=1 EXT=1 RTR=0                                              
  DATA = 00    

Es decir, esa información me la manda por la UART y dudo si la envía por el CAN o no  :shock:. La otra placa sigue enviando mensajes, pero nada, nunca entra al can_kbhit().

El código en sí es el siguiente:

Código: [Seleccionar]
void main()
{
struct rx_stat rxstat;
int32 rx_id;
int buffer[8];
int rx_len;
  int i;

for(i=0;i<8;i++)
{
buffer[i]=0;
}

printf("\r\n\r\nCCS CAN EXAMPLE\r\n");


can_init();
can_putd(0x100, 0, 1, 1, TRUE, FALSE);
delay_ms(500);

enable_interrupts(GLOBAL);


while(TRUE)
{
if ( can_kbhit() )
{
printf("\n\rEntro al kbhit\n\r");
printf("\r\n");
if(can_getd(rx_id, &buffer[0], rx_len, rxstat))
{
printf("Byte 0: %X\r\n",buffer[0]);

}
}
delay_ms(500);
}

}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Julio de 2011, 16:15:45
Si en el código deshabilitas Debug_printf la librería deja de enviar por el puerto cada vez que transmite o recibe, lo que pasa es que nadie le contesta nada, por lo tanto es imposible saber si esta o no transmitiendo. Yo lo dejaría así, porque si en algún momento recibes algo, al menos entiendes que paso o que salio mal o si salio bien, entenderás las tramas del CANBUS.

Si miras en la placa que yo puse en los primeros puntos de este hilo, veras que le puse leds a las lineas de transmicion y recepción de cada nodo, precisamente para enterarme que pasa cuando tengo problemas de transmision o recepción.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 28 de Julio de 2011, 17:17:23
Ok, me haré una plaquita con LEDs para observar el TX y RX del CAN. Ya os contaré.

Gracias!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 28 de Julio de 2011, 18:14:18
Muy buenas.... MGLSOFT

Tengo una placa de INGENIA ICM4011, con un dsPic. En su página web ya hay un proyecto de ejemplo para conectarse al bus can y el manual en pdf, aunque no está el código abierto, si está el archivo .hex para cargarlo.

Lo he probado en casa conectando la dirección asistida de un nissan micra y el bus parece ir a 500kbs, porque a otras velocidades me da error.

Si desconecto la dirección también me da error, por lo que parece que es correcta la velocidad de transmisión, aunque realmente no he recibido nada, lógico, puesto que yo no conozco ningún id para preguntarle a la direccion, pero el formato de la información parece correcta.

como el módulo, que convierte CAN-RS232(USB), parece funcionar, quiero conectarselo al coche y ver que puedo extraer. El modo de escuchar es muy sencillo, puesto que lo hace con un hipertérminal.

Tiene alguien la información que posteó Teleko en su momento, con la norma OBD donde vienen los Id y los rangos? Los he intentado bajar de los enlaces, pero ya no estan habilitados.

Cuando logre controlar la dirección, el siguiente paso será acondicionar la señal de un hall para conocer la velocidad y que actúe de forma automática, si se desea, o manual con varias selecciones de asistencia.

En cuanto tenga mas datos os cuento como va el asunto....

Saludos,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Julio de 2011, 19:15:22
Linda placa...
Cuentanos tus experiencias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 28 de Julio de 2011, 21:51:47
ya estoy aquí de nuevo...

He intentado conectarme al bus Can del coche, directamente, sin OBD, ya que creo que hay una interface a otra ISO (según veo en el conector y la información que he encontrado)...

Me he ido a la centralita y he localizado el par trenzado que parece llevar el bus. Lo he medido con el polímetro y tenía 2,45V, lo que me ha hecho tener esperanzas de que fuera el bus realmente.

Me he conectado con la placa y el software, pero nada de nada.... se supone que tenía que ver las tramas del tráfico, pero no he visto nada.

Es posible que tenga la máscara o los ID bloqueados, pero eso ya lo repasaré en otro momento.....

Saludos a todos..... tanto a los que demuestran ser una estrella..... como a los que nos estrellamos....
Título: Re: Mis experiencias con el BUS CAN
Publicado por: herr_emanuelb en 18 de Agosto de 2011, 11:01:47
Estoy desarollando un aparello para leer Datos para Camiones que tengan el bus CAN J1939.
El dispositivo está compuesto por un PIC18F2580, un Transceiver MCP2551 y un display LCD.

Alguién sabe me decir si es necesário definir un ID en mi aparello apenas para leer los datos?
Y cual es la resistencia más adecuada entre CANH e CANL del MCP2551 para esta aplicación?

En un primero momento, pienso en 120Ohms, pero he visto en algunos otros proyectos personas que utilizaban 60 Ohms.

Gracias,
Emanuel
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Agosto de 2011, 11:34:22
El aparato en este caso sera un Master, entiendo que no es necesario un ID.
La resistencia terminadora es de 120 Ohm.
Hay aplicaciones donde ponen una de 60 Ohm entre CANH y masa y otra de 60 Ohm entre CANL y masa, finalmente quedan 120 OHM entre CANH y CANL, esto hace que tengan bien definidos los niveles respecto a masa.

Comentanos mas respecto a tu desarrollo....
Título: Re: Mis experiencias con el BUS CAN
Publicado por: herr_emanuelb en 19 de Agosto de 2011, 10:15:20
MGLSOFT, gracias por su pronta respuesta.

Ayer yo puse el aparato para testar en un camión Volvo Fh440. En los primeros momentos nada apareció nel display.
Yo estaba intentando leer los datos del Cuentakilómetros y del tacómetro.

Entonces, yo hice algunas modificaciones en mi software, solo para leer que tipo de ID estaban llegando. Aun no llegaba nada.
El aparato solo empezó a recibir algo a partir del momento en que he cambiado el modo de operación del PIC para "LISTEN".

De todos modos aun no logré recibir los datos que deseaba. Los IDs del cuentakilómetros y del tacómetro deberian ser 0x00FEC1 y
0x00EEC1, pero otra vez cambiando a mi software me fué posible leer los IDs 0xE3C000, 0xE38000, 0xE38787, 0xE3C787, 0xE38000, 0xE3C7C0, 0xE387C0, 0xE38780, 0xE3C780, 0x00, 0x78.

Llego a la conclusión de que para operar nel modo normal en un camión, quizás yo tenga que definir un ID valido.
En segundo, si los IDs que yo tenia para cuentakilómetros y tacómetro son correctos  tal vez yo tenga que hacer uso de filtros para que el PIC no fique solo en  la recepción de datos inválidos.

Correcto?

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Agosto de 2011, 10:35:28
El filtrado aun no lo habilitaria, hasta no obtener datos en cada ID que sean correctos y estes seguro que lo que recibes corresponde al dato que necesitas.
Una vez obtengas esto si puedes filtrar y hacer sets de filtrado, que iras cambiando acorde a los valores que necesites medi.

Interesante lo del modo Listen, siempre me pregunte que utilidad tendria, je..je.. :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: herr_emanuelb en 19 de Agosto de 2011, 11:00:26
Entendi, pero también es posible que yo no los tenga recibido porque el PIC estaba demasiado ocupado recibiendo y tratando de IDs invalidos mientras los IDs validos pasaban sin tener la oportunidad de seren leídos.

De todos modos voy intentar procurar por algún representante de la Volvo y lo preguntaré si los datos de los camiones actuales realmente están de acuerdo con el FMS Standard.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Agosto de 2011, 11:12:04
Gracias por el aporte!!
Lo extraño es que en varios mensajes no se usan los primeros bytes del mensaje!!
Deben tener alguna razón...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: herr_emanuelb en 23 de Agosto de 2011, 11:59:09
He llegado a conclusión de que mi software no estaba preparado para recibir datos nel formato j1939. Ahora estoy intentando hacer un nuevo software basado en las librerías "j1939.c" y "j1939.h", descritas por el Application Note 930 de Microchip.
Pero yo no sé por que razón aun no logré hacer nada, ni siquiera el exemplo 1 del Application Note.

Alguién ya ha trabajado con estas librerías?
(Estoy usando el Compiler PCW)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Agosto de 2011, 14:30:58
Puedes poner el código de tu programa ??
Según leí el código de Mchp de esa librería en apariencia no funciona bien.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: herr_emanuelb en 23 de Agosto de 2011, 15:04:39
A mí tambien no me pareció funcionar bien.


Voy a poner el código del primero Chip. Su objetivo es enviar una mensaje para otro pic apagar o encender un LED y tambíen encender o apagar su led de acuerdo con las mensajes recibidas.


Código: [Seleccionar]
/*
Example 1

This example shows a very simple J1939 implementation.  It uses polling
to check for a message to light an LED and to send a message if a
button is pressed.

Both Node 0 and Node 1 should be programmed with the same code, except
that OTHER_NODE should be defined as the other node’s J1939 Address.

Application Maestro should be run with the following options changed
from their default values (in addition to NAME, Address, and bit rate
values):

Interrupts or Polling - Polling
*/

#include <18f2580.h>
#include "j1939.h"

J1939_MESSAGE Msg;

// Define some arbitrary values.  They must agree with the other node's
// values.

#define OTHER_NODE      129
#define TURN_ON_LED      92   
#define TURN_OFF_LED   94   

void main( void )
{
   unsigned char   LastSwitch = 1;
   unsigned char   CurrentSwitch;

   TRISBbits.TRISB4 = 1;         // Switch pin
   TRISD = 0;                     // LED pins
   LATD = 0;                     // Turn off LED

   J1939_Initialization( TRUE );

   // Wait for address contention to time out
   while (J1939_Flags.WaitingForAddressClaimContention)
      J1939_Poll(5);

   // Now we know our address should be good, so start checking for
   // messages and switches.

   while (1)
   {
      CurrentSwitch = PORTBbits.RB4;
      if (LastSwitch != CurrentSwitch)
      {
         Msg.DataPage            = 0;
         Msg.Priority            = J1939_CONTROL_PRIORITY;
         Msg.DestinationAddress   = OTHER_NODE;
         Msg.DataLength            = 0;
         if (CurrentSwitch == 0)
            Msg.PDUFormat = TURN_ON_LED;
         else
            Msg.PDUFormat = TURN_OFF_LED;
          while (J1939_EnqueueMessage( &Msg ) != RC_SUCCESS)
            J1939_Poll(5);
         LastSwitch = CurrentSwitch;
      }

      while (RXQueueCount > 0)
      {
         J1939_DequeueMessage( &Msg );
         if (Msg.PDUFormat == TURN_ON_LED)
            LATDbits.LATD0 = 1;
         else if (Msg.PDUFormat == TURN_OFF_LED)
            LATDbits.LATD0 = 0;
      }

      // Since we don’t accept the Commanded Address message,
      // the value passed here doesn’t matter.
      J1939_Poll(20);
   }
}



Para el segundo chip el software si mantiene el mismo, cambiando solo el valor de "OTHER_NODE" o cual es definido para 128.
Las librerias estoy ponendo en attachment.

El arquivo j1939.def del segundo chip tiene el valor J1939_STARTING_ADDRESS cambiado para 129 .
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Agosto de 2011, 16:29:41
Este código lo has probado usando otra placa en el bus??
Si lo has probado, Funciona ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: herr_emanuelb en 23 de Agosto de 2011, 17:37:56
Este código lo has probado usando otra placa en el bus??
Si lo has probado, Funciona ??

Sí, pero este es el codigo original de Microchip. Para poder compilar y grabar en mis PICs yo tuve que cambiar algunas cosas, como por ejemplo las puertas de los LEDS, y la creación de una librería para los registros del CAN Bus.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Agosto de 2011, 18:31:01
Puedes compartirla??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: herr_emanuelb en 24 de Agosto de 2011, 09:56:06
Claro!

Aqui está:

Código: [Seleccionar]
/*********************************************************************/
/*********************************************************************/
/*
Example 1
This example shows a very simple J1939 implementation. It uses polling
to check for a message to light an LED and to send a message if a
button is pressed.
Both Node 0 and Node 1   should be programmed with the same code, except
that OTHER_NODE should be defined as the other node’s J1939 Address.
Application Maestro should be run with the following options changed
from their default values (in addition to NAME, Address, and bit rate
values):
Interrupts or Polling – Polling
*/

#include <18F2580.h>
#fuses HS,NOPROTECT,NOLVP,NOWDT,NOMCLR
#include "regs_2580.h"
#use delay(clock=20000000)
#include <display.h>
#include "j1939_128.def"  //esta el archivo donde el valor J1939_STARTING_ADDRESS está definido como 128
#include "j1939.c"
#include "j1939.h"


J1939_MESSAGE Msg;
// Define some arbitrary values. They must agree with the other node's
// values.
#define OTHER_NODE 129
#define TURN_ON_LED  92
#define TURN_OFF_LED 94
void main( void )
{
int1 LastSwitch = 1;
int1 CurrentSwitch;
 // Switch pin
TRISA = 0; // LED pins
PORTA = 0; // Turn off LED


J1939_Initialization( TRUE );
TRISB = TRISB | 0b00010000;

// Wait for address contention to time out
while (J1939_Flags.WaitingForAddressClaimContention)
J1939_Poll(5);

// Now we know our address should be good, so start checking for
// messages and switches.
while (TRUE)
{
    CurrentSwitch = RB4;
   if (LastSwitch != CurrentSwitch)
   {
   Msg.DataPage = 0;
   Msg.Priority = J1939_CONTROL_PRIORITY;
   Msg.DestinationAddress = OTHER_NODE;
   Msg.DataLength = 0;
   
      if (CurrentSwitch == 0){
      Msg.PDUFormat = TURN_ON_LED;
      RA0=0;
      }
      else{
      Msg.PDUFormat = TURN_OFF_LED;
      RA0=1;
      }
   while (J1939_EnqueueMessage( &Msg ) != RC_SUCCESS){
                                                      delay_ms(200); RA0=~RA0; delay_ms(200);    //esto he adicionado para verificar donde el software estaba parando.
                                                      }
   J1939_Poll(5);
   LastSwitch = CurrentSwitch;
 
   }
   while (RXQueueCount > 0)
   {
   J1939_DequeueMessage( &Msg );
      if (Msg.PDUFormat == TURN_ON_LED)
      RA0 = 1;
      else if (Msg.PDUFormat == TURN_OFF_LED)
      RA0 = 0;
   }
// Since we don’t accept the Commanded Address message,
// the value passed here doesn’t matter.
}
}

La librería "regs_2580" fué hecha por mí, este es su código:
Código: [Seleccionar]
#BYTE TRISA    = 0xF92
#BYTE TRISB    = 0xF93
#BYTE TRISC    = 0xF94

#BYTE PORTA    = 0xF80
   #BIT RA0    = PORTA.0
   #BIT RA1    = PORTA.1
   #BIT RA2    = PORTA.2
   #BIT RA3    = PORTA.3
   #BIT RA4    = PORTA.4
   #BIT RA5    = PORTA.5
   #BIT RA6    = PORTA.6
   #BIT RA7    = PORTA.7

#BYTE PORTB    = 0xF81
   #BIT RB0    = PORTB.0
   #BIT RB1    = PORTB.1
   #BIT RB2    = PORTB.2
   #BIT RB3    = PORTB.3
   #BIT RB4    = PORTB.4
   #BIT RB5    = PORTB.5
   #BIT RB6    = PORTB.6
   #BIT RB7    = PORTB.7

#BYTE PORTC    = 0xF82
   #BIT RC0    = PORTC.0
   #BIT RC1    = PORTC.1
   #BIT RC2    = PORTC.2
   #BIT RC3    = PORTC.3
   #BIT RC4    = PORTC.4
   #BIT RC5    = PORTC.5
   #BIT RC6    = PORTC.6
   #BIT RC7    = PORTC.7


#BYTE LATA    = 0xF89
   #BIT LA0    = LATA.0
   #BIT LA1    = LATA.1
   #BIT LA2    = LATA.2
   #BIT LA3    = LATA.3
   #BIT LA4    = LATA.4
   #BIT LA5    = LATA.5
   #BIT LA6    = LATA.6
   #BIT LA7    = LATA.7

#BYTE LATB    = 0xF8A
   #BIT LB0    = LATB.0
   #BIT LB1    = LATB.1
   #BIT LB2    = LATB.2
   #BIT LB3    = LATB.3
   #BIT LB4    = LATB.4
   #BIT LB5    = LATB.5
   #BIT LB6    = LATB.6
   #BIT LB7    = LATB.7

#BYTE LATC    = 0xF8B
   #BIT LC0     = LATC.0
   #BIT LC1     = LATC.1
   #BIT LC2     = LATC.2
   #BIT LC3     = LATC.3
   #BIT LC4     = LATC.4
   #BIT LC5     = LATC.5
   #BIT LC6     = LATC.6
   #BIT LC7     = LATC.7


struct{
   int1 RBPU;
   int1 INTEDG0;
   int1 ITEDG2;
   int1 VOIDINTC2;
   int1 TMR0IP;
   int1 VOIDINTC2B;
   int1 RBIP;
} INTCON2;
#BYTE INTCON2 = 0xFF1

#BYTE INTCON = 0xFF2
   #BIT RBIF      = INTCON.0
   #BIT INT0IF    = INTCON.1
   #BIT TMR0IF    = INTCON.2
   #BIT RBIE      = INTCON.3
   #BIT INT0IE    = INTCON.4
   #BIT TMR0IE    = INTCON.5
   #BIT PEIE      = INTCON.6
   #BIT GIE       = INTCON.7


#ifdef ECAN_IS_CAN_MODULE
struct {
   int1 FILHIT0;
   int1 JTOFF;
   int1 RXBODBEN;
   int1 RXRTRRO;
   int1 voidrxb0con;
   int1 RXM0;
   int1 RXM1;
   int1 RXFUL;   
} RXB0CONbits;
#else
struct {
   int1 FILHIT0;
   int1 FILHIT1;
   int1 FILHIT2;
   int1 FILHIT3;
   int1 FILHIT4;
   int1 RTRRO;
   int1 RXM1;
   int1 RXFUL;   
} RXB0CONbits;
#endif

#byte RXB0CONbits = 0xF60
#byte RXB0CON = 0xF60


struct{
      int1 IRXIE;
      int1 WAKIE;
      int1 ERRIE;
      int1 TXBnIE;
      int1 TXB1IE;
      int1 TXB0IE;
      int1 RXB1IE;
      int1 RXB0IE;
      } PIE3bits;

#byte CANSTAT = 0xF6E
#byte CANCON = 0xF6F
#byte RXF3EIDH = 0xF0E
#byte RXB0SIDH = 0xF61
#byte ECANCON = 0xF77
#byte PIE3bits = 0xFA3
#byte PIE3 = 0xFA3
#byte BSEL0 = 0xDF8
#byte RXM0SIDH = 0xF18
#byte RXM0SIDL = 0xF19
#byte RXM0EIDH = 0xF1A
#byte RXM0EIDL = 0xF1B
#byte RXM1SIDH = 0xF1C
#byte RXM1SIDL = 0xF1D
#byte RXM1EIDH = 0xF1E
#byte RXM1EIDL = 0xF1F
#byte RXF0SIDH = 0xF00
#byte RXF0SIDL = 0xF01
#byte RXF0EIDH = 0xF02
#byte RXF0EIDL = 0xF03
#byte RXF1SIDH = 0xF04
#byte RXF1SIDL = 0xF05
#byte RXF1EIDH = 0xF06
#byte RXF1EIDL = 0xF07
#byte RXF2SIDH = 0xF08
#byte RXF2SIDL = 0xF09
#byte RXF2EIDH = 0xF0A
#byte RXF2EIDL = 0xF0B
#byte RXF3SIDH = 0xF0C
#byte RXF3SIDL = 0xF0D
#byte RXF3EIDH = 0xF0E
#byte RXF3EIDL = 0xF0F
#byte MSEL0 = 0xDF0

#byte RXFBCON0 = 0xDE0
#byte RXFBCON1 = 0xDE1
#byte RXFBCON2 = 0xDE2
#byte RXFCON0 = 0xDD4
#byte RXFCON1 = 0xDD5

#byte BRGCON1 = 0xF70
#byte BRGCON2 = 0xF71
#byte BRGCON3 = 0xF72

#byte COMSTAT = 0xF74

Aun yo hice una modificación en la función void J1939_Poll
Código: [Seleccionar]
void J1939_Poll( unsigned long ElapsedTime )
{
   unsigned int   Temp;

   // Update the Contention Wait Time.  We have to do that before
   // we call J1939_ReceiveMessages in case the time gets reset back
   // to zero in that routine.

   ContentionWaitTime += ElapsedTime;

   #if J1939_POLL_ECAN == J1939_TRUE
      J1939_ReceiveMessages();
      J1939_TransmitMessages();
   #endif

   if (J1939_Flags.WaitingForAddressClaimContention &&
      (ContentionWaitTime >= 25000l)) //el valor original era de 250000l, lo cambié porque el compiler dijo que la variável ContentionWaitTime jamás tenería este valor
   {
      J1939_Flags.CannotClaimAddress = 0;
      J1939_Flags.WaitingForAddressClaimContention = 0;
      J1939_Address = CommandedAddress;

      // Set up filter to receive messages sent to this address.
      // If we're using interrupts, make sure that interrupts are disabled
      // around this section, since it will mess up what we're doing.
      #if J1939_POLL_ECAN == J1939_FALSE
         #if (J1939_PRIORITIZED_INT == J1939_FALSE) || (ECAN_RX_INTERRUPT_PRIORITY == 0x00) || (ECAN_TX_INTERRUPT_PRIORITY == 0x00)
            INTCONbits.GIEL = 0;
         #endif
         #if (ECAN_RX_INTERRUPT_PRIORITY != 0x00) || (ECAN_TX_INTERRUPT_PRIORITY != 0x00)
            INTCONbits.GIEH = 0;
         #endif
      #endif
      SetAddressFilter( J1939_Address );
      #if J1939_POLL_ECAN == J1939_FALSE
         #if (J1939_PRIORITIZED_INT == J1939_FALSE) || (ECAN_RX_INTERRUPT_PRIORITY == 0x00) || (ECAN_TX_INTERRUPT_PRIORITY == 0x00)
            INTCONbits.GIEL = 1;
         #endif
         #if (ECAN_RX_INTERRUPT_PRIORITY != 0x00) || (ECAN_TX_INTERRUPT_PRIORITY != 0x00)
            INTCONbits.GIEH = 1;
         #endif
      #endif
   }
}
En esta última función, cual es el significado del carácter "l" (ContentionWaitTime >= 25000l), en la línea que yo he cambiado?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Agosto de 2011, 11:04:19
Bueno, por donde empezar.... :( :(

Deberás saber que CCS no es ANSI C, por lo tanto es muy diferente a C18 y hay que tener en cuenta muchas cosas al intentar una "traducción" de código a CCS desde un ejemplo de C18.

Intentare ir por lo que creo es el primer error:

Si miras el código de la librería del PIC, veras esto:

Código: C
  1. //////// Standard Header file for the PIC18F2580 device ////////////////
  2. #device PIC18F2580
  3. #nolist
  4. //////// Program memory: 16384x16  Data RAM: 1536  Stack: 31
  5. //////// I/O: 24   Analog Pins: 11
  6. //////// Data EEPROM: 256
  7. //////// C Scratch area: 00   ID Location: 200000
  8. //////// Fuses: LP,XT,HS,RC,EC,EC_IO,H4,RC_IO,INTRC_IO,INTRC,NOFCMEN,FCMEN
  9. //////// Fuses: NOIESO,IESO,PUT,NOPUT,NOBROWNOUT,BROWNOUT_SW,BROWNOUT_NOSL
  10. //////// Fuses: BROWNOUT,BORV46,BORV43,BORV28,BORV21,NOWDT,WDT,WDT1,WDT2
  11. //////// Fuses: WDT4,WDT8,WDT16,WDT32,WDT64,WDT128,WDT256,WDT512,WDT1024
  12. //////// Fuses: WDT2048,WDT4096,WDT8192,WDT16384,WDT32768,NOPBADEN,PBADEN
  13. //////// Fuses: NOLPT1OSC,LPT1OSC,NOMCLR,MCLR,NOSTVREN,STVREN,NOLVP,LVP
  14. //////// Fuses: BBSIZ1K,BBSIZ2K,NOXINST,XINST,DEBUG,NODEBUG,PROTECT
  15. //////// Fuses: NOPROTECT,CPB,NOCPB,CPD,NOCPD,WRT,NOWRT,WRTC,NOWRTC,WRTB
  16. //////// Fuses: NOWRTB,WRTD,NOWRTD,EBTR,NOEBTR,EBTRB,NOEBTRB
  17. ////////
  18. ////////////////////////////////////////////////////////////////// I/O
  19. // Discrete I/O Functions: SET_TRIS_x(), OUTPUT_x(), INPUT_x(),
  20. //                         PORT_x_PULLUPS(), INPUT(),
  21. //                         OUTPUT_LOW(), OUTPUT_HIGH(),
  22. //                         OUTPUT_FLOAT(), OUTPUT_BIT()
  23. // Constants used to identify pins in the above are:
  24.  
  25. #define PIN_A0  31744
  26. #define PIN_A1  31745
  27. #define PIN_A2  31746
  28. #define PIN_A3  31747
  29. #define PIN_A4  31748
  30. #define PIN_A5  31749
  31. #define PIN_A6  31750
  32. #define PIN_A7  31751
  33.  
  34. #define PIN_B0  31752
  35. #define PIN_B1  31753
  36. #define PIN_B2  31754
  37. #define PIN_B3  31755
  38. #define PIN_B4  31756
  39. #define PIN_B5  31757
  40. #define PIN_B6  31758
  41. #define PIN_B7  31759
  42.  
  43. #define PIN_C0  31760
  44. #define PIN_C1  31761
  45. #define PIN_C2  31762
  46. #define PIN_C3  31763
  47. #define PIN_C4  31764
  48. #define PIN_C5  31765
  49. #define PIN_C6  31766
  50. #define PIN_C7  31767

Donde ya se definen los pines de los puertos, por lo tanto si vuelves a definirlos cometes un error.
El compilador tomara solo una de estas definiciones, yo usaría la nativa de CCS y luego "traduciría " cada una de las partes donde esos pines sean utilizados.


Si has usado las librerías de C18 tal como vienen, veras que carga las definiciones del PIC utilizado en cada una de ellas, por lo tanto volverás a equivocar al compilador.

Ejemplo:

Código: C
  1. * Company:         Microchip Technology, Inc.
  2.  *
  3.  *
  4.  * Constants that are used by the J1939 C Library.
  5.  *
  6.  * Version     Date        Description
  7.  * ----------------------------------------------------------------------
  8.  * v01.00.00   2004/06/04  Initial Release
  9.  *
  10.  * Copyright 2004 Kimberly Otten Software Consulting
  11.  *
  12.  * Author               Date        Comment
  13.  *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  14.  * Kim Otten            6/04/04     Original
  15.  * Caio Gubel           6/11/04     Formatted
  16.  ********************************************************************/
  17.  
  18. #include        <p18cxxx.h>          //   >>>>>>>>>>>>>>  nueva definicion !!!!
  19. #include        "j1939.def"
  20.  
  21. #ifndef __J1939_H
  22. #define __J1939_H
  23.  
  24.  
  25. typedef enum _BOOL { FALSE = 0, TRUE } BOOL;
  26.  
  27.  
  28. // Function Return Codes
  29.  
  30. #define RC_SUCCESS                      0
  31. #define RC_QUEUEEMPTY                   1
  32. #define RC_QUEUEFULL                    1
  33. #define RC_CANNOTRECEIVE                2
  34. #define RC_CANNOTTRANSMIT               2



El otro error es que definas los registros tris
Citar
TRISB = TRISB | 0b00010000;

Cuando no declaras en que modo vas a utilizar los puertos, CCS ofrece tres modos, solo uno de ellos (modo fast) obliga a modificar los registros tris y latc de los puertos, pero deberás hacerlo en cada llamada a un pin que utilices...


Hay mas errores pero en su mayoría son por estas cuestiones de interpretación de como usar ese código en CCS.

Consejo:
Compila los ejemplos en C18 y MPLAB y asegurate que funcionan primero.
Luego comienza la traduccion, lentamente y observando a cada paso que esta bien o mal y que aplica CCS en cada caso.

Respecto al valor 250000l   (es una L minúscula y no un 1) creo que indica un valor Long de 250000, y se refiere a ticks, que es la unidad de temporizacion del compilador C18.
Ya habrá algún especialista de C18 del Foro que nos aclare mejor este tema, si alguno lee este hilo...


Título: Re: Mis experiencias con el BUS CAN
Publicado por: herr_emanuelb en 24 de Agosto de 2011, 11:32:17
MGLSOFT

Muchas gracias por su explicación. Voy a seguir tus consejos y intentar compilar estes ejemplos primero en MPLAB.
Mientras tanto, a respecto del FMS standard leí en algunos documentos que los IDs correctos son acrescidos de dos ceros (en hexadecimal) a su derecha.

Por ejemplo, el ID que identifica el cuentakilómetros 0x00FEC1 en verdad es 0x00FEC100, o que explica mis extrañas lecturas nel camión.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 31 de Agosto de 2011, 11:20:12
Buenas a todos....

Como os comentaba, había intentado conectarme a un bus can con la tarjeta de ingenia. Al final lo he conseguido, pero directamente a la dirección que quería controlar y no en el coche, que parece no ser un bus can, sino otra norma ISO (peugeot 307)

He podido leer los siguientes datos que recibía de la dirección, aunque no se lo que significan:

0xC2 N 6 0x10 73FF7FFFFF

0xC2 N 6 0xF7 4FF7FFFFF

0xC2 N 6 0xE7 5FF7FFFFF

0x300 N 1 0x0

0xC2 N 6 0xD7 6FF7FFFFF

0xC2 N 6 0xC7 7FF7FFFFF

0x5E4 N 3 0xC0 1E00

algunos estan incompletos, porque el bus de datos (rs232/115000) se satura, pero las cabeceras  y el número de bytes de datos parece ser correcta, aunque no se lo que significan. si alguien quiere el archivo de datos leido completo os lo puedo pasar o subirlo (si me explicais como hacerlo).

Si he comprobado que 0xC2 parece indicar los grados y la velocidad de giro de la dirección o algo así, porque varía cuando la giro.
En un Bus CAN, los diferentes dispositivos han de inicializarse e identificarse??
¿alguien sabe como indicarle la velocidad a la dirección?
¿Me podéis aclarar como funciona la máscara y el filtro en CAN?(para torpes)

Saludos,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2011, 11:36:47
Las mascaras te permiten recibir mensajes solamente de los ID que logran pasar el filtro que has realizado.
Es decir si quieres recibir mensajes con el id 0xC2, haces un filtro con esa mascara exacta y ya no recibirás ningún otro mensaje.
Lo que no se es si debes usar o no la mascara en forma de complemento, pero haz la prueba que no rompes nada. :mrgreen: :mrgreen:

Se usan en protocolos de mayor nivel para recibir en los esclavos solamente la mensajería que les compete, de ese modo con un cpu mas chico y atendiendo los mensajes compatibles con su función, el modulo trabaja mejor.

En los sniffer como predeterminado no se usan mascaras, porque la idea es que escuches todo lo que va y viene, pero si es tan rápido que no puedes recibir todo, entonces programas las mascaras para filtrar por tipos de mensajes, que normalmente tienen que ver con el rango de IDs que se asigna según el protocolo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: herr_emanuelb en 31 de Agosto de 2011, 11:38:42
Handpic

Creo que sí, puede ser un bus CAN. Es que la especificación de CAN, define solo las capas (layers) más bajas del modelo de referencia OSI, que es constituido por 7 capas.

Las capas más superiores son definidas de acuerdo con la aplicación. Por ejemplo, yo estoy intentando leer datos de autobuses y camiones. He descubierto que las capas más superiores de la referencia OSI para autobuses y camiones son definidas por la norma SAE J1939, y los datos de algunos modelos dentro del J1939 siguen un standard llamado FMS Standard.
Procura informarte a respecto de que normas definen las capas más superiores para los autos de Peugeot, para poder interpretar los datos.

Para los filtros, creo que este trend, nel forum de Microchip te puede aclarar (en inglés).
http://www.microchip.com/forums/tm.aspx?m=456043&settheme=Mobile

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2011, 11:51:46
Pongo la traduccion hecha por Google del post sugerido por herr_emanuelb  (muy buen aporte), tal como lo sugiere el traductor de Google:

Citar
Le sugiero que lea las siguientes observaciones al aire libre CAN2.0A / B spec en frente de usted, y una copia de la CAN dsPIC documento de referencia (de Microchip).

Dato importante 1: No creo que una identificación de la CAN es un "número". Se trata de un conjunto de bits que se utilizan para dar prioridad a un mensaje de CAN en un bus CAN.
Dato importante 2: No creo que una máscara de Rx es un "número", esto es sólo un conjunto de bits que activar o desactivar bits coincidentes en el filtro de Rx,
Hecho 3 Importante: No creo que un filtro de Rx es un "número", esto también es sólo un conjunto de bits que el motor pueda utilizará durante el proceso de recepción de mensajes.

(Ahora sería un buen momento para volver a leer los documentos CAN 2.0A / B y Microchip de Filtros y máscaras)

Para responder a tu pregunta (yo estoy usando ID ETS tratar de mantener las cosas simples) ...


    tengo la confusión en la máscara de ajuste y filtro de Identificación values.My mensaje por 7 nodos 1,2,3 ... 7

En primer lugar aplicar lo que ahora entendemos por CAN ID (ID recordar son sólo un conjunto de bits).
Tome su primera CAN mensaje de ID (1). En realidad, esta identificación se llega a enviar en el bus CAN como una serie de bits "00000000001", la CAN ID de mensaje (2) sea enviado como "00000000010".
Ok, por un nodo CAN para recibir correctamente los mensajes, el mensaje tiene que "pasar" de la CAN nodo Rx filtro.

Ejemplo 1:
Cómo establecer un nodo CAN Rx máscara y filtro para recibir sólo ID CAN 1 y CAN no ID 2?
Recuerde, pensar en la identidad como un poco a presentar (que lo es), y convertir el ID en binario (que hace las cosas fáciles si lo hace).
ID: 1 = 00000000001
ID: 2 = 00000000010

Ok, ahora (a partir de su lectura de la especificación CAN2.0A / B) se sabe que la máscara es como un interruptor para activar / desactivar el filtro de bits de Rx. Ya que es el filtro que hace el trabajo, lo primero que debe hacer es establecer el ámbito del filtro. Así que para su nodo puede recibir sólo CAN ID 1, usted quiere que su filtro para que coincida con este requisito.
FilterA = 00000000001

Ahora ponga la máscara para permitir que los bits del filtro que desea comprobar el ID de la CAN en contra. En nuestro caso, vamos a configurar la máscara para asegurarse de que el filtro sólo pasarán los marcos de la CAN con un ID de 1.
Máscara = 11111111111 (Todos los 1 significa que cada bit de la filterA Rx se utiliza para comprobar la entrada CAN marco de ID en contra.



Ejemplo 2:
Si desea configurar el filtro para recibir un número de (secuencial) CAN marco de ID, y luego todo lo que necesita hacer es configurar algunos de los bits de la máscara y filtro a 0.

Deseo recibir puede enmarcar 1,2 ID y 3, pero no quiero recibir CAN marco ID 4
Una vez más, siempre es mas fácil de descomponer la tarea en binario (hasta que entienda el proceso).
ID1 = 00000000001
ID2 = 00000000010
ID3 = 00000000011
ID 4 = 00000000100

Esta vez, en primer lugar establecer el filtro Máscara de hacer caso omiso de los bits del ID que son comunes a todos los identificadores quería - en este ejemplo, establezca los bits de la máscara de 0,1 = 0. Esto hará que el filtro de hacer caso omiso de los dos bits LSB de la ID de la CAN.
Máscara = 11111111100

En segundo lugar, configurar el filtro para "igualar" los bits comunes de los identificadores CAN desea.
FilterA = 00000000000

Cuando se combina la máscara y filtro, verá que usted ha creado (lo que yo llamo) una "regla de Rx".
Máscara = 11111111100
FilterA = 00000000000
Identificaciones que se aceptan: 1,2,3
ID que será rechazada: 4-2047

Esperamos que algunas de ayuda
Artic
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 31 de Agosto de 2011, 15:16:47
Si en el código deshabilitas Debug_printf la librería deja de enviar por el puerto cada vez que transmite o recibe, lo que pasa es que nadie le contesta nada, por lo tanto es imposible saber si esta o no transmitiendo. Yo lo dejaría así, porque si en algún momento recibes algo, al menos entiendes que paso o que salio mal o si salio bien, entenderás las tramas del CANBUS.

Si miras en la placa que yo puse en los primeros puntos de este hilo, veras que le puse leds a las lineas de transmicion y recepción de cada nodo, precisamente para enterarme que pasa cuando tengo problemas de transmision o recepción.


Hola MGLSOFT,

Después del verano vuelvo a carga por donde lo dejé.

Os situo, me he creado los LEDs de TX y RX y funciona correctamente, cada segundo parpadea el LED de RX, tal como debe ser. Pero con el debugger sigue sin entrarme al if ( can_kbhit() ), el código íntegro es el siguiente:
Código: [Seleccionar]
#include <18F2580.h>


#device ICD=TRUE
#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 BROWNOUT              //Reset when brownout detected
#FUSES BORV21                //Brownout reset at 2.1V
#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 NOIESO                  //Internal External Switch Over mode enabled
#FUSES FCMEN                  //Fail-safe clock monitor enabled
#FUSES PBADEN                //PORTB pins are configured as analog input channels on RESET
#FUSES BBSIZ1K                //1K words Boot Block size
#FUSES NOWRTC                //configuration not registers write protected
#FUSES NOWRTB                //Boot block not write protected
#FUSES NOEBTR                //Memory not protected from table reads
#FUSES NOEBTRB                //Boot block not protected from table reads
#FUSES NOCPB                  //No Boot Block code protection
#FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
#FUSES MCLR                  //Master Clear pin enabled
#FUSES NOXINST                //Extended set extension and Indexed Addressing mode disabled (Legacy mode)



#use delay(clock=22110000)
#define CAN_DO_DEBUG TRUE
#define set_50k_baud
#include <can-18F4580.c>

void main()
{
struct rx_stat rxstat;
int32 rx_id;
int buffer[8];
int rx_len;
  int i;

for(i=0;i<8;i++)
{
buffer[i]=0;
}

printf("\r\n\r\nCCS CAN EXAMPLE\r\n");


can_init();
delay_ms(500);//**********************************************



while(TRUE)
{
if ( can_kbhit() )
{
printf("\n\rEntro al kbhit\n\r");
printf("\r\n");
if(can_getd(rx_id, &buffer[0], rx_len, rxstat))
{
printf("Byte 0: %X\r\n",buffer[0]);
for(i=0;i<rx_len;i++)
{
printf("Mensaje: %X\r\n",buffer[i]);
}
}
}
// delay_ms(500);
}

}

Se os ocurre algo??

Gracias!!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2011, 15:26:35
Del otro lado debe haber otro emitiendo mensajes, porque no pones el código de ese también??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 31 de Agosto de 2011, 16:35:48
Del otro lado debe haber otro emitiendo mensajes, porque no pones el código de ese también??

Es el siguiente:

Código: [Seleccionar]
#include <18F2580.h>


#device ICD=TRUE
#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 BROWNOUT              //Reset when brownout detected
#FUSES BORV21                //Brownout reset at 2.1V
#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 NOIESO                  //Internal External Switch Over mode enabled
#FUSES FCMEN                  //Fail-safe clock monitor enabled
#FUSES PBADEN                //PORTB pins are configured as analog input channels on RESET
#FUSES BBSIZ1K                //1K words Boot Block size
#FUSES NOWRTC                //configuration not registers write protected
#FUSES NOWRTB                //Boot block not write protected
#FUSES NOEBTR                //Memory not protected from table reads
#FUSES NOEBTRB                //Boot block not protected from table reads
#FUSES NOCPB                  //No Boot Block code protection
#FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
#FUSES MCLR                  //Master Clear pin enabled
#FUSES NOXINST                //Extended set extension and Indexed Addressing mode disabled (Legacy mode)



#use delay(clock=22110000)
//#use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7)


#define CAN_DO_DEBUG TRUE
#define set_50k_baud
#include <can-18F4580.c>

void main()
{
int dato=0;

printf("\r\n\r\nCCS CAN TX EXAMPLE\r\n");

can_init();

while(TRUE)
{
can_putd(0, &dato, 1, 1, 0, 0);//****************
delay_ms(1000);//**********************************************

}

}
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Agosto de 2011, 16:58:22
Si en el código deshabilitas Debug_printf la librería deja de enviar por el puerto cada vez que transmite o recibe, lo que pasa es que nadie le contesta nada, por lo tanto es imposible saber si esta o no transmitiendo. Yo lo dejaría así, porque si en algún momento recibes algo, al menos entiendes que paso o que salio mal o si salio bien, entenderás las tramas del CANBUS.

Si miras en la placa que yo puse en los primeros puntos de este hilo, veras que le puse leds a las lineas de transmicion y recepción de cada nodo, precisamente para enterarme que pasa cuando tengo problemas de transmision o recepción.


Hola MGLSOFT,

Después del verano vuelvo a carga por donde lo dejé.

Os situo, me he creado los LEDs de TX y RX y funciona correctamente, cada segundo parpadea el LED de RX, tal como debe ser. Pero con el debugger sigue sin entrarme al if ( can_kbhit() ), el código íntegro es el siguiente:
Código: [Seleccionar]
#include <18F2580.h>


#device ICD=TRUE
#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 BROWNOUT              //Reset when brownout detected
#FUSES BORV21                //Brownout reset at 2.1V
#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 NOIESO                  //Internal External Switch Over mode enabled
#FUSES FCMEN                  //Fail-safe clock monitor enabled
#FUSES PBADEN                //PORTB pins are configured as analog input channels on RESET
#FUSES BBSIZ1K                //1K words Boot Block size
#FUSES NOWRTC                //configuration not registers write protected
#FUSES NOWRTB                //Boot block not write protected
#FUSES NOEBTR                //Memory not protected from table reads
#FUSES NOEBTRB                //Boot block not protected from table reads
#FUSES NOCPB                  //No Boot Block code protection
#FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
#FUSES MCLR                  //Master Clear pin enabled
#FUSES NOXINST                //Extended set extension and Indexed Addressing mode disabled (Legacy mode)



#use delay(clock=22110000)
#define CAN_DO_DEBUG TRUE
#define set_50k_baud
#include <can-18F4580.c>

void main()
{
struct rx_stat rxstat;
int32 rx_id;
int buffer[8];
int rx_len;
  int i;

for(i=0;i<8;i++)
{
buffer[i]=0;
}

printf("\r\n\r\nCCS CAN EXAMPLE\r\n");


can_init();
delay_ms(500);//**********************************************



while(TRUE)
{
if ( can_kbhit() )
{
printf("\n\rEntro al kbhit\n\r");
printf("\r\n");
if(can_getd(rx_id, &buffer[0], rx_len, rxstat))
{
printf("Byte 0: %X\r\n",buffer[0]);
for(i=0;i<rx_len;i++)
{
printf("Mensaje: %X\r\n",buffer[i]);
}
}
}
// delay_ms(500);
}

}

Se os ocurre algo??

Gracias!!!


Que debugger usas ??
Yo pondria la orden de encender y apagar un led despues del Kbhit() a ver si realmente pasa por ahi o no.
Si el debug que esperas es por serial, podrias tener mal algo del port serial.

Por otro lado prueba activar el bit rtr en el emisor (ultimo valor de la funcion Can_Put() cen 1), esto obligara a que el esclavo responda cuando recibe un mensaje.

Quedaria asi:
Citar
can_putd(0, &dato, 1, 1, 0, 1);
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 01 de Septiembre de 2011, 13:05:58
Que debugger usas ??
Yo pondria la orden de encender y apagar un led despues del Kbhit() a ver si realmente pasa por ahi o no.
Si el debug que esperas es por serial, podrias tener mal algo del port serial.

Por otro lado prueba activar el bit rtr en el emisor (ultimo valor de la funcion Can_Put() cen 1), esto obligara a que el esclavo responda cuando recibe un mensaje.

Quedaria asi:
Citar
can_putd(0, &dato, 1, 1, 0, 1);
[/quote]

Ahora ya si que me acabo de liar del todo... Resulta que en modo debugger el pintf de "CCS EXAMPLE" me lo hace correctamente, pero si lo grabo y lo arranco sin conectar el ICD no me lo hace  :shock: :shock: No se que puedo estar haciendo mal.

He puesto a 1 el bit RTR del emisor, pero sigue igual. Para probarlo tengo el printf de "Entro al kbhit()", pero nunca lo hace.

El debugger lo estoy haciendo desde el MPLAB con un ICD3.

Gracias por tu ayuda!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 01 de Septiembre de 2011, 13:52:00
Que debugger usas ??
Yo pondria la orden de encender y apagar un led despues del Kbhit() a ver si realmente pasa por ahi o no.
Si el debug que esperas es por serial, podrias tener mal algo del port serial.

Por otro lado prueba activar el bit rtr en el emisor (ultimo valor de la funcion Can_Put() cen 1), esto obligara a que el esclavo responda cuando recibe un mensaje.

Quedaria asi:
Citar
can_putd(0, &dato, 1, 1, 0, 1);

Ahora ya si que me acabo de liar del todo... Resulta que en modo debugger el pintf de "CCS EXAMPLE" me lo hace correctamente, pero si lo grabo y lo arranco sin conectar el ICD no me lo hace  :shock: :shock: No se que puedo estar haciendo mal.

He puesto a 1 el bit RTR del emisor, pero sigue igual. Para probarlo tengo el printf de "Entro al kbhit()", pero nunca lo hace.

El debugger lo estoy haciendo desde el MPLAB con un ICD3.

Gracias por tu ayuda!

[/quote]

Una prueba mas (el que piense que todo sale de una primera vez, que no entre a este foro!!), intercambia ambas placas y sus programas, asi el que hoy recibe pasa a transmitir y viceversa.
A ver si hay algun problema de hardware...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 01 de Septiembre de 2011, 19:09:53


Las capas más superiores son definidas de acuerdo con la aplicación. Por ejemplo, yo estoy intentando leer datos de autobuses y camiones. He descubierto que las capas más superiores de la referencia OSI para autobuses y camiones son definidas por la norma SAE J1939, y los datos de algunos modelos dentro del J1939 siguen un standard llamado FMS Standard.
Procura informarte a respecto de que normas definen las capas más superiores para los autos de Peugeot, para poder interpretar los datos.

Para los filtros, creo que este trend, nel forum de Microchip te puede aclarar (en inglés).
http://www.microchip.com/forums/tm.aspx?m=456043&settheme=Mobile



Hola de nuevo....
Lo cierto es que no quiero conectarme al CAN del Peugeot. Ese es mi coche y con él estaba haciendo una prueba a través del conector OBD, pero con la información que tengo, creo que no tiene bus can en ese conector, usa otro estandar.
Lo que yo quiero hacer es controlar una dirección asistida de un nissan micra. Los datos que he dado son de ella, lo que pude ver que enviaba al bus. Al parecer también la monta en Renault, en el clio o así. Es para coches pequeños y va directamente sobre la barra de la dirección.
La idea es montarla en un ATV y poder controlar su dureza enviándole los valores de velocidad que normalmente reciben.
Así que lo que de verdad necesito es el estandar que usa Renault y Nissan (supongo que son los mismos, ya que son del mismo grupo y usan piezas comunes).
Gracias por el enlace.... y por la traducción....
Si averiguo algo mas os lo comentaré.

Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 01 de Septiembre de 2011, 20:05:40


Para los filtros, creo que este trend, nel forum de Microchip te puede aclarar (en inglés).
http://www.microchip.com/forums/tm.aspx?m=456043&settheme=Mobile




Creo que he entendido mas o menos lo que se dice con respecto a la mascara y el filtro.

La máscara determina que bits serán examinados por el filtro. Aquellos bits cuyo valor en la máscara es 1 serán los que se tendrán en cuenta para comparar su valor con el indicado en su misma posición en el filtro.
Combinando ambos valores, podremos tener un rango de ID aceptados y no solo un ID.

Trataré de explicar el mismo ejemplo:
para que podamos aceptar los ID con valor 1, 2 y 3, pero no el 4, deberíamos tener:
ID 1= 0b00000001
ID 2= 0b00000010
ID 3= 0b00000011
ID 4= 0b00000100

Mask     0b11111100
filter      0b00000000
Los seis primeros bits de mas peso, a "1" en la máscara, son los que se tendrán en cuenta para comparar su valor con el del filtro y, de acurerdo con su valor, deberán ser "0", es decir, que todos los IDs menores o iguales a 0b00000011 serán aceptados.
El valor de ID validado será 0b000000xx, donde xx puede tomar cualquier valor.
Los dos bits de menos peso, aunque en el filtro se indican 00, realmente no son comparados, ya que los elimina la máscara.

Supongo, no lo he probado, que sería lo mismo poner como valor de filtro 0b00000000 que 0b00000011

Saludos,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 02 de Septiembre de 2011, 08:28:59
Hola buenos dias, ya que se esta hablando del tema del filtrado de ID en can bus me gustaria documentarme un poco mejor para asi realizar mi propia funcion de filtraje en la libreria de can bus para maneja esos IDs deseados por cada nodo Can.

Saludos y cualkquier aporte a la causa es bien recibido.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 03 de Septiembre de 2011, 15:50:15
Hola, buenas a todos, primero agradecer a los colaboradores del post toda la info, porque he aprendido bastante bien las dudas que tenia con el can bus.

La primera vez que entre en contacto con el can bus fue viendo un datasheet y un ejemplo de micropic, en cuanto lo vi sali corriendo porque veia muchisimos lios, pero una vez estas dentro ves que no es tan lioso, hay muchos registros, pero son muy sencillos una vez comprendes todo el funcionamiento.

Decir que en 2 dias me he currado mi primer proyecto de can-bus, donde un pic transmite a otro unos valores, y este otro los muestra en un glcd. No he usado ninguna biblioteca ya que me gusta hacer las cosas a mi gusto, unicamente he cogido de aqui, de alli, y me voy a montar mi propia libreria para C18 (mplab).

En este proyecto he usado 2 pics 18f46k80 con modulo ecan integrado, y 2 transceivers mcp2551. Decir que es bastante comodo este micro, ya que con el mismo oscilador interno te puedes hacer 64Mhz (es la frecuencia a las que los tengo trabajando) sin nada externo.

Bueno pongo el video para que veais, aunque se ve muy mal por la oscuridad, pero tambien podeis ver los mensajes can en el osciloscopio como estos van variando.


Una cosa que queria comentar que me ha sucedido, no se si es normal (yo diria que si) es que si unicamente conecto un pic y el otro lo dejo apagado (o con el modulo can off) el pic que esta enviando se pone a enviar mensajes (los mismos) reiteradamente como un loco. Y me refiero a que unicamente hago un send, y sigue mandando el mismo mensaje una y otra vez hasta que enciendo el pic2 y este activa el modulo can.

Y una duda, entre que voltajes oscila el CANH y CANL? Es que a mi me va entre 2V aproximadamente, y me parece bastante poco, alguien sabe si es normal, o como solucionarlo?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 04 de Septiembre de 2011, 06:31:30


Una cosa que queria comentar que me ha sucedido, no se si es normal (yo diria que si) es que si unicamente conecto un pic y el otro lo dejo apagado (o con el modulo can off) el pic que esta enviando se pone a enviar mensajes (los mismos) reiteradamente como un loco. Y me refiero a que unicamente hago un send, y sigue mandando el mismo mensaje una y otra vez hasta que enciendo el pic2 y este activa el modulo can.


Hola MerLiNz, eso es normal.

Si ves la info sobre los mensajes CAN, en la misma trama hay unos bits de ACK para que los receptores, al menos uno, indique que ha recibido un mensaje de CAN correcto. Si ningún receptor valida el mensaje, el transmisor lo da por erróneo y lo vuelve a enviar.

En cuanto a los niveles de tensión, yo se cual es la diferencia máxima, se que lo he leido en alguna parte, pero ahora mismo no me acuerdo. Si lo encuentro te lo indico.

Saludos,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 04 de Septiembre de 2011, 10:40:10
He visto en el osciloscopio que el canh por ejemplo sube de 0V a 3V la señal, y luego la señal (0,1) trabaja entre 1V aproximadamente, no se si me explico.

Es algo asi como esto:
(http://4.bp.blogspot.com/_43jDKyabaZc/TOD4OcocGLI/AAAAAAAAAVk/Vuf1ZbZxCP8/s1600/can%2BH%2Band%2BL.jpg)

Como ves desde el 2 hasta donde pone A hay determinados voltios, y luego la señal trabaja entre 2V por encima de este aproximadamente.

Yo creo que es normal, el mio es parecido a este, quizas algunos voltios menos pero 0,5V aproximadamente de diferencia.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Septiembre de 2011, 15:14:35
Por ser Can una señal diferencial, deberias conectar ambos canales de tu osciloscopio y lograr la superpocision de ambas ondas, para observar correctamente el funcionamiento.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 04 de Septiembre de 2011, 15:53:50
http://img26.imageshack.us/img26/2381/can2e.jpg
http://img838.imageshack.us/img838/1730/can3e.jpg
http://img15.imageshack.us/img15/7703/canej.jpg

ahi 3 imagenes, yo creo ke esta bien, porque lei por ahi que la señal de un canal tiene que restar la del otro y dar cerca de 0.

Otra cosa sobre lo anterior de que si ningun receptor indica que el mensaje ha sido recibido vuelve lo da como error y lo vuelve a enviar. Imaginemos que tenemos una red con 3 dispositivos, el dispositivo 1 envia un mensaje el cual el 2 lo acepta por el filtro/mascara, pero que pasaria si el 2 esta offline por cualquier razon? Seria un error, o ya el dispositivo 3 se encargaria de decir que el mensaje ha sido recibido, a pesar de que no entre en su filtro/mascara?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 04 de Septiembre de 2011, 18:04:55
Otra cosa sobre lo anterior de que si ningun receptor indica que el mensaje ha sido recibido vuelve lo da como error y lo vuelve a enviar. Imaginemos que tenemos una red con 3 dispositivos, el dispositivo 1 envia un mensaje el cual el 2 lo acepta por el filtro/mascara, pero que pasaria si el 2 esta offline por cualquier razon? Seria un error, o ya el dispositivo 3 se encargaria de decir que el mensaje ha sido recibido, a pesar de que no entre en su filtro/mascara?

En cuanto a la señal..., estás midiendo en DC o AC? Se supone que el "0" está en 2,5V y a partir de aquí, la señal de cada línea fluctúa según sea un valor recesivo o dominante y ésta fluctuación depende del valor de las resistencia de terminación que tienes en la línea del bus. Debe ser de 120 ohms en cada extremo. Otros valores pueden hacer que el bus no funcione o cambie el valor que toman las líneas.

En cuanto a la transmisión de una señal válida, una cosa es validar la señal como buena conforme a una señal CAN y otra cosa es aceptar el dato emitido. La validaciónde una transmisión no implica la aceptación del dato, solo indica que su transmisión ha sido correcta conforme al una señal CAN, pero no tiene por que indicar que el que lo tenía que recibir lo haya recibido. Ten en cuenta que en CAN los datos no son punto a punto, sino de uno a todos.

Saludos y espero haberte ayudado....
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 04 de Septiembre de 2011, 18:07:50
si esta en DC, te puedes fijar en la derecha los parametros del osciloscopio.

En principio la señal la recibo correctamente, unicamente me parecian unos valores bajos para el canl y canh por eso pregunte, pero el sistema me funciona correctamente.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 04 de Septiembre de 2011, 18:41:51
Hay numerosa documentación en pdf que hablan del bus CAN,

Mira si encuentras este archivo Juan_GuisandezInformeBusCan.pdf , una de las muchas documentaciones que puedes encontrar y que te darán una idea de  cómo funciona el bus CAN.

Saludos,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 04 de Septiembre de 2011, 20:27:37
Libreria de can para proteus.

http://es.blackboxaccess.com/search/library-and-models-for-proteus-7-1-mcp2515

Saludos y espero sus comentarios
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Septiembre de 2011, 22:41:33
Podrias pasarme el archivo??
Me obliga a registrarme si quiero bajarlo. :(

Sabes si hay librerias del MCP2551 ??
Porque sin ese aun no tienes Can... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Septiembre de 2011, 22:44:51
http://img26.imageshack.us/img26/2381/can2e.jpg
http://img838.imageshack.us/img838/1730/can3e.jpg
http://img15.imageshack.us/img15/7703/canej.jpg

ahi 3 imagenes, yo creo ke esta bien, porque lei por ahi que la señal de un canal tiene que restar la del otro y dar cerca de 0.

Otra cosa sobre lo anterior de que si ningun receptor indica que el mensaje ha sido recibido vuelve lo da como error y lo vuelve a enviar. Imaginemos que tenemos una red con 3 dispositivos, el dispositivo 1 envia un mensaje el cual el 2 lo acepta por el filtro/mascara, pero que pasaria si el 2 esta offline por cualquier razon? Seria un error, o ya el dispositivo 3 se encargaria de decir que el mensaje ha sido recibido, a pesar de que no entre en su filtro/mascara?

Es un osciloscopio DSO Nano el que usas??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 04 de Septiembre de 2011, 22:50:57
http://img26.imageshack.us/img26/2381/can2e.jpg
http://img838.imageshack.us/img838/1730/can3e.jpg
http://img15.imageshack.us/img15/7703/canej.jpg

ahi 3 imagenes, yo creo ke esta bien, porque lei por ahi que la señal de un canal tiene que restar la del otro y dar cerca de 0.

Otra cosa sobre lo anterior de que si ningun receptor indica que el mensaje ha sido recibido vuelve lo da como error y lo vuelve a enviar. Imaginemos que tenemos una red con 3 dispositivos, el dispositivo 1 envia un mensaje el cual el 2 lo acepta por el filtro/mascara, pero que pasaria si el 2 esta offline por cualquier razon? Seria un error, o ya el dispositivo 3 se encargaria de decir que el mensaje ha sido recibido, a pesar de que no entre en su filtro/mascara?

Es un osciloscopio DSO Nano el que usas??

Es el hantek DSO 2150 USB para PC, la verdad es que esta bastante bien y no es muy caro. Pero no es el DSO Nano. Lo bueno es que trae soft libre y puedes modificar el soft que viene en visual C
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Septiembre de 2011, 23:06:11
Lindo equipo !

http://www.hantek.net/english/produce_list.asp?unid=63 (http://www.hantek.net/english/produce_list.asp?unid=63)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 04 de Septiembre de 2011, 23:40:53
Lindo equipo !

http://www.hantek.net/english/produce_list.asp?unid=63 (http://www.hantek.net/english/produce_list.asp?unid=63)

Pues si, yo estoy bastante contento con el, he llegado a ver señales de 20Mhz sin problemas. Aun asi si hubiese tenido mas dinero me hubiese tirado a por el 5200A que es bastante superior, y el programa tambien es mucho mas completo. Ademas es bastante mas comodo que uno normal, porque en el pc puedes hacer capturas de pantalla, o capturas infinitas de la señal (hasta que tu HD se llene xD)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Septiembre de 2011, 23:52:27
Que hora es por alli??
Las 4AM ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 05 de Septiembre de 2011, 00:03:43
Que hora es por alli??
Las 4AM ??

Las 5, vamos que me voy a la cama ya, porque mañana me tengo que levantar temprano xD

pero en este foro veo mucho material, y eso engancha xD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Septiembre de 2011, 00:08:22
Ja..ja!!
El foro causa adiccion !! :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 06 de Septiembre de 2011, 13:07:40
Que debugger usas ??
Yo pondria la orden de encender y apagar un led despues del Kbhit() a ver si realmente pasa por ahi o no.
Si el debug que esperas es por serial, podrias tener mal algo del port serial.

Por otro lado prueba activar el bit rtr en el emisor (ultimo valor de la funcion Can_Put() cen 1), esto obligara a que el esclavo responda cuando recibe un mensaje.

Quedaria asi:
Citar
can_putd(0, &dato, 1, 1, 0, 1);

Ahora ya si que me acabo de liar del todo... Resulta que en modo debugger el pintf de "CCS EXAMPLE" me lo hace correctamente, pero si lo grabo y lo arranco sin conectar el ICD no me lo hace  :shock: :shock: No se que puedo estar haciendo mal.

He puesto a 1 el bit RTR del emisor, pero sigue igual. Para probarlo tengo el printf de "Entro al kbhit()", pero nunca lo hace.

El debugger lo estoy haciendo desde el MPLAB con un ICD3.

Gracias por tu ayuda!


Una prueba mas (el que piense que todo sale de una primera vez, que no entre a este foro!!), intercambia ambas placas y sus programas, asi el que hoy recibe pasa a transmitir y viceversa.
A ver si hay algun problema de hardware...
[/quote]

Bueno, ya me deja grabar, tiene que ser alguna historia con el MPLAB... Te he hecho caso y he intercambiado ambas placas, además he puesto LEDs de TX y RX en los pines TXD y RXD de cada chip de can, el resultado es el siguiente:

Placa emisora: Envía un mensaje cada segundo. Cada vez que envía se encienden ambos leds, el de TXD y el de RXD, supongo que el de RXD se enciende porque recibe la confirmación por parte del otro chip, por poner RTR a 1, no?

Placa receptora: Se enciende el led de TXD cada vez que la otra placa envía un mensaje, no debería encenderse el de RXD??

Gracias de nuevo por tu paciencia y ayuda
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Septiembre de 2011, 14:20:46
En la que emite el mensaje es normal que encienda ambos leds (si lo filmaras en alta velocidad y lo pasaras verias encenderse primer el de TX y luego el de RX), o sea que transmite y recibe.
Si el otro responde al RTR quiere decir que entiende lo que le transmiten, hasta ahi vamos bien....

El que recibe puede no encender el led RX por dos cosas, una que el led o el resistor esten mal colocados o calculados, o uno de ellos esta mal.
Si transmite es porque recibio OK, lo del led es un detalle en este momento.

Has avanzado y mucho!! :-/ :-/

Ahora falta saber que es lo que cada uno envia y recibe.
Arranca poniendo en el que recibe una linea que envie por el puerto serie los datos que van y vienen, o simplemente habilita el debug del PIC.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 06 de Septiembre de 2011, 15:12:10
Bien, y como puedo hacer eso? tengo puesto que cuando entre al kbhit() me envíe un mensaje por el puerto serie y que además me encienda un led, pero nunca lo hace... :?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Septiembre de 2011, 16:05:52
Una pregunta tonta, solo para aclararlo antes:
Estas seguro que tus nodos estan conectados entre si con CANH  <<>> CANH    y    CANL <<>> CANL  ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 06 de Septiembre de 2011, 16:21:56
Si si, eso está todo bien!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Septiembre de 2011, 16:54:45
Los pic son 18f2580, los que estas utilizando, no??
Y cargas la libreria del 4580, segun tu codigo??

Tienes un analizador CAN a mano para conectarlo a la linea??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 06 de Septiembre de 2011, 17:01:01
Ahí me has pillado. que es un analizador can?

Si, utilizo el 2580 y cargo las librerías del 4580, lo único que modifico es la velocidad siguiendo los pasos que hay en el post...

Por cierto, he seguido dandole vueltas y he de decir que en el la placa receptora también se enciende el LED de RXD, pero es rapidísimo y muy tenue!! pero sigue sin hacer la instrucción que está en el kbhit().
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Septiembre de 2011, 17:22:46
Un analizador CAN es básicamente una placa que se conecta al bus y sirve para "espiar" los mensajes de ida y vuelta a través de un software en PC que permite hasta detener el análisis para ver con precisión que es lo que pasa en el bus.

Por tu respuesta no lo tienes, así que intenta ver que pasa si desconectas el esclavo, a ver si sigues recibiendo en el transmisor.
Si no es así, se puede probar de poner en modo LoopBack, de ese modo ni precisa salir al bus, y recibe sus propios mensajes, ya si allí no entra en kbhit() me jubilo...je..je

Sacado del archivo can-18F4580.h

Código: C
  1. ////////////////////////////////////////////////////////////////////////////////
  2. ////////////////////////  CAN Control Register /////////////////////////////////
  3. ////////////////////////////////////////////////////////////////////////////////
  4.  
  5. enum CAN_OP_MODE {   CAN_OP_CONFIG=4,
  6.                      CAN_OP_LISTEN=3,
  7.                      CAN_OP_LOOPBACK=2,                       <<<<<<<<<<<<<<<<<<<  ¡¡¡ usar este modo!!!
  8.                      CAN_OP_DISABLE=1,
  9.                      CAN_OP_NORMAL=0 };
  10.  
  11. enum CAN_FUN_OP_MODE { CAN_FUN_OP_LEGACY=0,
  12.                        CAN_FUN_OP_ENHANCED=1,
  13.                        CAN_FUN_OP_ENHANCED_FIFO=2 };
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 07 de Septiembre de 2011, 13:39:19
No tengo analizador can  :(

Al desconectar la placa emisoraq de mensajes, los LEDs de la receptora dejan de encenderse, así que eso aparentemente está bien.

¿Cómo lo hago para utilizar el modo que me indicas? :oops:

Gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Septiembre de 2011, 15:02:02
Sencillo.
Busca en tus archivos la sentencia:

Código: C
  1. CAN_OP_MODE

Esa es la que configura todo, búscalo como tarea y le asignas ese valor que te marque.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 07 de Septiembre de 2011, 16:01:56
Esos son los valores que me vienen por defecto ¿? :?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Septiembre de 2011, 16:29:07
La sentencia Enum lo que hace es enumerar los posibles estados que puede tomar un registro.
Ese registro en particular (si miras la hoja de datos lo encontraras) puede tomar 5 estados, que van de 0 a 4 numericamente hablando.
El enumerador lo que hace es que no tengas que trabajar con los valores directamente, sino ya con nombres descriptivos de la opcion elegida.

En este caso deberas elegir el numero 2 o sea CAN_OP_LOOPBACK

La instruccion quedaria asi:
Código: C
  1. CAN_OP_MODE  CAN_OP_LOOPBACK;
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 07 de Septiembre de 2011, 16:55:12
Lo he puesto en el main justo debajo de la función can_init(); quedando así:

can_init();

can_set_mode(CAN_OP_LOOPBACK);

Está así bien? no creo, puesto que sigue sin entrar al kbhit()... (en una de estas me.... pfffff :5])
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Septiembre de 2011, 17:14:59
Lo he puesto en el main justo debajo de la función can_init(); quedando así:

can_init();

can_set_mode(CAN_OP_LOOPBACK);

Está así bien? no creo, puesto que sigue sin entrar al kbhit()... (en una de estas me.... pfffff :5])

Hay que hacerlo asi:

Código: C
  1. CAN_OP_MODE  CAN_OP_LOOPBACK;
  2. can_set_mode(CAN_OP_MODE);
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 07 de Septiembre de 2011, 17:28:42
Me vas a llamar torpe, pesado... pero no hay manera.

Si pongo esas dos instrucciones tal cual me las pones me da un error de compilación...

Si la función can_set_mode() es así:

void can_set_mode(CAN_OP_MODE mode) {
   CANCON.reqop=mode;
   while( (CANSTAT.opmode) != mode );
}


no sería suficiente con poner?

can_set_mode (CAN_OP_LOOPBACK);



En serio, muchas gracias por tu paciencia.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Septiembre de 2011, 18:05:47
Si, viendo el código, debería funcionar como dices...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: estenolotienen en 08 de Septiembre de 2011, 13:42:49
A ver si puedo probar este finde y te cuento!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: FIRMWARER en 08 de Septiembre de 2011, 20:51:10
Buenas Tardes a todos, antes que nada mis Felicitaciones MGL SOFT por el tremendo post de bus CAN, les deseo hacer una consulta con respecto al bus, existe alguna limitacion en la cantidad de nodos que pueden ser colgados de bus?, les comento, me han ofrecido realizar un proyecto donde los nodos tienen que ser 19  con diferentes sensores, y que lleven los datos a un monitor...,  por otro lado les deberia consultar, y pedir perdon si este no es el lugar apropiado, si me pueden brindar asesoramiento, informacion sobre la realizacion de un proyecto contemplando el costo del mismo, incluyendo investigacion, desarrollo, diseño, implementacion, pruebas y depuracion, etc.... les pediria si conoces algun link donde se hable de esto y los precios que se estan cobrando para realizar diferentes proyectos, si estan expresados en dolares mucho mejor para que cualquiera que necesite estos datos tenga una buena referencia,  para ser concretos les tiro un ejemplo... viene un cliente y les pide que realicen un sistema donde el pueda abrir el garage de su casa mediante un sms de su celular,  sacando los costos de componentes, de mano de obra cuanto cobrarian??????? GRACIAS A TODOS, les doy mi mail para estar comunicados.

firmwarer@hotmail.com.ar
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Septiembre de 2011, 21:16:48
Buenas Tardes a todos, antes que nada mis Felicitaciones MGL SOFT por el tremendo post de bus CAN, les deseo hacer una consulta con respecto al bus, existe alguna limitacion en la cantidad de nodos que pueden ser colgados de bus?, les comento, me han ofrecido realizar un proyecto donde los nodos tienen que ser 19  con diferentes sensores, y que lleven los datos a un monitor...,  por otro lado les deberia consultar, y pedir perdon si este no es el lugar apropiado, si me pueden brindar asesoramiento, informacion sobre la realizacion de un proyecto contemplando el costo del mismo, incluyendo investigacion, desarrollo, diseño, implementacion, pruebas y depuracion, etc.... les pediria si conoces algun link donde se hable de esto y los precios que se estan cobrando para realizar diferentes proyectos, si estan expresados en dolares mucho mejor para que cualquiera que necesite estos datos tenga una buena referencia,  para ser concretos les tiro un ejemplo... viene un cliente y les pide que realicen un sistema donde el pueda abrir el garage de su casa mediante un sms de su celular,  sacando los costos de componentes, de mano de obra cuanto cobrarian??????? GRACIAS A TODOS, les doy mi mail para estar comunicados.

firmwarer@hotmail.com.ar

El bus CAN estandar permite direccionar 11 bits, el modo extendido permite direccionar 29 bits, si vamos a una direccion unica, son 536 millones y pico de direcciones para el modo extendido y solo 2047 para el modo estandar.

Es posible en un bus llegar a esta cantidad de direcciones fisicas y atenderlos todos??
La respuesta es NO.

Algunos protocolos de alto nivel montados sobre CAN, permiten direccionar 64 nodos (DeviceNet), otros 128 (CanOpen), y mas o menos en esa misma direccion van protocolos del agro (estimo que alli vas con tu proyecto), con la cantidad de direcciones aplicadas a nodos.

Lo que hacen todos estos protocolos de alto nivel es una jerarquia de nodos, es decir que dividen parte del direccionamiento a asignar la Clase, otra parte a asignar la Tarea y por ultimo queda la direccion real del nodo.
De ese modo cuando se dirigen a pedir un dato con una cierta direccion estan pidiendo esto:

Clase tanto
               Tarea tanto
                          Nodo  tanto
<por favor pasame los datos>

Se entiende??
Para mas informacion (ya que esto es muyyy generico) referenciarte a la norma del protocolo que debas cumplir.

Respecto a precios de trabajos, sugiero que plantees tus dudas en el foro de compra venta o algun otro, aca no molesta pero este lado se lee poco por los usuarios del foro.

Y bienvenido al foro!! :mrgreen: :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 08 de Septiembre de 2011, 22:12:18
en el datasheet del 2551 pone hasta 112 nodos.

Bien, ahora tengo un problema con los 2551, he quemado como 2 ya, el problema esta en que si desconecto un nodo, se quema el transceptor, la primera vez que me paso esto fue probando fallos, como desconectar el canh, canl... me dio por desconectar la alimentacion de un 2551 y zas, se achicharro, pero no se achicharro el que desconecte, sino el otro!

Pues hoy me ha pasado lo mismo, enciendo uno bien, enciendo el otro bien, ahora desconecte completamente un modulo (la fuente de alimentacion) y zasca al volverlo a encender ya no funciona, le meto el osciloscopio y no hay datos en el canl ni canh...

Alguien sabe que puede estar pasando? O cual ser la solucion, porque me veo cambiando transceptores cada 2x3, he pedido 18 mas, espero no quemarlos todos xD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Septiembre de 2011, 22:24:33
Con estos datos es muy dificil ayudarte, deberias ponernos un esquema de como estan conectados, si las fuentes son independientes, si todos estan en una maquina, si comparten masas, etcetera.

Hay transceptores mas aptos para la industria del agro, por ejemplo, que resisten otro tipo de tratos, como los de Texas y otras marcas.

Igual en pruebas de mesa, jamas pude quemar uno, salvo el que conecte por equivocacion a la fuente, en vez de al bus... :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 08 de Septiembre de 2011, 22:42:22
son distintas fuentes, una es mediante el pickit3 y otra mediante otra fuente. El caso es que recuerdo que cuando desenchufe el modulo, vi como el otro perdia fuerza, es decir, como si hubiese una bajada de tension, me da la sensacion que al desconectar un nodo este coge alimentacion a traves del canh y l entonces se achicharra.

Estaba conectado unicamente a la alimentacion, osea +5V y gnd, luego la salida RS a una resistencia de 10k y masa, canh y canl a ambos canh y canl del otro nodo con 2 resistencias de 120ohm, y luego la salida rx y tx al pic.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Septiembre de 2011, 23:06:05
Si miras el esquema de la placa en que comence mis pruebas, cada nodo tiene fuente independiete, con su propio regulador, de hecho el pcb se puede troquelar y separar cada nodo, uniendolos solo por los cables de CAN y alimentacion.

La resistencia de RS yo le pongo 10 ohm, segun lei cuanto mas velocidad menor valor, y uso mis placas a 250 Kbps en la mayoria de las aplicaciones.

El valor de 10K de donde lo sacaste??
O usas una velocidad muy baja??

Para mi que estas teniendo uniones de masas y al sacar una fuente se alimenta todo de la otra, por masa y uno de los hilos.
Las resistencias de 120 ohm estan en paralelo a los pines CanH y CanL en los extremos del bus, no??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 08 de Septiembre de 2011, 23:21:23
los 10k los saque del datasheet del 2551 (apartado 1-1), aun asi eso es unicamente para controlar la velocidad de subida/bajada del flanco de la señal no? Yo lo uso a 1mbps y la subida/bajada es bastante rapida.
He visto en los ejemplos de microchip que le ponen 4k7, incluso a masa directamente sin resistencia.

Si, las resistencias estan en los extremos.

Puede ser porque no le tengo puesto ningun condensador??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Septiembre de 2011, 23:32:10
Debes ser pariente de Manolo (Nocturno), por los horarios en que andas por aqui.

Si que es extraño el caso.
Debe haber algo que esta mal en tu circuito, porque los pines de Can debieran estar aislados del resto, por lo tanto seria dificil que por alli se realimentara el circuito sin tension.

Testea si es posible que haya continuidad a positivo de una de las lineas y despues puedes quitar el MCP2551 y sacarle tension solo a esa placa a ver que pasa, leyendo que tension hay en el bus cuando se desconecta.
Es muy loco, pero todo problema siempre tiene una explicacion y solucion...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Septiembre de 2011, 00:06:24
jaja, pues si, yo deberia tener el nick de nocturno2 xD

segun he visto, el pin RS del slope se puede elegir 3 modos, alta velocidad, slope control y standby. El high speed es directo a masa sin resistencia, el slope le pones la resistencia que elijas, entre mas baja mas rapido son los flancos, y standby aplicandole +5V que pasa a modo sleep. De todas formas esto no creo que sea mi problema, pero ya he conectado el pin RS a masa directo para high speed.

El caso es que me he quedado sin transceptores, por lo cual hasta dentro de 1 semana que me llegen los que he pedido nada :(

El condensador que usais vosotros entre vdd y vss del mcp2551 es ceramico o electrolitico? Ya le tengo puesto uno de 100nf a ver si con esto me evita achicharrar mas transceptores.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 09 de Septiembre de 2011, 01:36:57
Pues no me suena tener ningún parentesco con tan afamado mago, pero vete tú a saber lo que hizo mi padre en su juventud  :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Septiembre de 2011, 08:20:40
Dicen las malas lenguas que Manolo esta teniendo sus experiencias en CAN... ;-)
Tal vez si es así quiera aportarnos sus experiencias, a ver si le ha ocurrido algo parecido a esto que te pasa a ti.

Mi nariz (que es grande y aunque esta resfriada aun olfatea bastante bien) me dice que tienes algún problema serio en el conexionado, que deberías revisar mientras esperas la partida de transceptores y antes de achicharrarlos nuevamente. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 09 de Septiembre de 2011, 08:41:20
Muy escasa experiencia todavía como para poder ayudar al compañero. Tan sólo un leve contacto en el que todo funcionó bien y estoy esperando para el momento del gran desembarco en el CAN.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: FIRMWARER en 09 de Septiembre de 2011, 08:59:37
Muchisimas Gracias MGL SOFT por tu tiempo para responderme, espero devolver la generosidad brindada por ustedes quien desee agregarme al mail es bienvenido para poder ayudarnos mutuamente.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Septiembre de 2011, 09:47:59
Es que el conexionado no es dificil, ademas la primera vez me ocurrio en la protoboard donde van pinchados los cables, y esta vez me ocurrio en la protoboard soldada.

No tiene mucha historia:
Vcc -> +5V
Vss-> Gnd
TXD -> PORTC.RC6
RXD -> PORTC.RC7
RS -> 10k -> Gnd
CANL -> bus1
CANH -> bus2

Ademas, me ha estado funcionando perfectamente, sin errores de trasmision recepcion.

La primera vez que se me achicharro fue por desconectarle la patilla VCC a un transceptor, pero se me quemo el transceptor contrario, no el que desconecte.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Septiembre de 2011, 13:38:32
Bueno, traigo noticias. El transceptor no estaba quemado, solo estaba quemado el primero que ya dije que le desconecte la VCC (lo he tirado a la basura para no confundirme).

Desconozco que ha podido pasar, el caso es que vuelve a funcionar perfecto, ademas le he añadido condensadores tanto al pic como a el transceptor de 0.1uf. Ademas de añadirle zocalos para facilitar el cambiar los transceptores. Tambien he puesto directamente la patita RS a masa tal y como pone en el datasheet para high speed.


He probado a desconectar y conectar ambas placas y no ha ocurrido nada, osea que no se ha quemado nada mas xD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 09 de Septiembre de 2011, 14:15:22
Bueno, aunque no encuentres ahora una explicación, me alegro que finalmente lo hayas conseguido.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Septiembre de 2011, 14:37:54
Me alegro.

Viéndole el lado positivo, has inventado la "Freidora CAN" !! :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Septiembre de 2011, 15:20:40
Mi nuevo protocolo sera CANFRIT xD con transceivers a la parrilla
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 09 de Septiembre de 2011, 15:44:30
Jajaaaa, CANFRIT, buenísimo  :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Septiembre de 2011, 16:32:08
Hay que ponerle buen humor a las cosas que nos enojan, y todos viviremos mejor...
Excelente lo del CanFRIT, deberias ingresarlo a la CAN CIA. :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Septiembre de 2011, 16:55:48
No, si yo no me enfado, unicamente busco el "porque de las cosas" para asi no cometer mas fallos en el futuro XD
Me molesta mas tener que esperar mucho tiempo para tener la pieza (y no poder seguir con el proyecto) que soltar 5€ en transceptores xD

Ahora vienen 18 de camino, me hare una buena barbacoa con ellos, alguien se anima?   :5] :-/

Por cierto nocturno, eres de sevilla?? Yo soy de un pueblo a 70km de sevilla. Donde sueles comprar tu los componentes por alli?? Yo es que los pillo por internet porque me da cosa ir a un sitio y que ahora no tengan lo que busco.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 09 de Septiembre de 2011, 17:36:41
Soy de Coria, ¿y tu?
Yo compro casi todo en Internet porque en Sevilla no hay de nada. De todas formas suelo ir a M. León.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Septiembre de 2011, 17:57:02
yo soy de santa olalla del cala, tirando direccion merida (despues de el ronquillo).

ya me suponia que en las tiendas no habria de nada, menos mal que ni me ha dado por ir, porque hubiese sido una perdida de tiempo xD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 10 de Septiembre de 2011, 13:01:59
bueno, aqui les pongo unas fotos de mis simples placas xD

(http://img20.imageshack.us/img20/2986/10092011138.jpg)
(http://img840.imageshack.us/img840/5513/10092011139.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Septiembre de 2011, 21:20:37
Que es el tercer cable que se separa del cableado del bus y va a la placa ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 10 de Septiembre de 2011, 21:45:53
nada, es un cable sin nada xD unicamente busque un cable y encontre este de un cargador que tenia por aqui, tenia 3 hilos asi que decidi no quitarle el 3er hilo por si en un futuro me sirve para cualquier otra cosa. Parece que esta enchufado pero no, unicamente esta ahi suelto, dio la casualidad que se puso encima de la otra placa.

Hoy tuve otro problema, el caso es que puse una fuente de pc que tenia por aqui, funciona correctamente, hice la prueba de desconectar una placa, y la otra, para ver el comportamiento... Pues cuando desconectaba la placa del glcd y la volvia a reconectar la otra placa se reiniciaba, segun en el osciloscopio observe que hay un pequeño bajon de tension al conectar la placa del glcd, asique le puse un condensador de 1000uf (si, soy muy exajerado) a la placa y ya no se volvio a reiniciar, todo correctamente xD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 16 de Septiembre de 2011, 03:33:30
Muy buenas...

MerLinz y nocturno, habéis comentado que comprais en Internet..., me podéis indicar algunas páginas buenas?

Yo solo conozco Rs-Online y la oficial de microchip.

En M.León me compré el ICM4011 de la casa Ingenia, es con el que he estado trasteando en CAN con la dirección asistida. La verdad es que da mucho juego, aunque yo no sepa dárselo  :mrgreen:

Saludos,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 16 de Septiembre de 2011, 03:57:16
Yo compro habitualmente en RS y Digikey. Esporádicamente también en Mouser o Farnell.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: EdoNork en 16 de Septiembre de 2011, 04:12:00
Soy de Coria

¿Cómo va la Feria?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 16 de Septiembre de 2011, 06:16:14
Me he escapado, estoy en la playa  :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 16 de Septiembre de 2011, 09:42:26
yo la mayoria de cosas las pillo en ebay, ahora suelo comprar tambien en la web de microchip.

si te hace falta transceivers, 2515, o algo asi me lo comentas, porque tengo aqui muchos y quiero quedarme con los justos xD, lo que pasa que aun no tengo nivel de colaborador y no puedo abrir posts de venta, pero tengo aqui muchas cosas que quiero deshacerme de ellas porque quiero recuperar algo de dinero.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: micronet3 en 20 de Septiembre de 2011, 12:56:52
Hola, hace tiempo hice un protocolo arcaico con el bus rs485, ahora me gustaria hacer lo mismo pero con el bus can, yo soy de peru y aqui no he podido encontrar los transceiver para el bus can.
estoy pensando entonces adquirir pic que traen incluido el bus can. mi consulta es la siguiente

es factible hacer una red industrial con el bus can utilizando en todos los nodos de la red  el pic 18f4580?

pregunto esto porque he visto que hay  algunos nodos que son controladores y otros expansores.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Septiembre de 2011, 13:37:26
Si que puede funcionar.
Ya existen protocolos industriales basados en CAN, como DeviceNet, CanOpen, y otros.

El PIC puede tener CAN pero de los transceiver no te salvas. Son los que realmente permiten realizar las comunicaciones.

Los expansores CAN (creo que solo Microchip los tiene) son elementos de bajo costo y con opciones simples de funcionamiento.
Donde tengas que accionar una salida o leer unos interruptores o adquirir un valor, úsalos, pero en aplicaciones mas difíciles usa un PIC.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 20 de Septiembre de 2011, 15:03:40
con el can bus te resultara mas facil que con el rs485 ya que tienes tanto la capa fisica como la capa de datos hecha. Es decir, el mismo hardware de canbus te hara el control de errores, el envio y recepcion sin tener que diseñarlo tu mismo.

Yo uso el pic 18f46k80, lo unico que es dificil encontrarlo, en la web de microchip lo compras facilmente, pero en tiendas es dificil encontrarlo.
El transceptor lo mismo, tambien lo puedes pillar en la web de microchip.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: micronet3 en 20 de Septiembre de 2011, 18:41:49
en conclusion el bus can implementa las dos primeras capas del modelo OSI?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 20 de Septiembre de 2011, 18:53:27
Así es... :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 21 de Septiembre de 2011, 09:19:00
Bueno, hoy si he frito un transceptor, pero frito frito XD

Me ocurrio haciendo lo siguiente:
-Modulo 1 encendido
-Modulo 2 sin fuente (se me olvido enchufarlo)
-Puse el ICD3 en el modulo 2 (el icd3 con la fuente interna desactivada).
-Vi como el modulo 1 la LCD perdia intensidad, ademas la fuente de pc hacia el tipico ruido de cortocircuito.
-Toque el transceptor del modulo 1 con el dedo y me quemo el dedo!!
-Transceptor achicharrado
-El del modulo 2 estaba correctamente

Desconozco porque ocurre tal cosa, pero lo pongo aqui para que la gente no repita mis pasos para no quemar el transceptor xD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Septiembre de 2011, 09:54:10
Sencillo, por alguna razón al no tener alimentación se deriva a través de los transceptores.
Ya tendrás para escribir un libro de cocina de chips... :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: micronet3 en 21 de Septiembre de 2011, 10:48:35
uffs, asi que refrito, tendre que tomarme el riesgo, quiero implementar un protocolo de comunicacion sencillo en el bus can y presentarlo como tesis, ya estoy en un 90% convencido que sera mi tema.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 21 de Septiembre de 2011, 11:46:35
uffs, asi que refrito, tendre que tomarme el riesgo, quiero implementar un protocolo de comunicacion sencillo en el bus can y presentarlo como tesis, ya estoy en un 90% convencido que sera mi tema.

te recomiendo que le pongas un zocalo al transceptor, asi puedes cambiar los tranceptores fritos con facilidad jajaja
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Septiembre de 2011, 12:02:51
La tesis de Merlinz se basa en quemaduras producidas por componentes electrónicos y sus consecuencias en las personas !!!   :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 21 de Septiembre de 2011, 12:07:10
nah, tengo por aqui 19 transceptores mas, asiq a ver quien se aburre antes, estos kemandose, o yo cambiandolos  :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 21 de Septiembre de 2011, 12:17:07
algo que te queria preguntar MGLSOFT, me he leido el post completo, pero claro asi rapido y tal de algunas cosas no me acuerdo xD

el tema es saber si con los pics de ecan integrado habeis mostrado el como usar los distintos buffers para recepcionar/enviar mensajes, es decir, el ke yo uso tiene 3 buffers para enviar, y 2 buffers para recibir, adicionalmente tiene 6 buffers mas que se pueden poner para TX o RX.
Yo esque los uso todos los buffers, osea 6buffers de envios, y 5buffers de recepcion, los de recepcion van por interrupciones.

Por si no lo habeis explicado para explicarlo yo asi por encima y aportar algo. Ademas una buena forma y sencilla de poner los mensajes en cola en los 6buffers para que se vayan enviando segun su prioridad.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Septiembre de 2011, 14:35:34
Adelante con la explicación.
Se hizo alguna vez una pequeña introducción al tema, por lo tanto si lo explicas aquí, ademas de poder debatirlo, te servirá para tu trabajo final.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 21 de Septiembre de 2011, 14:45:48
Adelante con la explicación.
Se hizo alguna vez una pequeña introducción al tema, por lo tanto si lo explicas aquí, ademas de poder debatirlo, te servirá para tu trabajo final.

xD, el caso es que yo no tengo "trabajo final" lo hago por voluntad propia, no he estudiado electronica tampoco, unicamente aprendo con lo que veo por alli y por alla xD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Septiembre de 2011, 14:55:36
Disculpas, creí que eras vos quien estaba preparando su tesis.
Respecto a que estudiamos cada uno, yo soy electromecánico, de electrónica vi válvulas solamente, en mi época hace 30 años atrás, así que no te hagas rollos. :mrgreen: :mrgreen:

El hilo es tuyo para exponer lo que interpretas de como utilizar los buffer de envío y recepción.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 21 de Septiembre de 2011, 15:05:55
juas, igual que yo, el año pasado termine el curso de electromecanica, dimos algo de can bus y me parecio interesante asiq aki estoy xD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 21 de Septiembre de 2011, 15:32:25
Bueno señores, pues voy a poner como funcionan los buffers de un pic el cual tiene el CAN integrado. Yo uso el 18F46K80 por lo que en otros pics puede cambiar, que no tengan los mismos buffers, pero se puede aplicar a cualquier pic en mayor o menor medida.

Para empezar empezamos por lo sencillo, una breve explicacion. Este pic tiene 3 buffers para enviar, 2 buffers para recibir, y 6 buffers adicionales para configurarlos segun queramos (RX/TX). Ahora os preguntareis, para que tantos buffers? Pues sencillo, si tenemos una aplicacion que envia mensajes sin parar con 1 solo buffer nos veriamos limitado a esperar que ese buffer quede libre y luego enviar el siguiente mensaje. Para aplicaciones que no se deben bloquear estos buffers nos son de mucha utilidad.

Es decir seria de la siguiente manera:
-Buscamos buffer libre (bit TXB*CON:TXREQ=0)
-Escribimos los datos (tamaño, filtro, datos...)
-Declaramos la prioridad del mensaje (TXB*CON:TXPRI<0:1>) entre 0 y 3 (3 mayor prioridad, 0 menor).
-Ponemos el TXB*CON.TXREQ=1 para solicitar el envio.

*El mismo modulo se encarga de verificar que mensaje tiene mayor prioridad (TXPRI) y envia ese, es decir si llenamos los 3 buffers a la vez, ponemos a uno 0, al otro 1, y al otro 3, el modulo enviara primero el 0, luego 1 y luego 3...

Con todo esto nos olvidamos de tener que poner el while(!TXREQ); unicamente tendriamos que poner un control de errores (TXERR) para verificar que mensaje nos da error de envio, y decidir si abortarlo, dejarlo hasta que se envie... Eso ya al gusto del programador.

Ahora me preguntareis, que rollo tener que estar mirando si el TXB0 esta libre, luego el TXB1.... No hay problema, yo he hecho lo siguiente:
En la funcion de CAN INIT he declarado un array de punteros (global) donde se guarda la direccion de TXB0CON, TXB1CON, TXB2CON...
Ejemplo:
char *txcon[2];
txcon[0]=&TXB0CON; txcon[1]=&TXB1CON; ....
Unicamente tendriamos que poner un for con if(! (*txcon[ x] & 0b1000)) { entonces usamos ese buffer x... }

Ahora, vale muy bien, y como escribimos los filtros, DLC, ... sencillo:
Todos los buffers tienen su memoria por orden, es decir TXB0CON, TXB0SIDH, SIDL, EIDH, EIDL, DLC, D0, D1, D2.... D7.
Para escribir el dlc del buffer 2 por ejemplo seria:
*(txcon[2]+5)=dlc;
Para el D0:
*(txcon[2]+6)=data0;
Facil no? Para gente que sepa usar punteros sera muy sencillo.

Ahora, como se configuran los buffers "extras" que nos regalan microchip?, los buffers se llaman B0CON, B1CON.... B5CON
Tenemos un registro que se llama BSEL0 (mirar el datasheet para mas info). Para configurar por ejemplo el buffer 5 y 4 como TX seria:
BSEL0=0b11000000
de los bit (7:2) es el buffer 5 al 0; 1=TX, 0=RX.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 21 de Septiembre de 2011, 15:32:46
Bien, ahora que ya sabemos aprobechar los buffers de TX veamos como funcionan los de RX.

Yo como ODIO los programas bloqueantes, es decir los WHILE(hastaquenoseenvie);... Siempre he evitado al 100% esto, para un programa normal no pasa nada, pero para un programa bien desarrollado evitar los bloqueos del codigo siempre es lo ideal.
Con todo esto quiero decir que yo uso las INTERRUPCIONES que MICROCHIP nos ha dado xD.
Al margen de explicar las interrupciones como funcionan y tal, miramos el datasheet ya que es bastante largo de explicar. Para TX no he usado interrupciones ya que me da igual saber cuando se completa el envio o no. Pero si me interesa muchisimo saber cuando llega un mensaje.

Pues configurando el ECAN como modo 1 (modo no fifo), activando gieh... obtendremos la interrupcion RXBnIF (tal y como suena, la n es una 'n'), activando los bits del BIE0 (mirar datasheet) para activar las interrupciones...

Cada vez que recibamos un mensaje en el CAN el codigo nos enviara al punto de interrupcion (0x08 o 0x18 segun prioridades).

Cosas a tener en cuenta:
*Es importante limpiar el RXFUL del buffer del cual recibamos el mensaje (ponerlo a 0), si no lo acemos la interrupcion se volvera a producir continuamente hasta que RXFUL sea 0.
*Limpiar el RXBnIF

Bien, imaginemos que recibimos 2 mensajes consecutivos (realmente es dificil hacer esto ya que al recibir 1 se activaria la interrupcion para atenderla, pero imaginemos que por ejemplo hemos desactivado el GIE para escribir en la EEPROM del pic, y en el momento de la escritura recibimos 2 mensajes.

Los mensajes iran a los buffers que esten libres es decir que tengan RXFUL=0, en caso de que todos esten ocupados se producira un error overflow (el que quiera saber mas, datasheet), de todas formas este error no causa ningun problema, unicamente se perderian los mensajes (se escribiria uno encima de otro o bien se ignora el ultimo).

Bien, llegamos a la interrupcion, despues de escribir la eeprom, y activar GIE el codigo nos tirara directamente a la interrupcion. Joder ahora tenemos 2 buffers, como se cual de los X es el que tiene los mensajes??

Para eso tenemos el registro CANSTAT:ICODE bits < 3:1>, este registro nos dice que buffer nos ha activado la interrupcion, desconozco cual de los buffers seria el primero en mostrarlo en el ICODE, supongo que el primero en recibirlo.

el ICODE tiene muchas convinaciones, segun modo 1 y 2. Por lo cual al datasheet y veis que significa cada convinacion, en nuestro caso diremos que se activaron el buffer 0 y 1, osea el ICODE sera 0b10000.
*Leemos el dlc, filtro si es necesario, datos... todo lo que necesitemos
*PONEMOS EL RXFUL=0.
*Salimos de la interrupcion (como normalmente) (RXBnIF=0).

Joer y ahora que pasa con el otro mensaje?? Pues nada, como dije antes hasta que todos los RXFUL no sean 0 (de todos los buffers configurados) se volvera a la interrupcion una y otra vez, por lo cual el codigo volvera al inicio de la interrupcion. Ahora el ICODE nos apuntara al buffer que no haya sido leido, en este caso el buffer 1, osea ICODE=0b10001.
*Leemos todo lo que queramos
*PONEMOS RXFUL del buffer 1 a 0.
*Salimos.

Con todo esto nos aseguramos de que cuando recibamos un buffer tengamos un buffer disponible para otro mensaje, asi tendriamos una cola de mensajes a la espera de procesarlos.
Para manejar los buffers se puede hacer el mismo sistema de punteros que en el envio, todo es cuestion de como querais hacerlo.
Para manejar los buffers adicionales, igual que antes BSEL0, ponemos los bits a 0 para los buffers que queramos recepcion, y usamos los B*CON que hayamos puesto como recepcion.

Cosa importante que me he dado cuenta:
*En modo 1 ECAN los filtros se asignan por buffer, es decir el filtro1 lo asignas al buffer 1, el filtro 2 al buffer 2... segun quieras
*Para que funcione el modo sin asignar filtros a buffers es necesario configurarlo en modo 2, FIFO, asi se usan los filtros pero se ignora la asignacion de buffer por filtro
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 22 de Septiembre de 2011, 01:41:14
Muy interesante MerLiNz, gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Septiembre de 2011, 08:46:43
Perfecto!!
Ya le puse links en la primera pagina del hilo.   ;-) ;-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 22 de Septiembre de 2011, 10:24:43
jeje, gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: micronet3 en 23 de Septiembre de 2011, 11:52:20
hola, he estado investigando sobre el bus can, he visto que hay TRANSCEPTORES, CONTROLADORES Y EXPANSORES
ya he entendido algo, pero seria bueno que alguien ducho nos explique con toda claridad la diferencias que hay entre ellos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Septiembre de 2011, 11:59:52
Aqui se vio el tema de los expansores.

Expansores CAN (http://www.todopic.com.ar/foros/index.php?topic=19182.msg300501#msg300501)

Luego hay PICs que tienen modulo CAN incorporado y controladores CAN (mcp2515) que pueden darle conectividad CAN a un PIC que no tiene ese modulo incorporado, usando conexión SPI.

Los transceptores son los que realmente conectan al BUS CAN y deben ser utilizados por TODOS los dispositivos anteriores.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: micronet3 en 23 de Septiembre de 2011, 12:02:00
seria algo asi    (controlador<====>transceptor)<==========bus can==========>(transceptor<====>expansor)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 23 de Septiembre de 2011, 12:39:54
si, asi es, el transceptor por asi decirlo es el enlace entre el bus del can, y el dispositivo (pic, expansor...).

juas, no sabia que existiesen los "expansores" he estado mirando el datasheet y parece muy interesante, para cosas simples, por ejemplo donde quieres activar o desactivar una bombilla, o leer el estado de voltaje (ADC).
Yo creia que era unicamente un dispositivo que funcionaba con mensajes can, pero no, por lo visto tambien se puede programar como un pic!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Septiembre de 2011, 13:36:41
En la placa experimental que hice y muestro en este mismo hilo (si lo leyeron habran visto el esquematico) tengo dos nodos expansores, un nodo que puede ser con un PIC sin CAN asociado a un controlador CAN externo (mcp2515) o usando un PIC con CAN y por ultimo un Nodo con display y teclado para usarlo en analisis de tramas, etc.
Si bien es una sola placa, puede ser troquelada y dividirla en 4 nodos diferentes.
Alli, uno de los expansores, tiene la posibilidad de conectarse al programador y bajarle el programa.
Esa programacion la hice con el ICDS de CCS, que es el unico programador no hecho por Microchip que lo soporta, incluso varios de los conocidos de Microchip tampoco lo soportan.
Si bien el dispositivo puede ser configurado a traves de instrucciones por mensajeria CAN, el Id del nodo y la configuracion de velocidad y otros temas deben ser realizadas a traves del programador.

Un detalle importante:
Estos dispositivos son OTP, si uno pifia la primer programacion, solo Dios sabe como se pueden acceder despues, aunque no lo crean, en tres pruebas solo tire uno, eso si, tengo la costumbre de doblar las patillas para no pincharse con ellas al manipular la basura... :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 23 de Septiembre de 2011, 13:51:16
pues si, segun pone el mplab el icd3 que me costo casi 200€ no me vale  :5] lo unico que he visto es que usa un ICSP por lo cual nose si se podria o no, pero segun mplab no.

A que te refieres con OTP? Una sola programacion? Es decir, que si escribes una vez ya no puedes volver a escribirlo?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Septiembre de 2011, 14:13:29
One Time Programming.
Esta tecnologia teniamos antes que aparecieran los micros con memoria flash.
Mas de una vez habia que doblarle las patillas a uno para tirarlo, je..je.. :mrgreen: :mrgreen:
Para poder desarrollar había que comprar los micros con ventana de borrado y disponer de una lampara ultravioleta para poder borrarlo y después poder re grabarlo nuevamente.
A veces en un día podías hacer unos 15 cambios y posterior prueba de software antes que el tedioso proceso te agotara.

Disfruten de esta época dichosa, donde puedes grabar 15 veces por hora sin sacar el PIC del circuito siquiera, ademas de poder usar el debugger que ahorra cientos de horas de programación!!

El proceso:

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 23 de Septiembre de 2011, 14:50:12
si, yo uso eproms de esas de la ventanita para una centralita la cual la requiere, en concreto son las eprom 27128. Tengo el aparato de UV para borrarlos tambien.

Entonces el expansor una vez le escribes ya no puedes modificarlo no? Ni borrarlo de alguna manera tampoco no?? Un poco "obsoleto" me parece jeje. Aunque no son muchas configuraciones pero para desarrollar viene bien poder borrar y escribir.

Algun expansor de otra marca aunque sea que permita indefinidas escrituras? xD

A pesar de que un expansor sea justo lo que necesito para un 3er modulo, me echa mucho para atras el tema del OTP y que haya que pillarse otro programador.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Septiembre de 2011, 15:18:29
Pon can io expander en tu buscador y veras las alternativas a un dispositivo de estos que hay...

Ninguna !!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 29 de Septiembre de 2011, 00:55:04
Hola buenas noches tengo una consulta, si tengo un nod el cual tiene entre la linea canH una resistencia de 60ohm y entre la linea CANL otra resistencia de 60  ohm ambas derivadas a masa en ttal suman 120 ohm mi duda es la siguiente si deseo conectar un nodo a este otro nodo mensionado debo colocar tambien resitencia terminal en este nuevoi nodo o ya con las resistencias existente el nodo en funcionamiento ya es mas que necesario.

Saludos y espero su gentil ayuda.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 29 de Septiembre de 2011, 07:21:14
las resistencias se colocan entre canh y canl, en ambos finales, y son de 120ohm ya que al estar en paralelo son 60ohm. A que te refieres de derivadas a masa?

(http://www.scielo.org.ar/img/revistas/laar/v35n2/2a10g90.gif)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 29 de Septiembre de 2011, 08:27:41
las resistencias se colocan entre canh y canl, en ambos finales, y son de 120ohm ya que al estar en paralelo son 60ohm. A que te refieres de derivadas a masa?

(http://www.scielo.org.ar/img/revistas/laar/v35n2/2a10g90.gif)

ok gracias amigo entendido entonce solo van las mresistencias terminal en el par trenzado y los nodos que se conecten a  ese par trenzado ya no es necesario la resistencia terminal.

Hago mis pruebas y les comento.

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Septiembre de 2011, 08:40:22
Hay configuraciones como las que dice astrocar, donde se conectan dos resistencias en serie de 60Ohm entre CanH y CanL, y el punto medio a masa, esto se hace para asegurarse que el par balanceado tenga la referencia de masa exactamente al centro de la señal diferencial, con este metodo se solucionan de antemano muchos problemas ocurridos cuando en un nodo en particular se eleva la tension de masa y luego no interpreta el modulo CAN los mensajes que llegan a el.

No tengo un lindo dibujito pero creo que pueden imaginarse el conexionado segun mi descripcion. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 29 de Septiembre de 2011, 14:27:56
Hay configuraciones como las que dice astrocar, donde se conectan dos resistencias en serie de 60Ohm entre CanH y CanL, y el punto medio a masa, esto se hace para asegurarse que el par balanceado tenga la referencia de masa exactamente al centro de la señal diferencial, con este metodo se solucionan de antemano muchos problemas ocurridos cuando en un nodo en particular se eleva la tension de masa y luego no interpreta el modulo CAN los mensajes que llegan a el.

No tengo un lindo dibujito pero creo que pueden imaginarse el conexionado segun mi descripcion. :mrgreen:

ok gracias por tus palabras explicativas hermano voy a tratar de monitores el can con mi interface para ver que resulta pero tenia la duda si a mi nodo monitor can colocarle resistencia terminal si o no.

Saludos y les informo tan proto tenga la conclusion de mis pruebas.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 29 de Septiembre de 2011, 18:11:51
Yo compro habitualmente en RS y Digikey. Esporádicamente también en Mouser o Farnell.


Gracias por la información, no las conocía.

Saludos a todos... y, aunque no escriba, os sigo de cuando en cuando....
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 07 de Octubre de 2011, 20:04:53
bueno, pues hoy me han llegado unos conectores y los he colocado para la mejor conexion entre bus can y alimentacion, esta curioso eh? xD
-¿CAN FRIT AL APARATO EN QUE PUEDO AYUDARLE?
Suerte que me dio por mirar la conexion del cable, porque los cables estan cruzados, si lo hubiese conectado seguramente habria tenido una preciosa barbacoa xD
(http://img143.imageshack.us/img143/5733/07102011158.jpg)
(http://img412.imageshack.us/img412/1664/07102011159.jpg)

otra cosa que me di cuenta es que el transceptor produce ruidos en la alimentacion, le puse el osciloscopio al + y GND de la placa y la señal del can se podia ver en la alimentacion en torno a 10mV, para probar le puse un condensador de 10uF y lo seguia haciendo pero muy muy poco, es decir en torno a 0.5mV (ruido normal que suele tener).
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 09 de Octubre de 2011, 17:19:22
Hola MerLinz,

La verdad es que te quedan las placas muy limpias y ordenadas.... igualito que las mías.....

Quería preguntarte por el módulo que hay a la izquierda pinchado y que parece para conectar todo el bus a ethernet (el que tienes montado en vertical).

Y los Zócalos para los pics, donde los has conseguido?, yo no los suelo usar, vamos que no tengo, pero es verdad que son muy cómodos cuando tienes que reprogramar varias veces los pics.

Saludos,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Octubre de 2011, 19:38:57
eso es un rj11 tambien, es para programar mediante el icd3, unicamente es un rj11 pinchado a los pines, si ves fotos anteriores de las placas veras a que me refiero. Lo utilizo para programar en ICSP con el icd3, antes lo ussaba con el pickit3 pero como murio me pille el icd3.
(http://www.designspark.com/files/ds/imagepicker/61/thumbs/RJ-11%20to%20ICSP%20Adapter.jpg)

Por arriba si se ven muy limpias, pero por abajo, puff vaya lio de cables que tiene xD espero en un futuro hacerme una PCB insolada, pero mientras tanto, con esto me va perfecto para diseñar.

Realmente no tengo la necesidad de quitar el pic para programarlo, unicamente enchufo el icd3 le doy a programar y yasta :D. Pero si el zocalo se lo puse por la comodidad, si quiero cambiar de pic, y como tengo por aqui varios zocalos de este tipo pues los use.
Recuerdo que me lo pille por ebay, varios de ellos, tambien recuerdo que no eran muy baratos (mas de 1€ por unidad), te pongo la busqueda por si te interesa:
http://www.ebay.es/sch/i.html?rt=nc&LH_PrefLoc=2&_nkw=zif%2040%20pin&_fln=1&_trksid=p3286.c0.m283

si los quieres para aplicaciones normales pillate los chinos, si lo quieres para algo bueno pillate de marca 3M que vienen con contactos en oro y demas, son bastante carillos, pero para una aplicacion final es lo mejor para evitar problemas.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: handpic en 10 de Octubre de 2011, 18:29:47
Gracias MerLinz por el enlace,

La verdad es que he de comprar un par de ellos. Tengo placas de prototipos como la picSchool y a veces me da la sensación de que los zócalos me fallan.

Un saludo,
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 11 de Octubre de 2011, 17:47:36
Bueno pues voy a dedicarme a hacer un bootloader para can, he visto que hay algunos por ahi, pero yo soy de los de hacer mis propias cosas  ;-)

ahora tengo una duda, los filtros solo se pueden poner en el modo configuracion del modulo can no?? Lo que quiero hacer es cuando se requiera el modo bootloader desactivar todos los filtros y activar un filtro unicamente el cual recibira los datos para el bootloader. A pesar de que los filtros solo se puedan poner en el can-config es posible cambiar el valor de estos? Es decir si tengo el filtro0 a 0xAA se puede cambiar editando el registro? Sin tener que entrar en modo config?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Octubre de 2011, 08:45:28
Los únicos registros que no son aconsejables de cambiar son los que hacen a la selección de velocidad del Bus.
El resto se puede re-configurar a gusto sin problemas, en todo caso si quedan mal configurados tendrás problemas para comunicarte o perderás comunicación con algunos nodos, pero de ahí no pasa.
Posiblemente antes de re-configurar los registros sea necesario desactivar el modulo can y luego volver a activarlo, solo por prolijidad.

Incluso la velocidad debería poder configurarse, sino como explicas que hoy existen módulos que detectan la velocidad del Bus y se auto programan a esa velocidad??
Pero ese es un tema muy fino, no digo que sea imposible para nosotros, pero por lo menos bastante complejo.
En esos buses el único que no permite autobaud es el nodo que oficia de Maestro del bus, a ese hay que configurarlo manualmente.

En todos los elementos que conozco la velocidad por defecto es de 125 KBPS, si usas librerías de Microchip, CCS, Mikroe u otras veras que todas configuran el bus asi.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 14 de Octubre de 2011, 17:01:11
bueno, despues de 2 largos dias haciendo el software pc y el software del pic al fin lo he conseguido, unicamente me queda implementarlo para CAN y ponerle unas cosillas mas como verificacion de datos.
Ya he hecho pruebas y graba perfectamente la .hex, la verdad es que ha sido un lio, porque este pic se programa por sectores de 64bytes, pero despues de muchas pruebas y lios ya lo hace correctamente.

aqui la placa que se encargara de la programacion por CAN, pc->usart->CAN ademas para que no quede tan sencilla le metere una memoria SPI para la deteccion y almacenamiento de errores, asi se podra consultar los errores en comunicacion, y en las placas que les he puesto deteccion de errores.
(http://img822.imageshack.us/img822/3484/14102011161k.jpg)

Aqui el software (no veas que trabajito aprender el C++.NET), intente en C# pero demasiado lioso como para ponerme ahora a volverlo a aprender.
(http://img828.imageshack.us/img828/4697/softbootloader.png)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Octubre de 2011, 17:05:21
EHH!!

Estas haciendo un bootloader Can ??

Me interesa, me interesa, de los pies a la cabeza !!!   :-/ :-/ :-/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 14 de Octubre de 2011, 17:14:58
asi es, te imaginas, programar 5 pics (5 placas) con un solo click de raton?? xD usando unicamente un rs232, o en un futuro pienso ponerle el ft232 para USB.

No es dificil, una vez he entendido como funciona un bootloader, como se programa la flash, y etc... Unicamente es implementarlo para que los datos se lean por CAN en vez de por USART.

Aun asi, me ha sido dificil aprender a programar la flash, porque no he encontrado ningun tutorial, ni ningun ejemplo claro, a base de leerme el datasheet mil veces, y de ver los bootloaders de microchip he sacado algo claro. Al igual que leer el .hex, no es tan sencillo, el  primer byte despues de cada : es el tamaño, los 2 bytes siguientes la direccion de memoria, el siguiente el tipo (memoria, desplazamiento...)

Lo unico que no he encontrado son LOS FUSES, no se donde se guardan porque en el .hex no los he encontrado, en otros .hex viejos he visto que se direcciona a la memoria 300000+ y luego se graba los fuses, pero en este .hex no viene nada de eso.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Octubre de 2011, 18:58:49
Hay una nota de aplicación de Microchip de un bootloader Can, pero no entiendo como diferencia una placa en el bus...
Si hay que desconectarlo, vale la pena ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 14 de Octubre de 2011, 19:40:06
Eso ya es tu cabeza la que debe hacerlo  :lol:

Para diferenciarlo pues le pones un SID especifico por cada placa, mi sistema trabaja de la siguiente manera, los 4 bits altos indican una funcion, y los restantes indican una subfuncion.

Ejemplo para entenderlo mejor:

0xF = bootloader
0x01 = placa 1
0x00 = placa 0
0x02 = placa 2

la placa que viste en la foto con el max232 enviaria el SID 0xF01 para programar la placa 1, 0xF02 para la placa 2...., cada placa tiene su filtro (aunque tambien puedes poner un if(SID==0xF01)) la placa 1 solo lee el 0xF01 en caso de que se quiera programar la 2 se enviaria 0xF02 por lo cual las demas placas ignorarian esa peticion y solo la reconoceria la placa 2.

Ahora los datos, por ejemplo el D0 indica si es una trama de datos, o una trama de funcion, es decir, si mando 'W', es para que se escriba la flash, si mando 'R' esa placa me envia los datos que pido... Aparte tambien lo puedes hacer por orden.

placa232 envia 'B' SID=0xF01, placa 1 se configura en modo bootloader y envia 'O' para confirmar que ha pasado a ese estado.
placa232 envia 'A' + direccion, para indicar la direccion a escribir, placa 1 le responde 'F' para confirmar que ha recibido la direccion... Y asi consecutivamente hasta que se programe.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Octubre de 2011, 21:41:36
Supongo que al final haces resetear el micro, una vez programado, asi carga el nuevo firmware, no??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 14 de Octubre de 2011, 22:04:13
no es necesario hacerlo, lo unico que no se puede es acceder a la memoria la cual esta siendo programada, bueno si se puede pero son todos NOP. Aun asi cuando cargas un nuevo firmware es para añadir o corregir algo, por lo cual lo ideal es resetearlo para que se cargen nuevos parametros, funciones...

Para ello le tengo puesto que al final de la programacion envie una 'X', y este hace un _asm RESET _endasm, lo que es un reset por software.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 17 de Octubre de 2011, 11:40:44
Bueno ya esta terminado, solo me queda probar xD es que estoy esperando unos conectores rj11 ya que los que pedi eran 4p4c y no sirven para los cables normales de telefono, por lo cual me pille unos cuantos 6p4c, unos cuantos conectores, y la herramienta para hacerme mi propio cable, y no quiero conectarlo hasta tenerlo para no hacer chapuzas xD

Pero resumo como va mi bootloader can para que os hagais una idea:

*pc envia modo bootloader->rs232->can envia el mensaje con el SID correcto.
*placa desactiva el modulo can y lo reconfigura para solo recibir datos de bootloader (filtro)->ademas responde cuando ha terminado de configurar el modulo
*rs232 envia direccion a grabar->placa can le responde
*rs232 envia datos mediante can->placa le responde cuando reciba todos los datos
*rs232 envia verificacion->placa le devuelve todos los datos que ha recibido->rs232 compara los datos con los reales->si esta OK envia escribir
*vuelve al paso de envio de direccion, hasta que termina de enviar todos los datos.
*rs232 le envia un dato para que se resetee, reset y completo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Suky en 17 de Octubre de 2011, 11:49:45
Hola, una consulta, la verificación se hace con los datos recibidos o con los datos leídos desde la memoria de programa? Los bootloader de Microchip (el que estudie) realizan la recepción de datos (Como es por USB y éste tiene su CRC no controlan el CheckSum), graban y después leen la memoria de programa para la verificación.


Saludos!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 17 de Octubre de 2011, 12:31:37
con los de la memoria recibida, yo pienso que si los datos se reciben correctamente luego en el flash tambien se escribiran tal y como estan en el buffer, he pensado como tu dices a leer los datos de la flash una vez escritos y compararlos, pero es mas probable que se reciban los datos erroneamente que se escriban erroneamente. Aun asi no es dificil implementar la lectura de la flash para la verificacion, unicamente seria leer, guardar en un buffer, y enviarlos para compararlos.

Aunque tambien, si sabemos que los datos del buffer estan bien (comparados correctamente) unicamente es cuestion de hacer una comparacion del buffer con la flash, si esta bien, adelante, si no que envie error de grabacion.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Juarmeve en 26 de Octubre de 2011, 11:40:57
Hola a todos! Estuve leyendo el foro y esta muy bueno. Felicitaciones, se nota que saben mucho sobre el tema.
Estoy empezando con el CAN, estoy usando MikroC para programar el PIC 18F4680. No entiendo el tema de las banderas CAN_CONFIG_FLAGS . Si alguien podria explicarme por favor.
Por ejemplo en la seccion de ayuda de mikroC hay un ejemplo de utilizacion de las banderas  CAN_CONFIG_FLAGS que lo utiliza con la libreria CANInitialize. Que hace ahi? Entiendo mas o menos los parametros SJW, BRP, PHSEG1,PHSEG2,PROPSEG pero no las banderas.

init = _CAN_CONFIG_SAMPLE_THRICE &
       _CAN_CONFIG_PHSEG2_PRG_ON &
       _CAN_CONFIG_STD_MSG       &
       _CAN_CONFIG_DBL_BUFFER_ON &
       _CAN_CONFIG_VALID_XTD_MSG &
       _CAN_CONFIG_LINE_FILTER_OFF;

CANInitialize(1, 1, 3, 3, 1, init);   // initialize CAN

Agradeceria si alguien pudiese ayudarme.

Saludos a todos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 26 de Octubre de 2011, 12:04:36
eso es para la configuracion de velocidad del CAN, muestreo...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Juarmeve en 26 de Octubre de 2011, 14:10:38
eso es para la configuracion de velocidad del CAN, muestreo...
Podrias ser mas especifico por favor. Cual es la funcion de cada una de las banderas citadas en le mensaje anterior?

Gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 26 de Octubre de 2011, 14:27:17
_CAN_CONFIG_SAMPLE_THRICE =
_CAN_CONFIG_PHSEG2_PRG_ON
_CAN_CONFIG_STD_MSG
_CAN_CONFIG_DBL_BUFFER_ON = doble buffer on
_CAN_CONFIG_VALID_XTD_MSG = solo aceptar mensajes extendidos validos
_CAN_CONFIG_LINE_FILTER_OFF= filtros desactivados

mas no te puedo ayudar porque para ello deberias entender bien la configuracion.
Aqui tienes mas info:
http://www.joinville.ifsc.edu.br/~nivaldo/Microcontroladores/ling_c/mikroc_manual.pdf


Ahi puedes ver que significa cada uno, y ademas ver que bit modifica cada funcion, con el datasheet delante puedes ver que es cada cosa.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Octubre de 2011, 13:22:49
Hola a todos! Estuve leyendo el foro y esta muy bueno. Felicitaciones, se nota que saben mucho sobre el tema.
Estoy empezando con el CAN, estoy usando MikroC para programar el PIC 18F4680. No entiendo el tema de las banderas CAN_CONFIG_FLAGS . Si alguien podria explicarme por favor.
Por ejemplo en la seccion de ayuda de mikroC hay un ejemplo de utilizacion de las banderas  CAN_CONFIG_FLAGS que lo utiliza con la libreria CANInitialize. Que hace ahi? Entiendo mas o menos los parametros SJW, BRP, PHSEG1,PHSEG2,PROPSEG pero no las banderas.

init = _CAN_CONFIG_SAMPLE_THRICE &
       _CAN_CONFIG_PHSEG2_PRG_ON &
       _CAN_CONFIG_STD_MSG       &
       _CAN_CONFIG_DBL_BUFFER_ON &
       _CAN_CONFIG_VALID_XTD_MSG &
       _CAN_CONFIG_LINE_FILTER_OFF;

CANInitialize(1, 1, 3, 3, 1, init);   // initialize CAN

Agradeceria si alguien pudiese ayudarme.

Saludos a todos.


Si miras la pagina 250 del manual que te dejo Merlinz, encontraras los diferentes valores que pueden tomar esas variables, y que bits de configuracion cambia en cada opcion.
Luego vas a la hoja de datos del PIC utilizado y miras en ese registro, que hace cada bit asi entiendes bien que esta haciendo la configuracion utilizada.

Este es un paso MUY importante (entender que hace cada instruccion que vas a utilizar) para empezar a programar en CAN.

Citar
const char
_CAN_CONFIG_DEFAULT = 0xFF, // 11111111
_CAN_CONFIG_PHSEG2_PRG_BIT = 0x01,
_CAN_CONFIG_PHSEG2_PRG_ON = 0xFF, // XXXXXXX1
_CAN_CONFIG_PHSEG2_PRG_OFF = 0xFE, // XXXXXXX0
_CAN_CONFIG_LINE_FILTER_BIT = 0x02,
_CAN_CONFIG_LINE_FILTER_ON = 0xFF, // XXXXXX1X
_CAN_CONFIG_LINE_FILTER_OFF = 0xFD, // XXXXXX0X
_CAN_CONFIG_SAMPLE_BIT = 0x04,
_CAN_CONFIG_SAMPLE_ONCE = 0xFF, // XXXXX1XX
_CAN_CONFIG_SAMPLE_THRICE = 0xFB, // XXXXX0XX
_CAN_CONFIG_MSG_TYPE_BIT = 0x08,
_CAN_CONFIG_STD_MSG = 0xFF, // XXXX1XXX
_CAN_CONFIG_XTD_MSG = 0xF7, // XXXX0XXX
_CAN_CONFIG_DBL_BUFFER_BIT = 0x10,
_CAN_CONFIG_DBL_BUFFER_ON = 0xFF, // XXX1XXXX
_CAN_CONFIG_DBL_BUFFER_OFF = 0xEF, // XXX0XXXX
_CAN_CONFIG_MSG_BITS = 0x60,
_CAN_CONFIG_ALL_MSG = 0xFF, // X11XXXXX
_CAN_CONFIG_VALID_XTD_MSG = 0xDF, // X10XXXXX
_CAN_CONFIG_VALID_STD_MSG = 0xBF, // X01XXXXX
_CAN_CONFIG_ALL_VALID_MSG = 0x9F; // X00XXXXX

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 30 de Octubre de 2011, 15:18:50
Bueno ya esta el bootloader CAN listo, probado y recomprobado, funciona perfectamente!!

(http://img220.imageshack.us/img220/4410/26102011163.jpg)
(http://img403.imageshack.us/img403/6724/soft.png)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Octubre de 2011, 15:23:00
Si pudieras desarrollarnos mas el tema, seria muy bueno.
Felicitaciones!!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 30 de Octubre de 2011, 15:40:42
Bueno, lo explico asi por encima, porque el codigo esta mezclado con el codigo general y seria dificil entenderlo sin entender el codigo anterior xD

Lo primero es la placa 1, esta conectada al pc por rs232 (uart), esta es la que se encarga de comunicar el soft del PC con la placa deseada de CAN mediante CAN.

El soft envia a la placa1 que quiere poner en modo bootloader a la placa 2 (uctrl), la placa 2 configura el CAN para solo aceptar (filtros) mensajes dedicados al bootloader, los demas mensajes los ignora, yo en mi caso identifico los mensajes segun placas para que al recibir el mensaje "modo bootloader" esta lo compara con el numero de placa, si es esta la coloca en modo bootloader, si no lo ignora.

Una vez la placa2 esta en modo bootloader, envia un mensaje (can) a la placa 1 para decir que se ha configurao y que ha aceptado el modo bootloader. La placa1 lo envia al PC.
Ahora llega el momento de enviar datos, lo primero decir que el soft se encarga de leer el .hex y pasarlo a almacenarlo en la ram del PC.

*El pc envia primero la direccion (ADDR) de la memoria que quiere modificar en el PIC, tambien el tamaño del buffer.  Luego la placa1 lo envia a la placa2 (can). La placa2 responde como que ha recibido bien la ADDR.
*Ahora el pc envia el buffer a la placa1, esta la envia a la placa2 (can).
*La placa2 confirma que le han llegado todos los datos.
*El pc envia un dato para la verificacion.
*La placa2 le envia todo el buffer a la placa1, y la placa1 al pc. El soft del pc se encarga de verificar los datos que reciben son iguales a los que tiene en su buffer. Si todo esta correcto manda un dato para escribir los datos en la flash.
*La placa2 escribe los datos, y compara los datos escritos con el buffer, si todo esta ok envia ok, si no envia error.
Tanto en la verificacion como en la comparacion de datos, si los datos estan mal se vuelve a ir al paso de enviar la direccion.

Y asi constantemente hasta que se llega al final del .hex, los datos se envian de 64 en 64bytes, ya que mi pic acepta la escritura de sectores por 64bytes (otros aceptan solo 32bytes o menos, mirar datasheet).

Una vez llega al final, el pc envia un comando para resetear la placa2, esta se resetea, y a su vez la placa1 sale del modo programacion y sigue haciendo su trabajo con normalidad.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Octubre de 2011, 15:50:35
Que uso le vas a dar al sistema??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 30 de Octubre de 2011, 15:56:19
pues quizas en un futuro sea un producto para venderlo, por ahora es un proyecto que quiero hacer y llevo ya tiempo pensandolo, estara dedicado al automovil para hacer determinadas funciones, decir que he visto productos similares pero se venden sueltos, mi idea es unirlos todos para que ocupe menos espacio ademas de mejoras, y es un producto pensado para el futuro, osea con actualizaciones. Por eso al tener bootloader los clientes podran actualizarlo facilmente con un PC para corregir posibles fallos que tenga el software, y actualizaciones de diseño o bien futuras ampliaciones (ya que al estar conectado por CAN se le podra meter mas placas con simples adaptaciones del software.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 30 de Octubre de 2011, 15:57:12
Está genial MerLiNz, felicidades.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Octubre de 2011, 16:07:53
Coincido con Manolo, esta muy bueno!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 30 de Octubre de 2011, 18:24:24
gracias, no veas ahora que facil programar las placas sin tener que estar cambiando de placa el icd3 xD
Título: Como usar las interrupciones en el BUS CAN y CCS ??
Publicado por: MGLSOFT en 05 de Diciembre de 2011, 11:20:00
Alguien utilizo las interrupciones por CAN en CCS ??
Me refiero a recibir a través de #int_canrx0 y #int_canrx1.
Estoy intentando usarlas y no veo que me funcionen, como esperaba.

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 05 de Diciembre de 2011, 11:41:50
con C18 yo como explique si me funcionan perfectamente, pero para CCS no se como va bien.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Diciembre de 2011, 11:49:35
Igual me serviría conocer el código que usas, a ver como es el desarrollo, porque hasta ahora lo hacia por polling del status de los buffer...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 05 de Diciembre de 2011, 12:19:06
uhm, ahora que lo dices, tu usabas un pic con can integrado?? o por SPI?

bueno te pongo los registros que uso con el can integrado para las interrupciones, puede que varie a tu pic porke el que yo use es el 18f46k80

   IPR5bits.RXBnIP=0; //prioridad
   PIE5bits.RXBnIE=1; //enable IE
   INTCONbits.GIEH=1; //global enable
   RCONbits.IPEN=1; //prioridad enable
   BIE0=0b00011111; //buffers interrupcion (RX)(0,1,2,3,4,5)=enable los demas (TX) disable.

y ahora en la low_isr (funcion interrupcion):

   if(PIR5bits.RXBnIF) { //si esta activado el flag de RX buffer
      cBuf=CANSTATbits.EICODE; //cbuf=buffer el cual ha activado la interrupcion
//codigo aki
}  

creo que en principio eso es todo, si usas por SPI recuerdo que el chip te trae un pin de interrupcion o algo asi, segun lo configures si lo activas para que al recibir se active la interrupcion, este se pone en high o low (revisar datasheet), para el pic podias conectarlo a una interrupcion externa (INTx) y hacer la lectura por SPI y tal...

Todo el codigo anterior va por el ECAN, para el CAN normal creo que hay otras interrupciones para el buffer 0 y 1.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: dewasha en 05 de Diciembre de 2011, 12:25:33
alguien ha encontrado el firmware del elm327 o similar? me refiero en codigo abierto... si lo han clonado los chinos en un pic18f2550 deberia de andar por hay... mi adaptador usb-obd2 (elm327 compatible) es en realidad un pic 18f2455 y me parece raro que nadie tenga el archivo .hex con el codigo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: chispas en 10 de Enero de 2012, 15:07:41
Saludos.

Estoy intentando simular un circuito con los integrados mcp2551 y mcp2515 en isis de proteus, pero no los encuentro en las librerias. Pero he visto por aquí algún circuito que si los incluye ¿donde los encontrais o como tengo que añadirlos?.

Gracias!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Enero de 2012, 15:30:07
No conozco si hay simuladores que puedan simular CAN.
Lo que si se es que Proteus no lo simula, lo que has visto fue hecho por los usuarios solo porque usan el Ares para hacer el impreso, pero no para simularlo...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: chispas en 10 de Enero de 2012, 15:33:47
Ok, muchas gracias. El diseño ya lo tenía hecho a mano pero la verdad es que me vedría muy bien simularlo. Bueno, experimentaré en una board---
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 17 de Enero de 2012, 06:47:39
Ok, muchas gracias. El diseño ya lo tenía hecho a mano pero la verdad es que me vedría muy bien simularlo. Bueno, experimentaré en una board---

Hola buenos dias, en una oportunidad ya el tema fue tocado y de verdad es lastimoso que proteus no disponga de simulacion can bus, pero ya hablando del tema comoi haria para crear el integrado controlador y el transcepver para si hacer mis esquemas en proteus.

Saludos y estamos en linea.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Diego Gonzalez en 21 de Febrero de 2012, 11:59:36
Muy buenas a todos:

Me presento por este hilo, porque estoy empezando con el CAN. De momento solamente estoy fabricandome dos placas con el 18f26k80 y posteriormente con el hermano mayor 18f46k80. Todas con transceptores mcp2551. De momento es un prototipo pero aqui hay cientos de respuestas que leer antes de comenzar. Asique gracias por este hilo y un saludo a los aqui presentes.

(http://img213.imageshack.us/img213/3710/image00014i.jpg) (http://imageshack.us/photo/my-images/213/image00014i.jpg/)

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Febrero de 2012, 13:09:24
Bienvenido al barco !!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Diego Gonzalez en 21 de Febrero de 2012, 17:47:13
Hola de nuevo.
Solo me paso para añadir fotos de los dos "modulos sensores" Los espero conectar a una tarjeta maestra que leera los datos almacenados por los sensores conectados a estos modulos. (O eso pretendo en un principio  :lol:)

(http://img526.imageshack.us/img526/4613/image00016x.jpg)
Alimentado un modulo
(http://img715.imageshack.us/img715/5554/image00015gu.jpg)

saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Febrero de 2012, 20:57:59
Que es la barra negra al borde de la placa , arriba??
Es un puente de diodos??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Diego Gonzalez en 22 de Febrero de 2012, 01:58:03
Que es la barra negra al borde de la placa , arriba??
Es un puente de diodos??
Hola MGLSOFT, se trata del icsp jjeje, lo que pasa que al ponerlo cerca de los elementos de la alimentacion, si que parece un rectificador.
Sigo leyendo, aun me queda mucho para hacer algo decente jejej
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 07 de Marzo de 2012, 07:46:08
Hola!
 Primero enhorabuena por el pedadzo de tema!! jeje
   Me uno a la lista de los envidiososjeje y  tambien quiero probar esto tengo  varios 18f4685   y los tranceptores mcp2551  , mi duda me surje que  veo que los codigos cogen la  libreria  #include "can-18F4580.c",¿si yo tambien la pongo en mi codigo funcionara?o tengo que adaptarla para el 18f4685?¿
Gracias!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 07 de Marzo de 2012, 09:41:33
He probado y funciona! jjeje Probado con  un cable paralelo de 4 metros :)  cuando haga la placa la subire :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 07 de Marzo de 2012, 10:23:21
Mas rápido que el rayo!!
Estaba por contestarte que lo probaras, ya que los registros CAN son los mismo y deberia funcionarte OK, pero veo que llego tarde... por suerte..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 08 de Marzo de 2012, 00:48:45
Hola buenos noches, tengo una duda estoy monitoreando una red can que opera a 500kbps, la idea es poder ir viendo las trama de un determinado Id que previamente hago el filtrado para ese ID, por ejemplo ID=720hex, todo funciona, es decir, veo solo las tramas con ese ID lo que mi indica que mi filtrado esta perfecto el problema es que en el monitoreo que lo muestro por rs232 usando el terminar que incluye ccs no me muestra todos las tramas es decir son varias las que brinca y creo que  es por velocidad el puerto com lo configuro a 115200 pero de igual forma no veo toda la tramas que deberia. otro dato es que el monitoreo de can bus lo hago atraves de interrupcion es decir cada ves que entra una trama deberia mostrarmela.

Saludos y acepto todo tipo de opinion por pequeña que sea.
 
 

 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 08 de Marzo de 2012, 01:25:14
A que velocidad se reproducen las tramas de ese ID? Si superas el ancho de banda del rs232 problemente sea este tu problema, sobretodo si envias tipo "CAN ID: %h; DATOS: %h %h %h...." piensa que son 115kbits por segundo, osea 14kbyte/s a la cual habria que quitarle el bitstart y bitstop por lo cual seria menos aun. Si necesitas mas velocidad comprime los datos de modo trama, o bien USB.
Tambien puedes crear un buffer en el que se almacenen los datos y los vas enviando lo mas rapido que puedas, asi no tendrias perdidas a no ser que se llenase el buffer, pero si esa trama can se envia por ejemplo 3 veces en poco tiempo y luego tarda otro tiempo en volverlas a mandar te asegurarias de que no se pierde nada.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 08 de Marzo de 2012, 01:26:08
Para poder mostrar todas las tramas, al menos la velocidad del puerto serie deberia ser el doble que la del bus que estas leyendo.
En cambio estas leyendo a menos de 1/4 de esa velocidad, por lo tanto no es extraño que saltees tramas.
Respecto a las que lees por interrupcion, recuerda que si procesas toda la informacion dentro de la interrupcion, hasta que no sales no vuelve a activarse la misma, y segun que compilador utilizes, evitara la reentrada en la interrupcion hasta que salgas, ya que de otro modo seria un llamado recursivo que termina en un loop infinito y el pic resetearia antes por watchdog o se quedaria bobo si este no esta activo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 08 de Marzo de 2012, 07:00:33
Para poder mostrar todas las tramas, al menos la velocidad del puerto serie deberia ser el doble que la del bus que estas leyendo.
En cambio estas leyendo a menos de 1/4 de esa velocidad, por lo tanto no es extraño que saltees tramas.
Respecto a las que lees por interrupcion, recuerda que si procesas toda la informacion dentro de la interrupcion, hasta que no sales no vuelve a activarse la misma, y segun que compilador utilizes, evitara la reentrada en la interrupcion hasta que salgas, ya que de otro modo seria un llamado recursivo que termina en un loop infinito y el pic resetearia antes por watchdog o se quedaria bobo si este no esta activo.

ok entonce en mi caso es la velocidd del puerto ya que en la interrupcion solo leo la trama que esta presente y la mando a imprimir pero es como usted indica la velocidad del puerto serial es mucho mas pequeña que la velocidad del bus.
Ahora lo que se me ocurre es leer trama y guardar en un buffer y cuanto yo quiera mostrar todo lo leido se lo indico al micro y mando a imprimir dicho buffer el problema seria que nosela cantidad de trama que me pueda llegar, pero de igual forma hare un pequeño codigo de ejemplo para ver como me va.


Saludos y mil gracias por su opinion.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 08 de Marzo de 2012, 15:21:44
 Esto me esta gustando :evil: !!
 Hoy he probado 3 nodos separados entre ellos  por 4m, encienden y apagan led a distancia, mñn quiero probar algo mas , enviar arrays de datos. He usado 2 pic18f4685 y un 16f877 con su  controlador can MCP2515.
 He visto algunos esquemas y si he comprobado que la RS del MCP2551 si la ponemos directamente a GND se calienta  mucho y si ponemos un  valor grande no envia los datos, como no tenia de 10Ohm, con 100 va bien en esta distancia.

 Me gustaria usar un pic 18f4550  para poderme comunicar mediante  usb al ordenador, tendria que añadirle MCP2515 y tambien me gustaria crear un mini web para ver algunos parametros con el  adaptador
http://www.ebay.es/itm/280706213546?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649 

 ¿como lo veis?  es posible unir las dos cosas por spi no? Gracias! Mñn mas!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 08 de Marzo de 2012, 17:21:39
la RS se pone a GND cuando la velocidad es muy alta como 1Mbps, yo lo tengo asi y no se calienta apenas.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 08 de Marzo de 2012, 19:57:20
Pues entonces algo habra  ma , en mi circuito jeje!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 09 de Marzo de 2012, 18:08:43
 Buenas de nuevo..
 Esta tarde he empezado de nuevo hacer cosillas y  no me funciona... muy raro ayer estaba  perfecto.. lo unico que hice fue quiar los cable del bus can y esta mañana he estado  encendida las placas perono tenian el cable de comunicacion puesto... ¿los MCP2551 se han podido extropear? gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Marzo de 2012, 18:15:50
Muy difícil que ocurra algo así.
Debes haber puesto alguno invertido, o no tienes resistencias terminadoras del bus...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Marzo de 2012, 18:24:57
a mi se me han kemado muchos mcp2551, con un osciloscopio te das cuenta facil.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Marzo de 2012, 18:49:04
Yo solo recuerdo quemar uno por insertarlo al revés en el zócalo, luego no...
Y eso que llevo la alimentación de tensión a mi placa en la misma bornera del CAN, o sea tengo +V, CanH, CanL y -V, en ese orden en una bornera desenchufable que me permite alimentar y poner en red una placa sin mas que enchufar ese conector.
Hice muchas veces desconexiones de una placa en el bus sin que se note otra cosa que esa dejo de transmitir, y cuando la vuelvo a enchufar, vuelve a funcionar sin mas.
Eso es típico de CAN, bastante difícil de ver en otros buses de comunicación.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 09 de Marzo de 2012, 18:52:14
Pues uno de ellos no tenia puesta la resistencia y ha estado conectado mucho rato aunque no enviaba nada...  pues vaya entonces pedire unos poquitos mcp2551 por lo que pueda pasar. Lo del osciloscopio no tengo :(
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Marzo de 2012, 19:36:43
A mi ha pasado varias veces apagando una placa antes que la otra, osea a una le kito corriente y la otra la dejo encendida. Se puede comprobar porque el mcp2551 se pone a mucha temperatura. Desconozco porque pasa esto.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 09 de Marzo de 2012, 22:13:34
Puede ser..
En mi caso es imposible apagarlo sino lo desconectas del bus tambien... :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Diego Gonzalez en 10 de Marzo de 2012, 06:59:34
Hola a todos.

No se porque no funciona si es la cosa aparentemente mas sencilla del mundo

Código: [Seleccionar]
#include <18f46k80.h>  //archivo de cabecera
#fuses HSH,MCLR,NOWDT,NOPROTECT,NODEBUG,NOPLLEN,NOFCMEN// fuses  configurados
#use delay(clock=8M)     // Clock en la entrada CPU,Cristal externo 12Mhz*pll4=48Mhz OJO PLL enabled
#include <stdlib.h>
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7,bits=8)


#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>
void main(){

   int i;
   int out_data[8];
   int32 tx_id=24;
   int1 tx_rtr=0;
   int1 tx_ext=0;
   int tx_len=8;
   int tx_pri=3;

setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED|T1_DIV_BY_1);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);

   //inicialización del buffer
   for(i=0;i<8;i++) {
    out_data[i]=1;
   }
   can_init();

while(1){
delay_ms(1000);
i=can_putd(tx_id,out_data, tx_len,tx_pri,tx_ext,tx_rtr); //put data on transmit buffer
         if (i != 0xFF) { //success, a transmit buffer was open
            printf("\r\nPUT %U: ID=%LU LEN=%U ", i, tx_id, tx_len);
            printf("PRI=%U EXT=%U RTR=%U\r\n   DATA = ", tx_pri, tx_ext, tx_rtr);
            for (i=0;i<tx_len;i++) {printf("%X ",out_data[i]);}
            printf("\r\n");
         }
         else {printf("\r\nFAIL on PUTD\r\n");}
}
}//fin main

Estoy tratando de programar una placa para ver si el modulo CAN del pic se activa y envia señales a los pines del puerto B para monitoriarlo con el osciloscopio, pero nada, está muerto :S

Por otra parte el 18f46k80 tiene este pinout
(http://pinout-circuits-images.dz863.com/43/PIC18F66K80.jpg)

Y revisando la libreria ccs del can (can-18xxx8.c) en la funcion can_init() aparece al final como dispone los puertos
Código: [Seleccionar]
   set_tris_b((*0xF93 & 0xFB ) | 0x08);   //b3 is out, b2 is in
¿que podrá pasar?

un saludo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 10 de Marzo de 2012, 07:35:13
Confirmado! muerieron los mcp2551.... he encontrado otro y me ha funcionado , pero otra vez he apagado una placa antes que la otra y ha muerto....... uno o los dos.. asi que comprare  bastantes para seguir con mis pruebas.. jejee
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Marzo de 2012, 09:13:10
Diego:
Porque no revisas en la hoja de datos del PIC, que son las funciones adicionales que tienen los pines del CAN (B2 y B3) porque se ven muchas opciones, tal vez tengas que deshabilitar algún Fuse que en otros no existen, ademas en la parte de CAN es posible que encuentres como se configura en la hoja de datos...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Diego Gonzalez en 10 de Marzo de 2012, 10:43:12
Hola MGLSOFT

Al final era una aparente tonteria. Digo aparente porque si bien los transceptores del USART por ejemplo envian niveles TTL al transceptor max232 por ejemplo) parece que en CAN no, y el transceptor mcp2551 juega un papel activo entre el modulo ECAN del pic y el propio transceptor  (corregirme si me equivoco)

El caso es que ahora veo las tramas del bus CAN. He usado un pic18f26k80 para enviar continuamente un vector de 8bits que se incrementan cada 2 segundos. Puedo ver en el osciloscopio como las lineas CANL y CANH van funcionando, y se puede ver que envia correctamente puesto que los bits se van incrementando continuamente.

Por tanto ahora el problema esta en el nodo receptor. Un pic18f46k80+mcp2551 Voy a poner los codigos por si veis algo. Vuestro ojo esta mas entrenado que el mio con esto del CAN porque es la primera vez que lo uso jeje
Un saludo!1

Nodo Enviador: pic18f26k80+mcp2551. Pin23pic(cantx)->pin1mcp      Pin24pic(canrx)->Pin4mcp
Código: [Seleccionar]
#include <18f26k80.h>  //archivo de cabecera
#fuses HSH,MCLR,NOWDT,NOPROTECT,NODEBUG,NOPLLEN,NOFCMEN// fuses  configurados
#use delay(clock=8M)     // Clock en la entrada CPU,Cristal externo 12Mhz*pll4=48Mhz OJO PLL enabled
#include <stdlib.h>
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7,bits=8)


#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>

void main(){
can_init();


can_set_mode(CAN_OP_CONFIG);

BRGCON1.brp=9;
BRGCON1.sjw=0;
BRGCON2.prseg=2;
BRGCON2.seg1ph=5;
BRGCON2.sam=FALSE;
BRGCON2.seg2phts=FALSE; 
BRGCON3.seg2ph=5;
BRGCON3.wakfil=FALSE;

can_set_mode(CAN_OP_NORMAL);

   int i,value=0;
   int out_data[8];
   int32 tx_id=0;
   int1 tx_rtr=0;
   int1 tx_ext=1;
   int tx_len=8;
   int tx_pri=3;

setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED|T1_DIV_BY_1);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
   //inicialización del buffer
   for(i=0;i<8;i++) {
    out_data[i]=0;
   }

while(1){
for(i=0;i<8;i++) {
    out_data[i]=value;
   }
delay_ms(2000);
if(value>255){value=0;}else{value++;}
i=can_putd(tx_id,out_data, tx_len,tx_pri,tx_ext,tx_rtr); //put data on transmit buffer
         if (i != 0xFF) { //success, a transmit buffer was open
            printf("\r\nPUT %U: ID=%LU LEN=%U ", i, tx_id, tx_len);
            printf("PRI=%U EXT=%U RTR=%U\r\n   DATA = ", tx_pri, tx_ext, tx_rtr);
            for (i=0;i<tx_len;i++) {printf("%X ",out_data[i]);}
            printf("\r\n");
         }
         else {printf("\r\nFAIL on PUTD\r\n");}
}
}//fin main


Nodo Recptor: Pic18f46k80+mcp2551. Pin35pic(cantx)->pin1mcp      Pin36pic(canrx)->Pin4mcp
Código: [Seleccionar]
#include <18f46k80.h>  //archivo de cabecera
#fuses HSH,MCLR,NOWDT,NOPROTECT,NODEBUG,NOPLLEN,NOFCMEN// fuses  configurados
#use delay(clock=8M)     // Clock en la entrada CPU,Cristal externo 12Mhz*pll4=48Mhz OJO PLL enabled
#include <stdlib.h>
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7,bits=8)


#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>

void main(){
can_init();


can_set_mode(CAN_OP_CONFIG);

BRGCON1.brp=9;
BRGCON1.sjw=0;
BRGCON2.prseg=2;
BRGCON2.seg1ph=5;
BRGCON2.sam=FALSE;
BRGCON2.seg2phts=FALSE; 
BRGCON3.seg2ph=5;
BRGCON3.wakfil=FALSE;

can_set_mode(CAN_OP_NORMAL);

   int i,value=0;
  //Emisor (aunque no lo uso ahora
   int out_data[8];
   int32 tx_id=0;
   int1 tx_rtr=1;
   int1 tx_ext=0;
   int tx_len=8;
   int tx_pri=3;
   //Receptor
   struct rx_stat rxstat;
   int in_data[8];
   int rx_len;
   int32 rx_id;

setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED|T1_DIV_BY_1);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
   //inicialización del buffer
   for(i=0;i<8;i++) {
    in_data[i]=0;
   }
printf("Nodo receptor a la escucha...\r\n");
while(1){
if ( can_kbhit() )   //if data is waiting in buffer...
      {
         if(can_getd(rx_id, &in_data[0], rx_len, rxstat)) { //...then get data from buffer
            printf("\r\nGOT: BUFF=%U ID=%LU LEN=%U OVF=%U ", rxstat.buffer, rx_id, rx_len, rxstat.err_ovfl);
            printf("FILT=%U RTR=%U EXT=%U INV=%U", rxstat.filthit, rxstat.rtr, rxstat.ext, rxstat.inv);
            printf("\r\n    DATA = ");
            for (i=0;i<rx_len;i++) {
               printf("%X ",in_data[i]);
            }
            printf("\r\n");
         }
         else {
            printf("\r\nFAIL on GETD\r\n");
         }

      }
}
}//fin main


Gracias por la ayuda :P
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Diego Gonzalez en 10 de Marzo de 2012, 10:49:17
Parece que funciona!!

Unos simples problemas de HARDWARE. Podeis emplear el ejemplo de arriba que vale bien!!

(http://img402.imageshack.us/img402/4140/image00051n.jpg)

Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 04 de Abril de 2012, 20:08:20
 Esto parece que ya va funcionando jeje!!   Ya envio  datos  a traves de un programa hecho en c#   de un pic a otro unidos por  Can.. solo puedo enviar  como máximo  con  leng=9, si pongo  leng=10 no me  funciona esto es asi??

  can_putd(ID, &array, leng, priority, ext, rtr);

 Gracias!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Abril de 2012, 20:59:47
La cantidad maxima de bytes a enviar por un solo mensaje CAN es de 8 bytes, en realidad deberia darte error cuando pones 9 tambien...
Salvo que hayas definido a la variable array como un string y tome el ultimo byte como fin del string...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 04 de Abril de 2012, 22:13:32
Pues eso va a ser eso. . mi ultimo es un fin de cadena. Cuando te refieres a 8 byte, quieres decir que se pueden enviar hasta 8 datos de 8 bytes  no? Gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Abril de 2012, 23:11:05
No, son solo 8 bytes por mensaje, o sea que cada byte va de 0x00 a 0xFF en hexadecimal o de 0 a 255 en decimal.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 05 de Abril de 2012, 06:18:53
 Entonces no me cuadra, jejee en cada mensaje se manda  el ID(int32), y un array de 8 bytes, (por  lo que puedo enviar 8 datos de 8bit, es decir 8 int8), SIno es asi algo estoy haciendo  algo raro , por que yo desde el pc envio una trama de 8 char(unsigned int 8) cuando llega al micro ,este le añade   un ID y los envia todo este bloqque, y lo recibe otro pic con un lcd.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Abril de 2012, 08:25:51
Hola MGLSOFT

Al final era una aparente tonteria. Digo aparente porque si bien los transceptores del USART por ejemplo envian niveles TTL al transceptor max232 por ejemplo) parece que en CAN no, y el transceptor mcp2551 juega un papel activo entre el modulo ECAN del pic y el propio transceptor  (corregirme si me equivoco)

El caso es que ahora veo las tramas del bus CAN. He usado un pic18f26k80 para enviar continuamente un vector de 8bits que se incrementan cada 2 segundos. Puedo ver en el osciloscopio como las lineas CANL y CANH van funcionando, y se puede ver que envia correctamente puesto que los bits se van incrementando continuamente.

Por tanto ahora el problema esta en el nodo receptor. Un pic18f46k80+mcp2551 Voy a poner los codigos por si veis algo. Vuestro ojo esta mas entrenado que el mio con esto del CAN porque es la primera vez que lo uso jeje
Un saludo!1

Nodo Enviador: pic18f26k80+mcp2551. Pin23pic(cantx)->pin1mcp      Pin24pic(canrx)->Pin4mcp
Código: [Seleccionar]
#include <18f26k80.h>  //archivo de cabecera
#fuses HSH,MCLR,NOWDT,NOPROTECT,NODEBUG,NOPLLEN,NOFCMEN// fuses  configurados
#use delay(clock=8M)     // Clock en la entrada CPU,Cristal externo 12Mhz*pll4=48Mhz OJO PLL enabled
#include <stdlib.h>
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7,bits=8)


#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>

void main(){
can_init();


can_set_mode(CAN_OP_CONFIG);

BRGCON1.brp=9;
BRGCON1.sjw=0;
BRGCON2.prseg=2;
BRGCON2.seg1ph=5;
BRGCON2.sam=FALSE;
BRGCON2.seg2phts=FALSE; 
BRGCON3.seg2ph=5;
BRGCON3.wakfil=FALSE;

can_set_mode(CAN_OP_NORMAL);

   int i,value=0;
   int out_data[8];
   int32 tx_id=0;
   int1 tx_rtr=0;
   int1 tx_ext=1;
   int tx_len=8;
   int tx_pri=3;

setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED|T1_DIV_BY_1);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
   //inicialización del buffer
   for(i=0;i<8;i++) {
    out_data[i]=0;
   }

while(1){
for(i=0;i<8;i++) {
    out_data[i]=value;
   }
delay_ms(2000);
if(value>255){value=0;}else{value++;}
i=can_putd(tx_id,out_data, tx_len,tx_pri,tx_ext,tx_rtr); //put data on transmit buffer
         if (i != 0xFF) { //success, a transmit buffer was open
            printf("\r\nPUT %U: ID=%LU LEN=%U ", i, tx_id, tx_len);
            printf("PRI=%U EXT=%U RTR=%U\r\n   DATA = ", tx_pri, tx_ext, tx_rtr);
            for (i=0;i<tx_len;i++) {printf("%X ",out_data[i]);}
            printf("\r\n");
         }
         else {printf("\r\nFAIL on PUTD\r\n");}
}
}//fin main


Nodo Recptor: Pic18f46k80+mcp2551. Pin35pic(cantx)->pin1mcp      Pin36pic(canrx)->Pin4mcp
Código: [Seleccionar]
#include <18f46k80.h>  //archivo de cabecera
#fuses HSH,MCLR,NOWDT,NOPROTECT,NODEBUG,NOPLLEN,NOFCMEN// fuses  configurados
#use delay(clock=8M)     // Clock en la entrada CPU,Cristal externo 12Mhz*pll4=48Mhz OJO PLL enabled
#include <stdlib.h>
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7,bits=8)


#define CAN_USE_EXTENDED_ID FALSE
#include <can-18xxx8.c>

void main(){
can_init();


can_set_mode(CAN_OP_CONFIG);

BRGCON1.brp=9;
BRGCON1.sjw=0;
BRGCON2.prseg=2;
BRGCON2.seg1ph=5;
BRGCON2.sam=FALSE;
BRGCON2.seg2phts=FALSE; 
BRGCON3.seg2ph=5;
BRGCON3.wakfil=FALSE;

can_set_mode(CAN_OP_NORMAL);

   int i,value=0;
  //Emisor (aunque no lo uso ahora
   int out_data[8];
   int32 tx_id=0;
   int1 tx_rtr=1;
   int1 tx_ext=0;
   int tx_len=8;
   int tx_pri=3;
   //Receptor
   struct rx_stat rxstat;
   int in_data[8];
   int rx_len;
   int32 rx_id;

setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED|T1_DIV_BY_1);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
   //inicialización del buffer
   for(i=0;i<8;i++) {
    in_data[i]=0;
   }
printf("Nodo receptor a la escucha...\r\n");
while(1){
if ( can_kbhit() )   //if data is waiting in buffer...
      {
         if(can_getd(rx_id, &in_data[0], rx_len, rxstat)) { //...then get data from buffer
            printf("\r\nGOT: BUFF=%U ID=%LU LEN=%U OVF=%U ", rxstat.buffer, rx_id, rx_len, rxstat.err_ovfl);
            printf("FILT=%U RTR=%U EXT=%U INV=%U", rxstat.filthit, rxstat.rtr, rxstat.ext, rxstat.inv);
            printf("\r\n    DATA = ");
            for (i=0;i<rx_len;i++) {
               printf("%X ",in_data[i]);
            }
            printf("\r\n");
         }
         else {
            printf("\r\nFAIL on GETD\r\n");
         }

      }
}
}//fin main


Gracias por la ayuda :P

Porque declaras una frecuencia de reloj de 8 mhz en use_delay??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Abril de 2012, 10:21:43
Entonces no me cuadra, jejee en cada mensaje se manda  el ID(int32), y un array de 8 bytes, (por  lo que puedo enviar 8 datos de 8bit, es decir 8 int8), SIno es asi algo estoy haciendo  algo raro , por que yo desde el pc envio una trama de 8 char(unsigned int 8) cuando llega al micro ,este le añade   un ID y los envia todo este bloqque, y lo recibe otro pic con un lcd.

Esta bien entonces, el ID no cuenta como dato, solo es para saber quien emite el mensaje, o en un protocolo de alto nivel quien lo emite, que tipo de dispositivo es y que dato es el que envía...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 05 de Abril de 2012, 10:29:44
Entonces no me cuadra, jejee en cada mensaje se manda  el ID(int32), y un array de 8 bytes, (por  lo que puedo enviar 8 datos de 8bit, es decir 8 int8), SIno es asi algo estoy haciendo  algo raro , por que yo desde el pc envio una trama de 8 char(unsigned int 8) cuando llega al micro ,este le añade   un ID y los envia todo este bloqque, y lo recibe otro pic con un lcd.

Esta bien entonces, el ID no cuenta como dato, solo es para saber quien emite el mensaje, o en un protocolo de alto nivel quien lo emite, que tipo de dispositivo es y que dato es el que envía...
Ok ahora si! gracias!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: rotting79 en 15 de Abril de 2012, 15:42:26
Ok guys, here is my CAN Bus Board v1, to learn with.
and of course, it couldn't happen without all your help, thanxx to all of you.

Ok chicos, aquí está mi bus CAN Junta v1, para aprender con.
 y, por supuesto, no podía pasar sin su ayuda, Thanxx a todos ustedes.



(http://img208.imageshack.us/img208/1847/95615606.jpg)

(http://img23.imageshack.us/img23/9574/002kgu.jpg)

(http://img35.imageshack.us/img35/7105/003oic.jpg)http://www.flickr.com/photos/79258405@N07/7095107131/in/photostream
Título: Re: Mis experiencias con el BUS CAN
Publicado por: rotting79 en 15 de Abril de 2012, 15:44:57
here some more

aquí un poco más

(http://img407.imageshack.us/img407/7492/004oif.jpg)

(http://img100.imageshack.us/img100/1238/005ttz.jpg)

(http://img18.imageshack.us/img18/1274/006cpn.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: rotting79 en 15 de Abril de 2012, 15:48:02
and the test

y la prueba

and part of the schematic

y parte de la esquemática

(http://img20.imageshack.us/img20/3483/007fvjc.jpg)

(http://img15.imageshack.us/img15/315/canbus.jpg)

(http://img94.imageshack.us/img94/2573/canbus01.jpg)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 15 de Abril de 2012, 16:23:19
nice boards!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Abril de 2012, 19:50:15
Buenas placas!!
Pondras tu esquematico??
Y con que software programas??
A decir verdad me mareas un poco, ya que escribes en Ingles, traduces al español, en las fotos hay escrituras en ingles, portugues y aleman...
Cual es realmente tu idioma original??

Traducido con San Google Traductor...

Nice boards!
And thou shalt put your schematic?
And software programs that your boards?
Indeed tide me a little, as you write in English, translate it into Spanish, in the photos there are scriptures in English, Portuguese and German ...
What is really your original language?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: rotting79 en 15 de Abril de 2012, 21:12:51
Saint goggle?  good one......... but yes, i use it to traslate to spanish.
Portuguese and German? sorry but i don't speak those lenguages..... u may seen my coumputer pad under my PCB, and it comes with many warranties in many lenguages, u'd probably thought i speak corean or chinese also, wouldn't u? lol.

the only C compiler that i use is CCS, i'd like to learn some others, but man, i'm a old guy, from the old school, u know hard to change old habits.

i thought was a good idea post my work here, because was a good start, and i really think i'm going to learn much more from u guys.........

and of course, if anyone want the schematics, just let me know, and i will post them.

San gafas? bueno ......... pero sí, lo uso a traducir al español.
 Portugués y alemán? lo siento pero no me hablan los lenguajes ..... u puede ver mi libreta coumputer bajo mi PCB, y viene con muchas garantías en muchos lenguajes, u'd probablemente pensó que yo hable coreana o china también, no u? lol.

 el único compilador de C que yo uso es CCS, me gustaría aprender algunos otros, pero el hombre, soy un viejo, de la vieja escuela, tu sabes difícil cambiar viejos hábitos.

 me pareció una buena idea publicar mi trabajo aquí, porque fue un buen comienzo, y realmente creo que voy a aprender mucho más de u guys .........

 y, por supuesto, si alguien quiere los esquemas, sólo házmelo saber, y las pondré.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: rotting79 en 15 de Abril de 2012, 21:19:36
let me talk about the board:

it has two nodes,
NODE-0 has
-10 LEDs arrays
-2 buttons ( with hardware debounce, i think is better than writting debounce code).
-2 ADC (RA0 & RA1)
- Reset button.
-ICSP
-RS232 port
-CCP1 putput pin

NODE-1 has
-2x16 LCD COG (chip on galss)
-2 buttons
-2 ADC (RA0 & RA1)
-reset button
-ICSP


permítanme hablar sobre el tablero:

 que tiene dos nodos,
 NODO-0 tiene
 -10 LED matrices
 -2 Botones de hardware (con rebote, creo que es mejor que waritting código de rebote).
 -2 ADC (RA0 y RA1)
 - Botón de reposición.
 -ICSP
 -RS232
 -CCP1 pin PUTPUT

 NODO-1 tiene

 -2x16 LCD COG (chip de vidrio)
 -2 botones
 -2 ADC (RA0 y RA1)
 -el botón de reinicio
 -ISCP

 y al final del bus CAN, un filtro y un conector DB9 macho para conectar otro nodo

Título: Re: Mis experiencias con el BUS CAN
Publicado por: rotting79 en 15 de Abril de 2012, 21:29:55
is there any way to post the pictures the way Diego Gonzalez did?
beacause the way i did it, u need to be log in to watch them.

¿hay alguna manera de enviar las imágenes de la forma en Diego González lo hizo?
 debido a la forma en que lo hizo, u necesidad de ser identifícate para verlos.


nevermind!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: jorgegualdi en 16 de Abril de 2012, 10:10:40
Hola estoy buscando un analizador de red CAN en argentina o alquienque pueda hacer un trabajo de lectura de los datos que pasan por una RED CAN.
Tengo un equipo y quiero saber que es lo que esta pasando por la red.
Agradezco su ayuda
Título: Re: Mis experiencias con el BUS CAN
Publicado por: rotting79 en 19 de Abril de 2012, 22:52:14
a simple program, just Node-0 sending a ADC RA0 value to Node-1 and display it an the LCD and then sending as message to PC

un programa sencillo, basta con nodo-0 el envío de un ADC RA0 valor al Nodo-1 y lo mostrará una pantalla LCD y luego enviarlo como mensaje a la PC

Título: Re: Mis experiencias con el BUS CAN
Publicado por: AcoranTf en 13 de Mayo de 2012, 20:45:39
Ya tengo tarea para leer. En mi trabajo, (maquinaria auxiliar de almacenaje, como carretillas y transpaletas), se utiliza bastante el CAN BUS y aunque varias veces he intentado entender algo acerca de este tipo de bus, no lo he conseguido de momento. Mi bloqueo al respecto creo que viene del hecho de no ser un sistema basado en direccionamiento, sino en mensajes y aun no consegui entender como sabe cada nodo cuales mensajes le afectan y cuales no.
He leido el indice y algunas cosillas mas, pero voy a estudiar entero este hilo a ver si consigo aclarar esa duda y entender el funcionamiento del CAN BUS.
Gracias por tu trabajo MGLSOFT.

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: McG en 23 de Agosto de 2012, 11:33:42
Muy buenas, y felicidades por el hilo, por lo que veo estais muy avanzados en el entendimiento de la linea CAN, yo ahora estoy haciendo mis primeros vinillos con esto y lenguaje C y por ahora lo veo aun complicado. Ya que por un lado no dispongo de mucho tiempo para poder aprender.

Asi que os voy a exponer mi caso haber si alguien podria hacerme el favor de ayudarme o guiarme.

Trabajo en un taller de reparacion de piezas de coches y se han topado conque las Bombas que se inician por medio de linea CAN, no pueden saber cuales estan bien y cuales estan mal y si tiene que ser reparadas y el que... (ya que a nosotros nos llegan piezas como bombas de desguaces y talleres para su reparacion y prueba de rendimiento) Y claro esta ahora mismo no pueden vender ninguna de las muchas que ya tiene por causa de esto, ya que nada sale de la empresa sin tener una certeza que funciona correctamente. (la calidad se la toman muy enserio) y yo me tengo que encargar de encontrar la solucion para ello.  :8} :sad:

Mi idea era conectar un coche al PC o una placa que fuera capaz de grabar las señales que el coche enviara por linea can y arrancar el coche que es cuando se inicia la bomba de la direccion (la que a mi me interesa) y despues con las señales esas, reproducirlas en las bombas de prueba para saber si estan bien, ya que entre las señales que grabaria estaria (entre otras) la que la ECU central manda u ordena a la bomba que arranque.

Para ello por ahora compre el Analyzer CAN BUS de Microchip con la intencion de capturar las tramas que envia el coche en los primeros segundos de inicio y ver los ID con los que habla, y con ellos ir probando hasta encontrar el desado. Pero no hay forma que el Analizador se comunique con el coche. No me muestra nada en las ventanas del programa que trae, Voy a seguir intentando con otros tipos de coche de linea can, haber si en el que probe fuera de LIN CAN y no fueran compatibles.

Mi intencion tambien, es una vez que consiga arrancarlas de una forma u otra. Ya tendre mas tiempo para hacer una serie de placas para implementar los bancos de pruebas para que no necesiten en PC en cada uno.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Nocturno en 23 de Agosto de 2012, 12:31:37
Imagino que has intentado conseguir la documentación de las bombas y ha sido imposible, ¿no?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Agosto de 2012, 14:51:45
Podras poner la marca y modelo de la bomba especifica que quieres comandar ??
Asi te ayudamos a construir tu solucion para el banco de pruebas....
Bienvenido al hilo...!! ;-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: McG en 24 de Agosto de 2012, 04:38:31
Si estado buscando esquemas y especificacines de la bomba, pero no encontre nada de ayuda, no informa (o por lo menos yo no supe encontrar) de que ID se le da en la estructura CAN que lleva ni nada.

Y no es solo un tipo de bomba, por ejejmplo: Yo una de las bombas que mas tengo son las de SEAT Ibiza, que se montan en el modelo nuevo y en el modelo anterior a este, las de PEUGEOT Boxer, 407, OPEL Zafira, Si no mal recuerdo del Opel Astra tambien es CAN por lo menos las ultimas y unas que se monta en los ultimos C4 y C4 Picaso. Ya que los primero C4 eran las mismas que el 307 y primeros 407 que se pueden arrancar con pulso de positivo y mas que hay...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 24 de Agosto de 2012, 08:05:45
Pero las marcas y modelos las tienes ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: McG en 24 de Agosto de 2012, 10:44:08
Por ejemplo: Esta la de Peugeot Boxer, con referencia HPI A5095965+c Aqui os muestro la imagen de una.   

(http://fotos.tsncs.com/img/2012_1_14/0/fiat-scudo-bomba-de-direccion-hidraulica-a5095965-g-9467600480-euro-668-yapszwty_3.jpg)

Otra en este caso la del Ibiza es la 6Q0423155AM y Aqui tambien os pongo una imagen de ella

(http://images04.olx.es/ui/18/07/82/1325963378_297690582_1-Fotos-de--Seat-Ibiza-bomba-de-direccion-KOYO-468-euros.jpg)

Esas dos principalmente me interesan mucho saber cual es el codigo CAN de arranque.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gustpe en 24 de Agosto de 2012, 14:19:22
Para que hagas la comunicación, primero debes medir entre los pines cuales dos te dan 120ohm sin conectar, ya conectado en el vehiculo t va a dar 60 ohm, conectas la interface q tienes le configuras la velocidad, por lo general saben ser dos 125kps o 250kps, ten en cuenta la posicion de los cables H y L
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 25 de Agosto de 2012, 18:32:39
El problema es que para hacer pruebas en la bomba con el CAN unicamente no creo que actuen, habria que mirar el esquema electrico, pero yo diria que el modulo recibe las señales pertinentes y actua segun esas señales, el CAN seguramente lo usara para obtener algunos datos como velocidad del vehiculo, RPM del motor, si esta arrancado... y tambien mandara alguna informacion para algun otro modulo que lo necesite, sin embargo no conseguiras ponerla en funcionamiento solo con señales CAN.
Te va a costar bastante encontrar datos, y te vas a llevar mucho tiempo intentando encontrar las tramas necesarias para hacerla funcionar.

He encontrado un esquema electrico en el autodata de un 407, el sistema es electrico no hidraulico, pero se puede ver que modulos actuan con la bomba de la direccion interconectadas mediante CAN (modulo abs A16, modulo motor A35, modulo del volante B106).
(http://img7.imageshack.us/img7/994/sinttul2o.png)
Como ya digo, son muchos modulos los que interactuan entre ellos, por lo cual te va a costar conseguir hacerla funcionar y sobretodo en un sistema tan cerrado, los fabricantes no sueltan prenda de estos tipos de componentes excepto a los fabricantes del vehiculo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Agosto de 2012, 18:53:00
Si tienen un servicio tecnico de las bombas, deberian tener un muy buen contacto con el fabricante de las mismas.
Porque no pedirle todos los datos y especificaciones de prueba al fabricante ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: firewarrior en 25 de Agosto de 2012, 20:13:46
Hola, a ver si me podeis aconsejar sobre un proyecto que tengo en mente.

Quiero que al pulsar un boton una de las centralitas que tiene mi coche se separe del bus can y actue segun los parametros que yo le pase y al pulsar otro boton se vuelva a unir a la red can y actue segun los parametros que circulen por el coche.
¿Cual es la mejor forma para hacer esto?, Habia pensado en un rele que en reposo una las lineas CANh y CANl al coche y conmutado las separe, pero, ¿metera ruido en la red can?,  ¿sabeis de otras opciones mejores?.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 26 de Agosto de 2012, 17:24:58
Con un rele queda algo chapucero, yo lo haria mas bien mediante algun buffer o algo parecido.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Agosto de 2012, 20:55:57
A ver.
Una de las mayores diferencias del protocolo CAN, es que es multimaestro, en un sistema denominado productor-consumidor.
Es decir, puede haber componentes que emitan un mensaje por intervalos de tiempo, dirijido a un determinado ID o a un grupo de IDs que consumiran ese dato.
Eso lo hacen sin necesidad de que un maestro le solicite el envio, y los ID restantes, a pesar que escuchan el mismo mensaje, pueden simplemente ignorarlo.

Normalmente un Sniffer CAN, esta abierto a toda la mensajeria del bus, para poder analizar tramas, o el usuario puede tambien determinar un ID o varios a cuales escuchar y enviar mensajes, ignorando el resto de las tramas que circulan por la red.

Toda esta explicacion, es para llegar a explicar que no interesa si hay mas de un maestro, ya que el sistema lo acepta.
Puedes enviar tramas de comandos sin necesidad de aislar la central propia del automovil, eso si, comienza probando algo muy sencillo, ya que si arrancas con algo embromado, como ejemplo la direccion o el control de frenado, podrias ponerte en riesgo y tambien a terceros dentro y fuera del vehiculo.
Esto no es un videojuego, es simplemente la realidad... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: McG en 27 de Agosto de 2012, 08:37:18
Por las pruebas que pude hacer con un SEAT Ibiza, dejado solo los cables de Potencia de alta seccion y los de la linea CAN era como arrancaba, si le quitaba alguno de CAN ya fuera H o L no hacia nada.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: firewarrior en 27 de Agosto de 2012, 09:07:29
No me he explicado bien.
La centralita de la que hablo es la del techo solar que es la que tiene el ID mas alto ya que es la menos importante, y no creo que ocurra nada malo con ella.
Esta centralita solo actua cuando el coche esta parado o casi parado, digamos menos de 3km/hora.

Lo que me propongo es capturar la pulsacion del boton de apertura y cierre del techo solar, aislar la centralita de la red CAN y enviarle una trama con la velocidad equivocada para que me deje abrir o cerrar el techo solar a una velocidad mayor de 3Km/Hora, cuando el techo se encuentre en la posicion deseada y suelte el boton, que la centralita vuelva a unirse a la red CAN del coche ya que el techo dispone de un display que refleja la hora, temperatura exterior y otras cosas que recoge del bus tambien y que todavia no he descifrado.

Ya he hecho las pruebas y funciona bien, pero si mando la trama con la velocidad modificada y la centralita esta unida a la red CAN, termina por leer la trama verdadera y no puedo abrir o cerrar el techo. En cambio si la aislo de la red, funciona perfectamente, pero el display se queda vacio.

Si solo aislo la centralita cuando abro o cierro el techo y vuelvo a unirla despues a la red funciona todo perfecto.

Mi duda es cual es la mejor forma de hacer esto, habia pensado con un pequeño rele de señal, pero como dice Merlinz es un poco rudo y chapucero y no se si afectaria al resto de la red CAN.

A ver si me podeis aconsejar sobre algun buffer o un sistema para hacer esto bien.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 27 de Agosto de 2012, 11:49:45
No me he explicado bien.
La centralita de la que hablo es la del techo solar que es la que tiene el ID mas alto ya que es la menos importante, y no creo que ocurra nada malo con ella.
Esta centralita solo actua cuando el coche esta parado o casi parado, digamos menos de 3km/hora.

Lo que me propongo es capturar la pulsacion del boton de apertura y cierre del techo solar, aislar la centralita de la red CAN y enviarle una trama con la velocidad equivocada para que me deje abrir o cerrar el techo solar a una velocidad mayor de 3Km/Hora, cuando el techo se encuentre en la posicion deseada y suelte el boton, que la centralita vuelva a unirse a la red CAN del coche ya que el techo dispone de un display que refleja la hora, temperatura exterior y otras cosas que recoge del bus tambien y que todavia no he descifrado.

Ya he hecho las pruebas y funciona bien, pero si mando la trama con la velocidad modificada y la centralita esta unida a la red CAN, termina por leer la trama verdadera y no puedo abrir o cerrar el techo. En cambio si la aislo de la red, funciona perfectamente, pero el display se queda vacio.

Si solo aislo la centralita cuando abro o cierro el techo y vuelvo a unirla despues a la red funciona todo perfecto.

Mi duda es cual es la mejor forma de hacer esto, habia pensado con un pequeño rele de señal, pero como dice Merlinz es un poco rudo y chapucero y no se si afectaria al resto de la red CAN.

A ver si me podeis aconsejar sobre algun buffer o un sistema para hacer esto bien.

Conoces como funcionan los buffers triestado? Creo que te vendrian bien, conectas el canh y canl a las entradas y mediante el pin enable activas/desactivas la comunicacion entre la linea can y el modulo que dices. Al igual que un rele cuando se desactiva se pone en alta impedancia el buffer es lo mismo, sin embargo el buffer no mete ningun ruido como el rele y su conmutacion es digital no por contactos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: firewarrior en 27 de Agosto de 2012, 12:07:17
Conoces como funcionan los buffers triestado? Creo que te vendrian bien, conectas el canh y canl a las entradas y mediante el pin enable activas/desactivas la comunicacion entre la linea can y el modulo que dices. Al igual que un rele cuando se desactiva se pone en alta impedancia el buffer es lo mismo, sin embargo el buffer no mete ningun ruido como el rele y su conmutacion es digital no por contactos.

Pues la verdad es que no conozco bien como funcionan ya que nunca los he usado y solo soy aficcionado a la electronica y no profesional, pero ahora mismo me pongo a buscar informacion por la red sobre estos buffers, ¿me recomiendas alguno en especial?

Gracias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 27 de Agosto de 2012, 13:02:33
SN74LVC2G125-Q1 por ejemplo, el unico problema es que solo lo venden en SMD, no se si has hecho alguna placa o algo, pero vamos seguramente que se pueda buscar otro en formato dip para hacer una placa mas facil.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: groundman en 27 de Agosto de 2012, 14:54:38
y el MC14066? yo lo use para conmutar audio.no se si servira para frecuencias mayores.y es bastante varato.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 27 de Agosto de 2012, 15:07:06
el can va a 1mhz como mucho (aunque los hay mas rapidos pero no es el caso) el caso es que hay cientos para elegir xD
Título: Re: Mis experiencias con el BUS CAN
Publicado por: firewarrior en 28 de Agosto de 2012, 12:27:50
Gracias por los consejos.
He estado mirando y parece que el MC14066 es mejor ya que es un Switch y puede recibir y enviar datos tanto por los pines de entrada y salida, y la centralita ademas de recibir mensajes CAN tambien los envia, en cambio con un buffer necesitaria 4, 2 para recibir mensajes desde la red (canH y canL) y otros 2 para enviarlos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 28 de Agosto de 2012, 14:37:20
cierto que no es bidireccional, no habia caido en ello. Lo importante es que sea triestado para que cuando lo pongas disable se ponga en alta impedancia.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: mogollan en 27 de Octubre de 2012, 20:42:44
Hola a todos, soy nuevo en este protocolo a lo que me surgieron un par de dudas; tengo dos microcontroladores un 16f8777A y un 18f2550 ambos con su respectivos Módulos CAN MCP2515 y Transceptores MCP2551, he visto que el autor MGLSOFT modificó las librerías "can-18F4580.c" para el uso de diferentes velocidades 125,250 y 500 kbps, pero en este caso...

1.-¿ Tendría que hacer el mismo procedimiento de modificación de las librerías can-mcp251x.c ? ya que la funcion can_set_baud es muy distinta a la del can-18F4580.c
me refiero a esto:
[IMG=http://img713.imageshack.us/img713/1010/preguntadelibrerias.jpg][/IMG] (http://imageshack.us/photo/my-images/713/preguntadelibrerias.jpg/)

2.-¿Para simular toda una red con BUS CAN que usan?, ya Proteus contiene casi todo pero no los Módulos CAN MCP2515 ni Transceptores MCP2551
espero que me puedan ayudar, de antemano muchas gracias , saludos desde México.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 27 de Octubre de 2012, 21:36:08
Hola, bienvenido al hilo...
Primero, ninguno de tus PIC contiene controlador CAN incorporado, por eso deberas utilizar el MCP2515 que es un controlador externo, que permite incorporar la funcionalidad CAN en cualquier PIC, aunque aumenta el tamaño de la placa...
La libreria que comentas es para PICs con controlador CAN incorporado, es mas, para la linea con ECAN.
La libreria que deberas utilizar es la mcp2515.c y esta tambien tiene esa parte de configuracion, pero en este caso los valores de velocidad vienen dados segun el cristal externo que le pongas, el mas comun es el de 16 Mhz, por lo tanto deberas tomar la herramieta de calculo y establecer los valores para el juego de seteos tu mismo, segun la velocidad del bus que vayas a utilizar.
La mas normal, en que vienen todos los ejemplos de CCS y de Microchip, es 125 Kbps, por lo tanto si te estas iniciando te recomiendo usar esa velocidad, y despues te vas a ir metiendo mas en el tema, y alli veras como sacas tus propias velocidades.
Si usas 125 K, con los ajustes originales de la libreria, seguramente podras trabajar con los ejemplos tal como vienen.

Saludos y suerte!! ;-) ;-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: mogollan en 27 de Octubre de 2012, 22:26:00
Hola,gracias por responder pronto,entonces reafirmando...
Entiendo que mis dos uC´s no tienen el modulo CAN incorporado, es por eso que compré los modulos externos MCP2515 y MCP2551

1.-Asimilando que trabajaré a 125 Kbps, deberé de incluir tal cual la libreria "can-mcp251x.c" ya sin ninguna modificacion ??
2.-Y para la simulación ¿Que Software usaste ? acostumbro a usar Proteus, pero no tiene los dispositivos MCP2515 y MCP2551 :(
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 28 de Octubre de 2012, 07:31:55
Buenos días a la CAN-family.

Por fín he podido sacar tiempo para leerme las 62 páginas, ante todo me rindo a vuestros pies. Estais hechos unos figuras.

Siempre había empezado a leer el post y debido al tiempo me quedaba en la página 8 aprox.

Bueno, mi intención es emplear el bus can con un PIC32MX534F064H, y el transceiver MCP2551.

Todavía estoy bastante  :mrgreen: (Verde pero sonriente), y tengo que macerar todos vuestros conocimientos, y por supuesto ir sacando mis dudas:

Por qué se pone la resistencia entre CANH y CANL??

Sobre el analizador que os habeis creado, yo tengo en la placa de mi bus can conectado un FT232 para sacarlo por USB al hipertérminal (Ya se que no haría falta el FT232 ya que del micro puedo sacar directamente el USB, pero todavía ando más verde en dicho tema y le doy prioridad al BUS CAN). Se podría hacer el analizador así sin problemas??Es decir, obtener los parámetros recibidos por el CAN y mandarlos por el mismo micro al FT??

Muchas gracias, espero ponerme pronto a vuestra altura en conocimientos.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 28 de Octubre de 2012, 10:34:47
 Buenas!
 La resistencia se ponen para cerrar el bus  quedaria asi

(http://www.inverter-china.com/blog-es/upload/CAN-bus.gif)

De lo del FT323 no te puedo ayudar
Yo lo que  he  probado es usar un pic con usb(18f4550 )+MCP2515(controlador can) + mcp2251(implemente la capa fisica ), y  envio y recibo desde el bus can al  pc los datos y leugo con un programa en vc# lo visualizo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Octubre de 2012, 13:23:35
Buenas!
 La resistencia se ponen para cerrar el bus  quedaria asi

(http://www.inverter-china.com/blog-es/upload/CAN-bus.gif)


Exactamente, para aclararlo aun mas, las resistencias van en los extremos del bus, y se llaman resistencias terminadoras de bus.
Son de 120 Ohm cada una.
Si miras las especificaciones del bus CAN, veras que hay varias formas de cerrarlo, y las mas completas tienen resistencias de BIAS, que van conectadas a ambas tensiones de alimentacion y tambien a masa.
Te puedo asegurar por experiencia propia, que si dejas una resistencia que a traves de un jumper, puedas seleccionar que cierre el bus, en cada placa que hagas, nunca tendras problemas y cualquiera de las placas podra estar en el final del bus. :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Octubre de 2012, 13:26:29
Hola,gracias por responder pronto,entonces reafirmando...
Entiendo que mis dos uC´s no tienen el modulo CAN incorporado, es por eso que compré los modulos externos MCP2515 y MCP2551

1.-Asimilando que trabajaré a 125 Kbps, deberé de incluir tal cual la libreria "can-mcp251x.c" ya sin ninguna modificacion ??
2.-Y para la simulación ¿Que Software usaste ? acostumbro a usar Proteus, pero no tiene los dispositivos MCP2515 y MCP2551 :(

No se puede simular CAN con el Proteus, y aunque consiguieras un simulador, te aconsejo que hagas tus experiencias directamente sobre circuitos, aunque esten armados en protoboard, ya que sino te perderas de miles de detalles que el simulador no te advertira. :? :?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 30 de Octubre de 2012, 06:37:11
Buenos días MGLSOFT,

Pero porque ponerle con las resistencias con un puente??Si son necesarias porqué no ponérsela fija??

Y sobre el tema de analizador que estoy haciendo con el FT232 cómo lo ves??

Gracias.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Octubre de 2012, 08:13:49
El jumper es para seleccionar cual de los equipos es fin de linea, de otro modo si tuvieras todos equipos iguales, deberías tener 2 de ellos con las resistencias puestas y los demás no, o sea te obliga a preparar un equipo cada vez que reemplazas uno o cuando cambias la traza del Bus.

Para el micro el FT232 es transparente, en la PC es un puerto COMM virtual, así que no le veo problemas, de hecho yo tengo así parte de mis debuggers por serie.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 30 de Octubre de 2012, 08:40:00
Gracias por tu rápida respuesta. Ahora si me he liado más.

Para la aplicación que quiero hacer habrá 5 tarjetas con bus CAN. y creía que todas deberían de llevar la resistencia. ¿Cuándo un equipo es fin de línea?

Muchas gracias.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Octubre de 2012, 09:25:23
Te contesto con otra pregunta:
Porque no dibujas como vas a implementar tu BUS y luego determinas cuales son sus extremos??

Alli veras tu mismo cuales deben llevar las resistencias... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 30 de Octubre de 2012, 10:31:07
Vale, creo haberlo entendido con tu pregunta.

En el manual pone una resistencia en el bus de 60 Ohmios, como está conectada en el bus en paralelo se pone 120 ohmios ya que al ponerse en los terminales tendríamos los 60 ohmios de resistencia que hay que ponerle al bus. ¿No es cierto?, de ahí el tema del jumper

Ahora, tendría que ver si mi diseño tendría que tener la resistencia. Somos un grupo y cada uno hará un diseño, uno hará una placa para los sensores y por supuesto con el BusCAN, otro hará para cambiar la geometría del motor, ....., y yo haré la telemetría, todos los parámetros recibidos por el CAN los tengo que pasar por RF al equipo. Por lo que si mi imaginación no me falla yo seré uno de los que tenga que poner la resistencia. ¿No creeis?

Muchas gracias.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Octubre de 2012, 10:40:55
Ahora vas bien rumbeado, felicitaciones !! ((:-)) ((:-))
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 30 de Octubre de 2012, 10:44:28
 :-/ :-/ :-/ :-/ :-/

La verdad que el post es tremendo, gracias a vosotros entendí como funcionaba el filtro y las máscaras.
Ahora estoy peleandome con el manual de microchip para ver como se programa el busCAN del PIC32 en C, viendo los comandos y los pasos a seguir, pero tengo mil dudas. A ver si puedo poco a poco ir resolviendolas.

Cuando lo tenga avanzado lo iré colgando por si puede servir a alguien de ayuda.

Seguimos en contacto.
Muchas gracias.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 31 de Octubre de 2012, 05:02:23
Buenos días,

ya estoy por aquí con más dudas   :oops:

Mirando como se programaban los filtros y las máscaras (el funcionamiento si que lo entiendo gracias a vosotros), me ha surgido una duda:

Supongamos que yo quiero recibir mensajes de los SID 100 a 103, que mi placa tiene el SID 104.
Dicho SID tengo que configurarlo yo??Cómo sé que SID tiene mi placa??

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 31 de Octubre de 2012, 08:45:09
Buenas éste es el código que he hecho para la configuración del CAN. ¿Ésta bien?¿Falta algo por configurar?
Soy todo. Casi todo dudas.

Citar
void ConfigCAN1 (void){
    /*Ponemos el módulo CAN en modo configuración*/
    C1CONbits.REQOP = 100;
    /*Esperamos hasta que conmute a modo configuración*/
    while(C1CONbits.OPMOD != 100);

    /*Configuración FIFO1 como lectura*/
    C1FIFOCON1bits.FSIZE = 2;     /*Almacenara 3 mensajes del buffer*/
    C1FIFOCON1CLR = 0x80;         /*Se limpia el bit de TXEN*/

    /*Configuración Filtro3 y máscara1 para recibir desde SID 1 a 3*/
    C1FLTCON0bits.FSEL3 = 1; /*Almaceno mensajes en FIFO1*/
    C1FLTCON0bits.MSEL3 = 1; /*Uso la máscara 1*/
    C1RXF3bits.SID = 0x1;       /*Filtro 1 SID*/
    C1RXF3bits.EXID = 0;        /*Filtramos Sólo SID*/
    C1RXM1bits.SID = 0x7FC;     /*Ignoramos los últimos 2 bits en compración*/
    C1RXM1bits.MIDE = 1;
    C1FLTCON0bits.FLTEN3 = 1;   /*Habilitamos filtros*/

    /************************************************************************/
    /*Configuración del Bit Timing                                                                                  */
    /*Fsys 80MHz, FBAUD = 250Kbps, N=20, Ftq=5Mbps                                                  */
    /*Calculando BRP=(Fsys/(2*Ftq))-1*, BRP=7                                                             */
    /*Synchronization Segment = 1TQ                                                                            */
    /*Bit Time = Sync Segm + Propagation Segm + PH1 + PH2                                        */
    /*Sync Segm = 1TQ; Propagation Segm = 6TQ; PH2 = 6TQ*; Bit Time = 20TQ             */
    /*PH1 = 7 TQ                                                                                                          */
    /*Basado en un sistema característico si el retraso de propagación                              */
    /*es de 6TQ y el punto de muestra es del 70% del tiempo de bit nominal                     */
    /*PH2 = 30% Del tiempo de bit nominal                                                                     */
    /************************************************************************/
    C1CFGbits.SEG2PHTS = 1;
    C1CFGbits.SEG2PH = 5;    /*Seg Fase 2 es de 6TQ*/
    C1CFGbits.SEG1PH = 6;    /*Seg Fase 1 es de 7TQ*/
    C1CFGbits.PRSEG = 5;     /*Seg Propagación es de 6TQ*/
    C1CFGbits.SAM = 1;      /*'0' Muestrea el bit 1 vez, '1' tres veces*/
    C1CFGbits.SJW = 2;      /*Entre 1TQ - 4TQ*/
    C1CFGbits.BRP = 7;      /*Valor calculado*/


    /*Se pone en modo normal*/
    C1CONbits.REQOP = 0;
    while (C1CONbits.OPMOD != 0);
}


Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Octubre de 2012, 08:58:01
Citar
Supongamos que yo quiero recibir mensajes de los SID 100 a 103, que mi placa tiene el SID 104.
Dicho SID tengo que configurarlo yo??Cómo sé que SID tiene mi placa??

Partamos de la base que quien programa ese micro eres tu, así que deberías saberlo, no?? :D :D

Pero supongamos que quieres hacer una placa genérica que transmite una temperatura, una presion y humedad, o sea, tres valores, y ninguno de ellos debería ser transmitido en una misma trama, es decir, vas a tener tres tramas diferentes a enviar.
En CAN esas tres tramas deberán llevar in ID diferente, para saber quien lo transmitió y que dato viene alli, para las placas que consuman esa información (recuerda que pueden ser varias).

Vamos a suponer que los IDs son asignados así:

Esto hará que quien reciba esa información, estará diferenciando las tres variables sin inconvenientes, porque vendrán en mensajes diferentes con IDs diferentes.

¿¿Pero que pasa si agregamos en ese BUS dos placas mas iguales a esta, que envían la misma información ??

En este caso debo ademas diferenciar entre placas, ademas de las variables, ¿¿ como lo hago ??

Hay dos formas (o tal vez tres), que son de distinta implementación pero igual resultado:


Finalmente, luego deberás agregarle como offset a los tres IDs de las variables, el ID de la placa, que quedaría mas o menos así:

Como veras, ya no hay forma de equivocarse desde que placa viene cada dato, ni que dato es cada uno, no??
Ademas hiciste tres placas idénticas y con el mismo software tambien... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Octubre de 2012, 09:02:42
Citar
Buenas éste es el código que he hecho para la configuración del CAN. ¿Ésta bien?¿Falta algo por configurar?
Soy todo. Casi todo dudas.

Haz el ejercicio de hacer esa configuracion con el software CAN Bit Timing y revisala contra la que has hecho, sera mejor a que nosotros lo hagamos por ti, y lo que aprenderas sera impagable.
Estas son las cosas que en el futuro te daran confianza, asi que mejor haz primero eso y si esta mal debieras darte cuenta tu mismo y corregirlo. Lo demas es prueba y error solamente... :mrgreen: :mrgreen:  Y no lo hace Mastercard !! :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 31 de Octubre de 2012, 09:18:06
Jejejeje.

Ya lo he hecho, y le da como amí BRP 7, en mi caso, yo hago un punto de muestra del 70% y el programa 60%, aún asi, lo he cambiado como el programa.

A la hora de generar informe me da error y no me genera los bits del registro.

Y volviendo al tema de la configuración:

Tengo configurado los Filtros y máscaras, las FIFOs, y el baud rate, me falta algo??

Cómo se yo que SID tiene mi placa??

Muchas gracias por tomaros el tiempo de ayudarnos.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Octubre de 2012, 09:20:59
Para saber donde se configura tu ID, hay que ver el programa completo... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 31 de Octubre de 2012, 09:24:25
Gracias MGLSOFT por tu atención.

Pues ahora mismo estoy peleandome con el código, he empezado con lo que os he puesto, la configuración, ya que estos días he estado leyendo el manual. No tengo nada más, pero quieres decir, o intuyo de tu comentario, que soy yo el que tiene que programar el SID que quiero que tenga mi placa??

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Octubre de 2012, 10:07:11
Lees e intuyes bien !!  :mrgreen: :mrgreen: ;-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 31 de Octubre de 2012, 10:20:01
Espera, creo haber llegado a la solución.
Es recomendable crear una estructura con los campos de las tramas a enviar, entre ellas está el SID, EID, etc... pues cuando vas a enviar una trama, rellenas ahí el SID que vas a enviar, es decir, tu SID. (Rellenas toda los parámetros de la estructura). Y ya lo cargas en el buffer. Puede ser??

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Octubre de 2012, 10:26:27
Nadie lo podría haber escrito mejor que tu !! :-/ :-/

Hay muchos caminos a Roma, no es así?? :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 31 de Octubre de 2012, 10:41:27
Puede ser que te lea el pensamiento MGLSOFT?? :D

Gracias.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 31 de Octubre de 2012, 11:22:04
Por que no??
Tengo una gran cabezota, es probable que se vea lo que pienso !! :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 02 de Noviembre de 2012, 16:05:37
Me ha surgido una duda:

¿Se puede usar el CAN con el DMA en los PIC32?

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 02 de Noviembre de 2012, 16:10:55
si
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Noviembre de 2012, 16:20:13
Ahora deberan explicarme ustedes dos, que es el DMA !!   :shock: :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 02 de Noviembre de 2012, 16:22:11
Perfecto, pues cuando haga funcionar el CAN lo probaré con el DMA.

El DMA viene de Direct Memory Access, uso del periférico sin utilizar la CPU.

Espero haberlo explicado bien.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Noviembre de 2012, 16:25:29
Y como se accede sin uso del cpu??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 02 de Noviembre de 2012, 16:36:38
Ahí ya no puedo ayudarte.

Intentaré mojarme, pero que sepas, que quizá te esté mintiendo.

El módulo DMA puede acceder a cualquier dirección de memoria dentro del sistema, ya sea SRAM, Flash o SFRs de periféricos. Aumentando la tasa de transferencia de datos y mejorando el rendimiento.

Por medio de software podemos asignar un canal del DMA.

De esta manera, la CPU puede hacer otras tareas de mayor importancia y dejar el manejo del periférico al módulo DMA logrando un mayor rendimiento de la CPU.

Supongamos que vamos a usar la UART con el DMA.

El módulo UART recibe datos.
Se llena el buffer de recepción.
El DMA obtiene los datos del buffer UART y los deposita en RAM.
Cuando el número de bytes especificados se transfieren a RAM entonces el DMA interrumpe a la CPU para decirle que ya están listos los datos en RAM para que los utilice.

Espero haberte solucionado la duda sin engañarte  :?

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Noviembre de 2012, 16:53:49
Creo que lo entiendo, tengo un PIC24 sobre la mesa de destripado y veo que tiene esta opcion de funcionamiento.
Lo estudiare a fondo, porque parece tener buena pinta... :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 02 de Noviembre de 2012, 16:55:06
Yo ahora estoy intentando buscar información sobre como usar, y configurar el CAN con interrupciones.  :5] así estoy, echando fuego. Me está costando el dichoso CAN.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Noviembre de 2012, 17:07:06
Yo ahora estoy intentando buscar información sobre como usar, y configurar el CAN con interrupciones.  :5] así estoy, echando fuego. Me está costando el dichoso CAN.

Un saludo.

En que programas??
Es C32??  >>> No puedo ayudarte
Es CCS??      Si puedo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 02 de Noviembre de 2012, 17:11:00
En C32. Una lástima.
He de suponer que habrá una interrupción para la recepción y otra para la transmisión al Bus, ¿Verdad?. Estoy buscando los registros de interrupciones para los módulos.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Noviembre de 2012, 17:15:08
Como dicen los americanos en los foros, aplique RTFM.!!


Read The Fucking Manual !!!! :D :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 02 de Noviembre de 2012, 17:26:31
Y como se accede sin uso del cpu??

Leete esto:
http://www.todopic.com.ar/foros/index.php?topic=38271.0

aunque no este 100% terminado, pero mas o menos lo comprenderas.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 02 de Noviembre de 2012, 17:38:19
Pero que no tiene éste foro??Lo miraré

Gracias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 02 de Noviembre de 2012, 17:42:11
Pero que no tiene éste foro??Lo miraré

Gracias.

Te contesto: CHICAS  :(
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 02 de Noviembre de 2012, 18:04:19
Si que hay, pero deben ser feas, porque son muy inteligentes !!   :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 02 de Noviembre de 2012, 18:07:06
 :D :D :D :D :D :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 02 de Noviembre de 2012, 18:39:28
Buenas chicos,

Cómo ya sabeis estoy un poco pillado al querer desarrollar el CAN con interrupciones. Quiero que cuando mi placa reciba un mensaje de otro SID, salte a una interrupción y procesar la trama dentro de la interrupción.

Estoy usando un PIC32 en C.

Viendo los registros, ando un poco liado, ya se cual es el registro para la prioridad, subprioridad, bandera de interrupción, y para activar el bit de interrupción del CAN1.
Pero no se muy bien que bit del registro de interrupciones del CAN1 tengo que activar para lo descrito anteriormente.

Todo me lleva a pensar en el bit RBIE del registro de nterrupciones del CAN1. Pero no estoy seguro si sólo tengo que activar éste o alguno más.

En la página 18 se puede ver el registro de interrupciones: http://ww1.microchip.com/downloads/en/DeviceDoc/61154C.pdf

Les pongo aquí parte del código (del tema de la interrupción por si así lo veis más claro):

Citar
C1CONbits.ON = 1;       /*Activo el módulo CAN1*/

    C1INTbits.RBIE = 1;     /*Activo Interrupción de Recepción en el Buffer*/

    IPC11bits.CAN1IP = 1;   /*Prioridad 1*/
    IPC11bits.CAN1IS = 0;   /*Subprioridad 0*/

    IFS1bits.CAN1IF = 0;    /*Limpio la bandera de interrupción*/
    /*Tengo que borrar tambien RBIF??????????????????*/

    INTEnableSystemSingleVectoredInt(); /*Activa el modo Single Vector*/

    IEC1bits.CAN1IE = 1;    /*Activa la interrupción de CAN1*/
   
    while(1);

    return 0;
}

//Rutina de Interrupción
void __ISR(0, ipl1) InterruptHandler(void){
    /*Código*/
    /*Tengo que borrar tambien RBIF??????????????????*/
    /******************/

    CANRxMessageBuffer *buffer;
    buffer  = (CANRxMessageBuffer*)(PA_TO_KVA1(C1FIFOUA1));

    /*Comprobar si hay algún mensaje para leer*/
    if (buffer->CMSGEID.DLC == 4)
    {
        /*if(message->data[0] == FALSE)
   {
      
   }
   else
   {
      
   }*/
    }

    /******************/
    IFS1bits.CAN1IF = 0; /*Limpio la bandera de interrupción*/
}

Espero que me podais ayudar.

Muchas gracias.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 02 de Noviembre de 2012, 21:17:55
RBIF no lo podras borrar, se borra solo cuando vacias el FIFO.

Para ver por que te ha saltado la interrupcion (ya que CAN1IF salta tanto en recepcion, envio, error...) debes comprobar el flag seria:

if(C1INTbits.RBIF) {
//flag de recepcion
//procesas lectura del FIFO

}

ahora bien, para saber que fifo es el que llama a la interrupcion (imagina que recibes 2 msjs seguidos y no te da tiempo a atenderlos pq estas en otra interrupcion) utilizas el registo C1VECbits.ICODE. Este te indica a que buffer/fifo pertenece la llamada de la interrupcion, por logica deberia ser siempre el 0. Tambien tal y como lo tienes con el C1FIFOUA1 te puede servir. Luego despues de esto debes poner el flag de que ya has leido ese fifo (para que no vuelva a saltar la interrupcion, seria: C1FIFOCONxSET = 0x2000
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 03 de Noviembre de 2012, 05:53:01
Creo que te entiendo MerLiNz.

De lo último que me has contado de las FIFOS no me he enterado, voy a seguir releyendolo y con los registros al lado a ver si pudiese verlo.


Muchas gracias.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 03 de Noviembre de 2012, 07:49:12
Más o menos lo voy entendiendo.

Os pongo el núevo código en la rutina de interrupción para ver si realmente lo he entendido o soy un negado.

Citar
void __ISR(0, ipl1) InterruptHandler(void){
    /*Código*/
    /******************/
    if (C1INTbits.RBIF){        /*Si ha sido interrupción de lectura*/

        CANRxMessageBuffer *buffer;
        if (C1VECbits.ICODE && '0000001'){ /*Verifico que la INT es en la FIFO1*/
           
            C1FIFOCON1SET = 0x2000;     /*Ya se ha leido la FIFO1*/
            buffer = (CANRxMessageBuffer*)(PA_TO_KVA1(C1FIFOUA1));

            /*Comprobar si hay algún mensaje para leer*/
            if(buffer -> CMSGEID.DLC == 4){
              /*if(message->data[0] == FALSE)
                    {

                    }
              else
                  {

                  }*/
            }
        }
    }
   

 
    /******************/
    IFS1bits.CAN1IF = 0; /*Limpio la bandera de interrupción*/
}

Cuando ha saltado la interrupción del CAN1 verifico que ha sido la de lectura.
Después compruebo que ha sido en FIFO1 (Aunque creo que sería mejor cambiarla a la 0).
Indico que si es en la FIFO1 ya lo estoy leyendo.
Y la tarea a realizar......

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 03 de Noviembre de 2012, 11:43:37
Utiliza FIFO0. Como es First In First Out creo que al ponerlo el FIFO0SET se borra y el mensaje del FIFO1 se pasa al FIFO0, pero esto lo ideal es que lo vayas probando segun programas.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 03 de Noviembre de 2012, 12:32:25
Si, la verdad que empecé a picar código con FIFO1 sin pensarlo pero llevas toda la razón, tendré que hacerlo con la FIFO0.

Por lo menos me consuela que he entendido lo que me habías puesto y lo que había programado está bien puesto, no??

A seguir mirando el manual.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 03 de Noviembre de 2012, 12:53:07
Lo que has programado ya te digo, vas probando a ver si te va funcionando bien, esto es así, en la teoria puede que funcione pero en la practica puede que algo no concuerde.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 03 de Noviembre de 2012, 12:55:46
Si. Lo mejor será la táctica Prueba y error.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 03 de Noviembre de 2012, 14:13:57
Dandole vueltas a la interrupción para leer el mensaje de la FIFO, he pensado en hacer éste otro método, me parece más sencillo que el que me explicabas MerLinz.

En lugar de ver que FIFO provoca la interrupción habilitar la interrupción de FIFO no empty, de tal manera, que cuando tenga un dato en la FIFO0 que es la de lectura, realizar las operaciones.

No es así más sencillo?? O tiene alguna pega comparado con el método que me proponías??

Pongo aquí el nuevo método.

Citar

    C1CONbits.ON = 1;       /*Activo el módulo CAN1*/

    C1INTbits.RBIE = 1;     /*Activo Interrupción de Recepción en el Buffer*/
    C1FIFOINT1bits.RXNEMPTYIE = 1; /*Activo bit interrupción FIFO no vacía*/

    IPC11bits.CAN1IP = 1;   /*Prioridad 1*/
    IPC11bits.CAN1IS = 0;   /*Subprioridad 0*/

    IFS1bits.CAN1IF = 0;    /*Limpio la bandera de interrupción*/

    INTEnableSystemSingleVectoredInt(); /*Activa el modo Single Vector*/

    IEC1bits.CAN1IE = 1;    /*Activa la interrupción de CAN1*/
   
    while(1);

    return 0;
}

//Rutina de Interrupción
void __ISR(0, ipl1) InterruptHandler(void){
   
    CANRxMessageBuffer buffer;
    unsigned int * bufferToRead;
   
    if (C1INTbits.RBIF){        /*Si ha sido interrupción de lectura*/

        //if (C1VECbits.ICODE && '0000001'){ /*Verifico que la INT es en la FIFO1*/
            /*Compruebo que hay un mensaje para leer*/
            if (C1FIFOINT1bits.RXNEMPTYIF == 1){

                /*Obtengo la dirección del buffer de lectura*/
                 bufferToRead = (CANRxMessageBuffer*)(PA_TO_KVA1(C1FIFOUA1));

                 bufferToRead[0] = buffer -> messageWord[0];
                 bufferToRead[1] = buffer -> messageWord[1];
                 bufferToRead[2] = buffer -> messageWord[2];
                 bufferToRead[3] = buffer -> messageWord[3];

                 //C1FIFOCON1SET = 0x2000;     /*Ya se ha leido la FIFO1*/

                 /*Actualizo el puntero al buffer de mensajes*/
                 C1FIFOCON1bits.UINC = 1;

                /*Comprobar si hay algún mensaje para leer*/
                /*if(buffer -> CMSGEID.DLC == 4){*/

                }
            //}
           
        }
    }
    /******************/
    IFS1bits.CAN1IF = 0; /*Limpio la bandera de interrupción*/
}


Mira que me va a costar la lectura (Y todavía no he empezado con la escritura  :shock:), jejeje.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 03 de Noviembre de 2012, 15:18:47
Si, todos los caminos llevan a roma XD

Yo es que lo hacia mediante DMA entonces tenia un array de X mensajes, cuando recibia un mensaje tenia que saber el numero de mensaje que era para leer la direccion apropiada del array, por eso utilizaba este modo. El caso es que no se como ira el FIFO en el pic32, pero en teoria cuando se queda vacio el 0 y el 1 esta ocupado el 1 deberia pasar al 0, si es asi bien.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: mogollan en 10 de Noviembre de 2012, 02:17:33
Hola a todos he estado intentando echar andar el bus CAN, en microcontroladores PIC sin modulo CAN integrado (16F877A), pero no sé que estoy haciendo mal y ya llevo un tiempo no encontrando el problema...

La conexión que estoy haciendo como la de la imagen, pongo los pines de mayor interés
(http://imageshack.us/a/img715/2063/escaneo10.th.jpg) (http://imageshack.us/photo/my-images/715/escaneo10.jpg/)

Me da incertidumbre el valor de los osciladores, tengo entendido que las librerías "can-mcp251x.c" y "can-mcp251x.h" estan por defecto a 125 kBps y he modificado la  los pines que trae por defecto "can-mcp251x.c" para que trabaje con el 16F877A como lo muestro en la figura
(http://imageshack.us/a/img22/562/ayuda1j.th.jpg) (http://imageshack.us/photo/my-images/22/ayuda1j.jpg/)

Tengo la duda si los pines de:   
#define EXT_CAN_SI   PIN_C4
#define EXT_CAN_SO   PIN_C5
estan bien conectados como lo tengo en mi esquematico =/

Adjunto los programas de mi Nodo A y mi Nodo B
De antemano muchas gracias, saludos desde México
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 10 de Noviembre de 2012, 07:11:29
Hola mogollan
 Mirando el esquema creo  que en el MCP2515  patilla resest(17) e int(12) tiebe que estar a nivel alto, (resistencia 10k a 5v)
   y en el mcp2551 RS (pin 8) tiene que poner a   gnd con una resistencia  de 10 o 100 . A lo mejor los mcp2551 se te han  quemao.. yo al principio de trastear con ellos me murieron varios en el intento.  Prueba a ver
:)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Noviembre de 2012, 08:32:28
Los pines SDI y SDO del micro están bien conectados.

Aquí una imagen de mi placa, mira el primer MCP2515, que va conectado a IC2 que es un PIC de 28 o 40 Pines, y lleva las demás señales.
En el MCP2515 es muy importante usar la patilla INT, para no estar continuamente ocupando el micro haciendo poolling para ver si llego un nuevo dato.
Esto que digo es para cuando quieras hacer una aplicación mas comercial, para pruebas te sirve tal como viene.
Lo otro muy importante es determinar bien que cristal vas a poner y su frecuencia de oscilación.

(http://img135.imageshack.us/img135/3627/placacanetha4hz9.jpg)

Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 10 de Noviembre de 2012, 10:24:37
Pues despues de revisar de nuevo este esquema.. nose porque INT lo tenia como entrada..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Noviembre de 2012, 11:01:38
Hay que leer la hoja de datos del MCP2515...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: radioelf en 30 de Noviembre de 2012, 05:22:24
Hola,tengo una duda que seguro ya se comento en este hilo, pero no tengo narices de encontrar la respuesta :oops:, y ésta es si usamos las librerías de CCS para trabajar con el MCP2515 con SPI sin ninguna modificación la velocidad del CAN bus es de 125 kb/s, ¿pero para que frecuencia del oscilador del MCP2515? 20Mhz, o 16Mhz....
Gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 30 de Noviembre de 2012, 06:15:27
Yo  sin tocar las librerias  me  va a 20Mhz  y Ok
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Noviembre de 2012, 08:27:25
A ver...
El MCP2515 es un controlador CAN externo, que se puede aplicar a cualquier PIC que no disponga de CAN y dotarlo de este tipo de bus.
Para comunicarse con ese controlador se usa el bus SPI, y la velocidad de procesamiento o clock del PIC no influye demasiado en ese bus y absolutamente NADA en como se configura el funcionamiento del bus CAN.

Para que este bus CAN funcione, se deben poner valores a unos cuantos registros que hacen funcionar el bus a la velocidad que uno elije.  Allí es donde influye el tiempo de bit, que esta íntimamente ligado a la frecuencia del cristal que tiene en este caso el controlador MCP2515 y como se hayan configurado los registros correspondientes.

Si en un ejemplo de CCS, usas la configuración original y el mismo cristal que pone CCS en sus placas, tus ejemplos funcionaran a 125 Kbps, y pasa lo mismo con los ejemplos de Microchip en sus placas.

Es por ello que recomendamos no cambiar el cristal del MCP2515 cuando este es usado con los ejemplos, y del mismo modo con los ejemplos cuando hay PICs con controlador CAN incorporado, para que la experiencia no sea frustante... se entiende ???

Igual si luego de esa primera experiencia aun no has perdido interes, vas a tener que aprender a configurar y dominar todos y cada uno de los registros de configuración, y jugar con diferentes frecuencias de cristal y asi dominaras tu el CAN y no el CAN a ti !! :D :D  (leer bien en este hilo, como se configura esto según el cristal, explicado paso a paso)...

Para ello, como dicen los Americanos, deberás aplicar RTFM !! :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: radioelf en 30 de Noviembre de 2012, 09:20:26
OK, la pregunta es ¿el cristal que pone CCS en sus placas es de 20Mhz?, el resto lo tengo claro..
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Noviembre de 2012, 11:57:40
Dimelo tu mismo...

Título: Re: Mis experiencias con el BUS CAN
Publicado por: radioelf en 30 de Noviembre de 2012, 18:53:20
Está claro 20Mhz para 125 Kbps con las librerías de CCS (defecto), la verdad es que no fui capaz de encontrarlo por ningún lado de forma clara. Gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 30 de Noviembre de 2012, 22:32:01
Es dificil de encontrar, pero buscando se encuentra... ;-) ;-)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: mogollan en 28 de Diciembre de 2012, 23:23:08
Hola a todos tengo una duda, he conseguido habilitar el BUS CAN en MikroC de Mikroelectronika, y veo que en sus librerias usan el PIN RST, pero en las de CCS no lo ocupan , en todo caso deberia de mandar RST a VCC (pasando por una resistencia de 100K)?? estoy usando por cada nodo PIC16f877a+MCP2515+MCP2551
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Diciembre de 2012, 08:39:12
Si vas a usar el CAN de MikroC, usa el pin de reset y no te compliques, ya que sus librerías seguramente lo usan.
Si usas el de CCS, deja libre ese mismo pin y lo pones a VCC.
De esa forma, podrás usar uno u otro compilador sin problemas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Alejandro en 14 de Enero de 2013, 14:13:59
Hola, alguien me podria aclarar la siguiente duda:

Tengo un scaner de J1939 el cual trabaja a la par con un software en PC, el problema es que quiero hacer pruebas sin conectar el scaner al computador del vehiculo, solo conectandole los +12V de la alimentancion pero parece que el software hace un test del bus can y como este no esta conectado al vehiculo no me permite iniciar el software para realizar mis pruebas, alguien me podria decir como emular un estado logico de este bus?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Alejandro en 14 de Enero de 2013, 14:20:23
 :oops:  Seria correcto conectar una resistencia de 120 ohms entre el J1939(+) y J1939(-)?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: willynovi en 14 de Enero de 2013, 15:09:17
Yo me buscaria un manual del scanner para ver como usarlo antes de hacer conexiones.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Enero de 2013, 15:14:30
Igualmente, no creo que rompas nada poniendo las resistencias en el bus, es probable que te detecte BusOpen, por no tenerlas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: alquimista en 18 de Enero de 2013, 22:19:54
Tengo una duda con respecto al MCP2551 se supone que ocupo micro dsPIC33FJ256GP710 y envio un dato por un puerto esperando recibir ese dato por el otro puerto ecan porque tiene 2  lo que pasa es que mando información y la verifico con el osciloscopio a la entrada del transceiver y entra un tren de pulsos a la salida tengo informacion y esa misma informacion la recibe el mcp del otro puerto pero checo los pines que se conectan al micro y nadamas veo que se encuentran en uno logico que pasa ahi?????????????????????? agradeceria mucho una repuesta pronta   
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 22 de Enero de 2013, 09:20:04
Buenas a todos,

Estoy intentando evolucionar...pero me está costando, la verdad.

Estoy intentando realizar un código en modo loopback, para testear el CAN. Pero me surgen varias dudas.

- Por lo visto, según el manual, cuando se elige el modo loopback, el módulo no utiliza el bus, por lo cual, no utiliza el transceptor MCP2551, ¿Verdad?
- En este modo, tengo que configurar una fifo de Tx y otra de Rx??
- Sigue las mismas pautas de propagación que el modo normal??

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Enero de 2013, 09:57:45
En que manual te dice que no utiliza el bus??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 22 de Enero de 2013, 10:32:50
Te indico lo que pone en el manual de microchip.

34.5.5Loopback Mode
Loopback mode is used for self-test to allow the CAN module to receive its own message. In this mode, the CAN module transmit path is connected internally to the receive path. A “dummy” acknowledge is provided, thereby eliminating the need for another node to provide the Acknowledge bit. The CAN message is not actually transmitted on the CAN bus.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Enero de 2013, 11:25:15
Ok, ahora si lo entiendo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 12 de Febrero de 2013, 15:17:52
Buenas a todos,

Tras sacar un poco tiempo he podido hacer pruebas con el Bus CAN, y la verdad que no son buenas noticias.

He conectado la BUS MONITOR MCP2515 de microchip para enviar tráfico, esnifarlo y verlo en el PC.

He empezado haciendo pruebas enviando tramas para que mi tarjeta las reciba.

Pero no recibía nada.
Tras realizar un debug he comprobado que no entra en la interrupción para atenderla.
Me he puesto a revisar el Hardware y nada, está bien, la trama llega al pin del PIC32MX534F064H. (Mirado por osciloscopio).

Creo que puede ser por lo siguiente:

Software:

No está bien configurada el CAN y sobre todo el tema de las interrupciones. Os pego el código de la transmisión y de la interrupción para ver si me podeis ayudar, que por más que lo miro lo veo bien.

Código: C
  1. void CAN1Init(void)
  2. {
  3.     CAN_BIT_CONFIG canBitConfig;
  4.     UINT baudPrescalar;
  5.  
  6.     /*Ponemos el módulo CAN en modo configuración*/
  7.     CANEnableModule(CAN1,TRUE);
  8.     CANSetOperatingMode(CAN1, CAN_CONFIGURATION);
  9.     /*Esperamos hasta que entre en modo configuración*/
  10.     while(CANGetOperatingMode(CAN1) != CAN_CONFIGURATION);
  11.  
  12.     /*Configuramos el reloj del módulo CAN*/
  13.     canBitConfig.phaseSeg2Tq            = CAN_BIT_3TQ;
  14.     canBitConfig.phaseSeg1Tq            = CAN_BIT_3TQ;
  15.     canBitConfig.propagationSegTq       = CAN_BIT_3TQ;
  16.     canBitConfig.phaseSeg2TimeSelect    = TRUE;
  17.     canBitConfig.sample3Time            = FALSE;
  18.     canBitConfig.syncJumpWidth          = CAN_BIT_1TQ;
  19.  
  20.     CANSetSpeed(CAN1,&canBitConfig,SYSTEM_FREQ,CAN_BUS_SPEED);
  21.  
  22.     /*Asignamos el tamaño del Búfer*/
  23.     CANAssignMemoryBuffer(CAN1,CAN1MessageFifoArea,(2 * 8 * 16));
  24.  
  25.     /*Seleccionamos las FIFOS                     */
  26.     /*FIFO0 para Tx                               */
  27.     /*FIFO1 para Rx                               */
  28.     /*FIFO0 con RTR deshabilitado y prioridad baja*/
  29.     /*FIFO1 recepción del mensaje completo*/
  30.     CANConfigureChannelForTx(CAN1, CAN_CHANNEL0, 8, CAN_TX_RTR_DISABLED, CAN_LOW_MEDIUM_PRIORITY);
  31.     CANConfigureChannelForRx(CAN1, CAN_CHANNEL1, 8, CAN_RX_FULL_RECEIVE);
  32.  
  33.     /*Configuramos Filtros y máscaras         */
  34.     /*Filtro0 para aceptar SID 0x201          */
  35.     /*Máscara0 para comparar todos los ID     */
  36.     /*El mensaje debe ser almacenado en FIFO1 */
  37.     CANConfigureFilter      (CAN1, CAN_FILTER0, 0x001, CAN_SID);
  38.     CANConfigureFilterMask  (CAN1, CAN_FILTER_MASK0, 0x7FC, CAN_SID, CAN_FILTER_MASK_IDE_TYPE);
  39.     CANLinkFilterToChannel  (CAN1, CAN_FILTER0, CAN_FILTER_MASK0, CAN_CHANNEL1);
  40.     CANEnableFilter         (CAN1, CAN_FILTER0, TRUE);
  41.  
  42.     /*Habilitamos interrupciones y eventos      */
  43.     /*Habilitamos la recepción si hay un evento */
  44.     /*Habilitamos la interrupción               */
  45.     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, TRUE);
  46.     CANEnableModuleEvent (CAN1, CAN_RX_EVENT, TRUE);
  47.  
  48.     INTSetVectorPriority(INT_CAN_1_VECTOR, INT_PRIORITY_LEVEL_4);
  49.     INTSetVectorSubPriority(INT_CAN_1_VECTOR, INT_SUB_PRIORITY_LEVEL_0);
  50.     //INTEnable(INT_CAN1, INT_ENABLED);
  51.     IEC1SET = 0x04000000;
  52.  
  53.     /*Ponemos el módulo CAN en modo normal */
  54.     CANSetOperatingMode(CAN1, CAN_NORMAL_OPERATION);
  55.     while(CANGetOperatingMode(CAN1) != CAN_NORMAL_OPERATION);
  56.  
  57.     CANClearModuleEvent(CAN1, CAN_OPERATION_MODE_CHANGE_EVENT);
  58.  
  59. }
  60.  
  61. void __ISR (_CAN_1_VECTOR, ipl4) CAN1Interrupt(void)
  62. {
  63.     /*Verifica si hay un evento en la recepción*/
  64.     if((CANGetModuleEvent(CAN1) & CAN_RX_EVENT) != 0)
  65.     {
  66.         /*Se podría verificar que causó el evento mediante*/
  67.         /*CANGetModuleEvent(), que devuelve el código     */
  68.         /*que representa la prioridad más alta del evento */
  69.         /*pendiente                                       */
  70.                 if(CANGetPendingEventCode(CAN1) == CAN_CHANNEL1_EVENT)
  71.                 {
  72.                     /*Verificamos si se ha producido un evento en la FIFO1    */
  73.                     /*El evento CAN_RX_CHANNEL_NOT_EMPTY es persistente       */
  74.                     /*Se puede leer la FIFO por la interrupción para borrar   */
  75.                     /*la condición de evento o deshabilitar el origen de      */
  76.                     /*de los eventos y hacerlo mediante una función como aquí */
  77.  
  78.                     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, FALSE);
  79.                     messageRx = (CANRxMessageBuffer *)CANGetRxMessage(CAN1,CAN_CHANNEL1);
  80.                     CANUpdateChannel(CAN1, CAN_CHANNEL1);
  81.                     CANClearModuleEvent (CAN1, CAN_RX_EVENT);
  82.                 }
  83.     }
  84.     /*Se borra la bandera de la interrupción  */
  85.     INTClearFlag(INT_CAN1);
  86. }

Os pego tambien el inicio del main por si tuviese algo que ver:
Código: C
  1. void main (void){
  2.  
  3.     /*Ponemos los puertos Analógicos-Digitales*/
  4.     AD1PCFG = 0xFFFF;
  5.     /*Pin del Led como salida*/
  6.     _TRISF3=0;
  7.     _LATF3 = 0;
  8.     /*Pines del CAN como entrada y Salida Respectivamente.*/
  9.     _TRISF0=1; //Tx
  10.     _TRISF1=0;//Entrada
  11.  
  12.     INTEnableSystemMultiVectoredInt();
  13.  
  14.     /*Configuramos CAN1*/
  15.     CAN1Init();
  16.  
  17.  
  18.     while(1){
  19. .....
  20. .....

Respecto al Hardware, creo que puede ser debido a los voltios, me explico, el pic lo tengo alimentado a 3,3V.
El transceiver MCP2551 a 5V
Y entre el pic y el transceiver, la conexión de Tx a Tx y Rx a Rx tengo unos diodos alimentados a 5V para que cuando se reciba se encienda el Led, (En este caso lo hace cuando recibo).

Puede ser que esos 5 voltios hagan que no funcionen bien con los 3,3V del micro??

Un saludo.

POSDATA: se me olvidaba comentar que la fsystema es de 80MHz, y la velocidad del CAN 125000. Los can de la placa MCP2515 está igual.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Febrero de 2013, 16:27:58
Una pregunta importante, cual es la velocidad de reloj ??
Tiene habilitado el PLL4 ??
Como calculaste la velocidad ??

Recuerda que una buena parte del protocolo la resuelve el hardware, una vez configurado, rechaza mensajes si no responden al baudrate programado, por lo tanto debes mirar muy bien esto, ya que nunca ocurrirá la interrupción siquiera...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 12 de Febrero de 2013, 16:31:03
80MHz la frecuencia del reloj y la de los periféricos.

No utilizo oscilador externos. uso el interno.

/*Fsys = 80MHz */
/*Fpb = 80MHz  */
#pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_1, FWDTEN = OFF
#pragma config POSCMOD = HS, FNOSC = PRIPLL, FPBDIV = DIV_1

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Febrero de 2013, 16:32:57
O sea que el CAN tiene reloj de 80 mhz.
Y que velocidad del bus elejiste usar ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 12 de Febrero de 2013, 16:36:32

#define CAN_BUS_SPEED 125000

La le he liado ahí??

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Febrero de 2013, 16:42:05
No, esa velocidad esta bien, pero tienes mal el segmento Propagation Delay, con un Time Quante de 3 cuando debiera ser de 1...


Citar

    /*Configuramos el reloj del módulo CAN*/
    canBitConfig.phaseSeg2Tq            = CAN_BIT_3TQ;
    canBitConfig.phaseSeg1Tq            = CAN_BIT_3TQ;
    canBitConfig.propagationSegTq       = CAN_BIT_3TQ;    <-------------------<<  Aqui esta tu problema !!  Ponle solo uno
    canBitConfig.phaseSeg2TimeSelect    = TRUE;
    canBitConfig.sample3Time            = FALSE;
    canBitConfig.syncJumpWidth          = CAN_BIT_1TQ;

Como regla de oro:
La suma de Time Quanta de los cuatro valores debe dar igual al prescripto como Number of Time Quanta in one bit
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 12 de Febrero de 2013, 16:53:04
Para usar el hardware del MCP2515 tengo que ajustarme a las siguientes especificaciones:

Bus Speed: 125kbps
Q=10, S1 =3, S2=3, SP=70%, SJW=1.

No sería con 3??
Si pongo 1 sería para Q=8, no??


Muchas gracias por responder tan rápido.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Febrero de 2013, 17:34:11
Tienes el PIC32 conectado detras de un MCP2515 ??
Si es asi hay que ver que frecuencia usa el MCP2515.

O el PIC32 usa su modulo CAN propio ??

Porque no pones tu circuito, aunque sea a mano, para revisarlo ??

Aquí va el calculo si usas 10 TQ, sigue dando 1 para PrpSeg, ahora da 5 para S1, 3 para S2 y 1 en SJW.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 12 de Febrero de 2013, 17:38:49
El micro trae su propio CAN.

A ver si se poner el circuito aquí.


(http://www.todopic.com.ar/foros/imgtiny/33dh952.jpg)

Probaré con esos nuevos cálculos. Lo malo que no podré probarlo hasta dentro de una semana. Pero lo cambio ahora mismo.

A ver si viendo el circuitos podeis ver algún fallo HW.

Muchas gracias.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Febrero de 2013, 17:44:58
Ponlo e otro formato de mas resolución, si se agranda no se lee y así tampoco va.
Si el archivo queda muy grande, puedes subirlo a un hosting de imágenes y de allí pegar la ruta aquí...

porque no podrás probar hasta una semana??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 12 de Febrero de 2013, 17:55:43
Porque el MCP251 5está en la Universidad, y yo con el trabajo no voy a poder ir antes pues no me cuadran los horarios.

A ver si puedo subir la imagen mejor.


(http://www.todopic.com.ar/foros/imgtiny/25zzq.jpg)

Un slaudo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Febrero de 2013, 18:00:03
No se ven detalles de hardware, y la conexión del MCP2551 esta bien hecha.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 12 de Febrero de 2013, 18:05:04
He adjuntado un pdf donde se encuentra el circuito a ver si así puedes ver mejor el circuito completo.

Muchas gracias por la ayuda.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Febrero de 2013, 18:12:31
Sigo sin encontrar problemas, aunque déjame indicarte algo, que veo has pasado por alto.
Si usas el oscilador interno, puede que por alguna razón en el tiempo necesites usar un cristal externo, deja el espacio y dibujo en placa para ubicarlo, de otro modo a futuro puedes arrepentirte.

No necesitas el MCP2515 para probarlo, ponlo en modo Loopback y ya lo tienes para pruebas.
Tendrás que mandarte mensajes a ti mismo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 12 de Febrero de 2013, 18:16:38
Gracias por el consejo.

Estuve mirando y en modo loopback no utiliza el bus, pero bueno, bastante pruebas he hecho hoy como para ver que no es cosa del bus.

Tal y como lo tengo, con poner en lugar de modo normal, en loopback ya valdría??Es decir, él sabe que lo que envía lo va a recibir??

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 12 de Febrero de 2013, 18:19:44
Pruebalo y me avisas, ya que nunca lo use así.
Hay algunas respuestas en este hilo, de hace no mas de 6 meses atrás, donde alguien lo uso.
Igual te valdrá para saber si esta bien configurado....
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 13 de Febrero de 2013, 07:30:00
Ahora no encuentro donde se habló del modo Loopback.
Seguiré intentandolo.

Esta noche no he logrado soñar con la solución (como nunca), pero si me ha surgido una duda, aunque creo que la tengo resuelta.

la board MCP2515 tendré que configurarla tambien con los mismo bit time, no??

Y no valdría el bit time que calculé yo??por??

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Febrero de 2013, 08:49:19
No confundas las cosas, en el Bus CAN cada dispositivo debe tener programada la misma velocidad, en tu caso 125 Kbps.
Eso no quiere decir que todos se configuran igual, ya que ello depende de que dispositivo es (cambia entre linea PIC18Fx58 y PIC18Fx58x y también con MCP2515) y ademas del cristal y frecuencia interna a la cual oscila el microcontrolador o el MCP2515, en tu caso.

Para el Sniffer de Microchip, solo deberías cambiar el baudrate ya que tiene su propio menú de configuración en el software.
Y luego si tienes mas de un PIC implementando nodos, por supuesto deberás calcularlos a todos , cada uno por su lado....
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 13 de Febrero de 2013, 08:57:56
OK, pensaba que si el SW de Microchip pone S1 = 3TQ, S2 = 3TQ tambien debería ponerlo en mi micro, por eso lo hice así.

Espero que sea eso...en cuanto saque algo de tiempo lo pruebo en LoopBack.
No me suena ahora mismo la opción de modificar el baudrate.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Febrero de 2013, 09:19:05
Bajate el software Microchip CAN Bit Timing Calculator, de Intrepid Control System MB Time Calculator (http://intrepidcs.com/support/mbtime.htm), y prueba ir configurando segun el dispositivo y velocidad de clock, aprenderas mucho usandolo, y lo que es mejor, fijaras muy bien el concepto de calculo de velocidad de cada nodo del BUS.
Una vez que lo consigas, veras que ya le pierdes el respeto... :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 13 de Febrero de 2013, 09:35:03
Pues me lo descargué hace tiempo (cuando empecé) con el CAN. Y lo utilicé en su momento para ver como funcionaba...pero cuando empecé con la configuración del CAN lo obvie y lo configuré como el del 2515 (pues pensaba que tenía que ser igual).

Un slaudo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Febrero de 2013, 09:57:07
No se que calculo hacen (tal vez muestran otra cosa), porque con cristal de 20 MHz en el MCP2515 (segun el diagrama del manual) es muy raro como lo configuran.
Igual ellos pueden usar el valor 3 alli, pero si miras en el calculador, prefieren usar 5 en el segmento 1, para ese Quanta.

Y eso esta basado en el mismo documento de Microchip, de como seleccionar el Baudrate. :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 13 de Febrero de 2013, 10:00:29
Bueno, primero probare con Loopback que seguro que me da tiempo antes de ir al laboratorio.

Supongo que el funcionamiento será el mismo, quiero decir, las interrupciones, etc....

Os mantendré informados.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 13 de Febrero de 2013, 15:59:12
Otra duda que tengo es sobre la memoria FIFO, el tamaño que hay que asignar a las FIFOS, en este caso, como en el ejemplo de microchip asigno:

BYTE CAN1MessageFifoArea[2 * 8 * 16];

He de suponer que 2 porque son dos fifos, una para Tx y una para Rx.
8 por los octetos.
Y 16??

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Febrero de 2013, 16:11:32
Cual es la razon por ahora de liarte con los fifo, cuando aun no has podido recepcionar tu primer Hola, mundo!!

Los toreros arrancan con un pequeño ternero, antes de llegar al toro malo, en tu caso deberías ir haciendo tus primeras cruces en esto, paso a paso.
Ya habra tiempo de meterte en ese barro, pero solo cuando las comunicaciones no representen un problema para ti.
El Quijote encaro los molinos de viento y mira como le fue !! :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 13 de Febrero de 2013, 16:25:35
Jejejeje, llevas razón, pues porque veo el código que tengo y aprovecho y digo todas las dudas, jejejej.

Pues he estado haciendo pruebas con el LOOPBACK, bueno, intentandolo, y nada, nunca llega a operar como loopback, se me queda en el while

CANSetOperatingMode(CAN1, CAN_NORMAL_OPERATION);
while(CANGetOperatingMode(CAN1) != CAN_LOOPBACK);

Tengo que buscar el post donde el compañero explicaba el loopback.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 13 de Febrero de 2013, 16:51:02
En la primer instrucción lo estas poniendo en modo Normal, y en la segunda le estas diciendo que espere estar en modo LoopBack !!
Nunca va a ocurrir !!
 :mrgreen: :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 14 de Febrero de 2013, 05:32:30
MGLSOFT ayer cuando leí tu respuesta no daba crédito....
A si que decidí que era mejor dejarlo para otro día y que me relajase un poco pues no estaba pensando correctamente, jejejej.

Lo probaré hoy.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 14 de Febrero de 2013, 16:12:33
Corregido el error infantil, le doy a correr el programa en modo debug, pongo puntos de ruptura, apareciendo el cuadradito rojo en el MPLAB X, pero cuando le doy a correr el programa algunos puntos de ruptura aparecen rotos, ¿Por qué?

Segundo, partiendo del modo Loopback, y que si que entra en la función para transmitir,..., no salta la interrupción a la recepción.

 :shock:  :5]

Código: C
  1. #include <p32xxxx.h>
  2. #include <stdio.h>
  3. #include <stdlib.h>
  4. #include <plib.h>
  5. //#include <peripheral\system.h>
  6. #include <peripheral\CAN.h>
  7. #include "GenericTypeDefs.h"
  8.  
  9.  
  10.  
  11.  
  12. #define SYSTEM_FREQ 80000000
  13. #define CAN_BUS_SPEED 125000
  14.  
  15. /*Fsys = 80MHz */
  16. /*Fpb = 80MHz  */
  17. #pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_1, FWDTEN = OFF
  18. #pragma config POSCMOD = HS, FNOSC = PRIPLL, FPBDIV = DIV_1
  19.  
  20. BYTE CAN1MessageFifoArea[2 * 8 * 16];
  21. BOOL isCAN1MsgReceived = FALSE;
  22. CANRxMessageBuffer * messageRx;
  23. CANTxMessageBuffer * messageTx;
  24. int prueba=0;
  25.  
  26.  
  27. void CAN1Init(void);
  28. void CAN1TxSendRTRMsg(void);
  29.  
  30.  
  31. /************************************/
  32. /************************************/
  33. /* Función Principal                */
  34. /************************************/
  35. /************************************/
  36.  
  37. void main (void){
  38.  
  39.     /*Ponemos los puertos Analógicos-Digitales*/
  40.     AD1PCFG = 0xFFFF;
  41.     /*Pin del Led como salida*/
  42.     _TRISF3=0;
  43.     _LATF3 = 0;
  44.     /*Pines del CAN como entrada y Salida Respectivamente.*/
  45.     _TRISF0=1;
  46.     _TRISF1=0;
  47.  
  48.     INTEnableSystemMultiVectoredInt();
  49.  
  50.     /*Configuramos CAN1*/
  51.     CAN1Init();
  52.     prueba=0;
  53.  
  54.  
  55.     while(1){
  56.         if(prueba==0){
  57.             CAN1TxSendRTRMsg();
  58.         }
  59.         //CAN1TxSendRTRMsg();
  60.         //CAN1RxMsgProcess();
  61.         /*Verificamos si Tx = Rx*/
  62.         if ((messageRx->messageWord[2]==0)){
  63.             _LATF3 = 1;
  64.         }
  65.         else
  66.             _LATF3 = 0;
  67.     }
  68. }
  69.  
  70.  
  71.  
  72.  
  73. /***************************/
  74. /***************************/
  75. /*Configuración del Bus CAN*/
  76. /***************************/
  77. /***************************/
  78.  
  79. void CAN1Init(void)
  80. {
  81.     CAN_BIT_CONFIG canBitConfig;
  82.     UINT baudPrescalar;
  83.  
  84.     /*Ponemos el módulo CAN en modo configuración*/
  85.     CANEnableModule(CAN1,TRUE);
  86.     CANSetOperatingMode(CAN1, CAN_CONFIGURATION);
  87.     /*Esperamos hasta que entre en modo configuración*/
  88.     while(CANGetOperatingMode(CAN1) != CAN_CONFIGURATION);
  89.  
  90.     /*Configuramos el reloj del módulo CAN*/
  91.     canBitConfig.phaseSeg2Tq            = CAN_BIT_3TQ;
  92.     canBitConfig.phaseSeg1Tq            = CAN_BIT_5TQ;
  93.     canBitConfig.propagationSegTq       = CAN_BIT_1TQ;
  94.     canBitConfig.phaseSeg2TimeSelect    = TRUE;
  95.     canBitConfig.sample3Time            = FALSE;
  96.     canBitConfig.syncJumpWidth          = CAN_BIT_1TQ;
  97.  
  98.     CANSetSpeed(CAN1,&canBitConfig,SYSTEM_FREQ,CAN_BUS_SPEED);
  99.  
  100.     /*Asignamos el tamaño del Búfer*/
  101.     CANAssignMemoryBuffer(CAN1,CAN1MessageFifoArea,(2 * 8 * 16));
  102.  
  103.     /*Seleccionamos las FIFOS                     */
  104.     /*FIFO0 para Tx                               */
  105.     /*FIFO1 para Rx                               */
  106.     /*FIFO0 con RTR deshabilitado y prioridad baja*/
  107.     /*FIFO1 recepción del mensaje completo*/
  108.     CANConfigureChannelForTx(CAN1, CAN_CHANNEL0, 8, CAN_TX_RTR_DISABLED, CAN_LOW_MEDIUM_PRIORITY);
  109.     CANConfigureChannelForRx(CAN1, CAN_CHANNEL1, 8, CAN_RX_FULL_RECEIVE);
  110.  
  111.     /*Configuramos Filtros y máscaras         */
  112.     /*Filtro0 para aceptar SID 0x201          */
  113.     /*Máscara0 para comparar todos los ID     */
  114.     /*El mensaje debe ser almacenado en FIFO1 */
  115.     CANConfigureFilter      (CAN1, CAN_FILTER0, 0x001, CAN_SID);
  116.     CANConfigureFilterMask  (CAN1, CAN_FILTER_MASK0, 0x7FC, CAN_SID, CAN_FILTER_MASK_IDE_TYPE);
  117.     CANLinkFilterToChannel  (CAN1, CAN_FILTER0, CAN_FILTER_MASK0, CAN_CHANNEL1);
  118.     CANEnableFilter         (CAN1, CAN_FILTER0, TRUE);
  119.  
  120.     /*Habilitamos interrupciones y eventos      */
  121.     /*Habilitamos la recepción si hay un evento */
  122.     /*Habilitamos la interrupción               */
  123.     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, TRUE);
  124.     CANEnableModuleEvent (CAN1, CAN_RX_EVENT, TRUE);
  125.  
  126.     INTSetVectorPriority(INT_CAN_1_VECTOR, INT_PRIORITY_LEVEL_4);
  127.     INTSetVectorSubPriority(INT_CAN_1_VECTOR, INT_SUB_PRIORITY_LEVEL_0);
  128.     INTEnable(INT_CAN1, INT_ENABLED);
  129.     //IEC1SET = 0x04000000;
  130.  
  131.     /*Ponemos el módulo CAN en modo normal */
  132.     CANSetOperatingMode(CAN1, CAN_LOOPBACK);
  133.     while(CANGetOperatingMode(CAN1) != CAN_LOOPBACK);
  134.  
  135.     CANClearModuleEvent(CAN1, CAN_OPERATION_MODE_CHANGE_EVENT);
  136.  
  137. }
  138.  
  139.  
  140.  
  141.  
  142. /***************************************************/
  143. /***************************************************/
  144. /*Función para enviar un mensaje al bus CAN        */
  145. /***************************************************/
  146. /***************************************************/
  147.  
  148. void CAN1TxSendRTRMsg(void)
  149. {
  150.     //CANTxMessageBuffer * messageTx;//Lo saco a variable global
  151.  
  152.     /*Actualizamos el índice en la FIFO0 */
  153.     messageTx = CANGetTxMessageBuffer(CAN1,CAN_CHANNEL0);
  154.  
  155.     /*Mensaje a enviar */
  156.     messageTx->messageWord[0] = 0;
  157.     messageTx->messageWord[1] = 0;
  158.     messageTx->messageWord[2] = 0;
  159.     messageTx->messageWord[3] = 0;
  160.  
  161.     messageTx->msgSID.SID = 0x201;
  162.     messageTx->msgEID.IDE = 0;
  163.     messageTx->msgEID.RTR = 1;
  164.     messageTx->msgEID.DLC = 0;
  165.  
  166.     /*Actualizamos el índice a la nueva posición de la FIFO0*/
  167.     CANUpdateChannel(CAN1,CAN_CHANNEL0);
  168.  
  169.     /*Limpiamos la FIFO0 permitiendo enviar cualquier mensaje de Tx*/
  170.     CANFlushTxChannel(CAN1,CAN_CHANNEL0);
  171. }
  172.  
  173.  
  174.  
  175.  
  176. /***************************************************/
  177. /***************************************************/
  178. /*Manejador de la interrupción del CAN1            */
  179. /*Todos los eventos se habilitan en CanEnableEvent */
  180. /*En este caso un evento en la recepción           */
  181. /***************************************************/
  182. /***************************************************/
  183.  
  184. void __ISR (_CAN_1_VECTOR, ipl4) CAN1Interrupt(void)
  185. {
  186.     /*Verifica si hay un evento en la recepción*/
  187.     if((CANGetModuleEvent(CAN1) & CAN_RX_EVENT) != 0)
  188.     {
  189.         /*Se podría verificar que causó el evento mediante*/
  190.         /*CANGetModuleEvent(), que devuelve el código     */
  191.         /*que representa la prioridad más alta del evento */
  192.         /*pendiente                                       */
  193.                 if(CANGetPendingEventCode(CAN1) == CAN_CHANNEL1_EVENT)
  194.                 {
  195.                     /*Verificamos si se ha producido un evento en la FIFO1    */
  196.                     /*El evento CAN_RX_CHANNEL_NOT_EMPTY es persistente       */
  197.                     /*Se puede leer la FIFO por la interrupción para borrar   */
  198.                     /*la condición de evento o deshabilitar el origen de      */
  199.                     /*de los eventos y hacerlo mediante una función como aquí */
  200.                     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, FALSE);
  201.                     messageRx = (CANRxMessageBuffer *)CANGetRxMessage(CAN1,CAN_CHANNEL1);
  202.                     CANUpdateChannel(CAN1, CAN_CHANNEL1);
  203.                     CANClearModuleEvent (CAN1, CAN_RX_EVENT);
  204.                     prueba=1;
  205.                 }
  206.     }
  207.     /*Se borra la bandera de la interrupción  */
  208.     /*Siempre al final para que si se produce */
  209.     /*otra interrupción no tenga efecto       */
  210.     INTClearFlag(INT_CAN1);
  211. }
Desmoralizado me hallo.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2013, 16:24:15
No, esa velocidad esta bien, pero tienes mal el segmento Propagation Delay, con un Time Quante de 3 cuando debiera ser de 1...


Citar

    /*Configuramos el reloj del módulo CAN*/
    canBitConfig.phaseSeg2Tq            = CAN_BIT_3TQ;
    canBitConfig.phaseSeg1Tq            = CAN_BIT_3TQ;
    canBitConfig.propagationSegTq       = CAN_BIT_3TQ;    <-------------------<<  Aqui esta tu problema !!  Ponle solo uno
    canBitConfig.phaseSeg2TimeSelect    = TRUE;
    canBitConfig.sample3Time            = FALSE;
    canBitConfig.syncJumpWidth          = CAN_BIT_1TQ;

Como regla de oro:
La suma de Time Quanta de los cuatro valores debe dar igual al prescripto como Number of Time Quanta in one bit

Hasta aquí habíamos llegado antes...

Pero aquí haces otra cosa distinta, Porque ??


Citar
canBitConfig.phaseSeg2Tq            = CAN_BIT_3TQ;
    canBitConfig.phaseSeg1Tq            = CAN_BIT_5TQ;
    canBitConfig.propagationSegTq       = CAN_BIT_1TQ;
    canBitConfig.phaseSeg2TimeSelect    = TRUE;
    canBitConfig.sample3Time            = FALSE;
    canBitConfig.syncJumpWidth          = CAN_BIT_1TQ;

No entiendo porque llegas a este valor de 5.
Es por mi comentario sobre el analizador CAN ??
Ese comentario era valido solo para el analizador CAN, no para el PIC !!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 14 de Febrero de 2013, 16:30:56
Comooorrr?? :oops: :oops: :oops:

Dejame que me apunte en la agenda pedirme vacaciones, jejejej

OK, pues entonces tenía bien el bit time que puse al principio, no??

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2013, 16:37:20
Ponle este:

Citar

    canBitConfig.phaseSeg2Tq                 = CAN_BIT_3TQ;
    canBitConfig.phaseSeg1Tq                 = CAN_BIT_3TQ;
    canBitConfig.propagationSegTq          = CAN_BIT_1TQ;
    canBitConfig.phaseSeg2TimeSelect    = TRUE;
    canBitConfig.sample3Time                  = FALSE;
    canBitConfig.syncJumpWidth              = CAN_BIT_1TQ;

 :mrgreen: :mrgreen:  Es el dia de los enamorados !!
Eso te pasa!!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 14 de Febrero de 2013, 16:56:18
Bueno ya está cambiado:

tras hacer el while la primera vez del main:

Código: C
  1. while(1){
  2.         if(prueba==0){
  3.             CAN1TxSendRTRMsg();
  4.         }
  5.         //CAN1TxSendRTRMsg();
  6.         //CAN1RxMsgProcess();
  7.         /*Verificamos si Tx = Rx*/
  8.         if ((messageRx->messageWord[2]==0)){
  9.             _LATF3 = 1;
  10.         }
  11.         else
  12.             _LATF3 = 0;
  13.     }
Se para el debug indicando Target Halted, y no se donde. Pues no debería parar creo yo.
Aún así...tampoco atiende a la interrupción.

Tengo que decir, que en el HW no  uno a la salida del Transceiver MCP2551 Rx - Tx de ninguna manera, (ni a la entrada)...pues en el manual dice que no utiliza el bus.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 14 de Febrero de 2013, 17:08:46
Tampoco entiendo por qué nada más iniciar el debugg el punto de ruptura de la interrupción...entra en un estado "extraño"

(http://www.todopic.com.ar/foros/imgtiny/21ccn61.jpg)

Sin ni siguiera llegar correr el debugg

En cambio otros (por los que paso a paso termina llegando a él) tienen el formato correcto:

(http://www.todopic.com.ar/foros/imgtiny/2h4z79g.jpg)

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2013, 17:15:44
El primero es un breakpoint roto.
Has comentado una linea que tenia un breakpoint, sacalo y listo.

Por lo demas, deberias ir corriendo los breakpoints de lugar hasta ver que ejecuta y que no.

Si pasa la linea del envio del mensaje, barbaro, sino hay un problema.

Algo que puede estar pasandote es que habilitas los filtros y mascaras, y si no estan preparados para recibir el ID del mensaje enviado, este no pasara, por lo tanto no habra interrupcion tampoco.
Te diria que los dejes con valores 0 a todos, asi eliminas esa posibilidad (lo vi pero no lo comente antes, para no hacerte mas lio del que ya tenias)...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 14 de Febrero de 2013, 17:18:15
Jejejej, y del que sigo teniendo, pero vamos poco a poco.
Si...está en una línea comentada. pero vamos porque lo único que quería es ver si entraba en la interrupción y lo puse donde primero pillé

pues voy a poner filtros y máscaras a cero a ver.
Si que pasa la línea de transmisión de un mensaje, se va a la función y termina dicha función, luego al if para comprobar el valor y ahí se fini.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 14 de Febrero de 2013, 17:37:09
Los filtros y las máscaras los he borrado, ya no están.
Ahora....sigue sin ir.

Os pego una imagen para que veais donde se para:

(http://www.todopic.com.ar/foros/imgtiny/2zjggnq.jpg)

Al punto de ruptura no llega, el siguiente paso de donde está ahora la línea....es perderse.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2013, 17:48:03
No tienes declarado cuantos datos envias (valor entre 0 y 8) en el mensaje, mira la variable DLC como la cargas.

Citar
 /*Mensaje a enviar */
    messageTx->messageWord[0] = 0;
    messageTx->messageWord[1] = 0;
    messageTx->messageWord[2] = 0;
    messageTx->messageWord[3] = 0;
 
    messageTx->msgSID.SID = 0x201;
    messageTx->msgEID.IDE = 0;
    messageTx->msgEID.RTR = 1;
    messageTx->msgEID.DLC = 0;

Si lo que intentas es enviar 4 datos, DLC deberia ser igual a 4...

Ademas pones el bit RTR en 1, eso obliga a contestar y no tiene que contestar. Ponlo en 0.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 14 de Febrero de 2013, 18:06:28
Ya está puesto, si no te digo que he hecho tantas modificaciones al que hice que ya no se ni que hago.

Pues nada, sigue sin ir. Y lo raro es que se pierde en el while cuando debería estar ahí en el bucle infinitamente.
Ya por hoy desisto.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2013, 18:12:53
Pega el código que tienes de nuevo, así le doy otra leída mas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 14 de Febrero de 2013, 18:26:59
Muchas gracias por la ayuda MGLSOFT, y perdona el tiempo que te estoy quitando.

Código: C
  1. #include <p32xxxx.h>
  2. #include <stdio.h>
  3. #include <stdlib.h>
  4. #include <plib.h>
  5. //#include <peripheral\system.h>
  6. #include <peripheral\CAN.h>
  7. #include "GenericTypeDefs.h"
  8.  
  9.  
  10.  
  11.  
  12. #define SYSTEM_FREQ 80000000
  13. #define CAN_BUS_SPEED 125000
  14.  
  15. /*Fsys = 80MHz */
  16. /*Fpb = 80MHz  */
  17. #pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_1, FWDTEN = OFF
  18. #pragma config POSCMOD = HS, FNOSC = PRIPLL, FPBDIV = DIV_1
  19.  
  20. BYTE CAN1MessageFifoArea[2 * 8 * 16];
  21. BOOL isCAN1MsgReceived = FALSE;
  22. CANRxMessageBuffer * messageRx;
  23. CANTxMessageBuffer * messageTx;
  24. int prueba=0;
  25.  
  26.  
  27. void CAN1Init(void);
  28. void CAN1TxSendRTRMsg(void);
  29.  
  30.  
  31. /************************************/
  32. /************************************/
  33. /* Función Principal                */
  34. /************************************/
  35. /************************************/
  36.  
  37. void main (void){
  38.  
  39.     /*Ponemos los puertos Analógicos-Digitales*/
  40.     AD1PCFG = 0xFFFF;
  41.     /*Pin del Led como salida*/
  42.     _TRISF3=0;
  43.     _LATF3 = 0;
  44.     /*Pines del CAN como entrada y Salida Respectivamente.*/
  45.    _TRISF0=1;
  46.    _TRISF1=0;
  47.  
  48.     INTEnableSystemMultiVectoredInt();
  49.  
  50.     /*Configuramos CAN1*/
  51.     CAN1Init();
  52.     prueba=0;
  53.  
  54.  
  55.     while(1){
  56.         if(prueba==0){
  57.             CAN1TxSendRTRMsg();
  58.         }
  59.         //CAN1TxSendRTRMsg();
  60.         //CAN1RxMsgProcess();
  61.         /*Verificamos si Tx = Rx*/
  62.         if ((messageRx->messageWord[2]==0)){
  63.             _LATF3 = 1;
  64.         }
  65.         else
  66.             _LATF3 = 0;
  67.     }
  68. }
  69.  
  70.  
  71.  
  72.  
  73. /***************************/
  74. /***************************/
  75. /*Configuración del Bus CAN*/
  76. /***************************/
  77. /***************************/
  78.  
  79. void CAN1Init(void)
  80. {
  81.     CAN_BIT_CONFIG canBitConfig;
  82.     UINT baudPrescalar;
  83.  
  84.     /*Ponemos el módulo CAN en modo configuración*/
  85.     CANEnableModule(CAN1,TRUE);
  86.     CANSetOperatingMode(CAN1, CAN_CONFIGURATION);
  87.     /*Esperamos hasta que entre en modo configuración*/
  88.     while(CANGetOperatingMode(CAN1) != CAN_CONFIGURATION);
  89.  
  90.     /*Configuramos el reloj del módulo CAN*/
  91.     canBitConfig.phaseSeg2Tq            = CAN_BIT_3TQ;
  92.     canBitConfig.phaseSeg1Tq            = CAN_BIT_3TQ;
  93.     canBitConfig.propagationSegTq       = CAN_BIT_1TQ;
  94.     canBitConfig.phaseSeg2TimeSelect    = TRUE;
  95.     canBitConfig.sample3Time            = FALSE;
  96.     canBitConfig.syncJumpWidth          = CAN_BIT_1TQ;
  97.  
  98.     CANSetSpeed(CAN1,&canBitConfig,SYSTEM_FREQ,CAN_BUS_SPEED);
  99.  
  100.     /*Asignamos el tamaño del Búfer*/
  101.     CANAssignMemoryBuffer(CAN1,CAN1MessageFifoArea,(2 * 8 * 16));
  102.  
  103.     /*Seleccionamos las FIFOS                     */
  104.     /*FIFO0 para Tx                               */
  105.     /*FIFO1 para Rx                               */
  106.     /*FIFO0 con RTR deshabilitado y prioridad baja*/
  107.     /*FIFO1 recepción del mensaje completo*/
  108.     CANConfigureChannelForTx(CAN1, CAN_CHANNEL0, 8, CAN_TX_RTR_DISABLED, CAN_LOW_MEDIUM_PRIORITY);
  109.     CANConfigureChannelForRx(CAN1, CAN_CHANNEL1, 8, CAN_RX_FULL_RECEIVE);
  110.  
  111.     /*Configuramos Filtros y máscaras         */
  112.     /*Filtro0 para aceptar SID 0x201          */
  113.     /*Máscara0 para comparar todos los ID     */
  114.     /*El mensaje debe ser almacenado en FIFO1 */
  115.     //CANConfigureFilter      (CAN1, CAN_FILTER0, 0x001, CAN_SID);
  116.     //CANConfigureFilterMask  (CAN1, CAN_FILTER_MASK0, 0x7FC, CAN_SID, CAN_FILTER_MASK_IDE_TYPE);
  117.     //CANLinkFilterToChannel  (CAN1, CAN_FILTER0, CAN_FILTER_MASK0, CAN_CHANNEL1);
  118.     //CANEnableFilter         (CAN1, CAN_FILTER0, TRUE);
  119.  
  120.     /*Habilitamos interrupciones y eventos      */
  121.     /*Habilitamos la recepción si hay un evento */
  122.     /*Habilitamos la interrupción               */
  123.     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, TRUE);
  124.     CANEnableModuleEvent (CAN1, CAN_RX_EVENT, TRUE);
  125.  
  126.     INTSetVectorPriority(INT_CAN_1_VECTOR, INT_PRIORITY_LEVEL_4);
  127.     INTSetVectorSubPriority(INT_CAN_1_VECTOR, INT_SUB_PRIORITY_LEVEL_0);
  128.     INTEnable(INT_CAN1, INT_ENABLED);
  129.     //IEC1SET = 0x04000000;
  130.  
  131.     /*Ponemos el módulo CAN en modo normal */
  132.     CANSetOperatingMode(CAN1, CAN_LOOPBACK);
  133.     while(CANGetOperatingMode(CAN1) != CAN_LOOPBACK);
  134.  
  135.     CANClearModuleEvent(CAN1, CAN_OPERATION_MODE_CHANGE_EVENT);
  136.  
  137. }
  138.  
  139.  
  140.  
  141.  
  142. /***************************************************/
  143. /***************************************************/
  144. /*Función para enviar un mensaje al bus CAN        */
  145. /***************************************************/
  146. /***************************************************/
  147.  
  148. void CAN1TxSendRTRMsg(void)
  149. {
  150.     //CANTxMessageBuffer * messageTx;//Lo saco a variable global
  151.  
  152.     /*Actualizamos el índice en la FIFO0 */
  153.     messageTx = CANGetTxMessageBuffer(CAN1,CAN_CHANNEL0);
  154.  
  155.     /*Mensaje a enviar */
  156.     messageTx->messageWord[0] = 0;
  157.     messageTx->messageWord[1] = 0;
  158.     messageTx->messageWord[2] = 0;
  159.     messageTx->messageWord[3] = 0;
  160.  
  161.     messageTx->msgSID.SID = 0x001;
  162.     messageTx->msgEID.IDE = 0;
  163.     messageTx->msgEID.RTR = 0;
  164.     messageTx->msgEID.DLC = 4;
  165.  
  166.     /*Actualizamos el índice a la nueva posición de la FIFO0*/
  167.     CANUpdateChannel(CAN1,CAN_CHANNEL0);
  168.  
  169.     /*Limpiamos la FIFO0 permitiendo enviar cualquier mensaje de Tx*/
  170.     CANFlushTxChannel(CAN1,CAN_CHANNEL0);
  171. }
  172.  
  173.  
  174.  
  175.  
  176. /***************************************************/
  177. /***************************************************/
  178. /*Manejador de la interrupción del CAN1            */
  179. /*Todos los eventos se habilitan en CanEnableEvent */
  180. /*En este caso un evento en la recepción           */
  181. /***************************************************/
  182. /***************************************************/
  183.  
  184. void __ISR (_CAN_1_VECTOR, ipl4) CAN1Interrupt(void)
  185. {
  186.     /*Verifica si hay un evento en la recepción*/
  187.     if((CANGetModuleEvent(CAN1) & CAN_RX_EVENT) != 0)
  188.     {
  189.         /*Se podría verificar que causó el evento mediante*/
  190.         /*CANGetModuleEvent(), que devuelve el código     */
  191.         /*que representa la prioridad más alta del evento */
  192.         /*pendiente                                       */
  193.                 if(CANGetPendingEventCode(CAN1) == CAN_CHANNEL1_EVENT)
  194.                 {
  195.                     /*Verificamos si se ha producido un evento en la FIFO1    */
  196.                     /*El evento CAN_RX_CHANNEL_NOT_EMPTY es persistente       */
  197.                     /*Se puede leer la FIFO por la interrupción para borrar   */
  198.                     /*la condición de evento o deshabilitar el origen de      */
  199.                     /*de los eventos y hacerlo mediante una función como aquí */
  200.                     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, FALSE);
  201.                     messageRx = (CANRxMessageBuffer *)CANGetRxMessage(CAN1,CAN_CHANNEL1);
  202.                     CANUpdateChannel(CAN1, CAN_CHANNEL1);
  203.                     CANClearModuleEvent (CAN1, CAN_RX_EVENT);
  204.                     prueba=1;
  205.                 }
  206.     }
  207.     /*Se borra la bandera de la interrupción  */
  208.     /*Siempre al final para que si se produce */
  209.     /*otra interrupción no tenga efecto       */
  210.     INTClearFlag(INT_CAN1);
  211. }

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Febrero de 2013, 19:00:53
Te faltan completar aperturas y cierres de llaves en el If-Else.

raro que no te grito el compilador!!

Citar
    while(1){    <------------------------<< abre nivel 1
        if(prueba==0){   <--------------<< abre nivel IF 1
            CAN1TxSendRTRMsg();
        }    >>----------------------->  cierra nivel IF 1
        //CAN1TxSendRTRMsg();
   //CAN1RxMsgProcess();
        /*Verificamos si Tx = Rx*/
        if ((messageRx->messageWord[2]==0)){  <-----------<< abre nivel IF 2
            _LATF3 = 1;
        }    >>----------------->     cierra nivel IF 2
        else              <--------------------<<  AQUI DEBIERAS ABRIR NIVEL ELSE 2
            _LATF3 = 0;
    }    >>--------------------->  Y AQUI CERRARLO, PERO TOMA ESTE COMO CIERRE DEL IF 2 O ALGO ASI, POR ESO SE VA DE VIAJE....

Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 15 de Febrero de 2013, 05:28:31
Buenos días,

Hoy no podré probar el código ya que por asuntos propios tengo que realizar un viaje, pero de mañana Sábado no pasa.

Creo que ahí no debe estar el fallo, pues al tener sólo un comando no es necesario poner los corchetes del else, por eso no me dio error, aún así los pondré y probaré. (Cuando he programado otros micros de otras marcas no habido problemas por eso.

Pensando un poco, creo que el problema puede estar en el Watchdog, que no está desactivado, no??
Lo pregunto porque no se como se desactiva el Watchdog del PIC.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 15 de Febrero de 2013, 05:48:58
Acabo de ver en el post de más arriba, donde configuro el reloj que tengo desactivado el Watchdog:

FWDTEN = OFF

Asi que descartada mi suposición.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Febrero de 2013, 08:41:05
Esta bien lo que dices, hay una sola instruccion, pero igual ponle la apertura y cierre.
A veces los compiladores hacen cosas raras...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 15 de Febrero de 2013, 08:46:28
Si es por eso...tengo que decir que es demasiado delicado el compilador.

Lo probaré en cuando pueda.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 16 de Febrero de 2013, 09:13:58
Nada, con los corchetes pasa exactamente lo mismo.

Puede ser que sea por el tratamiento de la estructura de los mensajes recibidos??

Código: C
  1. if ((messageRx->messageWord[2]==0)){

El problema es cuando llega al if, y apartir de ahí se pierde el debug y se para no se donde....
Voy a probar a crear una estructura, y en la interrupción asigno dichos valores a mi estructura recien creada para en el if tratar dicha estructura.

Ya no se me ocurren más cosas.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 17 de Febrero de 2013, 07:46:12
Buenas,

MGLSOFT  :-/ :-/ :-/.
He solucionado lo del while(1).

Me parece tristísimo que tenga que celebrar que hace un while(1), pero estas cosas tan obvias que funcionan siempre...cuando fallan dan una guerra.
Bueno, pues como puse en el post anterior, pensé que a la hora de realizar el segundo if, buscando la estructura de datos de la librería del CAN se perdía y no volvía en si.
Pues he creado una estructura y ahora el if es sobre esa estructura realizando el bucle infinito sin problemas.

ahora decir, que sigue sin entrar en la interrupción de las narices.
Seguiré mirando a ver que puede ser...he añadido una nueva línea, habilitando la Tx  :oops:
Pego el código por si podeis ayudarme, (Más todavía).

Código: C
  1. #include <p32xxxx.h>
  2. #include <stdio.h>
  3. #include <stdlib.h>
  4. #include <plib.h>
  5. //#include <peripheral\system.h>
  6. #include <peripheral\CAN.h>
  7. #include "GenericTypeDefs.h"
  8.  
  9.  
  10.  
  11.  
  12. #define SYSTEM_FREQ 80000000
  13. #define CAN_BUS_SPEED 125000
  14.  
  15. /*Fsys = 80MHz */
  16. /*Fpb = 80MHz  */
  17. #pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_1, FWDTEN = OFF
  18. #pragma config POSCMOD = HS, FNOSC = PRIPLL, FPBDIV = DIV_1
  19.  
  20.  
  21. typedef struct{
  22.     unsigned B0recibido:32;
  23.     //unsigned B1recibido:8;
  24.     //unsigned B2recibido:8;
  25.     //unsigned B3recibido:8;
  26.     //unsigned B4recibido:8;
  27.     //unsigned B5recibido:8;
  28.     //unsigned B6recibido:8;
  29.     //unsigned B7recibido:8;
  30. }TDatosRecibidos;
  31.  
  32.  
  33. BYTE CAN1MessageFifoArea[2 * 8 * 16];
  34. BOOL isCAN1MsgReceived = FALSE;
  35. int prueba=0;
  36.  
  37.  
  38. void CAN1Init(void);
  39. void CAN1TxSendRTRMsg(void);
  40.  
  41.  
  42. /************************************/
  43. /************************************/
  44. /* Función Principal                */
  45. /************************************/
  46. /************************************/
  47.  
  48. void main (void){
  49.     TDatosRecibidos Datos;
  50.  
  51.     /*Ponemos los puertos Analógicos-Digitales*/
  52.     AD1PCFG = 0xFFFF;
  53.     /*Pin del Led como salida*/
  54.     _TRISF3=0;
  55.     _LATF3 = 0;
  56.     /*Pines del CAN como entrada y Salida Respectivamente.*/
  57.    _TRISF0=1;
  58.    _TRISF1=0;
  59.  
  60.     INTEnableSystemMultiVectoredInt();
  61.  
  62.     /*Configuramos CAN1*/
  63.     CAN1Init();
  64.     prueba=0;
  65.  
  66.  
  67.     while(1){
  68.         if(prueba==0){
  69.             CAN1TxSendRTRMsg();
  70.         }
  71.         //CAN1TxSendRTRMsg();
  72.         //CAN1RxMsgProcess();
  73.         /*Verificamos si Tx = Rx*/
  74.         if(Datos.B0recibido == 0x12345678){
  75.             _LATF3 = 1;
  76.         }
  77.         else{
  78.             _LATF3 = 0;
  79.         }
  80.     }
  81. }
  82.  
  83.  
  84.  
  85.  
  86. /***************************/
  87. /***************************/
  88. /*Configuración del Bus CAN*/
  89. /***************************/
  90. /***************************/
  91.  
  92. void CAN1Init(void)
  93. {
  94.     CAN_BIT_CONFIG canBitConfig;
  95.     UINT baudPrescalar;
  96.  
  97.     /*Ponemos el módulo CAN en modo configuración*/
  98.     CANEnableModule(CAN1,TRUE);
  99.     CANSetOperatingMode(CAN1, CAN_CONFIGURATION);
  100.     /*Esperamos hasta que entre en modo configuración*/
  101.     while(CANGetOperatingMode(CAN1) != CAN_CONFIGURATION);
  102.  
  103.     /*Configuramos el reloj del módulo CAN*/
  104.     canBitConfig.phaseSeg2Tq            = CAN_BIT_3TQ;
  105.     canBitConfig.phaseSeg1Tq            = CAN_BIT_3TQ;
  106.     canBitConfig.propagationSegTq       = CAN_BIT_1TQ;
  107.     canBitConfig.phaseSeg2TimeSelect    = TRUE;
  108.     canBitConfig.sample3Time            = FALSE;
  109.     canBitConfig.syncJumpWidth          = CAN_BIT_1TQ;
  110.  
  111.     CANSetSpeed(CAN1,&canBitConfig,SYSTEM_FREQ,CAN_BUS_SPEED);
  112.  
  113.     /*Asignamos el tamaño del Búfer*/
  114.     CANAssignMemoryBuffer(CAN1,CAN1MessageFifoArea,(2 * 8 * 16));
  115.  
  116.     /*Seleccionamos las FIFOS                     */
  117.     /*FIFO0 para Tx                               */
  118.     /*FIFO1 para Rx                               */
  119.     /*FIFO0 con RTR deshabilitado y prioridad baja*/
  120.     /*FIFO1 recepción del mensaje completo*/
  121.     CANConfigureChannelForTx(CAN1, CAN_CHANNEL0, 8, CAN_TX_RTR_DISABLED, CAN_LOW_MEDIUM_PRIORITY);
  122.     CANConfigureChannelForRx(CAN1, CAN_CHANNEL1, 8, CAN_RX_FULL_RECEIVE);
  123.  
  124.     /*Configuramos Filtros y máscaras         */
  125.     /*Filtro0 para aceptar SID 0x201          */
  126.     /*Máscara0 para comparar todos los ID     */
  127.     /*El mensaje debe ser almacenado en FIFO1 */
  128.     //CANConfigureFilter      (CAN1, CAN_FILTER0, 0x001, CAN_SID);
  129.     //CANConfigureFilterMask  (CAN1, CAN_FILTER_MASK0, 0x7FC, CAN_SID, CAN_FILTER_MASK_IDE_TYPE);
  130.     //CANLinkFilterToChannel  (CAN1, CAN_FILTER0, CAN_FILTER_MASK0, CAN_CHANNEL1);
  131.     //CANEnableFilter         (CAN1, CAN_FILTER0, TRUE);
  132.  
  133.     /*Habilitamos interrupciones y eventos      */
  134.     /*Habilitamos la recepción si hay un evento */
  135.     /*Habilitamos la interrupción               */
  136.     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, TRUE);
  137.     CANEnableModuleEvent (CAN1, CAN_RX_EVENT, TRUE);
  138.  
  139.     INTSetVectorPriority(INT_CAN_1_VECTOR, INT_PRIORITY_LEVEL_4);
  140.     INTSetVectorSubPriority(INT_CAN_1_VECTOR, INT_SUB_PRIORITY_LEVEL_0);
  141.     INTEnable(INT_CAN1, INT_ENABLED);
  142.     //IEC1SET = 0x04000000;
  143.  
  144.     /*Ponemos el módulo CAN en modo normal */
  145.     CANSetOperatingMode(CAN1, CAN_LOOPBACK);
  146.     while(CANGetOperatingMode(CAN1) != CAN_LOOPBACK);
  147.  
  148.     CANClearModuleEvent(CAN1, CAN_OPERATION_MODE_CHANGE_EVENT);
  149.  
  150. }
  151.  
  152.  
  153.  
  154.  
  155. /***************************************************/
  156. /***************************************************/
  157. /*Función para enviar un mensaje al bus CAN        */
  158. /***************************************************/
  159. /***************************************************/
  160.  
  161. void CAN1TxSendRTRMsg(void)
  162. {
  163.     CANTxMessageBuffer * message;//Lo saco a variable global
  164.  
  165.     /*Actualizamos el índice en la FIFO0 */
  166.     message = CANGetTxMessageBuffer(CAN1,CAN_CHANNEL0);
  167.  
  168.     /*Mensaje a enviar */
  169.     //message->messageWord[0] = 0;
  170.     //message->messageWord[1] = 0;
  171.     message->messageWord[2] = 0x12345678;
  172.     //message->messageWord[3] = 0;
  173.  
  174.     message->msgSID.SID = 0x001;
  175.     message->msgEID.IDE = 0;
  176.     message->msgEID.RTR = 0;
  177.     message->msgEID.DLC = 4;
  178.  
  179.     /*Actualizamos el índice a la nueva posición de la FIFO0*/
  180.     CANUpdateChannel(CAN1,CAN_CHANNEL0);
  181.     //Habilitamos la transmisión.
  182.     C1FIFOCON0SET=0x00000008;
  183.  
  184.  
  185.     /*Limpiamos la FIFO0 permitiendo enviar cualquier mensaje de Tx*/
  186.     CANFlushTxChannel(CAN1,CAN_CHANNEL0);
  187. }
  188.  
  189.  
  190.  
  191.  
  192. /***************************************************/
  193. /***************************************************/
  194. /*Manejador de la interrupción del CAN1            */
  195. /*Todos los eventos se habilitan en CanEnableEvent */
  196. /*En este caso un evento en la recepción           */
  197. /***************************************************/
  198. /***************************************************/
  199.  
  200. void __ISR (_CAN_1_VECTOR, ipl4) CAN1Interrupt(void)
  201. {
  202.     CANRxMessageBuffer * message;
  203.     /*Verifica si hay un evento en la recepción*/
  204.     if((CANGetModuleEvent(CAN1) & CAN_RX_EVENT) != 0)
  205.     {
  206.         /*Se podría verificar que causó el evento mediante*/
  207.         /*CANGetModuleEvent(), que devuelve el código     */
  208.         /*que representa la prioridad más alta del evento */
  209.         /*pendiente                                       */
  210.                 if(CANGetPendingEventCode(CAN1) == CAN_CHANNEL1_EVENT)
  211.                 {
  212.                     /*Verificamos si se ha producido un evento en la FIFO1    */
  213.                     /*El evento CAN_RX_CHANNEL_NOT_EMPTY es persistente       */
  214.                     /*Se puede leer la FIFO por la interrupción para borrar   */
  215.                     /*la condición de evento o deshabilitar el origen de      */
  216.                     /*de los eventos y hacerlo mediante una función como aquí */
  217.                     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, FALSE);
  218.                     message = (CANRxMessageBuffer *)CANGetRxMessage(CAN1,CAN_CHANNEL1);
  219.                     CANUpdateChannel(CAN1, CAN_CHANNEL1);
  220.                     CANClearModuleEvent (CAN1, CAN_RX_EVENT);
  221.                     prueba=1;
  222.                 }
  223.     }
  224.     /*Se borra la bandera de la interrupción  */
  225.     /*Siempre al final para que si se produce */
  226.     /*otra interrupción no tenga efecto       */
  227.     INTClearFlag(INT_CAN1);
  228. }

Un Saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 17 de Febrero de 2013, 09:30:28
Nada, sigo sin ser capaz de hacer que atienda la interrupción de recepción.
Desesperado estoy ya.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 17 de Febrero de 2013, 11:45:31
Te estas intentando morder la cola, como los perros.
Es decir, estas girando en redondo, vuelves a cometer errores que antes solucionaste.

Los datos a transmitir por un mensaje CAN son de tipo INT8, es decir van de 0 a 255 decimal, o 0 a FF hexa.
En tu programa pones en una sola posicion el dato 0x12345678 , que de por si excede el valor numerico que puedes mandar en una posicion.

Haz lo siguiente, ponle DLC = 1
y en mesage.mesageword1 = 11

y en el main haz la comparacion sobre ese numero y esa posicion esclusivamente.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 18 de Febrero de 2013, 07:42:55
Buenas,

Ya he cambiado como me dijiste lo de los mensajes.

Código: C
  1. #include <p32xxxx.h>
  2. #include <stdio.h>
  3. #include <stdlib.h>
  4. #include <plib.h>
  5. //#include <peripheral\system.h>
  6. #include <peripheral\CAN.h>
  7. #include "GenericTypeDefs.h"
  8.  
  9.  
  10.  
  11.  
  12. #define SYSTEM_FREQ 80000000
  13. #define CAN_BUS_SPEED 125000
  14.  
  15. /*Fsys = 80MHz */
  16. /*Fpb = 80MHz  */
  17. #pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_1, FWDTEN = OFF
  18. #pragma config POSCMOD = HS, FNOSC = PRIPLL, FPBDIV = DIV_1
  19.  
  20.  
  21. typedef struct{
  22.     unsigned B0recibido:8;
  23.     //unsigned B1recibido:8;
  24.     //unsigned B2recibido:8;
  25.     //unsigned B3recibido:8;
  26.     //unsigned B4recibido:8;
  27.     //unsigned B5recibido:8;
  28.     //unsigned B6recibido:8;
  29.     //unsigned B7recibido:8;
  30. }TDatosRecibidos;
  31.  
  32.  
  33. BYTE CAN1MessageFifoArea[2 * 8 * 16];
  34. int prueba=0;
  35.  
  36.  
  37. void CAN1Init(void);
  38. void CAN1TxSendRTRMsg(void);
  39.  
  40.  
  41. /************************************/
  42. /************************************/
  43. /* Función Principal                */
  44. /************************************/
  45. /************************************/
  46.  
  47. void main (void){
  48.     TDatosRecibidos Datos;
  49.  
  50.     /*Ponemos los puertos Analógicos-Digitales*/
  51.     AD1PCFG = 0xFFFF;
  52.     /*Pin del Led como salida*/
  53.     _TRISF3=0;
  54.     _LATF3 = 0;
  55.     /*Pines del CAN como entrada y Salida Respectivamente.*/
  56.     _TRISF0=1;
  57.     _TRISF1=0;
  58.  
  59.     INTEnableSystemSingleVectoredInt();
  60.  
  61.     /*Configuramos CAN1*/
  62.     CAN1Init();
  63.     prueba=0;
  64.  
  65.  
  66.     while(1){
  67.         if(prueba==0){
  68.             CAN1TxSendRTRMsg();
  69.             prueba=1;
  70.         }
  71.        
  72.         /*Verificamos si Tx = Rx*/
  73.         if(Datos.B0recibido == 11){
  74.             _LATF3 = 1;
  75.         }
  76.         else{
  77.             _LATF3 = 0;
  78.         }
  79.     }
  80. }
  81.  
  82.  
  83.  
  84.  
  85. /***************************/
  86. /***************************/
  87. /*Configuración del Bus CAN*/
  88. /***************************/
  89. /***************************/
  90.  
  91. void CAN1Init(void)
  92. {
  93.     CAN_BIT_CONFIG canBitConfig;
  94.     UINT baudPrescalar;
  95.  
  96.     /*Ponemos el módulo CAN en modo configuración*/
  97.     CANEnableModule(CAN1,TRUE);
  98.     CANSetOperatingMode(CAN1, CAN_CONFIGURATION);
  99.     /*Esperamos hasta que entre en modo configuración*/
  100.     while(CANGetOperatingMode(CAN1) != CAN_CONFIGURATION);
  101.  
  102.     /*Configuramos el reloj del módulo CAN*/
  103.     canBitConfig.phaseSeg2Tq            = CAN_BIT_3TQ;
  104.     canBitConfig.phaseSeg1Tq            = CAN_BIT_3TQ;
  105.     canBitConfig.propagationSegTq       = CAN_BIT_3TQ;
  106.     canBitConfig.phaseSeg2TimeSelect    = TRUE;
  107.     canBitConfig.sample3Time            = FALSE;
  108.     canBitConfig.syncJumpWidth          = CAN_BIT_1TQ;
  109.  
  110.     CANSetSpeed(CAN1,&canBitConfig,SYSTEM_FREQ,CAN_BUS_SPEED);
  111.  
  112.     /*Asignamos el tamaño del Búfer*/
  113.     CANAssignMemoryBuffer(CAN1,CAN1MessageFifoArea,(2 * 8 * 16));
  114.  
  115.     /*Seleccionamos las FIFOS                     */
  116.     /*FIFO0 para Tx                               */
  117.     /*FIFO1 para Rx                               */
  118.     /*FIFO0 con RTR deshabilitado y prioridad baja*/
  119.     /*FIFO1 recepción del mensaje completo*/
  120.     CANConfigureChannelForTx(CAN1, CAN_CHANNEL0, 8, CAN_TX_RTR_DISABLED, CAN_LOW_MEDIUM_PRIORITY);
  121.     CANConfigureChannelForRx(CAN1, CAN_CHANNEL1, 8, CAN_RX_FULL_RECEIVE);
  122.  
  123.     /*Configuramos Filtros y máscaras         */
  124.     /*Filtro0 para aceptar SID 0x201          */
  125.     /*Máscara0 para comparar todos los ID     */
  126.     /*El mensaje debe ser almacenado en FIFO1 */
  127.     //CANConfigureFilter      (CAN1, CAN_FILTER0, 0x001, CAN_SID);
  128.     //CANConfigureFilterMask  (CAN1, CAN_FILTER_MASK0, 0x7FC, CAN_SID, CAN_FILTER_MASK_IDE_TYPE);
  129.     //CANLinkFilterToChannel  (CAN1, CAN_FILTER0, CAN_FILTER_MASK0, CAN_CHANNEL1);
  130.     //CANEnableFilter         (CAN1, CAN_FILTER0, TRUE);
  131.  
  132.     /*Habilitamos interrupciones y eventos      */
  133.     /*Habilitamos la recepción si hay un evento */
  134.     /*Habilitamos la interrupción               */
  135.     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, TRUE);
  136.     CANEnableModuleEvent (CAN1, CAN_RX_EVENT, TRUE);
  137.  
  138.     INTSetVectorPriority(INT_CAN_1_VECTOR, INT_PRIORITY_LEVEL_4);
  139.     INTSetVectorSubPriority(INT_CAN_1_VECTOR, INT_SUB_PRIORITY_LEVEL_0);
  140.     INTEnable(INT_CAN1, INT_ENABLED);
  141.     //IEC1SET = 0x04000000;
  142.  
  143.     /*Ponemos el módulo CAN en modo normal */
  144.     CANSetOperatingMode(CAN1, CAN_LOOPBACK);
  145.     while(CANGetOperatingMode(CAN1) != CAN_LOOPBACK);
  146.  
  147.     //CANClearModuleEvent(CAN1, CAN_OPERATION_MODE_CHANGE_EVENT);
  148.  
  149. }
  150.  
  151.  
  152.  
  153.  
  154. /***************************************************/
  155. /***************************************************/
  156. /*Función para enviar un mensaje al bus CAN        */
  157. /***************************************************/
  158. /***************************************************/
  159.  
  160. void CAN1TxSendRTRMsg(void)
  161. {
  162.     CANTxMessageBuffer * message;//Lo saco a variable global
  163.  
  164.     /*Actualizamos el índice en la FIFO0 */
  165.     message = CANGetTxMessageBuffer(CAN1,CAN_CHANNEL0);
  166.  
  167.     /*Mensaje a enviar */
  168.     //message->messageWord[0] = 0;
  169.     //message->messageWord[1] = 0;
  170.     message->messageWord[1] = 11;
  171.     //message->messageWord[3] = 0;
  172.  
  173.     message->msgSID.SID = 0x001;
  174.     message->msgEID.IDE = 0;
  175.     message->msgEID.RTR = 0;
  176.     message->msgEID.DLC = 1;
  177.  
  178.     /*Actualizamos el índice a la nueva posición de la FIFO0*/
  179.     CANUpdateChannel(CAN1,CAN_CHANNEL0);
  180.     //Habilitamos la transmisión.
  181.     C1FIFOCON0SET=0x00000008;
  182.  
  183.  
  184.     /*Limpiamos la FIFO0 permitiendo enviar cualquier mensaje de Tx*/
  185.     //CANFlushTxChannel(CAN1,CAN_CHANNEL0);
  186. }
  187.  
  188.  
  189.  
  190.  
  191. /***************************************************/
  192. /***************************************************/
  193. /*Manejador de la interrupción del CAN1            */
  194. /*Todos los eventos se habilitan en CanEnableEvent */
  195. /*En este caso un evento en la recepción           */
  196. /***************************************************/
  197. /***************************************************/
  198.  
  199. void __ISR (_CAN_1_VECTOR, ipl4) CAN1Interrupt(void)
  200. {
  201.     CANRxMessageBuffer * message;
  202.     TDatosRecibidos Datos;
  203.    
  204.     /*Verifica si hay un evento en la recepción*/
  205.     if((CANGetModuleEvent(CAN1) & CAN_RX_EVENT) != 0)
  206.     {
  207.         /*Se podría verificar que causó el evento mediante*/
  208.         /*CANGetModuleEvent(), que devuelve el código     */
  209.         /*que representa la prioridad más alta del evento */
  210.         /*pendiente                                       */
  211.                 if(CANGetPendingEventCode(CAN1) == CAN_CHANNEL1_EVENT)
  212.                 {
  213.                     /*Verificamos si se ha producido un evento en la FIFO1    */
  214.                     /*El evento CAN_RX_CHANNEL_NOT_EMPTY es persistente       */
  215.                     /*Se puede leer la FIFO por la interrupción para borrar   */
  216.                     /*la condición de evento o deshabilitar el origen de      */
  217.                     /*de los eventos y hacerlo mediante una función como aquí */
  218.                     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, FALSE);
  219.                     message = (CANRxMessageBuffer *)CANGetRxMessage(CAN1,CAN_CHANNEL1);
  220.                     Datos.B0recibido = message->messageWord[1];
  221.                     CANUpdateChannel(CAN1, CAN_CHANNEL1);
  222.                     CANClearModuleEvent (CAN1, CAN_RX_EVENT);
  223.                 }
  224.     }
  225.     /*Se borra la bandera de la interrupción  */
  226.     /*Siempre al final para que si se produce */
  227.     /*otra interrupción no tenga efecto       */
  228.     prueba=0;
  229.     INTClearFlag(INT_CAN1);
  230. }

La verdad que (como ya se ve no me entero mucho) no se muy bien como manejar los datos, estoy bastante liado en ese aspecto, cuando miro el manual del Bus CAN del fabricante, veo lo siguiente:

messageWord[0] y messageWord[1] está compuesto por:

SID
ID
DLC
...
...
...

Total, que para messageWord[2] y messageWord[3] hay 8 datos de 1 byte para cada uno, por eso puse lo que puse.
Entonces, yo diría que tendría que probar con messageWord[2], en lugar de con messageWord[1], ¿No?

Como veis mis conocimientos de esto es prácticamente nulo, muchas gracias por la ayuda.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Febrero de 2013, 08:12:12
Revisa bien en el principio del hilo, como se compone una trama del bus CAN.
Eso te clarificara mucho.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 18 de Febrero de 2013, 08:50:05
Si, va a ser lo mejor, echarle un vistazo para recordarlo y enterarme en condiciones y luego seguir con el código.

¿Crees que puede ser por eso que no entre a la interrupción?No, la verdad que no, será otra cosa..pero primero he de tener claras algunas cosas.
Muchas gracias.
Cuando lo tenga claro y vuelva al código comento como va el CAN.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Febrero de 2013, 08:51:45
Vas mejorando, al menos ya te vas dando cuenta que quieres ir muy rapido... :D :D :D
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Mil24. en 20 de Febrero de 2013, 14:33:43
MGLSOFT sos un groso, de corazon eh, y tambien los que aportaron tanta data, como pere y otros, hoy me levante con los ojos colorados de tanto leer anoche, me llevo unas horitas pero me lei todo el post.

Ahora les cuento que tengo unos pic18f4585 y  2585 y los mcp2551 los cuales, como buen ignaro del can, compre pensando que eran una especie de max232 o max485, que podia conectar al serie del micro y listo, pero bue, despues tuve claramente que mandar a pedir los 18fXX8 para poder laburar, lo que tengo que hacer basicamente es comunicarme con un equipo comercial, utilizado para el agro y a perdido el nodo unico que lleva, del cual no se consigue reemplazo, por tanto debo leer los datos interpretarlos y enviar data tambien, eso va a ser lo complicado, para no decir casi imposible, pero bueno, sera una ardua tarea que tiene el respaldo de toda la data de la gente grosa que aporto al tema.

Esta tardecita arranco a armar una placa y le meto mano al trabajito, pero antes queria agradecerles por la informacion aqui presente y seguramente estare molestando con alguna consulta, espero que no, pero no le pidamos peras al olmo, jeje! Un abrazo

JuanPablo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: joscar66 en 28 de Febrero de 2013, 11:34:00
Excelente tema!

De casualidad alguien conoce de un monitor para canopen ?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Febrero de 2013, 11:45:17
Depende de a que te refieres con Monitor para CanOpen.

Si lo que buscas es una herramienta Sniffer, si los hay.

Si te refieres a un HMI que se comunique por CanOpen, te dire que no se si hay, ya que si hay un HMI, normalmente esta asociado a un PLC y comunicado a el en otro estandar industrial y el PLC es quien en el maestro de la red CanOpen.
Por esa razon dudo que un HMI se comunique directo a CanOpen, pero no descarto que los haya.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: joscar66 en 28 de Febrero de 2013, 12:06:08
Hola MGLSOFT

Si, realmente me referia a un sniffer.  He visto algunos, pero no ofrecen la identificacion de tramas canopen. Me gustaria conocer de uno que permina identificar ese tipo de tramas para su analisis.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Febrero de 2013, 13:38:46
Yo pude probar este modelo de ADFWEB:

(http://www.adfweb.com/Home/products/images/HD67216_L.jpg)

http://www.adfweb.com/Home/products/CAN_BUS_analyzers.asp?frompg=GooHardware (http://www.adfweb.com/Home/products/CAN_BUS_analyzers.asp?frompg=GooHardware)

Anda bastante bien y no es muy caro.

Tengo este otro, de DELTA y aunque no da todas las posibilidades del otro y es USB y muy portable:

(http://www.delta.com.tw/product/em/control/cm/images/IFD6503.jpg)

http://www.delta.com.tw/product/em/control/cm/control_cm_product.asp?pid=3&cid=5&itid=20 (http://www.delta.com.tw/product/em/control/cm/control_cm_product.asp?pid=3&cid=5&itid=20)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: joscar66 en 28 de Febrero de 2013, 14:26:35
Que piensas de este?

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=160612578514&ssPageName=ADME:X:RTQ:US:1123#vi-desc
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 28 de Febrero de 2013, 22:03:03
Parece bueno, el Can Festival es gratuito??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: joscar66 en 02 de Marzo de 2013, 14:09:36
Si, es gratis pero hasta ahora solo he podido conseguir es el codigo fuente. Debo leer los tutoriales para ver como se hace para poner en ejecucion uno de los ejemplos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 04 de Marzo de 2013, 18:10:03
Buenas MGLSOFT,

Vuelvo a dar guerra, tras revisarme la documentación del CAN y de enterarme de algunas cosas más, mañana podré ir a provar con el snifer, a ver si entrase en la interrupción del CAN. en modo loopback no he podido hacer nada. No avancé.

pongo aquí el código que voy a probar.

Código: C
  1. #include <p32xxxx.h>
  2. #include <stdio.h>
  3. #include <stdlib.h>
  4. #include <plib.h>
  5. //#include <peripheral\system.h>
  6. #include <peripheral\CAN.h>
  7. #include "GenericTypeDefs.h"
  8.  
  9.  
  10.  
  11.  
  12. #define SYSTEM_FREQ 80000000
  13. #define CAN_BUS_SPEED 125000
  14.  
  15. /*Fsys = 80MHz */
  16. /*Fpb = 80MHz  */
  17. #pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_1, FWDTEN = OFF
  18. #pragma config POSCMOD = HS, FNOSC = PRIPLL, FPBDIV = DIV_1
  19.  
  20.  
  21. typedef struct{
  22.     unsigned B0recibido:8;
  23.     //unsigned B1recibido:8;
  24.     //unsigned B2recibido:8;
  25.     //unsigned B3recibido:8;
  26.     //unsigned B4recibido:8;
  27.     //unsigned B5recibido:8;
  28.     //unsigned B6recibido:8;
  29.     //unsigned B7recibido:8;
  30. }TDatosRecibidos;
  31.  
  32.  
  33. BYTE CAN1MessageFifoArea[2 * 8 * 16];
  34. int prueba=0;
  35.  
  36.  
  37. void CAN1Init(void);
  38. void CAN1TxSendRTRMsg(void);
  39.  
  40.  
  41. /************************************/
  42. /************************************/
  43. /* Función Principal                */
  44. /************************************/
  45. /************************************/
  46.  
  47. void main (void){
  48.     TDatosRecibidos Datos;
  49.  
  50.     /*Ponemos los puertos Analógicos-Digitales*/
  51.     AD1PCFG = 0xFFFF;
  52.     /*Pin del Led como salida*/
  53.     _TRISF3=0;
  54.     _LATF3 = 0;
  55.     /*Pines del CAN como entrada y Salida Respectivamente.*/
  56.     _TRISF0=1;
  57.     _TRISF1=0;
  58.  
  59.     INTEnableSystemSingleVectoredInt();
  60.  
  61.     /*Configuramos CAN1*/
  62.     CAN1Init();
  63.     prueba=0;
  64.  
  65.  
  66.     while(1){
  67.         if(prueba==0){
  68.             CAN1TxSendRTRMsg();
  69.             prueba=1;
  70.         }
  71.        
  72.         /*Verificamos si Tx = Rx*/
  73.         if(Datos.B0recibido == 11){
  74.             _LATF3 = 1;
  75.         }
  76.         else{
  77.             _LATF3 = 0;
  78.         }
  79.     }
  80. }
  81.  
  82.  
  83.  
  84.  
  85. /***************************/
  86. /***************************/
  87. /*Configuración del Bus CAN*/
  88. /***************************/
  89. /***************************/
  90.  
  91. void CAN1Init(void)
  92. {
  93.     CAN_BIT_CONFIG canBitConfig;
  94.     UINT baudPrescalar;
  95.  
  96.     /*Ponemos el módulo CAN en modo configuración*/
  97.     CANEnableModule(CAN1,TRUE);
  98.     CANSetOperatingMode(CAN1, CAN_CONFIGURATION);
  99.     /*Esperamos hasta que entre en modo configuración*/
  100.     while(CANGetOperatingMode(CAN1) != CAN_CONFIGURATION);
  101.  
  102.     /*Configuramos el reloj del módulo CAN*/
  103.     canBitConfig.phaseSeg2Tq            = CAN_BIT_3TQ;//3
  104.     canBitConfig.phaseSeg1Tq            = CAN_BIT_3TQ;//5
  105.     canBitConfig.propagationSegTq       = CAN_BIT_1TQ;//1
  106.     canBitConfig.phaseSeg2TimeSelect    = TRUE;
  107.     canBitConfig.sample3Time            = FALSE;
  108.     canBitConfig.syncJumpWidth          = CAN_BIT_1TQ;
  109.  
  110.     CANSetSpeed(CAN1,&canBitConfig,SYSTEM_FREQ,CAN_BUS_SPEED);
  111.  
  112.     /*Asignamos el tamaño del Búfer*/
  113.     CANAssignMemoryBuffer(CAN1,CAN1MessageFifoArea,(2 * 8 * 16));
  114.  
  115.     /*Seleccionamos las FIFOS                     */
  116.     /*FIFO0 para Tx                               */
  117.     /*FIFO1 para Rx                               */
  118.     /*FIFO0 con RTR deshabilitado y prioridad baja*/
  119.     /*FIFO1 recepción del mensaje completo*/
  120.     CANConfigureChannelForTx(CAN1, CAN_CHANNEL0, 8, CAN_TX_RTR_DISABLED, CAN_LOW_MEDIUM_PRIORITY);
  121.     CANConfigureChannelForRx(CAN1, CAN_CHANNEL1, 8, CAN_RX_FULL_RECEIVE);
  122.  
  123.     /*Configuramos Filtros y máscaras         */
  124.     /*Filtro0 para aceptar SID 0x001          */
  125.     /*Máscara0 para comparar todos los ID     */
  126.     /*El mensaje debe ser almacenado en FIFO1 */
  127.     //CANConfigureFilter      (CAN1, CAN_FILTER0, 0x001, CAN_SID);
  128.     //CANConfigureFilterMask  (CAN1, CAN_FILTER_MASK0, 0x7FC, CAN_SID, CAN_FILTER_MASK_IDE_TYPE);
  129.     //CANLinkFilterToChannel  (CAN1, CAN_FILTER0, CAN_FILTER_MASK0, CAN_CHANNEL1);
  130.     //CANEnableFilter         (CAN1, CAN_FILTER0, TRUE);
  131.  
  132.     /*Habilitamos interrupciones y eventos      */
  133.     /*Habilitamos la recepción si hay un evento */
  134.     /*Habilitamos la interrupción               */
  135.     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, TRUE);
  136.     CANEnableModuleEvent (CAN1, CAN_RX_EVENT, TRUE);
  137.  
  138.     INTSetVectorPriority(INT_CAN_1_VECTOR, INT_PRIORITY_LEVEL_4);
  139.     INTSetVectorSubPriority(INT_CAN_1_VECTOR, INT_SUB_PRIORITY_LEVEL_0);
  140.     INTEnable(INT_CAN1, INT_ENABLED);
  141.     //IEC1SET = 0x04000000;
  142.  
  143.     /*Ponemos el módulo CAN en modo normal */
  144.     CANSetOperatingMode(CAN1, CAN_LOOPBACK);
  145.     while(CANGetOperatingMode(CAN1) != CAN_LOOPBACK);
  146.  
  147.     //CANClearModuleEvent(CAN1, CAN_OPERATION_MODE_CHANGE_EVENT);
  148.  
  149. }
  150.  
  151.  
  152.  
  153.  
  154. /***************************************************/
  155. /***************************************************/
  156. /*Función para enviar un mensaje al bus CAN        */
  157. /***************************************************/
  158. /***************************************************/
  159.  
  160. void CAN1TxSendRTRMsg(void)
  161. {
  162.     CANTxMessageBuffer * message;//Lo saco a variable global
  163.  
  164.     /*Actualizamos el índice en la FIFO0 */
  165.     message = CANGetTxMessageBuffer(CAN1,CAN_CHANNEL0);
  166.  
  167.     /*Mensaje a enviar */
  168.     //message->messageWord[0] = 0;
  169.     //message->messageWord[1] = 0;
  170.     message->messageWord[1] = 11;
  171.     //message->messageWord[3] = 0;
  172.  
  173.     message->msgSID.SID = 0x001;
  174.     message->msgEID.IDE = 0;
  175.     message->msgEID.RTR = 0;
  176.     message->msgEID.DLC = 1;
  177.  
  178.     /*Actualizamos el índice a la nueva posición de la FIFO0*/
  179.     CANUpdateChannel(CAN1,CAN_CHANNEL0);
  180.     //Habilitamos la transmisión.
  181.     C1FIFOCON0SET=0x00000008;
  182.  
  183.  
  184.     /*Limpiamos la FIFO0 permitiendo enviar cualquier mensaje de Tx*/
  185.     //CANFlushTxChannel(CAN1,CAN_CHANNEL0);
  186. }
  187.  
  188.  
  189.  
  190.  
  191. /***************************************************/
  192. /***************************************************/
  193. /*Manejador de la interrupción del CAN1            */
  194. /*Todos los eventos se habilitan en CanEnableEvent */
  195. /*En este caso un evento en la recepción           */
  196. /***************************************************/
  197. /***************************************************/
  198.  
  199. void __ISR (_CAN_1_VECTOR, ipl4) CAN1Interrupt(void)
  200. {
  201.     CANRxMessageBuffer * message;
  202.     TDatosRecibidos Datos;
  203.    
  204.     /*Verifica si hay un evento en la recepción*/
  205.     if((CANGetModuleEvent(CAN1) & CAN_RX_EVENT) != 0)
  206.     {
  207.         /*Se podría verificar que causó el evento mediante*/
  208.         /*CANGetModuleEvent(), que devuelve el código     */
  209.         /*que representa la prioridad más alta del evento */
  210.         /*pendiente                                       */
  211.                 if(CANGetPendingEventCode(CAN1) == CAN_CHANNEL1_EVENT)
  212.                 {
  213.                     /*Verificamos si se ha producido un evento en la FIFO1    */
  214.                     /*El evento CAN_RX_CHANNEL_NOT_EMPTY es persistente       */
  215.                     /*Se puede leer la FIFO por la interrupción para borrar   */
  216.                     /*la condición de evento o deshabilitar el origen de      */
  217.                     /*de los eventos y hacerlo mediante una función como aquí */
  218.                     CANEnableChannelEvent(CAN1, CAN_CHANNEL1, CAN_RX_CHANNEL_NOT_EMPTY, FALSE);
  219.                     message = (CANRxMessageBuffer *)CANGetRxMessage(CAN1,CAN_CHANNEL1);
  220.                     Datos.B0recibido = message->messageWord[1];
  221.                     CANUpdateChannel(CAN1, CAN_CHANNEL1);
  222.                     CANClearModuleEvent (CAN1, CAN_RX_EVENT);
  223.                 }
  224.     }
  225.     /*Se borra la bandera de la interrupción  */
  226.     /*Siempre al final para que si se produce */
  227.     /*otra interrupción no tenga efecto       */
  228.     prueba=0;
  229.     INTClearFlag(INT_CAN1);
  230. }

Me falta cambiar el modo de operación.
Y en el SW del sniffer cambiar el baudrate.

Mañana os comentaré. Cruzo los dedos.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: AioriaG en 14 de Marzo de 2013, 13:05:34
Hola que tal, soy nuevo en el foro, antes que nada pues felicidades por esta excelente liga sobre el bus "can" mi resumen para describirla es esta expresión "si no esta en esta pagina no esta en internet". Bueno esta pagina en general es mi enciclopedia del "pic", muchas gracias a todos por que aunque nunca había posteado he sido uno de los muchos beneficiados por tantas y tantas veces que me ha sacado de apuros. Volviendo al tema de esta liga tengo un problema con el bus can, apenas estoy comenzando a usarlo, he logrado hacer comunicación can muy simple con CCS pero el problema al que me enfrento es el siguiente, necesito comunicar una tarjeta programada con CCS (por mí) con otra que esta programada en mikroC (por otra persona), el código fuente de la tarjeta transmisora  esta en mikroC y la receptora en CCS, cuando ambas tarjetas las programamos en mikroC o en CCS la comunicación siempre funciona pero cuando se pone una y una entonces la comunicación se queda colgada, la transmisión siempre es a 125kb. Imagino que el problema debe ir con los filtros o mascaras pero no entiendo bien como configurar eso. Les agradecería mucho su ayuda mientras tanto volveré a leer las 69 paginas que llevan sobre el modulo can.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 14 de Marzo de 2013, 23:05:48
Hola que tal, soy nuevo en el foro, antes que nada pues felicidades por esta excelente liga sobre el bus "can" mi resumen para describirla es esta expresión "si no esta en esta pagina no esta en internet". Bueno esta pagina en general es mi enciclopedia del "pic", muchas gracias a todos por que aunque nunca había posteado he sido uno de los muchos beneficiados por tantas y tantas veces que me ha sacado de apuros. Volviendo al tema de esta liga tengo un problema con el bus can, apenas estoy comenzando a usarlo, he logrado hacer comunicación can muy simple con CCS pero el problema al que me enfrento es el siguiente, necesito comunicar una tarjeta programada con CCS (por mí) con otra que esta programada en mikroC (por otra persona), el código fuente de la tarjeta transmisora  esta en mikroC y la receptora en CCS, cuando ambas tarjetas las programamos en mikroC o en CCS la comunicación siempre funciona pero cuando se pone una y una entonces la comunicación se queda colgada, la transmisión siempre es a 125kb. Imagino que el problema debe ir con los filtros o mascaras pero no entiendo bien como configurar eso. Les agradecería mucho su ayuda mientras tanto volveré a leer las 69 paginas que llevan sobre el modulo can.

Si pones ambos codigos, creo que podremos ayudarte...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: AioriaG en 15 de Marzo de 2013, 12:37:05
El código del receptor (en CCS) es:
Código: [Seleccionar]
#include <18F4580.h>
#include <stdlib.h>
#use delay (clock=20000000)
#use rs232(uart1, baud=9600,TIMEOUT=10)
#fuses HS,NOWDT,WDT256,NOPROTECT,NOPUT,BROWNOUT,NOLVP,NOCPD,NODEBUG,NOWRT

#byte port_c = 0xF82
#byte port_d = 0xF83

#define CAN_DO_DEBUG TRUE

#include "can-18F4580.c"
int16 ms;
const int word_size = 8;//TAMAÑO DE LAS PALABRAS
char XX[word_size];

#define TSE1   0x201

void main() {
struct rx_stat rxstat;
int32 rx_id;
char buffer[8];
int rx_len=8;
int i;

for(i=0;i<8;i++) {
      buffer[i]=0;
}

setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);

can_init();
enable_interrupts(GLOBAL);
printf("INICIO");
SETUP_WDT(WDT_ON);//inicializa el wdt cada 2304 ms

while(true){
 if ( can_kbhit() ) {
   printf("\r\n");
   if(can_getd(rx_id, &buffer, rx_len, rxstat)) {//ID,DATO,TAMAÑO,...
        if (rx_id == TSE1) {
           for (i=0;i<word_size;i++) XX[i] = buffer[i];
           printf("RECIBE: %c%c%c%c%c%c%c%c\r\n",XX[0]XX[1]XX[2]XX[3]XX[4]XX[5]XX[6]XX[7]);
        }//END IF IDENTIFICACION RX CAN
   }//END IF CAPTURA CAN
 }//end can kbhit
 restart_wdt();
 }//end while
}//end main
El código del transmisor (mikroC) es:
Código: [Seleccionar]
unsigned char Can_Init_Flags, Can_Send_Flags, Can_Rcv_Flags; // can flags
unsigned char Rx_Data_Len;                                   // received data length in bytes
char RxTx_Data[8];                                           // can rx/tx data buffer
char Msg_Rcvd;
//const long transmisor = 102, receptor = 3;                       // node IDs
const long main_node = 0x201;
long Rx_ID;
unsigned int cnt;
unsigned int temp_res;
char envio1[]="ENVIO 01";

void main() {
  PORTC = 0;                                                // clear PORTC
  TRISA  = 0xFF;              // PORTA is input
  CMCON=7;
  T2CON  =  0x07;           // Timer2 settings
  TMR2IF_bit = 0;           // clear TMR2IF
  TMR2IE_bit = 1;           // enable Timer2 interrupt
  cnt =   0;                // initialize cnt
  INTCON = 0xC0;            // Set GIE, PEIE
  TRISC = 0;                                                // set PORTC as output
  LATD  = 0 ;
  TRISD = 0 ;             // set PORTD as output
  value = 0;                          // When program starts, DAC gives
                                        //   the output in the mid-range
  PORTC.F7 = 1;
  PORTC.F6 = 0;

  Can_Init_Flags = 0;                                       //
  Can_Send_Flags = 0;                                       // clear flags
  Can_Rcv_Flags  = 0;                                       //
  Can_Send_Flags = _CAN_TX_PRIORITY_0 &                     // form value to be used
                   _CAN_TX_XTD_FRAME &                      //     with CANWrite
                   _CAN_TX_NO_RTR_FRAME;

  Can_Init_Flags = _CAN_CONFIG_SAMPLE_THRICE &              // form value to be used
                   _CAN_CONFIG_PHSEG2_PRG_ON &              // with CANInit
                   _CAN_CONFIG_XTD_MSG &
                   _CAN_CONFIG_DBL_BUFFER_ON &
                   _CAN_CONFIG_VALID_XTD_MSG &
                   _CAN_CONFIG_LINE_FILTER_OFF;

  CANInitialize(1,3,3,3,1,Can_Init_Flags);                  // initialize external CAN module
  CANSetOperationMode(_CAN_MODE_CONFIG,0xFF);               // set CONFIGURATION mode
  CANSetBaudRate(1,1,8,8,3,_CAN_CONFIG_SAMPLE_ONCE & _CAN_CONFIG_PHSEG2_PRG_ON & _CAN_CONFIG_LINE_FILTER_OFF); //500
  CANSetMask(_CAN_MASK_B1,-1,_CAN_CONFIG_XTD_MSG);          // set all mask1 bits to ones
  CANSetMask(_CAN_MASK_B2,-1,_CAN_CONFIG_XTD_MSG);          // set all mask2 bits to ones
  CANSetFilter(_CAN_FILTER_B2_F3,ID_1001,_CAN_CONFIG_XTD_MSG);// set id of filter B2_F3 to 1st node ID
  CANSetOperationMode(_CAN_MODE_NORMAL,0xFF);               // set NORMAL mode
  while (1) {
    CANWrite(main_node, envio1 , 8, Can_Send_Flags);
    Delay_ms(1000);
   }
}
Ambos códigos son para el pic 18F4580 con cristales de 20Mhz
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Marzo de 2013, 23:59:22
Estas seguro que el codigo en Mikro C es para ese PIC ??

En el comentario de la inicializacion dice que es para u modulo externo...
Porque no lo compruebas??
Y si hay un MCP2515, dinos que cristal tiene, asi vemos la velocidad a que esta prefijada... :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: AioriaG en 16 de Marzo de 2013, 12:33:22
Si es para ese pic, lo del modulo externo si ya hicimos pruebas quitando esa linea que se supone configura de forma rápida el modulo can pero hizo lo mismo. Usa un mcp2551 por lo que no tiene otro cristal. Voy hacer otras pruebas cambiando las velocidades haber como responde y comento si hubo cambios.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Marzo de 2013, 14:26:00
Creo que aca tienes dos errores.

Código: C
  1. CANSetBaudRate(1,1,8,8,3,_CAN_CONFIG_SAMPLE_ONCE & _CAN_CONFIG_PHSEG2_PRG_ON & _CAN_CONFIG_LINE_FILTER_OFF); //500 <<< es para 500K
  2.   CANSetMask(_CAN_MASK_B1,-1,_CAN_CONFIG_XTD_MSG);          // set all mask1 bits to ones
  3.   CANSetMask(_CAN_MASK_B2,-1,_CAN_CONFIG_XTD_MSG);          // set all mask2 bits to ones
  4.   CANSetFilter(_CAN_FILTER_B2_F3,ID_1001,_CAN_CONFIG_XTD_MSG);// set id of filter B2_F3 to 1st node ID

Deberias probar con esto:

Código: C
  1. CANSetBaudRate(4,1,8,8,3,_CAN_CONFIG_SAMPLE_ONCE & _CAN_CONFIG_PHSEG2_PRG_ON & _CAN_CONFIG_LINE_FILTER_OFF); //500 <<< para 125 K
  2.   CANSetMask(_CAN_MASK_B1,-1,_CAN_CONFIG_XTD_MSG);          // set all mask1 bits to ones
  3.   CANSetMask(_CAN_MASK_B2,-1,_CAN_CONFIG_XTD_MSG);          // set all mask2 bits to ones
  4.   CANSetFilter(_CAN_FILTER_B2_F3,0x0000,_CAN_CONFIG_XTD_MSG);// set id of filter B2_F3 to 1st node ID
Título: Re: Mis experiencias con el BUS CAN
Publicado por: AioriaG en 16 de Marzo de 2013, 16:20:08
Hola que tal, hicimos los cambios que indicaste pero el problema continuo, pero intentamos configurar la velocidad de una forma mas directa (así como lo hiciste tu al modificar el registro en la libreria de ccs) pero en mikroc y asunto resuelto, agrego el codigo donde se configuro en mikroc para compartirlo
Código: [Seleccionar]
CANSetOperationMode(_CAN_MODE_CONFIG,0xFF);               // set CONFIGURATION mode
BRGCON1 = 0x03;
BRGCON2 = 0xBA;
BRGCON3 = 0x07;
CANSetOperationMode(_CAN_MODE_NORMAL,0xFF);               // set NORMAL mode
Así por fin nos quedo configurada bien la velocidad para 125kbps. Te comento que estamos trabajando en un mando a distancia con un touch glcd razón por la cual utilizamos mikroc (en lo particular no me gusta jeje) ya que tiene una herramienta llamada visual glcd y ayuda mucho en la creación del código para el touch.
Te agradezco que hayas estado al pendiente tratando de ayudarnos, muchas gracias.
Como dato curioso yo también soy Lazcano jejeje
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 16 de Marzo de 2013, 16:28:36
Me parece una solucion muy inteligente, usar la herramienta de programacion mas adecuado, segun lo que necesites hacer.
Felicitaciones por haberlo sacado en marcha, y ademas por ser Lazcano seras muy inteligente !! Ja..ja..!! :D :D

Una pregunta que me mata y me corroe:
Que recibes del otro lado cuando mandas ese mensaje desde MikroC ?

Me refiero a este:

Código: C
  1. char envio1[]="ENVIO 01";
  2.  
  3. CANWrite(main_node, envio1 , 8, Can_Send_Flags);
Título: Re: Mis experiencias con el BUS CAN
Publicado por: AioriaG en 18 de Marzo de 2013, 18:39:27
Recibo esa cadena de 8 bytes "ENVIO 01", son 8 caracteres de 1 byte, del otro lado lo imprimo como char por el puerto serial para comprobar el mensaje. En esta instrucción CANWrite(main_node, envio1 , 8, Can_Send_Flags); main_node es el id, envio1 es el arreglo que tiene la información a transmitir,8 es el tamaño de los datos que espera transmitir (es decir 8 bytes) y Can_Send_Flags son las banderas, del otro lado también espero recibir un dato de 8 bytes. No se si eso es lo que me preguntabas, también pude transmitir números enteros con 1 byte, o cualquier cosa pero que sea siempre en paquetes de 1 byte
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 18 de Marzo de 2013, 18:59:44
Excelente !! :mrgreen: :mrgreen:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Andr1c en 03 de Abril de 2013, 00:53:48
¡Hola a todos!, recién me han dejado implementar el protocolo BUS CAN en la Universidad, pero no tengo idea de nada, me iré leyendo todo desde el inicio y espero poder entender, la verdad estoy muy novato en esto, y pregunto ¿Los códigos que han puesto pueden ser grabados en el PIC e iniciar las pruebas de inmediato? me refiero a que si hicieron uso de las librerías originales o hubo modificaciones en algunas de ellas, de ser así ¿Podrían decirme cuales?. Espero no haber interrumpido nada y si las preguntas que hice ya tienen respuestas en este tema perdonen pero como dije apenas inicié leer y ponerme al tanto de sus avances. Ojalá cuente con su ayuda.  :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Abril de 2013, 11:20:54
Hasta donde yo se, lo que se ha colgado aqui, siempre anduvo...
Y lo que se cambio, esta explicado donde y como cambiarlo.
No debieras tener problema en compilarlos...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Andr1c en 03 de Abril de 2013, 18:19:10
Ok, mi tarea fue implementarlo para un solo nodo, pero para que de verdad se note el protocolo como mínimo deberán de haber 2 o 3 nodos en los que se tenga comunicación mútua... Recién iniciaré a entender y compilar los programas, espero no tener problemas (Tendrás algún correo en donde poder contactarte). Buen día.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Abril de 2013, 18:32:04
Si es tu primer prueba, hazlo punto a punto, es decir, sólo dos nodos, y cuando ya vayas tomándole el tiro, vas agregando nodos.
Tres o cuatro nodos ya te dan una buena experiencia.
Debajo de mi Nick hay un icono de sobre (mail), esa es mi dirección de correo, nunca estuvo oculta, de hecho muchos foristas me han escrito, y los ayudo dentro de mis posibilidades, pero insisto, tu aporte al hilo estará mejor si escribes aquí, ya que quedan nuevas experiencias para otros nuevos usuarios...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Andr1c en 03 de Abril de 2013, 23:22:16
He tomado los programas de los nodos e intente compilarlos en "PIC Compiler" pero al momento de hacerlo el programa deja de funcionar, no se si sea problema de la instalación (del programa) o será que debo hacer uso de otro software para compilarlos y generar los archivos *.hex para después proceder a quemarlos en los PIC. Perdón por tantas dudas  :oops:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Andr1c en 03 de Abril de 2013, 23:26:03
Otra cosa, ¿Usted mismo creo los MCP2551 dentro de Proteus? el Proteus con que contaba no los tiene y me bajé la última versión pero cual fue mi sorpresa de que tampoco los incluye.  :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Abril de 2013, 23:35:05
Ahh!!
Estas intentando usarlo en Proteus !! :D :D :D :D

Es simple, NO HAY programas emuladores que puedan emular el funcionamiento del bus CAN, y si encuentras uno, por favor avisanos !!! :mrgreen: :mrgreen:

eso ya lo aclare por lo menos 5 veces en este hilo a diferentes personas.

Solo puedes probar en un montaje real, y cuidado si lo armas en protoboard, ya que los cristales HS suelen traer problemas por la falla de sus contactos, y no funcionara el bus CAN.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Andr1c en 03 de Abril de 2013, 23:49:09
De hecho no lo quería simular, simplemente quería generar el diagrama para presentarlo en clase  :mrgreen: , pero ¿A que cree se deba que no me compilen?  :shock:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Abril de 2013, 23:55:09
Puedes bajarte el DesignSpark PCB, que es gratis (solo debes registrarte para bajarlo) y tiene un modo de uso similar a Eagle.
Podras hacer tus esquemas y ademas luego pasarlos a PCB.

No me queda claro, estas realmente usando una placa para las pruebas??
Puedes subir tu esquema, aunque sea hecho a mano??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Andr1c en 04 de Abril de 2013, 00:10:40
Gracias por el programa sugerido, haré uso de él, y no, lamentablemente no cuento con una placa con la cual probar, de hecho planeo hacer uso del esquema que subió el compañero "pierno10" y montarla sobre placa (PD: no se como adjuntar el archivo .rar del esquema) pero el esquema del cual te hablo es el corregido de la página 9 del usuario "pierno10" (El cual espero no se moleste  :( )
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Abril de 2013, 00:28:37
Cuando quieras adjuntar un archivo, aprietas en Opciones adicionales, y te sale un botón de Seleccionar Archivo y puedes adjuntar archivos de hasta 256 Kb.

Los archivos de Pierno fueron un gran aporte, y si los publico aquí es porque no tiene problemas en que los usen, yo mismo use uno de sus archivos en una placa...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: AioriaG en 05 de Abril de 2013, 15:14:46
Hola Andr1c que tal, mira creo que estas tratando de implementarlas cosas sin entenderlas, yo a principio de febrero 2013 no sabia nada del can, hoy 5 de abril ya tengo varias tarjetas que uso con can. No lo he aprendido por completo aun, pero ya entiendo bastantes cosas, cuando me trabo o tengo dudas vuelvo a dar una hojeada. Y esa es mi primera recomendación, lee lo que esta escrito en este foro y trata de entender como funciona el can, después lo que necesitas para implementar la comunicación, no encontraras un simulador con el que puedas probarlo así que hay que hacer el circuito y probarlo de forma real (en pcb de preferencia), comienza con lo mas simple que conozcas,  lee los datasheet de los componentes eso ayuda mucho a entender como debes conectarlo. Lo malo es que tendrás que gastar algo de dinero al no poder simularlos, si estas estudiando pues aveces eso es lo mas complicado, pero si vale la pena hacer ese esfuerzo, la primera tarjeta con la que probé solo use el can, el mcp2551 y un max 232 para poder monitorear los datos que envío
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Andr1c en 05 de Abril de 2013, 17:32:46
Gracias Ingeniero Marcos, de verdad no sé como agradecerte toda la ayuda que me has brindado si algún día necesitas de algo contarás conmigo, toda la info que he leído en el foro me ha sacado de grandes dudas, y gracias por tus consejos AioriaG de verdad que los estoy tomando en cuenta y como tu dices hacer gastos junto con la escuela es algo pesado pero no imposible. Saludos y los mantendré al tanto de mis avances. :)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 05 de Abril de 2013, 17:51:12
Je..je.. :mrgreen: :mrgreen:
Gracias por lo de ingeniero, pero soy apenas un tecnico que se esmera en aprender todos los dias.

Si van a decir que me merezco ese titulo, les dire que los realmente ingenieros de este foro, hay muchos que deberian tener ya un doctorado por la categoria del material que aportaron.

 ((:-)) ((:-)) ((:-)) ((:-))
Título: Re: Mis experiencias con el BUS CAN
Publicado por: carlosPino en 23 de Abril de 2013, 02:53:45
Saludos a todos los participantes del foro, veo que tienen una excelente información. Estoy iniciando con el BusCan con el dsPIC30F4011, ya tengo los transceiver MCP2551, y trato de hacer una prueba sencilla con dos nodos usando el código de ejemplo que provee el programa MikroC 5.0, pero no he logrado comunicación. El código es el siguiente no se si vean algún detalle que no he considerado. El cristal que uso es de 4MHz.

Nodo 1
Código: [Seleccionar]
unsigned int Can_Init_Flags, Can_Send_Flags, Can_Rcv_Flags;  // can flags
unsigned int Rx_Data_Len;                                    // received data length in bytes
char RxTx_Data[8];                                           // can rx/tx data buffer
char Msg_Rcvd;                                               // reception flag
unsigned long Tx_ID, Rx_ID;                                  // can rx and tx ID

void main() {

  ADPCFG = 0xFFFF;
  PORTB = 0;
  TRISB = 0;

  Can_Init_Flags = 0;                            //
  Can_Send_Flags = 0;                            // clear flags
  Can_Rcv_Flags  = 0;                            //

  Can_Send_Flags = _CAN_TX_PRIORITY_0 &           // Form value to be used
                   _CAN_TX_XTD_FRAME &            //  with CAN2Write
                   _CAN_TX_NO_RTR_FRAME;

  Can_Init_Flags = _CAN_CONFIG_SAMPLE_THRICE &    // Form value to be used
                   _CAN_CONFIG_PHSEG2_PRG_ON &    //  with CAN2Initialize
                   _CAN_CONFIG_XTD_MSG &
                   _CAN_CONFIG_DBL_BUFFER_ON &
                   _CAN_CONFIG_MATCH_MSG_TYPE &
                   _CAN_CONFIG_LINE_FILTER_OFF;

  RxTx_Data[0] = 9;                              // set initial data to be sent
  CAN2Initialize(1,3,3,3,1,Can_Init_Flags);      // initialize CAN2
 
  CAN2SetOperationMode(_CAN_MODE_CONFIG,0xFF);    // set CONFIGURATION mode

  CAN2SetMask(_CAN_MASK_B1,-1,_CAN_CONFIG_MATCH_MSG_TYPE & _CAN_CONFIG_XTD_MSG);   // set all mask1 bits to ones
  CAN2SetMask(_CAN_MASK_B2,-1,_CAN_CONFIG_MATCH_MSG_TYPE & _CAN_CONFIG_XTD_MSG);   // set all mask2 bits to ones
  CAN2SetFilter(_CAN_FILTER_B2_F3,3,_CAN_CONFIG_XTD_MSG);                         // set id of filter B1_F1 to 3
 
  CAN2SetOperationMode(_CAN_MODE_NORMAL,0xFF);                                   // set NORMAL mode
 
  Tx_ID = 12111;                                                                // set transmit ID
 
  CAN2Write(Tx_ID, RxTx_Data, 1, Can_Send_Flags);                               // send initial message
 
  while(1) {                                                                    // endless loop
    Msg_Rcvd = CAN2Read(&Rx_ID , RxTx_Data , &Rx_Data_Len, &Can_Rcv_Flags);     // receive message
    if ((Rx_ID == 3u) && Msg_Rcvd) {                                            // if message received check id
      PORTB = RxTx_Data[0];                                                     // id correct, output data at PORTB
      RxTx_Data[0]++;                                                          // increment received data
      Delay_ms(10);
      CAN2Write(Tx_ID, RxTx_Data, 1, Can_Send_Flags);                           // send incremented data back
    }
  }
}


Nodo 2
Código: [Seleccionar]
unsigned int Can_Init_Flags, Can_Send_Flags, Can_Rcv_Flags;  // can flags
unsigned int Rx_Data_Len;                                    // received data length in bytes
char RxTx_Data[8];                                           // can rx/tx data buffer
char Msg_Rcvd;                                               // reception flag
unsigned long Tx_ID, Rx_ID;                                  // can rx and tx ID


void main() {

  ADPCFG = 0xFFFF;
  PORTB = 0;
  TRISB = 0;

  Can_Init_Flags = 0;                              //
  Can_Send_Flags = 0;                              // clear flags
  Can_Rcv_Flags  = 0;                              //

  Can_Send_Flags = _CAN_TX_PRIORITY_0 &             // Form value to be used
                   _CAN_TX_XTD_FRAME &              //  with CAN2Write
                   _CAN_TX_NO_RTR_FRAME;

  Can_Init_Flags = _CAN_CONFIG_SAMPLE_THRICE &      // Form value to be used
                   _CAN_CONFIG_PHSEG2_PRG_ON &      //  with CAN2Initialize
                   _CAN_CONFIG_XTD_MSG &
                   _CAN_CONFIG_DBL_BUFFER_ON &
                   _CAN_CONFIG_MATCH_MSG_TYPE &
                   _CAN_CONFIG_LINE_FILTER_OFF;

  CAN2Initialize(1,3,3,3,1,Can_Init_Flags);        // initialize CAN2
 
  CAN2SetOperationMode(_CAN_MODE_CONFIG,0xFF);      // set CONFIGURATION mode

  CAN2SetMask(_CAN_MASK_B1,-1,_CAN_CONFIG_MATCH_MSG_TYPE & _CAN_CONFIG_XTD_MSG);   // set all mask1 bits to ones
  CAN2SetMask(_CAN_MASK_B2,-1,_CAN_CONFIG_MATCH_MSG_TYPE & _CAN_CONFIG_XTD_MSG);   // set all mask2 bits to ones
  CAN2SetFilter(_CAN_FILTER_B1_F1,12111,_CAN_CONFIG_XTD_MSG);                     // set id of filter B1_F1 to 12111

  CAN2SetOperationMode(_CAN_MODE_NORMAL,0xFF);                                   // set NORMAL mode

  Tx_ID = 3;                                                                    // set tx ID

  while(1) {                                                                    // endless loop
    Msg_Rcvd = CAN2Read(&Rx_ID , RxTx_Data , &Rx_Data_Len, &Can_Rcv_Flags);     // receive message
    if ((Rx_ID == 12111u) && Msg_Rcvd) {                                        // if message received check id
      PORTB = RxTx_Data[0];                                                     // id correct, output data at PORTB
      RxTx_Data[0]++;                                                          // increment received data
      CAN2Write(Tx_ID, RxTx_Data, 1, Can_Send_Flags);                           // send incremented data back
    }
  }
}

Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Abril de 2013, 08:24:45
Estas seguro que en ambos nodos has utilizado el puerto CAN 2 para comunicarte??
Porque asi esta escrito en este codigo que pones...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: carlosPino en 25 de Abril de 2013, 02:07:22
Buenas noches. El código que publiqué, lo tomé tal cual sale en los ejemplos de Mikro C. Como estoy utilizando el dsPIC30f4011 (que solo tiene un modulo para CAN) le hice el cambio a CAN1 en ambos. Para verificar el dato que se exterioriza al puerto B, conecte unos leds para visualizar los 8bits, pero no hace absolutamente nada. El trasceiver que estoy utilizando es el MCP2551. Agradezco su ayuda
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Abril de 2013, 08:41:04
Veo que usas  un cristal de 4 Mhz, en el circuito de MikroC, que cristal usan??
Ese mismo??
Si es asi, sabes cual es la velocidad de bus CAN a la cual estas trabajando??  (o intentando hacerlo) :mrgreen:
Puede que por ahi venga el problema...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 25 de Abril de 2013, 08:46:44
Me respondo solo.
La velocidad del bus sera de 125 Kb, siendo de 8Tq, te da 1,3,3,1 que es lo que se configura en el codigo.

Deberias ponerle leds a las lineas Tx y Rx que van desde el PIC al MCP2551, para ver si alguno de ellos estan intentando transmitir...

Una pregunta obvia sobre lo nunca obvio:
¿esta cableado el bus entre CanH y CanL de ambos MCP2551 ?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: carlosPino en 25 de Abril de 2013, 19:44:21
Efectivamente esa es la velocidad configurada. El hardware del dsPIC y el transceiver lo he revisado muchas veces pensando que por allí puede estar el error y esta correcto, incluyendo el cableado de las salidas CanH CanL. Probare lo de los leds en las lineas Tx y Rx y reportare lo que vea. Muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Picuino en 09 de Mayo de 2013, 17:23:17
Estoy estudiando el CAN bus y he leido buena parte del hilo (es difícil porque ya lleva 70 páginas) y no he conseguido responder algunas dudas que tengo.

1º ¿Cómo se mantiene la tensión recesiva del bus de 2.5 voltios?
Imagino que se puede conectar la salida de tensión de referencia de uno de los transceivers MCP2551 al bus. ¿Como se hace? ¿Hay que poner un operacional entre medias? ¿Condensadores? ¿Se conectan 2 resistencias de 60 ohms desde la tensión de referencia a cada cable?


2º Recuerdo que el cable de Devicenet (que usa bus CAN en los niveles OSI 1 y 2) cuesta bastante dinero. Es un cable de 120 ohmios.
El cable ethernet (cat. 5) tiene 100 ohmios, por lo que las resistencias terminadoras de 120 ohmios no tienen la misma impedancia y no evitan reflexiones de la señal.
Para distancias cortas no dara problemas, pero para distancias largas ¿hay cables baratos de 120 ohmios? ¿Se puede poner una resistencia terminadora de 100 ohmios al cable ethernet?


Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Mayo de 2013, 17:56:52
Estoy estudiando el CAN bus y he leido buena parte del hilo (es difícil porque ya lleva 70 páginas) y no he conseguido responder algunas dudas que tengo.

1º ¿Cómo se mantiene la tensión recesiva del bus de 2.5 voltios?
Imagino que se puede conectar la salida de tensión de referencia de uno de los transceivers MCP2551 al bus. ¿Como se hace? ¿Hay que poner un operacional entre medias? ¿Condensadores? ¿Se conectan 2 resistencias de 60 ohms desde la tensión de referencia a cada cable?


2º Recuerdo que el cable de Devicenet (que usa bus CAN en los niveles OSI 1 y 2) cuesta bastante dinero. Es un cable de 120 ohmios.
El cable ethernet (cat. 5) tiene 100 ohmios, por lo que las resistencias terminadoras de 120 ohmios no tienen la misma impedancia y no evitan reflexiones de la señal.
Para distancias cortas no dara problemas, pero para distancias largas ¿hay cables baratos de 120 ohmios? ¿Se puede poner una resistencia terminadora de 100 ohmios al cable ethernet?


Saludos.

1º: Lo hace el solo, no hay que hacer nada, ni ponerle nada. Las resistencias se ponen en los 2 extremos del cable, seria 120ohm a cada extremo para hacer 60ohm
(http://e2e.ti.com/resized-image.ashx/__size/550x0/__key/CommunityServer-Discussions-Components-Files/26/0160.CAN_5F00_Standard_5F00_Termination.bmp)

2º: En la resistencia (tanto terminadoras como del cable) lo que influye es la velocidad, a baja velocidad puedes poner cables de alta resistencia y resistencias terminadoras mayores, a alta velocidad debes hacer lo contrario, te pongo una web donde vienen algunas tablas:
http://www.cd-systems.com/Can/can-cables.htm
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Picuino en 09 de Mayo de 2013, 18:03:57
Gracias por el dato MerLiNz.

Las señales que aparecen en los cables V+ y V- ¿Qué són? ¿Vdd y GND?

Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: Picuino en 09 de Mayo de 2013, 18:09:03
Me respondo yo mismo.

Son cables de alimentación: http://en.wikipedia.org/wiki/CAN_bus


Saludos.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 09 de Mayo de 2013, 20:39:44
Si, alimentacion.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: carlosPino en 29 de Mayo de 2013, 16:26:49
Buenas tardes, estoy tratando de comunicar dos dspic30f4011 con el transceiver MCP2551, y no he tenido éxito. En los pines del dspic C1TX y C1RX midiendo el voltaje me dan el mismo voltaje de alimentación, y en las salidas del trasnceiver CANH y CANL una tension muy cercana a 3v fijos. Me gustaría saber que indican estos niveles de tensión a ver si por allí se identifica el error. Muchas gracias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 29 de Mayo de 2013, 18:48:25
Buenas tardes, estoy tratando de comunicar dos dspic30f4011 con el transceiver MCP2551, y no he tenido éxito. En los pines del dspic C1TX y C1RX midiendo el voltaje me dan el mismo voltaje de alimentación, y en las salidas del trasnceiver CANH y CANL una tension muy cercana a 3v fijos. Me gustaría saber que indican estos niveles de tensión a ver si por allí se identifica el error. Muchas gracias.

Si pudieras poner aqui un diagrama de conexion, creo que podriamos ayudarte mas.
Sin osciloscopio, es muy dificil que puedas ver si hay comunicacion...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: juanjuan19 en 11 de Agosto de 2013, 22:25:16
recien veo este hilo, te felicito por tu trabajo, es excelente, yo recien empiezo a despertar en esto, por el momento estoy por comprar un modulo de desarrolo gsm sim900 y realizar mis comunicaciones con pic y un celular cualquiera, y avisar sobre determinados eventos que sucedan, por ejemplo el comportamiento de la temperatura en una habitacion. Me intereso lo de can, a ver si me tiras una idea por favor de como puedo implementar este protocolo can a lo que quiero hacer con mi futura adquisicion, un abrazo
Título: Re: Mis experiencias con el BUS CAN
Publicado por: JUAN_RAMON_RG en 03 de Septiembre de 2013, 17:21:56
Muy buenas tardes espero me puedan ayudar con lo siguiente ..logre la comunicacion de dos dspic30f4013 mediante can bus.. envie un mensaje (mi nombre) de un pic para mostrarlo en un display lcd conectado a otro pic ...el problema es que solo me aparece la primer letra del nombre y nada mas . adjunto el codigo que tengo del pic receptor. muy buenas tardes y gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 03 de Septiembre de 2013, 18:36:13
Muy buenas tardes espero me puedan ayudar con lo siguiente ..logre la comunicacion de dos dspic30f4013 mediante can bus.. envie un mensaje (mi nombre) de un pic para mostrarlo en un display lcd conectado a otro pic ...el problema es que solo me aparece la primer letra del nombre y nada mas . adjunto el codigo que tengo del pic receptor. muy buenas tardes y gracias

No entiendo tu programa, cual es la parte donde transmite en CAN ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 03 de Septiembre de 2013, 18:56:10
El problema puede estar en el puntero array raro que has puesto, si declaras un array[] y luego pones *Rxdata=C1RX0B1 pues es algo raro, o por lo menos no entiendo que pretendes con ello, si lo que quieres es apuntar un puntero hacia los C1RX0Bx debes hacerlo asi:

char *Rxdata=&C1RX0B1;

y ahora con eso o bien usas Rxdata
Título: Re: Mis experiencias con el BUS CAN
Publicado por: JUAN_RAMON_RG en 04 de Septiembre de 2013, 14:18:21
Muy buenas tardes espero me puedan ayudar con lo siguiente ..logre la comunicacion de dos dspic30f4013 mediante can bus.. envie un mensaje (mi nombre) de un pic para mostrarlo en un display lcd conectado a otro pic ...el problema es que solo me aparece la primer letra del nombre y nada mas . adjunto el codigo que tengo del pic receptor. muy buenas tardes y gracias

No entiendo tu programa, cual es la parte donde transmite en CAN ??
paso el programa del pic transmisor ..el que habia puesto era solo la parte receptora pongo la parte donde mando mensaje por medio de can
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 04 de Septiembre de 2013, 15:05:25
Bueno, has progresado...
Ahora entiendo menos que antes que quieres hacer !! :lol: :lol: :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: JUAN_RAMON_RG en 06 de Septiembre de 2013, 16:36:39
Muchas gracias por tu ayuda . Ya solucione mi pequeño problema. me gustaría colaborar con este tema compartiendo mi proyecto ...un lector CAN BUS automotriz. solo faltan unos pequeños toques finales y se los presentare con mucho gusto ....gracias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: acukla en 06 de Septiembre de 2013, 18:19:23
Buenas Tardes a Todos! Antes que nada, tambien les dejo mis felicitaciones por todos los logros y el material tan valioso que aportan para toda la comunidad de todopic. Para seguir la linea de comunicacion CAN, me gustaria compartir mi problema, que supongo que para ustedes sera sencillo, pero hace unos dias que estoy con dificultades. Estava trabajando con comunicacion CAN con PIC18F4580, donde con mucho trabajo fueron modificadas las librerias de "can-pic18f4580", para comunicar un PIC con un modulo comercial de sistemas neumaticos, donde escribiendo su direccion (direccion del modulo comercial 0x080), el respondia o valor correspondiente a su posicion.
El problema que estoy teniendo, es basicamente en configurar el modulo CAN, en lo relacionado a baudrate (tiene ser de 1Mhz) y modo de operacion normal CAN A (no extendida). Estoy trabajando ahora con un microcontrolador dspic33fj128gp802, y programando en ccs. Por lo que tengo entendido, las bibliotecas "can-pic24.c" deberian funcionar para estos microcontroladores. El problema por lo que pude corroborar no es electrico o fisico, es mas bien configurar esas velocidiadades.
Estoy anexando el codigo para que se sientan a gusto y pueda hecharle un ojo al codigo y darme su parecer y/o sugerencias de modificacion. Desde ya muchas gracias; y a MGLSOFT felicitaciones por haber comenzado el foro hace ya un tiempo y todavia sigue produciendo resultados positivos y ayudando a toda la comunidad. Saludos


Código: C
  1. #include <33FJ128GP802.h>
  2. #FUSES WDT                    //Watch Dog Timer
  3. #FUSES NOWRTB                   //Boot block not write protected
  4. #FUSES NOBSS                    //No boot segment
  5. #FUSES NOPROTECT                //Code not protected from reading
  6. #FUSES NOWRTss                    //Program memory not write protected
  7. #FUSES PR_PLL                     //Pimary oscillator
  8. #FUSES HS
  9. #FUSES PUT128                   //Power On Reset Timer value 128ms
  10. #FUSES NOIESO                   //Internal External Switch Over mode disabled
  11. #FUSES NORSS                    //No secure segment RAM
  12. #FUSES NOSSS                    //No secure segment
  13. #FUSES NOWRTSS                  //Secure segment not write protected
  14. #FUSES NORBS                    //No Boot RAM defined
  15. #FUSES NODEBUG                  //No Debug mode for ICD
  16. #FUSES NOJTAG                   //JTAG disabled
  17.  
  18. #use delay(clock=48M)         // Cristal externo de 8MHZ
  19. #use rs232(baud=57600,parity=N,xmit=PIN_B8,rcv=PIN_B9,bits=8)
  20.  
  21. #include <can-PIC24.c>
  22.  
  23. //definimos los pines RS232 y ECAN
  24. #Pin_select U1TX=PIN_B8    // Transmision RS232 (pin 17)
  25. #Pin_select U1RX=PIN_B9    // Recepcion RS232 (pin 18)
  26. #Pin_select C1RX=PIN_B10   // Recepcion ECAN
  27. #Pin_select C1TX=PIN_B11   // Transmision ECAN
  28.  
  29. struct rx_stat rxstat;
  30. int32 rx_id;
  31. int8   in_data[8]={0,0,0,0,0,0,0,0},out_data[8]={0,0,0,0,0,0,0,0}, rx_len;
  32.  
  33. int32 solpos(void)   // Funcion que solicita informacion del modulo CAN
  34. {
  35. int32 pos;
  36. can_putd(0x080, out_data[0], 0, 0 , 0 , 1 );    //solicitacion RTR
  37.      while ( can_kbhit()!= 1)   //espera retornar valor
  38.         {
  39.           delay_cycles( 2 ); //funciona con 2 (no se por que)
  40.         }
  41.       if ( can_kbhit() == 1 )
  42.        {
  43.          if(can_getd(rx_id, &in_data[0], rx_len, rxstat))
  44.          {
  45.          pos=make32(in_data[0],in_data[1],in_data[2]);  // reconstruye valor para 32 bits
  46.          }
  47.        }
  48. return pos;
  49. }
  50.  
  51. void main()
  52. {  int32 posicion;
  53.  
  54.    setup_adc(ADC_CLOCK_INTERNAL );
  55.    can_init();
  56.  
  57. while (true)
  58.    {
  59.    output_toggle(pin_b6);     // cambia estado de un led para verificacion
  60.    posicion=solpos();         // llama a una funcion que lee valores de CAN
  61.    printf("%d\t",in_data[0]); // imprime valor mas significativo via rs232
  62.    printf("%d\t",in_data[1]);
  63.    printf("%d\n",in_data[2]); // valor menos significativo
  64.    delay_ms(250);             // tiempo de espera
  65.  
  66.    
  67.    }
  68.  
  69.  
  70. }
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 06 de Septiembre de 2013, 18:36:31
Muestranos que proceso usaste para configurar la velocidad, y el resultado al que llegaste (mas que nada como ejercicio para encontrar el problema).

Ademas quita o comenta la pausa de dos ciclos de reloj, que puede estar haciendo el ruido por el cual esto no funciona.

Solo una vez trabaje a 1 Mb, y te aseguro que es bastante quisquilloso, con el cumplimiento de los tiempos....

No se si es buena idea a esa velocidad trabajar por poolling, yo activaria las interrupciones y usaria los buffers de recepcion.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: acukla en 06 de Septiembre de 2013, 23:01:36
Gracias por la pronta respuesta MGLSOFT, te cuento lo que he hecho sin tener resultados positivos;
he utilizado a herramienta que propusiste inicialmente en e foro (Microchip Controller Area Network (CAN) Bit Timing Calculator), utilizando una frecuencia de oscilador de 48MHZ y un baud rate de 1Mbps, los resutados fueron los siguientes para los dspic33f;
CICFG1=0x0000
CICFG2=0x07BE
que reemplaze en el archivo "can-pic24.c", comentando las otras lineas, un trabajo similar a lo que nos presentaste inicialmente.
Voy a pasarte el trabajo original, basado en el pic18f4580, que estoy utilizando de referencia para modificar algunas las configuraciones, por lo menos las que se de que se trata la linea de comando, solo que finalmente volvi a la forma original asi no alterar los archivos y consulto a personas con mucha experiencia en la area.
Este trabajo lo he realizado con un colega de habla portuguesa, veras por los comentarios. El esta funcionando hasta hoy en un brazo de actuacion neumatica. Estoy con la idea de mejorar algunas cosas y entre eso quiero cambiar el microcontrolador y embarcar un control dedicando; pero como veras... estoy en pañaes todavia principalmente por el tema de CAN.
Estoy viendo paralelamente tambien para ver si modifico alguna cosa, como me sugeriste lo de pooling, pues bien... era como siempre haciamos jeje, es buena tu sugerencia, pero si funcionaria es bueno que lo haga de las dos formas. Desde ya muchas gracias por la ayuda!
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 15 de Septiembre de 2013, 08:36:22
Hola :
 Despues de un tiempo vuelvo a retomar el tema,  tengo ya conectado  mediante 18f4550 + mcp2515 el ordenador  con bus can, me gustaria que cuando el bus can reciba  una trama active la !int del mcp2515 que iria conectado con pin b0 de 18f4550,  la cosa es no se como configurar los registro y los bit.
 Os pediria que me dijeras los registros he visto que en la pagina 45 del mcp2515
 seria esta  CANINTE.RXnIE = 1 , pero no se donde ni como se pone
 Muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 15 de Septiembre de 2013, 09:44:57
al ser un dispositivo SPI debes configurarlo mediante comandos por SPI

Para ello tienes que enviar un comando WRITE (2) seguido de la direccion del registro 0x2B y seguido de los bits que quieres modificar para que se produzca la interrupcion
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 15 de Septiembre de 2013, 15:25:29
Gracias tomo nota!!
  Pensaba que era mas sencillo , ademas  no cojo las patillas que tiene habilitadas para el protocolo, coj otras para que en la placa se queden mas cerca... y tambien toy pegaete en spi
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MerLiNz en 15 de Septiembre de 2013, 15:43:20
Si te buscas un pic con CAN integrado te resultara mas sencillo, solo necesitaras un mcp2551, lo demas podras configurarlo en el firmware del pic sin tener que usar SPI
Título: Re: Mis experiencias con el BUS CAN
Publicado por: PICSHIRU en 22 de Septiembre de 2013, 10:37:03
Hola antes de nada felicitar a MGLSOFT por este buen hilo. Espero que me puedan ayudar con mi problema.

Estoy con un proyecto de manejo del bus can usando el controlador integrado del pic18f2580 + mcp2551. Tengo conectado al bus el CAN BUS Analyzer tool de Microchip en modo de escucha y un simulador de centralita multi ecu de ozen elektronic

he conseguido con exito comunicarme con la centralita, realizando consultas a varios pid incluidos los multiframe y capturar las respuestas, mi problema es que la centralita solo me responde al id de broadcast y no a los individuales. La cuestion es si es normal o tengo algun problema en la creacion de las tramas.
La central parece aceptar el codigo pero no veo respuesta. tal vez sea una cuestion de filtros, aunque estan configurados para aceptar todo. Si teneis alguna sugerencia...

Aqui os pongo la funcion de manejo del can, por si sirve


Código: C
  1. ERROR_CODE SendQuery(int32 ECU_ID,int8 MODE,int8 PID,struct ODB_MPacket *OBDPacket)
  2. {
  3.    int8 i;
  4.    int8 Alen;
  5.    int8 ByteCheck;
  6.    struct rx_stat rxstat;
  7.    unsigned int32 ReceiptID;
  8.    static TICKTYPE lastTick;
  9.    TICKTYPE currTick;
  10.    struct OBD_Packet OBDPacketToSend;
  11.    struct OBD_Packet OBDFlowControlFrame;
  12.    OBDPacketToSend.NBYTES  =0x02;   //stardard packet
  13.    OBDPacketToSend.MODO    =MODE;
  14.    OBDPacketToSend.PID     =PID;      
  15.    OBDPacketToSend.DATA[0] =0x55;   //No usados 55h para mas compatibilidad
  16.    OBDPacketToSend.DATA[1] =0x55;
  17.    OBDPacketToSend.DATA[2] =0x55;
  18.    OBDPacketToSend.DATA[3] =0x55;
  19.    OBDPacketToSend.DATA[4] =0x55;
  20.    
  21.    
  22.    OBDFlowControlFrame.NBYTES=0x30;  //trama de control de flujo
  23.    OBDFlowControlFrame.MODO=0x07;
  24.    OBDFlowControlFrame.PID=0xF9;
  25.    
  26.    i=0;
  27.    *OBDPacket->NRecibidos=0;
  28.    
  29.    if(can_tbe())
  30.    {  
  31.       can_putd(ECU_ID,&OBDPacketToSend,8,3,0,0);  //enviamos la consulta
  32.       currTick = lastTick=TickGet();      //inicializamos el timeout
  33.       TimeOut=False;
  34.       do
  35.       {
  36.          currTick = TickGet();
  37.          if(can_kbhit())
  38.          {
  39.            can_getd(ReceiptID,&OBDPacket->OBDPacketToSave[i],Alen,rxstat); //capturamos la respuesta
  40.            OBDPacket->NRecibidos=OBDPacket->NRecibidos+1;                       //incrementamos los el numero de paquetes recibidos
  41.            OBDPacket->Receipt_ID[i]=ReceiptID;                                            //guardamos la id del paquete
  42.            ByteCheck=OBDPacket->OBDPacketToSave[i].NBYTES;                   //chequeamos el tipo de trama
  43.            ByteCheck=ByteCheck&0xF0;
  44.             if (ByteCheck==0x10)
  45.             {    
  46.                can_putd(ECU_ID,&OBDFlowControlFrame,3,3,0,0);                    //si es un first frame enviamos trama de control
  47.                fprintf(DEBUG,"First Frame detected\r\n");
  48.             }
  49.             else if (ByteCheck==0x20)
  50.             {
  51.                fprintf(DEBUG,"Consecutive Frame detected\r\n");
  52.             }
  53.             i++;
  54.             lastTick=currTick;
  55.          }
  56.          else if (TickGetDiff(currTick, lastTick) > (TICKS_PER_SECOND*5)) // si han pasado 5 segundos sin respuesta error por timeout
  57.          {
  58.             TimeOut=True;
  59.             #ifdef PROGRAM_DEBUG
  60.                fprintf(DEBUG,"TimeOut\r\n");
  61.             #endif
  62.             lastTick = currTick;
  63.          }
  64.       }while(!TimeOut);         // cinco segundos
  65.       if(OBDPacket->NRecibidos!=0)   // si hay algun paquete el resultado es bueno
  66.       {
  67.          return(EC_OK);
  68.       }
  69.       else
  70.       {
  71.          return(EC_TIMEOUT);
  72.       }
  73.    }
  74.    else
  75.    {
  76.       return(EC_SENDBUFFERBUSY);
  77.    }
  78. }
 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Septiembre de 2013, 11:18:57
No entiendo donde defines la estructura OBD_Packet, que luego copias en las demas....

Tampoco entiendo como es que transmites mensajes con id de broadcast, es decir, conoces cuales son los id que usa esa central ?
Título: Re: Mis experiencias con el BUS CAN
Publicado por: PICSHIRU en 22 de Septiembre de 2013, 12:19:09
Mis disculpas, tal vez omiti demasiados detalles

La central me responde al broadcast siempre y responden aquellas ecus que soportan el pid de la solicitud. Ésta tiene 3 y son 0x7E8, 0xE9h y 0x7EA

Uso la id de broadcast por que no me queda otra. Mi problema es que no responde cuando la misma consulta la envio con 0x7E0 por ejemplo. pero tampoco responde cuando uso el Analyzer en modo normal y transmito desde el.

Código: C
  1. #include <CAN_GSM.h>
  2.  
  3. #define PROGRAM_DEBUG
  4.  
  5.  
  6. #define CAN_USE_EXTENDED_ID           FALSE
  7. #define CAN_BRG_SEG_2_PHASE_TS     TRUE  
  8. #define CAN_BRG_PRESCALAR               4
  9. #define CAN_BRG_SYNCH_JUMP_WIDTH 0
  10. #define CAN_BRG_PROPAGATION_TIME  2
  11. #define CAN_BRG_PHASE_SEGMENT_1   5
  12. #define CAN_BRG_PHASE_SEGMENT_2   5
  13. #define CAN_BRG_WAKE_FILTER           TRUE
  14. #define CAN_BRG_SAM                         FALSE
  15.  
  16. #include <can-18F4580.c>
  17. #include <Tick.c>
  18.  
  19. #define STACK_USE_SHA1 TRUE
  20.  
  21. #include <Hashes.c>
  22.  
  23.  
  24. /**
  25.  *
  26.  */
  27. #define BroadcastID_11    0x7DF
  28. #define BroadcastID_29    0X18DB33F1
  29.  
  30.  
  31. int1 TimeOut;
  32.  
  33.  
  34. struct OBD_Packet{
  35.    int8 NBYTES;    //0 Numero bytes adicionales
  36.    int8 MODO;      //1 Modo
  37.    int8 PID;       //2 PID
  38.    int8 DATA[5];    //3 Data
  39. };
  40.  
  41.  
  42. struct ODB_MPacket{
  43.    int8 NRecibidos;
  44.    unsigned int32 Receipt_ID[8];
  45.    struct OBD_Packet OBDPacketToSave[8];  
  46. };
  47.  
  48.  
  49.  
  50. enum ERROR_CODE {  
  51.                     EC_OK=0,
  52.                     EC_SENDBUFFERBUSY=1,
  53.                     EC_TIMEOUT =2};
  54.  
  55.  
  56. ERROR_CODE SendQuery(int32 ECU_ID,int8 MODE,int8 PID,struct ODB_MPacket *OBDPacket)
  57. {
  58.    int8 i;
  59.    int8 Alen;
  60.    int8 ByteCheck;
  61.    struct rx_stat rxstat;
  62.    unsigned int32 ReceiptID;
  63.    static TICKTYPE lastTick;
  64.    TICKTYPE currTick;
  65.    struct OBD_Packet OBDPacketToSend;
  66.    struct OBD_Packet OBDFlowControlFrame;
  67.    OBDPacketToSend.NBYTES  =0x02; //stardard packet
  68.    OBDPacketToSend.MODO    =MODE; //Mostrar valor actual
  69.    OBDPacketToSend.PID     =PID; //Mostrar PIS soportados
  70.    OBDPacketToSend.DATA[0] =0x55; //No usados 55h
  71.    OBDPacketToSend.DATA[1] =0x55;
  72.    OBDPacketToSend.DATA[2] =0x55;
  73.    OBDPacketToSend.DATA[3] =0x55;
  74.    OBDPacketToSend.DATA[4] =0x55;
  75.    
  76.    
  77.    OBDFlowControlFrame.NBYTES=0x30;
  78.    OBDFlowControlFrame.MODO=0x07;
  79.    OBDFlowControlFrame.PID=0xF9;
  80.    
  81.    i=0;
  82.    *OBDPacket->NRecibidos=0;
  83.    
  84.    if(can_tbe())
  85.    {  
  86.       can_putd(ECU_ID,&OBDPacketToSend,8,3,0,0);
  87.       currTick = lastTick=TickGet();
  88.       TimeOut=False;
  89.       do
  90.       {
  91.          currTick = TickGet();
  92.          if(can_kbhit())
  93.          {
  94.            can_getd(ReceiptID,&OBDPacket->OBDPacketToSave[i],Alen,rxstat);
  95.            OBDPacket->NRecibidos=OBDPacket->NRecibidos+1;
  96.            //fprintf(DEBUG,"NRecibidos:%d\r\n",OBDPacket->NRecibidos);
  97.            OBDPacket->Receipt_ID[i]=ReceiptID;
  98.            //fprintf(DEBUG,"ReceiptID:%lx\r\n",OBDPacket->Receipt_ID[i]);
  99.            ByteCheck=OBDPacket->OBDPacketToSave[i].NBYTES;
  100.            //fprintf(DEBUG,"ByteCheck:%x\r\n",ByteCheck);
  101.            ByteCheck=ByteCheck&0xF0;
  102.             if (ByteCheck==0x10)
  103.             {    
  104.                can_putd(ECU_ID,&OBDFlowControlFrame,3,3,0,0);
  105.                fprintf(DEBUG,"First Frame detected\r\n");
  106.             }
  107.             else if (ByteCheck==0x20)
  108.             {
  109.                fprintf(DEBUG,"Consecutive Frame detected\r\n");
  110.             }
  111.             i++;
  112.          }
  113.          else if (TickGetDiff(currTick, lastTick) > (TICKS_PER_SECOND*5)) //4 segundos lo iremos ajustando hacia abajo
  114.          {
  115.             TimeOut=True;
  116.             #ifdef PROGRAM_DEBUG
  117.                fprintf(DEBUG,"TimeOut\r\n");
  118.             #endif
  119.             lastTick = currTick;
  120.          }
  121.       }while(!TimeOut); // cinco segundos o los datos
  122.       if(OBDPacket->NRecibidos!=0)
  123.       {
  124.          return(EC_OK);
  125.       }
  126.       else
  127.       {
  128.          return(EC_TIMEOUT);
  129.       }
  130.    }
  131.    else
  132.    {
  133.       return(EC_SENDBUFFERBUSY);
  134.    }
  135. }
  136.  
  137.  
  138.  
  139.  
  140.  
  141. void main()
  142. {
  143.  
  144.    static struct ODB_MPacket OBDPacket;
  145.    Set_tris_a(0x00);
  146.    Set_tris_b(0x00);
  147.    Set_tris_c(0x80);
  148.    setup_timer_1(T1_INTERNAL|T1_DIV_BY_2);
  149.    TickInit();
  150.    can_init();
  151.    enable_interrupts(INT_RDA);
  152.    STACK_STATUS=GET_IMEI;
  153.    CASE_STATUS=SEND_CMD;
  154.    CONNECTION_STATUS=0;
  155.    MODEM_STATUS=0;
  156.    fprintf(DEBUG,"Ready\r\n")
  157.    delay_ms(5000);
  158.    fprintf(DEBUG,"Query Result%d\r\n",SendQuery(BroadcastID_11,0X01,0x00,&OBDPacket));
  159.    while(true)
  160.    {
  161.      
  162.    // GSM_STACK();
  163.      
  164.    }
  165.  
  166. }
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 22 de Septiembre de 2013, 14:04:54
Citar
int8 NBYTES;    //0 Numero bytes adicionales
   int8 MODO;      //1 Modo
   int8 PID;       //2 PID
   int8 DATA[5];    //3 Data

por que DATA esta limitado a 5 bytes??
Nunca usan los 8 posibles del CAN ??
Título: Re: Mis experiencias con el BUS CAN
Publicado por: PICSHIRU en 23 de Septiembre de 2013, 09:53:19
Hasta donde se la trama se compone de, entre otras cosas, un id, un dlc y 8 bytes de datos que son los que guardo en la estructura, es cierto que podria usar un sencillo array de ocho elementos pero tengo previsto complicarlo mucho mas.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 23 de Septiembre de 2013, 12:46:50
Podrias ampliaros au mas de como es ese protocolo y el uso de sus id ??
En lo que muestras no se ven cosas raras, pero eso no dice si esta bien o mal, ni que esta mal...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: JUAN_RAMON_RG en 23 de Septiembre de 2013, 15:13:29
Les paso un link en donde viene explicado lo de los pid y el uso de los 8 bytes que comenta el compañero...espero que les sirva

http://obdcon.sourceforge.net/2010/06/obd-ii-pids/
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 08 de Octubre de 2013, 08:48:54
Buenos días,

Sabeis si en modo Loopback se atienden a las interrupciones??
Si lo hago sin interrupciones recibo el mensaje, pero al hacerlo por interrupciones en el PIC32 no atiende a éstas y no recibo ningún mensaje.

Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: afelio en 10 de Octubre de 2013, 16:24:51
Buenas,

Ya he verificado que si se puede acceder a las interrupciones en el modo Loopback. Era un error de configuración en las interrupciones.

Pero ahora me surge una duda sobre los datos.

Tenemos en la estructura BYTE data[8]

Me pregunto si se podría cargar en la misma función de transmitir
data[0] = 0xAA
data[1] = 0xBB
...
...

Muchas gracias.
Un saludo.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: peteorito en 20 de Octubre de 2013, 20:23:09
Hola:
 Despues de  llevar un tiempo cacharreando con el CAN , me he puesto a ver  las configuraciones,   segun he leido  con estos parametros que son los que trae el CCS por defecto estamos trabajando ¿con un Cristal de 20mhz y un velocidad de  transmision de 125KPBS?, pero mi duda sale que cuando lo intento calcular con  el programa que se habla en la pagina 2 del post que no me coinciden, conoceis alguna web para calcularlo a mano , o vengan ex`plicado cada parametro . Gracias!

Código: C
  1. #include "can-18F4580.c"
  2. #define CAN_BRG_SYNCH_JUMP_WIDTH  0  //synchronized jump width (def: 1 x Tq)
  3. #define CAN_BRG_PRESCALAR  4  //baud rate generator prescalar (def: 4) ( Tq = (2 x (PRE + 1))/Fosc )
  4. #define CAN_BRG_PHASE_SEGMENT_1  5 //phase segment 1 (def: 6 x Tq)
  5. #define CAN_BRG_PROPAGATION_TIME 2 //propagation time select (def: 3 x Tq)
  6. #define CAN_BRG_PHASE_SEGMENT_2 5 //phase segment 2 time select (def: 6 x Tq)
Título: Re: Mis experiencias con el BUS CAN
Publicado por: JUAN_RAMON_RG en 21 de Octubre de 2013, 02:14:12
Muy buenas noches..estoy haciendo un proyecto de comunicacion can bus con un automovil ...pero alguien tiene idea de las configuracion de velocidad con las que se comunica el can bus del automovil...gracias.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: pegasso en 03 de Noviembre de 2013, 13:04:37
Hola que esten todos muy bien, nunca he programado el bus can en un microcontrolador, es mas hasta apenas ahora me entero que existia esto. Ustedes conocen mas del tema, y tengo un  proyecto que deseo desarrollar, pero para eso, me gustaria si alguien pudiera darme alguna recomendación.
El proyecto consiste, en recibir una trama de datos (a través de bus can)  que me permita modificar una pwm de acuerdo al valor de un convertidor ADC ( esto es para fines de regulación),. es decir senso voltaje-- mando la trama de datos por buscan-- y modifico la pwm para regular..
No se que integrados me recomienden para esto,o si solo sera necesario con un microcontrolador que posea bus can y adcs.
Muchas gracias
Título: Re: Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 01 de Marzo de 2014, 12:37:15
Muy buenas noches..estoy haciendo un proyecto de comunicacion can bus con un automovil ...pero alguien tiene idea de las configuracion de velocidad con las que se comunica el can bus del automovil...gracias.
N
Hola buen día a que modelo y marca de carro te refieres. Saludos
Título: Re: Mis experiencias con el BUS CAN
Publicado por: rotting79 en 22 de Marzo de 2014, 01:15:27
hey there

u r talking about the SAE J1939 CAN Bus, that's the automotive car's communication with some kind of module (computer's vehicle), and the baud rate for that SAE is always at 125kb per sec

and sadly you have to follow some rules, with specific address and acknowledge and stuff, please read some SAE J1939 literature.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gatocristian en 26 de Marzo de 2014, 00:14:43
buenas noches soy nuevo en esto del bus can y no se por donde empezar quiero realizar una conexion entre dos pic32 donde el nodo a le mande la orden al nodo 2 de encender varios led al mismo tiempo gracias agradesco su colaboraxion
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Marzo de 2014, 00:23:18
En que lenguaje quieres hacerlo??
Hay en este hilo varios ejemplos, busca en el indice (creo que esta actualizado). :lol:
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gatocristian en 26 de Marzo de 2014, 00:41:15
en lenguaje c
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gatocristian en 26 de Marzo de 2014, 00:43:11
o c++ la idea es que haga la funcion que quiero y que pueda entender cada una de las instrucciones agradesco tu ayuda
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Marzo de 2014, 08:19:27
Antes de ver un ejemplo deberás pasar por leer como funciona el BUS CAN, de otro modo llevaría un año explicártelo paso a paso...

Arranca leyendo el hilo (creado para tener info en español) y buscando información sobre el tema, si sabes ingles encontraras aun mas información en la WEB de Microchip y otras.

No te valdrá de nada un ejemplo si no entiendes primero como funciona, y que parte del protocolo se resuelve en hardware y cual en el firmware que hagas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gatocristian en 26 de Marzo de 2014, 10:41:02
ya yo lei sobre el bus can gracias por preocuparte lo que pasa es que no se por donde empezar se sobr e las tramas todo ya yo estoy informado  solo que no sepor donde empezar agradeceria tu ayuda
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Marzo de 2014, 12:17:42
Pon un esquema en el cual ya tengas armado, de ambos nodos.
Esto del CAN NO SE SIMULA, así que olvídate de proteus en este caso...
En base a tu es que te modifico un ejemplo para que te funcione en C de CCS, no pidas mas...
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gatocristian en 26 de Marzo de 2014, 13:38:05
/#include <32MX795F512L.h>
//#fuses HS,NOPROTECT,NOLVP,NOWDT
#use delay(clock=10000000)
//#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
 
#define CAN_DO_DEBUG TRUE
 
//#include <can-32xxxx.c>
#include "can-32MX795F512L.c"
 
#define PIN_LED1  PIN_A5

 
#define LED1_LOW  output_low(PIN_LED1)
#define LED1_HIGH output_high(PIN_LED1)

#define ASK_FOR_ID_AD_B      0x201  //ask for AD info from CAN port B
#define SET_LED_ID_B         0x202  //set LEDs for CAN port B

 
void main() {
   int a_leds=1;
   struct rx_stat rxstat;
   int32 rx_id;
   int buffer[8];
   int rx_len;
   }
   
   LED1_HIGH;
   delay_ms(1000);
   LED1_LOW;
   
 
   can_init();
 
   enable_interrupts(INT_TIMER2);
   enable_interrupts(GLOBAL);
 
 
   while(TRUE)
   {
      if ( can_kbhit() )
      {
         printf("\r\n");
         if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) {
            if (rx_id == ASK_FOR_ID_AD_B) {
               printf("Channel B AD: %X\r\n",buffer[0]);
            }
           
         }
      }
 
 
         //change leds on port b
         printf("\r\n\r\nSet LEDs on Port B to %U",b_leds);
         can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);
         b_leds++;
         if (b_leds > 7) {b_leds=0;}
      }
 
Título: Re: Mis experiencias con el BUS CAN
Publicado por: gatocristian en 26 de Marzo de 2014, 13:38:56
NODO 1

Código: C
  1. /#include <32MX795F512L.h>
  2. //#fuses HS,NOPROTECT,NOLVP,NOWDT
  3. #use delay(clock=10000000)
  4. //#use delay(clock=20000000)
  5. #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
  6.  
  7. #define CAN_DO_DEBUG TRUE
  8.  
  9. //#include <can-32xxxx.c>
  10. #include "can-32MX795F512L.c"
  11.  
  12. #define PIN_LED1  PIN_A5
  13.  
  14.  
  15. #define LED1_LOW  output_low(PIN_LED1)
  16. #define LED1_HIGH output_high(PIN_LED1)
  17.  
  18. #define ASK_FOR_ID_AD_B      0x201  //ask for AD info from CAN port B
  19. #define SET_LED_ID_B         0x202  //set LEDs for CAN port B
  20.  
  21.  
  22. void main() {
  23.    int a_leds=1;
  24.    struct rx_stat rxstat;
  25.    int32 rx_id;
  26.    int buffer[8];
  27.    int rx_len;
  28.    }
  29.    
  30.    LED1_HIGH;
  31.    delay_ms(1000);
  32.    LED1_LOW;
  33.    
  34.  
  35.    can_init();
  36.  
  37.    enable_interrupts(INT_TIMER2);
  38.    enable_interrupts(GLOBAL);
  39.  
  40.  
  41.    while(TRUE)
  42.    {
  43.       if ( can_kbhit() )
  44.       {
  45.          printf("\r\n");
  46.          if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) {
  47.             if (rx_id == ASK_FOR_ID_AD_B) {
  48.                printf("Channel B AD: %X\r\n",buffer[0]);
  49.             }
  50.            
  51.          }
  52.       }
  53.  
  54.  
  55.          //change leds on port b
  56.          printf("\r\n\r\nSet LEDs on Port B to %U",b_leds);
  57.          can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);
  58.          b_leds++;
  59.          if (b_leds > 7) {b_leds=0;}
  60.       }
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Marzo de 2014, 13:59:17
Me permiti modificarte la forma de poner el codigo, para que se lea estilo C.
Lo haces con Geshi y eliges C del listado.
Título: Re: Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 26 de Marzo de 2014, 14:01:48
Lo lamento, pero con PIC32 no vas a poder programarlos en CCS, porque aun no tiene el compilador...
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 11 de Abril de 2016, 03:05:35
Hola buenas noches aca te subo un monitoreo de unas tramas que estoy analizando, son de un carro ford el scanne envia las trama con ID720 y el carro responde con las tramaa ID728:

(HEX),720,8,02,11,01,00,00,00,00,00
(HEX),728,8,03,7F,11,22,00,00,00,00
(HEX),720,8,02,10,85,00,00,00,00,00
(HEX),728,8,02,50,85,00,00,00,00,00
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,89,45,CC,00,00
(HEX),720,8,05,27,02,A1,18,CA,00,00
(HEX),728,8,03,7F,27,35,00,00,00,00
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,D9,8B,52,00,00
(HEX),720,8,05,27,02,16,17,B7,00,00
(HEX),728,8,03,7F,27,35,00,00,00,00
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,28,D2,FA,00,00
(HEX),720,8,05,27,02,4C,54,60,00,00
(HEX),728,8,03,7F,27,35,00,00,00,00
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,79,18,61,00,00
(HEX),720,8,05,27,02,37,C8,37,00,00
(HEX),728,8,02,67,02,00,00,00,00,00

 saludos y si alguien tiene informacion de como analizar las respuesta que envia el carro y segun esas rspuesta lo que luego le envia el equipo. ese es mi proposito de analisis
Título: Re:Mis experiencias con el BUS CAN
Publicado por: teleko en 11 de Abril de 2016, 03:40:53
Hola buenas noches aca te subo un monitoreo de unas tramas que estoy analizando, son de un carro ford el scanne envia las trama con ID720 y el carro responde con las tramaa ID728:

(HEX),720,8,02,11,01,00,00,00,00,00
(HEX),728,8,03,7F,11,22,00,00,00,00
(HEX),720,8,02,10,85,00,00,00,00,00
(HEX),728,8,02,50,85,00,00,00,00,00
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,89,45,CC,00,00
(HEX),720,8,05,27,02,A1,18,CA,00,00
(HEX),728,8,03,7F,27,35,00,00,00,00
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,D9,8B,52,00,00
(HEX),720,8,05,27,02,16,17,B7,00,00
(HEX),728,8,03,7F,27,35,00,00,00,00
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,28,D2,FA,00,00
(HEX),720,8,05,27,02,4C,54,60,00,00
(HEX),728,8,03,7F,27,35,00,00,00,00
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,79,18,61,00,00
(HEX),720,8,05,27,02,37,C8,37,00,00
(HEX),728,8,02,67,02,00,00,00,00,00

 saludos y si alguien tiene informacion de como analizar las respuesta que envia el carro y segun esas rspuesta lo que luego le envia el equipo. ese es mi proposito de analisis

Hola,
Como bien dices, cada vez que envías una trama con el ID 720, la centralita te responde con 728. El siguiente 8 es la longitud del mensaje (can de 11 bytes). Luego la longitud del mensaje enviado (PDU). Y lo siguiente es el PID pedido o el valor de vuelta, que va con un +400 hex sumado si es respuesta.

Por ejemplo:
(HEX),720,8,02,11,01,00,00,00,00,00 --> 720, mensaje codificado de 8, PDU de longitud 2: PID 1101.
(HEX),728,8,03,7F,11,22,00,00,00,00 --> 728, mensaje codificado de 8, PDU de longitud 3: 7F11 (Respuesta de 1101), valor=22

(HEX),720,8,02,10,85,00,00,00,00,00 --> 720, mensaje codificado de 8, PDU de longitud 2: PID 1085.
(HEX),728,8,02,50,85,00,00,00,00,00 --> 728, mensaje codificado de 8, PDU de longitud 2: 5085 (Respuesta de 1085), no hay respuesta con valor (ya que la longitud es 2) = No soportado

(HEX),720,8,02,27,01,00,00,00,00,00 --> 720, mensaje codificado de 8, PDU de longitud 2: PID 2701.
(HEX),728,8,05,67,01,89,45,CC,00,00 --> 728, mensaje codificado de 8, PDU de longitud 5: 6701 (Respuesta de 2701), valor=89 45 CC

Aquí tienes lo que significa cada PID: https://en.wikipedia.org/wiki/OBD-II_PIDs
Aunque algunos PID que pide parece que no están registrados en esa web
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 11 de Abril de 2016, 10:16:42
perfecto hermano eso lo tengo claro pero hay valores que no le veo la logica. ya paso a explicar con ejemplo como lo hiso usted teleko.

saludos y agradecido por su explicacion

(HEX),720,8,02,11,01,00,00,00,00,00 pedido de reset (11)
(HEX),728,8,03,7F,11,22,00,00,00,00 respuesta negativa (7F)
(HEX),720,8,02,10,85,00,00,00,00,00 inicio de sesión (10)
(HEX),728,8,02,50,85,00,00,00,00,00 inicio de sesion correcto
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,89,45,CC,00,00
(HEX),720,8,05,27,02,A1,18,CA,00,00
(HEX),728,8,03,7F,27,35,00,00,00,00 respuesta negativa (7F) key inválida (35)
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,D9,8B,52,00,00
(HEX),720,8,05,27,02,16,17,B7,00,00
(HEX),728,8,03,7F,27,35,00,00,00,00 respuesta negativa (7F) key inválida (35)
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,28,D2,FA,00,00
(HEX),720,8,05,27,02,4C,54,60,00,00
(HEX),728,8,03,7F,27,35,00,00,00,00 respuesta negativa (7F) key inválida (35)
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,79,18,61,00,00
(HEX),720,8,05,27,02,37,C8,37,00,00 este habría que analizar
(HEX),728,8,02,67,02,00,00,00,00,00
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 12 de Abril de 2016, 06:13:45
buen dia , paso a dar otro enfoque del analisis de las tramas espero se entienda

(HEX),720,8,02,11,01,00,00,00,00,00 pedido de reset (11)
(HEX),728,8,03,7F,11,22,00,00,00,00 respuesta negativa (7F)
(HEX),720,8,02,10,85,00,00,00,00,00 inicio de sesión (10)
(HEX),728,8,02,50,85,00,00,00,00,00 inicio de sesion correcto
(HEX),720,8,02,27,01,00,00,00,00,00
(HEX),728,8,05,67,01,89,45,CC,00,00 esta resuesta la da el carro y tenemos claro que 89 xor 45=CC (para mi esta respuesta es de forma aleatoria es decir el 89 y 45 ya que el CC es como un checksum)
(HEX),720,8,05,27,02,A1,18,CA,00,00 esta trama seria lo que se le debe enviar segun la respuesta anterior pero es lo que no tengo claro como armar un algoritmo para que segun los byte 89 45 y CC yo enviarle A1 18 y CA porque ya tenemos claro que la trama es:
(HEX),720,8,05,27,02,xx,yy,zz,00,00 donde en ese caso puntual xx=A1; yy=18 y zz=CA pero esos byte tiene que salir de 89 45 CC.

Saludos y nuevamente gracias
Título: Re:Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Julio de 2016, 12:18:32
Nuevos periféricos con CAN FD (flexible Data)...

(http://www.todopic.com.ar/foros/imgtiny/8zk9w5.jpg)
Título: ISOBus
Publicado por: jocafli en 04 de Octubre de 2016, 05:03:08
Hola a todos!

Soy nuevo en el foro y me gustaría hacer unas consultas para un proyecto con comunicación CAN y protocolo ISOBUS. He realizado una comunicación PC - uC mediante el dispositivo PCAN (CAN - USB) y envío/recibo tramas correctamente. Mi duda es, a la hora de recivir en el uC varias tramas de datos con distintos índices, ?Cómo debo o cúal es la mejor manera de filtrar esos mensajes y enviar la respuestas pertinentes? Me explico. Por ejemplo mi uC recive dos mensajes de tipo dato con los datos 70 y 71, y el uC tiene que devolver respectivavente una velocidad (70) y una aceleración (71). ?Se suele utilizar un "case", tengo que realizar unas librerías? Me gustaría que me orientáseis. Muchas gracias.
Título: Microchip CAN Bit Timing Calculator
Publicado por: AioriaG en 19 de Octubre de 2016, 11:24:15
Una duda, tenia rato sin usar el programa Microchip CAN Bit Timing Calculator y ahora que quise utilizarlo para calcular las velocidades del can me llevo la sorpresa de que ya no me genera el reporte html, lo probé en 2 equipos uno con windows 10 y otro con 7, en ninguno de los 2 lo genero, la pregunta del millón ¿soy al único que ya no le genera los reportes?, o ¿conocen algún otro programa que muestre el valor BRGCON1,2 y 3 ?
Título: Re:Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Octubre de 2016, 11:45:41
En mi caso acabo de probarlo en Win7 (no tengo 10) y funciona correctamente.
Al terminar aprietas el botón Generate Report, no es así?
Título: Re:Mis experiencias con el BUS CAN
Publicado por: AioriaG en 19 de Octubre de 2016, 12:47:41
si, de hecho antes me funcionaba bien, pero ahora ya no me genera el reporte me abre el navegador (https://s18.postimg.org/gr5lrjhm1/can_bit.jpg)
Título: Re:Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Octubre de 2016, 13:02:57
Por lo que veo usas Chrome como navegador.
Pero tienes instalado también Mozilla.
Haz que Mozilla sea el navegador por defecto, luego genera el reporte y déjalo que se abra la ventana del navegador y me cuentas como te fue.
Creo que allí esta tu problema, Chrome ya no es compatible desde hace unos años atrás. :mrgreen: :mrgreen:
Título: Re:Mis experiencias con el BUS CAN
Publicado por: AioriaG en 19 de Octubre de 2016, 13:06:44
ya probe con explorer, edge, firefox, chrome y nada
(https://s15.postimg.org/6s149h32z/can_bit2.jpg)
Título: Re:Mis experiencias con el BUS CAN
Publicado por: AioriaG en 19 de Octubre de 2016, 13:13:30
ya busque con el explorador en la carpeta C:\Program Files\MCP2510 Bit Time\ y en efecto no hay ningún archivo htm, por eso pienso que no lo esta generando. ya desinstale y volví a instalar pero nada, sigue igual
Título: Re:Mis experiencias con el BUS CAN
Publicado por: KILLERJC en 19 de Octubre de 2016, 13:14:07
En resumen el problema esta en que no tenes los archivos, o estas viendo una version tal ves cacheada del mismo. Revisaria o buscaria tener los archivos de nuevo. O ver cual es el archivo que falta, y te esta tirando error
Título: Re:Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Octubre de 2016, 13:19:13
Reinstala el programa entonces, no se que otra cosa decirte...
Título: Re:Mis experiencias con el BUS CAN
Publicado por: AioriaG en 19 de Octubre de 2016, 13:23:25
ya lo volvi a descargar de esta liga https://www.intrepidcs.com/products/free-tools/mb-time-calculator/  (https://www.intrepidcs.com/products/free-tools/mb-time-calculator/) pero sigue igual, si alguien puede pasarme el instalador que usa se los agradecería, es lo ultimo que puedo hacer creo jejeje. De todos modos gracias
Título: Re:Mis experiencias con el BUS CAN
Publicado por: AioriaG en 19 de Octubre de 2016, 13:26:09
O si me pueden ayudar con los valores de los registros BRGCON1,2 y 3 para usar con un cristal de 10mhz y H4 (40mhz), para la velocidad de 125kbps también seria de mucha ayuda
Título: Re:Mis experiencias con el BUS CAN
Publicado por: AioriaG en 19 de Octubre de 2016, 13:46:58
ya lo resolví les comparto mi solución, pues no se si es por el windows 10 o que sea pero resulta que el reporte me lo esta generando en una carpeta diferente a la que carga el navegador, en mi caso esta fue la ruta donde se encuentra el reporte C:\Users\USUARIO\AppData\Local\VirtualStore\Program Files\MCP2510 Bit Time.htm
Muchas gracias por tomarse su tiempo tratando de ayudarme. hay les dejo el dato por si a alguien mas le pasa lo mismo
Título: Re:Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 19 de Octubre de 2016, 15:58:03
Buen caso!!
Estaba preocupado y a punto de hacerte el calculo para que lo tuvieras... :D :D :D
Saludos!!
Título: Re:Mis experiencias con el BUS CAN
Publicado por: BEXTIXTOX en 11 de Junio de 2017, 19:42:24
que tal cominezo con esto del can bus, tengo 4 modulos mcp2515 y 4 18f4550.
he seguido el tema y tengo 13 adjuntos de archivitos para tomarlos como ejemplo de los cuales he notado que unos utilizan pics18fxx8x.
segun entiendo algunos achivitos son para usarlos con estos pics (fxx8x) y otros no, tambien he visto que han modificado las librerias que tiene ccs , pero como es muy extenso el tema me he perdido entre tanto nectar.

 ¿alguien tiene las librerias actualizadas?

he visto en este tema que usan un pic 16f87x estoy buscando donde esta pero no la encuentro.
¿me ayudan con las librerias?
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 11 de Agosto de 2018, 06:31:15
Hola buenos días, tiempo sin tocar el tema de can bus y nada mejor que postear acá donde inicie hace mucho.
Mi tema es el siempre tengo Arduino y shield can bus de sparkfun. Que me funciona muy bien pero ahora quiero emprender un nuevo proyecto y quiero sus opciones y recomendaciones, he venido trabajando can bus operando todo en el Arduino es decir las trama y procesos de cálculo ahora pretendo crear las tramas y procesar las recibidas en una aplicación  aparte específicamente Delphi. Mi consulta puntual es que me recomiendan para crear paquetes de tramas y enviarlos a la interface Arduino-shield can bus. Lo otro como fijar la frecuencia de trabajo y filtrado de tramas del can desde la aplicación y no desde el mismo Arduino como lo vengo haciendo.

Saludos y espero me halla hecho entender.
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 11 de Agosto de 2018, 06:39:45
Hola buenos días, tiempo sin tocar el tema de can bus y nada mejor que postear acá donde inicie hace mucho.
Mi tema es el siempre tengo Arduino y shield can bus de sparkfun. Que me funciona muy bien pero ahora quiero emprender un nuevo proyecto y quiero sus opciones y recomendaciones, he venido trabajando can bus operando todo en el Arduino es decir las trama y procesos de cálculo ahora pretendo crear las tramas y procesar las recibidas en una aplicación  aparte específicamente Delphi. Mi consulta puntual es que me recomiendan para crear paquetes de tramas y enviarlos a la interface Arduino-shield can bus. Lo otro como fijar la frecuencia de trabajo y filtrado de tramas del can desde la aplicación y no desde el mismo Arduino como lo vengo haciendo.

Saludos y espero me halla hecho entender.

Ampliando un poco más lo expuesto, les comento que para todo lo dicho tengo que ajustarme un código o podríamos llamarlo firmware para mi Arduino que pueda interactuar con las peticiones que pretendo en mi aplicación Delphi.

Saludos y atento a sus comentario

Nota: he leido de API can bus para Delphi que supongo puede ayudarme para lo que quiero lograr pero siempre van de la mano de una interface propia y dicha interface con un firmware ya instalado en la misma
Título: Re:Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 11 de Agosto de 2018, 08:31:09
Hola, si quieres usar elementos ya desarrollados, puedes utilizar la interfase de Microchip, o la USB-CAN de Lawicel, por ejemplo.

Aqui te pongo links a ambas.

https://www.can232.com/ (https://www.can232.com/)

http://www.microchip.com/developmenttools/ProductDetails/PartNo/APGDT002 (http://www.microchip.com/developmenttools/ProductDetails/PartNo/APGDT002)
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 14 de Agosto de 2018, 14:57:49
Hola, si quieres usar elementos ya desarrollados, puedes utilizar la interfase de Microchip, o la USB-CAN de Lawicel, por ejemplo.

Aqui te pongo links a ambas.

https://www.can232.com/ (https://www.can232.com/)

http://www.microchip.com/developmenttools/ProductDetails/PartNo/APGDT002 (http://www.microchip.com/developmenttools/ProductDetails/PartNo/APGDT002)

Aquí está el detalle que me gustaría trabajar en base a mi propia interface Arduino y shield can bus que Es lo que tengo a la mano o En su defecto crearme una interface can bus con Pic y controlador interno en el pic y sólo usar un transceiver.


Saludos y quedó atento a sus comentario
Título: Re:Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 15 de Agosto de 2018, 10:15:33
Hola, yo arme mis interfaces CAN con un PIC con USB, Controlador CAN MCP2515 y el correspondiente transceiver.

El código del micro (que no puedo darte porque es comercial) tiene varias instrucciones que manejan el intercambio hacia el bus CAN, y ademas se encarga de intercambiar ordenes y respuestas con puerto USB conectado al software en PC, que se corresponde con el desarrollo hecho para esa aplicación comercial.

Puedo ayudarte a desarrollar lo tuyo, pero deberás escribir tu código tu mismo...

Y deberás compartirlo en este hilo.

Saludos
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 16 de Agosto de 2018, 07:42:40
Hola, yo arme mis interfaces CAN con un PIC con USB, Controlador CAN MCP2515 y el correspondiente transceiver.

El código del micro (que no puedo darte porque es comercial) tiene varias instrucciones que manejan el intercambio hacia el bus CAN, y ademas se encarga de intercambiar ordenes y respuestas con puerto USB conectado al software en PC, que se corresponde con el desarrollo hecho para esa aplicación comercial.

Puedo ayudarte a desarrollar lo tuyo, pero deberás escribir tu código tu mismo...

Y deberás compartirlo en este hilo.

Saludos
Estaria encantado de compartirlo de hecho ya tengo mis idea pero quería ver si había algo ya más profesional ya que lo que tengo pensado es hacer mi código en mi interfaz ya sea hecha con Arduino o con Pic y que desde la aplicación que preferiblemente usaría Delphi envíe las tramas y la interfaz  la ponga en el bus can  y cuando reciba  la envíe a mi aplicación ojo la comunicación entre interfaz y Delphi  lo haría con rs232, es decir serial

Yo lo que pretendía era ver si podía aprovechar API  que ya estuvieran bien probadas y así ganar tiempo.

Saludos y manos a la obra .
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 21 de Agosto de 2018, 06:45:08
Buenos días, estudiando más la situación y revisando una posible interface  decidí usar el pic18f46k80 que tiene controlador CAN ya integrado. Ahora siempre he trabajado los pic en protón pero ya hace mucho que no  programó por y hojeando noto que protón no está bien documentado y soportado en Can bus que compilador me recomiendan para tal fin de la programación can usando dicho pic luego me centro en lenguaje que usaré para crear la aplicación ya sea para win  u/o Android según me llegue la oportunidad tengo en mente Delphi multiplataforma nueva versión pero sería ya luego que tenga claro lo del hardware con el pic y el firmware para esa interface que ya estoy diseñando el esquema .

Saludos y cualquier avance o novedad les comento
Título: Re:Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 21 de Agosto de 2018, 08:14:01
Te recomiendo usar lenguaje C de CCS o de MikroElectronika, ya que ambos tienen librerías C para CAN, de otro modo vas a tener que escribirlas y ademas testearlas tambien.

En mi caso uso el primero, estoy acostumbrado a el y me es mas comodo.

Saludos
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 22 de Agosto de 2018, 05:44:24
Te recomiendo usar lenguaje C de CCS o de MikroElectronika, ya que ambos tienen librerías C para CAN, de otro modo vas a tener que escribirlas y ademas testearlas tambien.

En mi caso uso el primero, estoy acostumbrado a el y me es mas comodo.

Saludos
ok hermano mil gracias por tus sabios consejos en tiempo pasado ambos IDE hice par de ejemplo seria cuestion de familiarizarme con ese lenguaje y trabajar en lo que quiero.

saludos y nuevamente gracias
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 02 de Diciembre de 2018, 12:54:21
Hola días, quien tiene información de componentes para can bus lenguaje de programación ya sea delphy, python o cualquier otro ide de programación que facilite el manejo de can bus para ser usado con una interface x de can bus .

Saludos y estamos en contacto .
Nota: he leído sobre una llamada Tcandriver para delphi pero por más qu3 la busco no encuentro información al respecto
Título: Re:Mis experiencias con el BUS CAN
Publicado por: Neutrino en 02 de Diciembre de 2018, 13:07:14
Hola ASTROCAR, en Python tienes la libreria python-can (https://python-can.readthedocs.io/en/3.0.0/index.html) y la puedes instalar fácilmente usando pip (https://pypi.org/project/python-can/)

Saludos.
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 02 de Diciembre de 2018, 20:07:04
Hola ASTROCAR, en Python tienes la libreria python-can (https://python-can.readthedocs.io/en/3.0.0/index.html) y la puedes instalar fácilmente usando pip (https://pypi.org/project/python-can/)
Hola hermano mil gracias voy a revisar y les aviso como me va con python

Saludos.
Título: Re:Mis experiencias con el BUS CAN
Publicado por: Neutrino en 02 de Diciembre de 2018, 20:29:10
Hola ASTROCAR, Si tienes alguna duda, no dudes en publicar en el foro de Python, yo tengo algo de experiencia con el lenguaje.

Saludos
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 16 de Enero de 2019, 00:51:37
ok gracias hermano
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 10 de Mayo de 2019, 09:30:06
hola buenos dias, estoy emigrando mis codigos can bus a pic18f25k80 y pienso usar el IDE de CCS; si tienes algun otro que me puedan recomentar aparte del ccs.
otras de mis dudas es que vengo usando libreria can bus usadas en arduino y ahora el can lo tengo integrado en el pic  que libreria deberia usar o cyales me recomiendan.
 Tambien tengo en mente poder actualizar el firmware del pic para tal caso debo usar un bootloarder.

luego les paso mas detaller del proyecto y la aplicacion que voy haciendo para interactual con el pic y poder manejar las tramas can la comunicacion  con erl pic sera via puerto serial rs232 uart.

saludos y cualquier recomendacion bienvenida sea.
Título: Re:Mis experiencias con el BUS CAN
Publicado por: MGLSOFT en 10 de Mayo de 2019, 10:57:13
Uso el pic18f26k80, en ese te puedo ayudar mas.
Cuando tuve que actualizar usé el Project Wizard, alli podras ya seleccionar todos los items que quieres agregar a tu proyecto.
Título: Re:Mis experiencias con el BUS CAN
Publicado por: ASTROCAR en 10 de Mayo de 2019, 22:04:52
Gracias por tu pronta respuesta hermano y que compilador usas .

Saludos