TODOPIC
Otros Microcontroladores / Dispositivos programables => Microcontroladores ARM => Mensaje iniciado por: planeta9999 en 23 de Septiembre de 2014, 12:26:26
-
Encaro mi primer proyecto completo hard-soft, usando Raspberry y Beaglebone black, además necesitaba usar un bus de comunicaciones para enlazar varias placas y me he decidido por CAN bus, como entorno de desarrollo QT Creator con C++ bajo Windows, la instalación y configuración ya la documenté al detalle en este post: http://www.todopic.com.ar/foros/index.php?topic=41770.0
La decisión del tipo de bus a usar, me ha liado un poco, en principio las placas las diseñé para comunicarse con un bus paralelo de 8 hilos, más una linea de control por placa, máximo 7 placas, pero como se van a instalar en un entorno ruidoso electromagnéticamente hablando, y el cableado puede llegar a tener 1 ó 2 metros, decidí buscar otra solución. Se me presentaban 3 opciones, RS485, CAN bus o Ethernet, el primero no lo conozco y tendría que empezar de cero, así que descartado, Ethernet requiere un hardware caro, un hub, un conector demasiado voluminoso y un controlador para la capa física demasiado pequeño (LQFP48) para montar prototipos caseros o hacer pequeñas tiradas, así que me he decidido por CAN bus, los transceptores son baratos, a 1Mb/s de velocidad tengo de sobra y el conector y cableado no es caro ni específico.
Aquí van las 3 placas, que tengo diseñadas por ahora, ya están encargadas a HQPCB, salieron este Lunes de China, así que las espero en breve. El reto va a estar realmente en el desarrollo del software, porque QT apenas lo conozco, pero todo es empezar, me parece un entorno de desarrollo extraordinario y además es GRATUITO.
Placa MASTER, con zócalos para pinchar una Raspberry o una Beaglebone Black, PIC32 para controlar LEDS digitales WS2812B, MOSFET para controlar un motor DC, tarjetero micro SD para actualización de firmware con bootloader encriptado, controlador CAN bus MCP2551 o MCP2561, conversor SPI - CAN bus MCP2515 para dotar a la RPI/BBB de comunicación CAN bus, comunicación auxiliar por I2C RPI/BBB - PIC32, puerto USB para conexión a PC o Sticks PC (MK802, Mele, uHost, etc...).
(http://i1322.photobucket.com/albums/u573/planeta9999/ScreenHunter_001_zps1c1d67b6.jpg)
Placa ESCLAVA de entradas, con PIC32, tarjetero micro SD, controlador CAN bus MCP2551, entradas en matriz de 8*16 (128 pulsadores)
(http://i1322.photobucket.com/albums/u573/planeta9999/ScreenHunter_002_zps9a1f7a66.jpg)
Placa ESCLAVA de salidas, con PIC32, tarjetero micro SD para actualización de firmware, controlador CAN bus MCP2551. Salidas a MOSFET para controlar 8 bobinas alimentadas a 50 voltios DC.
(http://i1322.photobucket.com/albums/u573/planeta9999/ScreenHunter_004_zps09e5b36c.jpg)
-
muy buenas placas!!!! y son para un pinball?
sds.
-
Que buena pinta!! Gracias por compartir!
-
muy buenas placas!!!! y son para un pinball?
sds.
Si, es una de las aplicaciones, pero lo que más me interesa es aprovechar este proyecto para meterme de lleno en la programación de la Raspberry y la Beaglebone Black con QT-Creator, y también de paso tocar el CAN bus para comunicar varias placas en red, espero que sea rápido y fiable.
-
Si quieres mas proteccion (aunque para lo que quieres creo que no lo necesitarias) en vez del mcp2551 buscate un iso1050.
Yo he tenido malas experiencias con el mcp2551 y deje de usarlo por eso, a veces si apagabas una placa antes que otra se quemaban misteriosamente.
-
ME encantan los pcb , tus tarjetas se ven muy padres !! ((:-))
Saludos!!
P.D. Buen tuto del QT , no lo habia visto. 8)
-
Si quieres mas proteccion (aunque para lo que quieres creo que no lo necesitarias) en vez del mcp2551 buscate un iso1050.
Yo he tenido malas experiencias con el mcp2551 y deje de usarlo por eso, a veces si apagabas una placa antes que otra se quemaban misteriosamente.
Lo tendré en cuenta, aunque ya tengo encargadas las placas, si que es raro que se quemen los chips según se apaguen antes o después las placas, lo probaré todo bien por si acaso.
-
Si que es raro, es como si al apagar una placa hubiese una corriente de fuga a traves del bus can y se quema el mcp al intentar alimentar la otra placa. De todas formas, ahora que ya lo sabes, si te ocurre ya sabes que puede ser, asi no te comes la cabeza como hice yo en su momento jaja.
-
Nunca me paso eso en un MCP2551... :shock: :shock:
Es mas, nunca cambie uno tampoco...
Que vas a transmitir por ese bus CAN, planeta9999 ??
-
Nunca me paso eso en un MCP2551... :shock: :shock:
Es mas, nunca cambie uno tampoco...
Espero que tampoco me pase a mi, es la primera vez que voy a usar estos chips.
Que vas a transmitir por ese bus CAN, planeta9999 ??
La placa MASTER, activa 8 bobinas de la placa de salidas, y lee 128 pulsadores de la placa de entradas, son muy poquitos bits los que hay que transmitir. De la MASTER a la de salidas, tan solo hay que enviar 1 byte (1 bit por bobina), para activar o no cada una de las 8 bobinas, se desactivarán solas, transcurridas unas decimas de segundo, por el programa que lleva el PIC de la placa.
De la placa de entradas, se leen los 128 pulsadores conectados en una matriz de 8 x 16, las 8 filas se activan secuencialmente por un ULN2803, y con cada fila activada se leen sus 16 columnas, en total cuando la placa MASTER lo pida, la placa de entradas le debe de devolver 128 bits, cada bit se corresponde con el estado de un pulsador. La placa también se podría configurar para leer 8 entradas directas, y las otras en matriz de 8*8. Bueno en realidad, en esta placa iban más entradas, pero lo olvidé, y cuanto se lo dije al chino, ya estaban fabricando el PCB, para la próxima revisión añadiré otras 16 entradas más, para tener una matriz de 8 * 32 (256 pulsadores).
-
El MCP2551 va a 5 voltios, el IO de recepción coge bien 3.3V pero si no pones una resistencia para limitar la corriente en el IO de transmisión (para forzar caida de voltaje) "freirás" la RPI y/o la BBB.
Lo digo por experiencia: el que avisa no es traidor :P
Un saludo!
-
El MCP2551 va a 5 voltios, el IO de recepción coge bien 3.3V pero si no pones una resistencia para limitar la corriente en el IO de transmisión (para forzar caida de voltaje) "freirás" la RPI y/o la BBB.
Lo digo por experiencia: el que avisa no es traidor :P
Un saludo!
El MCP2551 no va conectado directamente a la RPI/BBB, ninguna tienen CAN bus, para eso utilizo un MCP2515 que convierte SPI a CAN bus, ese chip si que va a 3v3.
-
Sorry: olvidé lo de la RPI.
La BBB sí que tiene CAN: búscalo bien ;-)
-
El MCP2551 va a 5 voltios, el IO de recepción coge bien 3.3V pero si no pones una resistencia para limitar la corriente en el IO de transmisión (para forzar caída de voltaje) "freirás" la RPI y/o la BBB.
Lo digo por experiencia: el que avisa no es traidor :P
Un saludo!
Allí si te serviría el MCP2561, que si mal no lo vi, trabaja a 3,3V directamente.
Ademas hay un modelo (creo que termina en 62) que tiene splitter de bus, por lo tanto permite eliminar cualquier sospecha de aterrizaje diferente de los nodos entre si.
Si bien el patillaje es similar, hay que leer las notas de aplicación para utilizarlos.
-
Genial MGLSOFT no los conocía: el 62 es perfecto!
Gracias!
-
Sorry: olvidé lo de la RPI.
La BBB sí que tiene CAN: búscalo bien ;-)
Ok, ya veo, no sabía que la BBB tuviera CAN bus, de todas formas como ya están hechas las placas y además como la RPI no tiene CAN bus, voy a dejar la circuiteria compartida entre ambas, SPI-CAN bus con el MCP2515 a 3v3 y el transceptor MCP2551 a 5v.
También podría haber usado un ISO1050 a 3v3, compartido entre ambas, y aislarlo con un par de jumpers del MCP2515 cuando se use con la BBB, pero creo que complicaría las cosas. El MCP2515 funciona a 10Mhz por SPI y no supongo que sea ningún cuello de botella para el MCP2551 que va a 1Mb/s por CAN bus.
Pero bueno es saber para otros proyectos, que la BBB integra CAN bus, creo que tiene dos puertos CAN, gracias por la advertencia.
-
Si pones en tus proyectos esos nuevos transceivers, te aproximas a utilizar el futuro del bus CAN, denominado CAN FD (Flexible Data).
Este va a superar varias veces las velocidades maximas de hoy.
Vean la nota de aplicacion de CAN CIA:
http://www.can-newsletter.org/hardware/semiconductors/140617_bit-rates-up-to-2-mbit-and%20higher/ (http://www.can-newsletter.org/hardware/semiconductors/140617_bit-rates-up-to-2-mbit-and%20higher/)
-
Hace tiempo vi el MCP2561, y parece que es pin a pin compatible con el MCP2551, creo que se puede reemplazar sin necesidad de hacer cambios en el circuito. http://ww1.microchip.com/downloads/en/DeviceDoc/90003101A.pdf
Tengo los dos, los probaré a ver si noto diferencias.
-
Aqui tienes el documento que indica cuales son las diferencias en la migracion...
http://ww1.microchip.com/downloads/en/DeviceDoc/90003101A.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/90003101A.pdf)
-
Se ven estupendas las placas.
En cuanto a la decisión de utilizar CAN o RS485, ambos son estándares fieldbus muy utilizados en la industria.
Aquí en Europa, Siemens domina en el mercado de PLCs y su estandar está basado en RS-485 (Profibus)
Rockwell (AllenBradley), que domina en el mercado, americano utiliza un estandar basado en CAN Bus (Devicenet)
Ambos estándares son más que suficientes para lo que quieres y ambos tienen mucho apoyo.
Aquí una comparativa:
http://www.ixxat.com/download/artikel_20105_can-vs-rs485_e.pdf
Saludos.
-
Menudo cachondeo se llevan los chinos últimamente en Aduanas, una semana tengo retenido el paquete con los PCB y los Stencil, en las aduanas de Hong Kong. No se si será cierto o un hoax, dicen que debido al trapicheo de importaciones ilegales de Iphone 6, se han puesto duros en las revisiones de los paquetes, y los miran todos con lupa, el resultado es un colpaso de tres pares de narices.
Por cierto, ¿ alguien sabe si para usar CAN bus con los PIC, es imprescindible usar el oscilador a cuarzo, o se puede usar el interno ?, la misma cuestión para usar SPI y DMA. Se que para utilizar USB si que es imprescindible el oscilador a cuarzo, debido a la falta de estabilidad o precisión del RC, pero desconozco si CAN bus y SPI también lo precisan.
-
SPI seguro que no y CAN yo diría que tampoco.
-
SPI no ya que tiene su propio clock (SCK) da igual incluso que vayan a distinta velocidad. El CAN tampoco necesita que sea un reloj preciso suele tener cierta tolerancia.
-
Ok, gracias, lo probaré en cuanto me lleguen las placas, tengo otras con CAN bus y oscilador interno todavía pendientes de ensamblar, a esta nueva que me llega ahora si que le puse el cuarzo por si acaso.
Por algún sitio leí hace poco, que CAN bus necesitaba el cuarzo, creo que en los foros de Microchip, será cuestión de probar, espero que no haga falta sino algunas placas terminarán en la basura.
-
No use hasta ahora PIC32, pero en PIC18F y PIC24HJ use el oscilador interno con el CAN a 250 K y RS232 a 115200 BPS sin ningun tipo de problemas.
No te preocupes, es muy bueno el oscilador interno, igualmente siempre dejo los pines sin usar y el circuito para ponerle el cristal si hace falta, por si las moscas... :mrgreen: :mrgreen:
-
Yo hice hace un año o asi un bus de 3 componentes, los 3 con cristal interno y no me dio ningun problema. Incluso con usb y cristal interno tampoco he tenido problemas.
-
Yo hice hace un año o asi un bus de 3 componentes, los 3 con cristal interno y no me dio ningun problema. Incluso con usb y cristal interno tampoco he tenido problemas.
El problema del cristal interno es justo eso: que está dentro :P. Es decir: si el PIC disipa mucha potencia el cristal ("como el resto del PIC") se calienta y cambia su frecuencia. Como tú comentas: para cualquier aplicación al uso el USB funciona genial con el cristal interno.
-
El Bus Can tiene un sistema parecido al RS232, en los que se sobremuestrean las señales: http://en.wikipedia.org/wiki/CAN_bus#Bit_timing
Ambas comunicaciones son asíncronas, es decir que los relojes del emisor y del receptor son independientes y deben sincronizarse con frecuencia.
En SPI el reloj viaja por una línea más y por lo tanto es común a ambos y la comunicación es síncrona.
En el caso del RS232 la resincronización cada 10 bits da un margen de hasta +-5% de error en el reloj sin causar problemas, debido a que los relojes se resincronizan en cada secuencia de bits Start/Stop.
En el caso del Bus Can imagino que será semejante, aunque desconozco los detalles.
Saludos.
-
The Configuration of the CAN Bit Timing - Bosch
No consigo encontrar el enlace original, dejo aquí el de google:
http://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCMQFjAA&url=http%3A%2F%2Fwww.bosch-semiconductors.de%2Fmedia%2Fpdf_1%2Fcanliteratur%2Fcia99paper.pdf&ei=prMqVMiQFceBsQSG94HIBA&usg=AFQjCNHK7q3-OJr58kU8cuThYvdUaFDt5g&bvm=bv.76477589,d.cWc
Apartado 4: Oscillator Tolerance Range
Saludos.
-
Por fin me llegaron las placas, 10 días han tardado por culpa del colapso que hay en las aduanas de Hong Kong.
Ahora a ensamblar y empezar con el software, que será lo más complicado. Como creo que no hay un post al respecto, documentaré con fotos todo el proceso del ensamblado, con la aplicación del estaño en pasta con el stencil, colocación de componentes, soldadura en horno de infrarrojos e inspección de soldaduras con el microscopio.
Placa principal.
(http://i1322.photobucket.com/albums/u573/planeta9999/PCB_Pinsolution_001_zps4be2f4c5.jpg)
Placa de entradas.
(http://i1322.photobucket.com/albums/u573/planeta9999/PCB_Pinsolution_003_zpsfc0ecb1b.jpg)
Placa de salidas.
(http://i1322.photobucket.com/albums/u573/planeta9999/PCB_Pinsolution_002_zps8d451429.jpg)
Y estas 3 para probar los famosos leds digitales WS2812B.
(http://i1322.photobucket.com/albums/u573/planeta9999/PCB_Pinsolution_004_zps9d82a566.jpg)
.
-
:-/
((:-))
que bueno planeta!!
-
Muy profesional, enhorabuena!
-
Información detallada para instalar y configurar CAN bus con el MCP2515 en Raspberry:
http://elinux.org/RPi_CANBus
Ya veremos como de complicado son todas estas gaitas de compilar el kernel.
-
Al parecer la Raspberry es un poco opaca en su documentación y código. No es del todo open-hardware como otras plataformas.
Suerte. Ya nos contarás.
-
No he tenido la oportunidad de profundizar con la Raspberry, lo bueno es que hay una comunidad enorme, seguro que cualquier cosa que se nos ocurra ya está resuelta.
De todas formas no descarto utilizar Ethernet, en ese caso en la placa principal no tendría que todar nada, y los módulos los rediseñaría añadiendo un ENC o usando un PIC con Ethernet y el controlador para la capa física, lo bueno con respecto a CAN bus, es que pasamos de 1Mb/s a 10Mb/s ó 100Mb/s.
Por aquí he localizado información para usar el MCP2515 con la Beaglebone Black:
http://the8thlayerof.net/tag/socketcan/
http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/
Lo que todavía no tengo claro es si se podría conectar directamente el MCP2551 a la Beaglebone Black, porque este chip va a 5 voltios, ahora lo tengo conectado a través del MCP2515 que actua como conversor SPI - CAN bus, pero sería mejor usar los puertos CAN bus que si tiene la BBB y añadirle solo el transceptor para la capa física, podria usar el ISO1050 que va a 3v3, pero es carísimo en comparación.
Empezaré con las pruebas, en cuanto lo ensamble todo, y ya veremos si está solución MCP2515-MCP2551 funciona decentemente.
-
El
MCP2515 MCP2551 tiene niveles TTL
La entrada está a nivel alto por encima de 2V
La salida puedes adaptarla con una o dos resistencias para reducirla a 3.3V
Saludos.
-
El MCP2515 tiene niveles TTL
La entrada está a nivel alto por encima de 2V
La salida puedes adaptarla con una o dos resistencias para reducirla a 3.3V
Saludos.
Esa solución la testeé en el pasado. No es buena idea adaptar niveles con divisores resistivos ya que la impedancia de entrada de los pines de un micro es bastante alta y varía dependiendo del micro por lo que "toca" hacerlo "a ojo"; además si pones un divisor con resistencias de valor muy alto corres el riesgo de que no llegue la corriente necesaria.
Bajo mi punto de vista y mi experiencia previa: si "la cagas" con niveles lo mejor es cambiar de IC o añadir un "level translator" que suelen ser baratos.
Saludos.
-
Lo probaré todo con el MCP2515, y si no tira bien o va lento, tendré que cambiar el MCP2551 por otro que vaya a 3v3 y conectarlo directamente a los puertos CAN de la BBB, en vez de utilizar el conversor SPI.
Otra duda que tengo, es al buscar información comparativa Ethernet versus CAN bus, parece que a pesar de que CAN bus va a 1Mb/s, tiene mejor rendimiento que Ethernet a 10Mb/s, esto me ha sorprendido un poco, además parece que CAN bus gestiona automáticamente todo el tema de colisiones, errores, y es más seguro, o al menos eso es lo que he leido aquí: http://www.ixxat.com/download/artikel_comparison_can_and_ethernet.pdf
De ser así, no me planteo pasarlo todo a Ethernet 10Mb/s, si al final CAN bus es en la práctica más rápido, y gestiona errores y colisiones automáticamente.
(http://i1322.photobucket.com/albums/u573/planeta9999/ScreenHunter_027_zpsf5ba742e.jpg)
-
Eso es para una red con muchos nodos y conexiones/desconexiones frecuentes . Para un punto a punto TCP es muuuucho más rápido.
-
Esa solución la testeé en el pasado. No es buena idea adaptar niveles con divisores resistivos ya que la impedancia de entrada de los pines de un micro es bastante alta y varía dependiendo del micro por lo que "toca" hacerlo "a ojo"; además si pones un divisor con resistencias de valor muy alto corres el riesgo de que no llegue la corriente necesaria.
La velocidad del bus Can no es alta. Como máximo 1 MHz.
Los divisores resistivos no deberían dar problemas en este caso.
Utilizando un divisor con una resistencia de 1K8 en serie con otra de 3K3, bajará la tensión de 5V a 3.24 Voltios
La corriente absorbida por el divisor es de 1mA (relativamente bajo)
La impedancia de salida (en el lado de 3.3V) será de 1.16K.
Con una capacidad de entrada en el lado de 3.3V de 200pF (mayor de lo habitual) la constante de tiempo es de 233ns
El tiempo de subida desde cero hasta el nivel alto de 2.8 voltios será de 460ns.
El tiempo de bajada desde 3.24V hasta el nivel bajo de 0.44V será de 460ns
Esto es suficiente para trabajar a 1MHz.
Para frecuencias mayores, este divisor te dará problemas de velocidad. Tendrías que reducir la impedancia.
Por ejemplo para 20MHz y capacitancia de entrada de 200pF, las resistencias deberían ser de 90 y 165 ohmios y la corriente absorbida 20mA, que está fuera del rango de muchas salidas de microcontrolador
Depende por lo tanto de la velocidad y de la capacitancia de entrada.
Saludos.
-
Perdón: me refería a que la impedancia de entrada era más baja de lo que esperaba. Picuino: no me refería a la velocidad de transmisión (capacidad) si no a la resistencia de entrada del pin.
Sigo pensando que por precio (0.2$ para pocos ICs) es mejor un "level translator", porque te ahorras sustos.
Por otro lado, te llevo siguiendo muchos posts y me encanta la forma rigurosa/académica con la que argumentas tus respuestas. Se aprende mucho de tí ((:-)).
Saludos.
-
Respecto al Can Versus Ethernet, con solo saber que CAN permite trabajar el bus en forma determinística y Ethernet es probabilístico (reenvia mensajes hasta recibir el Ack), se puede deducir que ante redes con mucho trafico en CAN sera mas eficiente siempre, porque maneja colisiones por hardware, parte en el transceiver y parte en el controlador, sin que tengas que tocar un solo bit de programa...
Si a esa evaluación le sumas que la nueva norma permitirá un flujo mayor de información, de 1 Mb/seg va a pasar casi a 5 Mb/seg, le va a sobrar rollo para bajárselo al ethernet varias veces...
Esa nueva normativa es para manejar audio y vídeo dentro de vehículos...
-
En realidad no se porque el can esta limitado a 1mb, en un coche por ejemplo la red can no tiene mas de 5 metros, y con eso soportaria bastante, sin embargo los fabricantes lo limitan a 512 y cosas asi, habra alguna razon pero yo creo que podria ir a 1mb facilmente.
-
Sigo pensando que por precio (0.2$ para pocos ICs) es mejor un "level translator", porque te ahorras sustos.
Por otro lado, te llevo siguiendo muchos posts y me encanta la forma rigurosa/académica con la que argumentas tus respuestas. Se aprende mucho de tí ((:-)).
Gracias manwenwe. Todos aprendemos de los demás, cada uno en su estilo. Y siendo riguroso uno aprende también de sí mismo.
Intento argumentar bien las respuestas porque así, en muchas ocasiones, aprendo tanto con mis respuestas, como con las preguntas que me responden.
La respuesta de antes era la primera vez que la calculaba. Al principio pensaba que el divisor resistivo valdría para frecuencias mucho mayores, pero el resultado me dió que sólo valía para 1MHz.
Tienes razón. En general será mejor un level translator: Consume menos, es más rápido, más fiable, vamos que es mejor solucíón.
Las resistencias son un pequeño apaño que funciona para velocidades bajas, aunque tienen la ventaja de ocupar muy poco para adaptar una sóla señal y son fáciles de implementar para hacer un apaño si no tienes a mano el level shifter.
Saludos.