Mis experiencias con el BUS CAN

[electrolinux]

Lo podras bajar de aqui (piden registro).
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

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

Saludos

[MGLSOFT]

Lo podras bajar de aqui (piden registro).
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

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

[maunix]

Te hago una correccion.
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.

[MGLSOFT]

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

[maunix]

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  , 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

[electrolinux]

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

[electrolinux]

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

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

Saludos

[maunix]

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.

[electrolinux]

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

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.

Saludos

[electrolinux]

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

[maunix]

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. 

[MGLSOFT]

Bueno, espero que no nos vayamos nuevamente de tema en este hilo...
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...

[electrolinux]

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.

[electrolinux]

Bueno, espero que no nos vayamos nuevamente de tema en este hilo...

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

Sin duda que lo enviare, dejenme empaquetarlos y lo envio como archivos de texto.

[electrolinux]

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