Necesitábamos un protocolo inmune al ruido, de bajo costo, multipunto, multimaestro (en tiempo real y distribuido) y solo hay un bus CAN que parece cumplir con estos requisitos.
Dado que no hay controladores de latas (hardware de capa de enlace de datos) para MCU de muy bajo costo (como STM32F0) y ninguna API fácil de usar que podamos encontrar para comenzar, no podemos considerar el bus CAN como una pila de comunicación predeterminada de nuestros proyectos .
Así que creo que puedo implementar una capa realmente pequeña que permitirá implementar cualquier protocolo (como Modbus) sobre UART sobre la capa física CAN mientras aprovecho la detección de colisión de datos usando 1 byte de inicio como cebo.
Además, supongo que cualquier hardware I2C o de 1 cable puede usar directamente un transmisor CAN para su protocolo de bus con un simple truco de resistencia de diodo, similar al truco de resistencia de diodo de 1 cable <-> uart.
Sospecho que me estoy perdiendo algo, ya que este enfoque brinda muchas ventajas con un esfuerzo relativamente pequeño, aunque no hay una implementación que pueda encontrar para este propósito.
¿Hay alguna consecuencia oculta en esta encuesta?
1-Wire (con UART hack) no funciona con el transceptor CAN MCP2551, ya que el transceptor comienza a alimentarse a sí mismo con cero (dominante) en el punto final (el lado de 1-Wire), lo que evita que cualquier dispositivo escriba "1" en el bus hasta que la función de "detección TXD permanente" del transceptor tome el control. Por lo tanto, es inútil desde el punto de vista del "extensor de rango simple de 1 cable". RXDLo que significa que los pines / transceptores de bus CAN TXDno se pueden convertir en una línea de drenaje abierta con un simple truco de convertidor de 1 cable / uart, por lo que tampoco funcionará con un bus I2C.
El uso de 1 byte como cebo no funciona, ya que tenemos que usar solo 1 bit como cero, lo que significa que tenemos que usar 100 bits solo para el direccionamiento si planeamos conectar 100 dispositivos en el mismo bus porque, aunque podríamos detectar a alguien más. hablando al mismo tiempo pero no podemos detectar la prioridad (por ejemplo, si node#0b101y node#0b011habla al mismo tiempo, leeremos 0b001cuál es la misma respuesta cuando node#0b011y node#0b001habla. Por lo tanto node#011, nunca sabremos si tiene la prioridad o no). Entonces esto es imposible si no usamos una técnica de bit banging y leemos el RXport poco a poco. Lo cual no tiene sentido porque está reinventando el bus CAN como se mencionó.
En general, usaría CAN hasta el final. Necesitará controladores/receptores de línea de una forma u otra. Los transceptores CAN son tan buenos como cualquier otro, pero luego es más fácil usar el resto de CAN. La principal diferencia con CAN es que los niveles inferiores del protocolo han sido bien pensados y están disponibles a bajo costo integrados directamente en muchos microcontroladores. RS-485 le arroja una especificación eléctrica, luego está solo.
Es mucho más difícil obtener todos los detalles de un autobús de caída múltiple correcto y robusto de lo que la mayoría de la gente cree. Usa CAN. Todo ha sido elaborado y hecho para usted. Envía paquetes completos a nivel de firmware. El hardware se encarga de la detección de colisiones, el reintento y la generación y validación de la suma de verificación CRC. Estas son todas las cosas que desea, y con CAN las obtiene prácticamente gratis.
Hay controladores discretos (MCP2515) que requieren SPI y algunos otros GPIO.
No es cierto que CAN no esté disponible en piezas pequeñas de Cortex m0. Mire LPC11C22; tiene un transceptor CAN incorporado. O el STM32F042. NXP cuesta 3 $ en cantidad, STM32 alrededor de 2 $ pero requiere un transceptor externo que agrega costo.
Si el costo adicional de una pieza con controlador CAN no se ajusta a su proyecto, supongo que debe estar cobrando una tarifa de diseño muy alta para inventar su propio sistema CAN de software y poder alcanzar el punto de equilibrio. Construir casos de prueba y probar que su propio sistema de bus de datos es confiable, inmune al ruido, 'libre' de errores de bit, detección de colisiones, árbitro de bus, etc., no es fácil.
Hice exactamente esto una vez. No sé si todavía compila (ahora estoy usando la conexión inalámbrica), pero funciona muy bien si haces todo bien.
Microchip solía tener un chip CAN que fallaba mucho si había demasiado voltaje en modo común o algo así. Los adaptadores de CA podrían activar el modo de falla con su basura de CA con fugas IIRC. Luego salieron con una nueva versión. Olvidé el número de parte, pero investigue.
Sin embargo, I2C necesita un truco más complicado. Por lo general, el transceptor no puede funcionar en ambos sentidos sin un chip más inteligente que le indique qué dirección está en uso (aunque en realidad existen). MCU UART no tiene ese problema porque el microcontrolador es consciente de los pines TX y RX separados del transceptor, I2C usa cables bidireccionales.
david tweed
ceremonia