¿MCP2551 es un convertidor de UART a CAN?

Quiero hacer un sniffer de bus CAN a 250 kbit / s usando mi computadora. Después de algunas investigaciones, descubrí que MCP2551 es una especie de regulador de nivel de voltaje para la capa física de CAN. Teniendo esto en cuenta, me pregunto si esta configuración podría funcionar. Solo quiero grabar los mensajes intercambiados con fines de prueba automatizados, no ser parte de la comunicación:

PC <-> USB-UART (quizás CP2102, porque ya tengo uno) <-> MCP2551 <-> bus CAN

Si no es así, ¿qué tipo de señales deben ingresar al MCP2551 para hacerme parte del autobús?

usb microchip can runas
fuente

Respuestas:

Puede hacerlo, pero lo que obtendrá en su bus CAN será UART usando niveles de voltaje CAN. Debe proporcionar al MCP2551 mensajes de protocolo CAN si desea comunicarse con dispositivos CAN en su bus. Lo mismo para escuchar: los mensajes CAN son tan diferentes del formato UART que UART no sabrá qué hacer con ellos. Tendrá al menos errores de trama todo el tiempo y no obtendrá el contenido del mensaje.
Esta imagen muestra la estructura de un mensaje CAN:

ingrese la descripción de la imagen aquí

Hay muchos microcontroladores alrededor que tienen una interfaz CAN, sin el transceptor. Es para estos que el MCP2551 fue diseñado. En el pasado hemos usado el NXP LPC2294, que tiene 4 interfaces CAN. Cada uno de ellos necesita un MCP2551 para conectarse a un bus CAN. Los controladores más recientes de NXP incluyen la familia LPC1800 , de la cual todos los miembros son compatibles con CAN.

stevenvh
fuente

Olvidé por completo los bits de inicio / parada de UART y probablemente algunas situaciones de "bits de inicio / superior" de CAN. Probablemente trataré de encontrar una solución usando una pila CAN en la PC usando FTDI como gpio que terminará transmitiendo a MCP2551

runas

@rnunes: no se trata solo de los bits de inicio / parada. Sin ellos, una transmisión UART es solo un byte de 8 bits. Un mensaje CAN es mucho más complejo, con direccionamiento, prioridad y verificación de errores. No puedes comparar los dos.

stevenvh

Pero usando el FTDI estaré trabajando poco a poco (básicamente, es un USB <-> GPIO realmente rápido), no byte a byte como con UART. Ya estoy buscando esos CAN MCU, pero preferiría gastar dinero por ahora (es un proyecto de pasatiempo para estudiantes) y ya tengo el FTDI. Si concluyo con mis investigaciones que el FTDI no podrá hacer esto, intentaré usar una MCU CAN.

Runas

La pila será responsable de manejar todo (por ejemplo, relleno de bits) y transmitirlo poco a poco a MCP2551. El único problema que tengo ahora es la latencia FTDI, porque necesito que sea rápida y regular, pero la mediré más adelante.

Runas

@rnunes: pero lo que sale del CP2102 (SiLabs, no FTDI) son bytes , no bits. No puedes detenerlo después de un momento. Necesitará tanto el CP2102 para conectar su microcontrolador con USB como un microcontrolador que admita CAN + el MCP2551. O un microcontrolador que también puede actuar como un dispositivo USB. Entonces no necesitas el CP2102.

stevenvh

He creado una interfaz USB / CAN con FT2232H en modo MPSSE (olvide UART), MCP2515 y MCP2551. MCP2515 es la pieza clave que te falta aquí. Estudia bien lo que hace. Es el controlador CAN real el que realiza el encuadre, los ACK, la generación y verificación de suma de verificación, el filtrado de mensajes y otras cosas menos obvias que el estándar debe hacer un nodo CAN. Si desea un sniffer, MCP2515 tiene un modo de solo escucha que garantiza que no haya transmisiones en el bus. MCP2551 es simplemente un adaptador de capa física tonto, similar a un MAX232 para RS-232 o ADM485 para RS-485.

Ahora, esta arquitectura está lejos de ser perfecta, ya que la tecnología FTDI MPSSE no tiene esencialmente soporte para interrupciones (creo que solo usa transferencias USB masivas detrás de escena), por lo que tengo que sondear el controlador con frecuencia para buscar nuevos mensajes. Esto coloca mucha carga en el controlador host USB, pero aún no garantiza que no se pierdan mensajes (MCP2515 puede almacenar hasta 2 mensajes recibidos internamente si habilita el "modo de desbordamiento", solo uno si no lo hace). Una solución mucho mejor sería un microcontrolador adecuado con CAN y periféricos USB incorporados como STM32F105 (103 no puede usar USB y CAN al mismo tiempo). Vea este proyecto para una implementación funcional de exactamente esta idea. LPC18xx como lo sugiere stevenh también funcionará, pero LPC17xx es probablemente más barato y más fácil de encontrar.

Espina
fuente

En este caso, la agrupación no es un problema, pero sí, la solución ideal sería usar una MCU con controlador CAN que funcione como un búfer de mensajes CAN. A partir de ahora intentaré usar la primera configuración que escribiste. Gracias

runas

+1 El uso del chip FTDI para hablar directamente con un controlador CAN sin un uC está bien. Aparentemente FTDI salió FT221X, que es un puente dedicado de USB a SPI. (También hay un modelo diferente para USB a I2C.)

Nick Alexeev

Dado que quiere escuchar en un bus CAN existente, como entiendo la pregunta, realmente no puede usar un UART en absoluto. La señalización CAN y UART son totalmente diferentes.

En teoría, podría mirar la línea de recepción CAN que sale del MCP2551 y decodificar el tráfico CAN. Eso no será fácil, pero es teóricamente posible. Sin hardware CAN especializado, tendrá que muestrear algunas veces más rápido que la velocidad de bits CAN y decodificar ese flujo de bits en el software más adelante. Probablemente necesitará grabar a aproximadamente 1 Mbit / s para decodificar CAN de 250 kbit / s.

Usar un microcontrolador será mucho más fácil. El PIC 18F2580 y otros procesadores similares tienen un periférico CAN incorporado. El hardware realiza la decodificación a nivel de bits y recibe tramas CAN completas. El procesador puede enviar las tramas CAN recibidas a través de su UART a su PC.

Olin Lathrop
fuente