Implantación de una capa de protocolo CAN en software

Question

Fondo

Estoy desarrollando un proyecto que requerirá el modesto microcontrolador especificaciones de:

• 8 ADC de 12 bits y 10 kHz
• 1kB de RAM
• 48-QFN o tamaño inferior
• Protocolo de comunicación en cadena a 20 kbps resistente al ruido y con corrección de errores

Los requisitos de procesamiento de señales son bastante bajos, y la mayoría pueden exportarse al procesador maestro del sistema. Las tres primeras especificaciones son fáciles de cumplir y pueden hacerse por menos de 2 dólares en cantidad. Sin embargo, la comunicación tendrá lugar en un entorno eléctricamente muy ruidoso, por lo que las redes vulnerables al ruido como LIN e I2C están descartadas. Un argumento adicional en contra de LIN es que me gustaría ejecutar todo el asunto en 5V o 3,3V, y transceptores LIN requieren 12V, y por lo tanto requeriría un regulador adicional o alambre por placa de sensores. Inicialmente elegí CAN para esta tarea. Sin embargo, los controladores CAN añaden un coste considerable, y tengo curiosidad por saber si esto se puede hacer por software.

Capa física CAN

La especificación CAN define las capas de enlace de datos y física del modelo de referencia de red OSI. Muchos circuitos integrados económicos de 8 patillas, como el NXP TJA1040/50 , Maxim MAX3058/59 , Microchip MCP2551 y TI SN65HVD1050 para implementar la capa física. Implementar la capa física con convertidores D/A u op-amps sería difícil, si no imposible, por lo que estos circuitos integrados bien valen el 1$ o así que cuestan.

Enlace de datos CAN/Capa de protocolo

Para la capa de enlace de datos, algunos microcontroladores añaden módulos de protocolo CAN a las capas básicas de comunicaciones UART, I2C y SPI. Sin embargo, son bastante más caros que los chips básicos.

Investigación del coste de los módulos del protocolo CAN

Para corroborar esta afirmación, he aquí algunos micros populares en versiones CAN y no CAN, del :

• ATmega16 - ATMEGA16M1 (con CAN): $3.87, ATMEGA168A (no CAN): $ 3.23
• dsPIC - DSPIC33FJ64MC802 (con CAN): $6.14, DSPIC33FJ64GP202 (no CAN): $ 5.48
• PIC18 - PIC18F2480 (con CAN): $6.80, PIC18F24J10 (no CAN): $ 2.10
• Cortex-M3 - STM32F103C4T6A (con CAN): $6.50, STM32F100C4T6B (no CAN): $ 2.73

Para ser justos, sólo he comparado microcontroladores con tamaños de memoria equivalentes; sin embargo, muchas de las versiones sin CAN están disponibles con tamaños de memoria más pequeños por menos dinero. Los controladores CAN externos, como el Microchip MCP2515 , cuestan casi 2 dólares, así que obviamente es más rentable tener el CAN integrado en el microcontrolador si tienes la opción.

Curiosamente, la pieza ATmega es con diferencia la pieza equipada con CAN más barata del inventario de Digikey.

Función de la capa de protocolo CAN

El módulo CAN que se encuentra en los microcontroladores dsPIC hace lo siguiente:

El módulo de bus CAN consta de un motor de protocolo y mensajes de mensajes. El motor de protocolo CAN se encarga de todas las funciones de recepción y transmisión de mensajes en el bus CAN. Los mensajes se Los mensajes se transmiten cargando primero los registros de datos correspondientes. El estado y los errores pueden comprobarse leyendo los registros correspondientes. Cualquier mensaje detectado en el bus CAN se comprueba en busca de errores y luego se empareja con los filtros para ver si debe recibirse y almacenarse en uno de los registros de recepción. en uno de los registros de recepción.

Esto parece bastante factible en software.

La pregunta

¿Se puede utilizar una capa de protocolo de software para implementar la especificación CAN con sólo un microcontrolador barato equipado con UART y un transceptor CAN? En caso afirmativo, ¿existen implementaciones de código abierto?

Como alternativa, ¿se pueden utilizar transceptores CAN con UART para implementar un protocolo personalizado? Me parece bien una topología de maestro único; entiendo que el arbitraje puede ser difícil de conseguir en un protocolo personalizado.

Answer 1

Creo que implementar el protocolo CAN sólo en firmware será difícil y llevará un tiempo hacerlo bien. No es una buena idea.

Sin embargo, sus precios son elevados. Acabo de comprobarlo, y un dsPIC 33FJ64GP802 en paquete QFN se vende por 3,68 USD en microchipdirect por 1000 unidades. El precio será inferior para volúmenes de producción reales.

El periférico de hardware CAN hace algunas cosas reales para usted, y el incremento de precio para ello no es ni de lejos lo que usted está reclamando.

Añadido:

Ya que pareces decidido a probar la vía del firmware, aquí tienes algunos de los problemas obvios que se me ocurren. Lo más probable es que haya otros problemas que aún no se me han ocurrido.

Quieres hacer CAN a 20 kbit/s. Esa es una velocidad muy lenta para CAN, que llega hasta 1Mbit/s en al menos 10 metros. Para darte un dato, la norma de señalización a bordo NMEA 2000 se basa en CAN a 200 kbits/s, y está pensada para ir de un extremo a otro de un gran barco.

Puedes pensar que todo lo que necesitas es una interrupción por bit y que puedes hacer todo lo que necesites en esa interrupción. Eso no funcionará porque hay varias cosas sucediendo en cada tiempo de bit CAN. Dos cosas en particular necesitan hacerse a nivel de sub-bits. La primera es detectar una colisión, y la segunda es ajustar la tasa de bits sobre la marcha.

En un bus CAN existen dos estados de señalización, recesivo y dominante. El estado recesivo es el que se produce cuando no hay nada en el bus. Ambas líneas están unidas por un total de 60 Ω. Un bus CAN normal como el implementado por chips comunes como el MCP2551, debería tener terminadores de 120 Ω en ambos extremos, por lo tanto un total de 60 Ω juntando las dos líneas diferenciales pasivamente. El estado dominante es cuando ambas líneas se tiran activamente aparte, en algún lugar alrededor de 900mV del estado recesivo si no recuerdo mal. Básicamente, esto es como un bus de colector abierto, excepto que se implementa con un par diferencial. El bus está en estado recesivo si CANH-CANL < 900mV y dominante cuando CANH-CANL > 900mV. El estado dominante señala 0, y el recesivo 1.

Cada vez que un nodo "escribe" un 1 en el bus (lo deja pasar), comprueba si algún otro nodo está escribiendo un 0. Cuando encuentra el bus en estado dominante (0) cuando cree que está enviando y el bit actual que está enviando es un 1, significa que alguien más está enviando también. Las colisiones sólo importan cuando los dos remitentes no están de acuerdo, y la regla es que el que envía el estado recesivo retrocede y aborta su mensaje. El nodo que envía el estado dominante ni siquiera sabe que esto ha ocurrido. Así funciona el arbitraje en un bus CAN.

Las reglas de arbitraje del bus CAN significan que tienes que estar vigilando el bus en cada bit que envías como 1 para asegurarte de que alguien más no está enviando un 0. Esta comprobación se hace normalmente a unos 2/3 del bit, y es la limitación fundamental de la longitud del bus CAN. Cuanto más lenta sea la tasa de bits, más tiempo habrá para la propagación del peor caso de un extremo del bus al otro, y por lo tanto más largo puede ser el bus. Esta comprobación debe realizarse cada bit donde crees que eres dueño del bus y estás enviando un 1 bit.

Otro problema es el ajuste de la velocidad binaria. Todos los nodos de un bus deben ponerse de acuerdo sobre la velocidad binaria, más estrechamente que con RS-232. Para evitar que pequeñas diferencias de reloj se conviertan en errores significativos, cada nodo debe poder emitir un bit un poco más largo o más corto que el nominal. En hardware, esto se consigue haciendo funcionar un reloj entre 9 y 20 veces más rápido que la velocidad de bits. Los ciclos de este reloj rápido se denominan cuantos de tiempo. Hay formas de detectar que el inicio de los nuevos bits se está desviando con respecto a donde se cree que debería estar. Las implementaciones de hardware añaden u omiten un cuanto de tiempo en un bit para volver a sincronizar. Hay otras formas de implementar esto, siempre y cuando puedas ajustarte a pequeñas diferencias de fase entre los tiempos de bit esperados y los tiempos de bit reales medidos.

En cualquier caso, estos mecanismos requieren que se hagan varias cosas en varios momentos dentro de un bit. Este tipo de temporización será muy complicada en firmware, o requerirá que el bus funcione muy lentamente. Digamos que implementas un sistema de cuantos de tiempo en firmware a 20 kbits/s. Con un mínimo de 9 cuantos de tiempo por bit, se necesitaría una interrupción de 180 kHz. Eso es ciertamente posible con algo como un dsPIC 33F, pero se comerá una fracción significativa del procesador. A la máxima tasa de instrucción de 40 MHz, se obtienen 222 ciclos de instrucción por interrupción. No debería llevar tanto tiempo hacer todas las comprobaciones, sino probablemente entre 50 y 100 ciclos, lo que significa que entre el 25 y el 50% del procesador se utilizará para CAN y que tendrá que adelantarse a todo lo demás que se esté ejecutando. Eso impide muchas aplicaciones que estos procesadores suelen ejecutar, como el control pulso a pulso de una fuente de alimentación conmutada o un controlador de motor. La latencia de 50-100 ciclos en cada interrupción sería un completo obstáculo para muchas de las cosas que he hecho con chips como este.

Así que vas a gastar el dinero para hacer CAN de alguna manera. Si no es en el periférico de hardware dedicado a tal fin, entonces en conseguir un procesador más grande para manejar la sobrecarga significativa de firmware y luego hacer frente a la impredecible y posible gran latencia de interrupción para todo lo demás.

Luego está la ingeniería inicial. El periférico CAN simplemente funciona. Por tu comentario, parece que el coste incremental de este periférico es de 0,56 dólares. Me parece una ganga. A menos que tengas un producto de gran volumen, no hay forma de que recuperes el tiempo y los gastos considerables que te llevará implementar CAN sólo en firmware. Si tus volúmenes son tan altos, los precios que hemos estado mencionando no son realistas de todos modos, y el diferencial para añadir el hardware CAN será menor.

Realmente no veo que esto tenga sentido.

Answer 2

Si estoy leyendo bien, suena como que desea bit-bash CAN funcionalidad utilizando sólo una UART y algunos firmware inteligente. Créeme, esto nunca funcionará - te sugiero que leas un buen texto sobre las complejidades de CAN o CANopen. Usted habrá erradicado cualquier ahorro de costes que está buscando por ir por este camino.

Yo usaría un microcontrolador con un módulo CAN y pasaría los 2$ extra, o has pensado en un protocolo diferente que sea compatible con una UART, como por ejemplo Modbus en RS-485 ?

Answer 3

Utilizamos el PIC18F25K80 . Si bien no tiene un DSP, es ~ $ 2 en cantidad. Es casi un sustituto directo del PIC18F2480 que mencionas. Nosotros usamos el CCS y su pila de software para CAN, probablemente portado de Microchip. Funciona bien para todo lo que he necesitado y probado.

Answer 4

También estoy pensando en bit-banging CAN-Protocolo en un PIC µC, así que por favor EricM, si realmente hiciste eso, por favor responde y di al menos, qué bitrate a qué frecuencia de núcleo de PIC18F o DSPic tienes. Gracias.

En general: RS 485 sería la solución para el principal problema planteado, pero también sería posible utilizar CAN-(o incluso FlexRay)-Transceptores con comunicaciones UART no full-duplex (punto 2 punto) ya que todos esos protocolos utilizan codificación NRZ.

Pero en UART/V24/RS232 full duplex se utiliza sobre todo sin pensar en detalle, así que tal vez usted tendrá que poner un poco de cerebro en el superloop o statemachine de su aplicación ...

Pero volvamos al CAN-bitbanging: Trabajo con CAN desde hace muchos años y nunca he visto una implementación de bitbanging, pero por lo que puedo pensar, eso debería funcionar para tiempos de bit de hasta 100kBit con µC modernos como DSPic o ARM etc. (con núcleos a 80MHz o más...)

Al menos si sólo se tiene en cuenta la lectura... El envío supondría cierta sobrecarga en la preparación de las estructuras de bits, de modo que no se alcanzaría el 100% de la carga del bus, pero en CAN es raro que se supere el 65%...