¿Es MCP2551 un convertidor de UART a CAN?

Quiero hacer un rastreador de bus CAN para 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 eso en cuenta, me pregunto si esta configuración podría funcionar. Solo quiero registrar 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, ¿qué tipo de señales debo ingresar al MCP2551 para que sea parte del bus?

Respuestas (3)

Puede hacer eso, 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 marco 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 que tienen una interfaz CAN, sin el transceptor. Es para esto que se diseñó el MCP2551. En el pasado, usamos 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.

Me olvidé por completo de los bits de inicio/parada de UART y probablemente de algunas situaciones de "bits de inicio/superior" de CAN. Probablemente intentaré encontrar una solución usando una pila CAN en la PC usando FTDI como un gpio que terminará transmitiendo a MCP2551
@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.
Pero usando el FTDI estaré trabajando poco a poco (básicamente, es un USB <-> GPIO realmente rápido), no byte por byte como con UART. Ya estoy buscando esos CAN MCU, pero preferiría gastar algo de dinero por ahora (es un proyecto de pasatiempo de los estudiantes) y ya tengo el FTDI. Si concluyo con mis investigaciones que el FTDI no podrá hacer esto, intentaré usar una MCU CAN.
La pila se encargará de manejar todo (por ejemplo, el relleno de bits) y transmitirlo poco a poco al MCP2551. El único problema que tengo ahora mismo es la latencia del FTDI, porque necesito que sea rápido y regular, pero lo mediré más adelante.
@rnunes: pero lo que sale del CP2102 (SiLabs, no FTDI) son bytes , no bits. No puedes detenerlo después de un bit. Necesitará tanto el CP2102 para conectar su microcontrolador con USB como un microcontrolador compatible con CAN + el MCP2551. O un microcontrolador que también puede actuar como un dispositivo USB. Entonces no necesita el CP2102.
Pensé que el OP estaba tratando de escuchar en un bus CAN existente, en cuyo caso tiene que ser compatible con CAN.
@stevenvh - No lo expliqué bien. Estoy cambiando CP2102 de la configuración a un módulo FTDI (UM232H) que funciona como USB <-> GPIO (comunicación controlada bit a bit), que creo que podría hacer el trabajo si tiene baja latencia. Si no, probablemente buscaré alguna MCU con CAN integrado y usaré el CP2102 para comunicarme con la MCU, que se comunicará con el MCP2551 (si es necesario)
@Olin: sí, esa es la que se supone que es mi respuesta. ¿No lo expresé lo suficientemente bien? ¿Crees que necesita edición?
Habla de que el OP tiene que proporcionar al MCP2551 mensajes de protocolo CAN, lo que significa que necesita enviar mensajes CAN. Tal vez solo quiso decir conectar el MCP2551 al bus CAN existente. Supongo que podría tomarse de esa manera. También le dice "él puede hacer eso" al conectar un UART al MCP2551, pero eso no funcionará en absoluto para recibir mensajes CAN.

Hice una interfaz USB/CAN usando FT2232H en modo MPSSE (olvídese de 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 la suma de comprobación, el filtrado de mensajes y otras cosas menos obvias que el estándar requiere que haga un nodo CAN. Si desea un rastreador, 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 esencialmente no admite interrupciones (creo que solo usa transferencias USB masivas detrás de escena), por lo que tengo que sondear el controlador con frecuencia en busca de nuevos mensajes. Esto genera mucha carga en el controlador de 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 periféricos CAN y 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 sugirió stevenh también funcionará, pero LPC17xx probablemente sea más barato y más fácil de encontrar.

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
+1 Usar el chip FTDI para hablar directamente con un controlador CAN sin un uC es genial. Aparentemente, FTDI salió FT221X, que es un puente USB a SPI dedicado. (También hay un modelo diferente para USB a I2C).

Dado que desea escuchar en un bus CAN existente según entiendo la pregunta, realmente no puede usar un UART en absoluto. CAN y UART siganlling 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 varias veces más rápido que la tasa de bits CAN y decodificar ese flujo de bits en el software más tarde. 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 toda la decodificación a nivel de bits y recibe tramas CAN completas. Luego, el procesador puede enviar tramas CAN recibidas a través de su UART a su PC.

¿Es MCP2551 un convertidor de UART a CAN?
RespuestasAquíPolítica de privacidad1y, 0v