Implementación de una capa de protocolo CAN en software


12

Antecedentes

Estoy desarrollando un proyecto que requerirá las modestas especificaciones de microcontroladores de:

  • 8 ADC de 12 bits y 10 kHz
  • 1kB de RAM
  • Huella 48-QFN o menor
  • Protocolo de comunicación de 20 kbps con conexión en cadena, resistente al ruido y con corrección de errores

Los requisitos de procesamiento de señal son bastante bajos, y la mayoría se pueden exportar al procesador maestro en el sistema. Las primeras tres especificaciones son fáciles de cumplir y se pueden hacer por menos de $ 2 en cantidad. Sin embargo, la comunicación ocurrirá en un entorno muy ruidoso eléctricamente, por lo que las redes vulnerables al ruido como LIN e I2C están fuera. Un argumento adicional contra LIN es que me gustaría ejecutar todo a 5V o 3.3V, y los transceptores LIN requieren 12V, por lo que requerirían un regulador o cable adicional por placa de sensores. Inicialmente elegí CAN para esta tarea. Sin embargo, los controladores CAN agregan un costo considerable, y tengo curiosidad por saber si esto se puede hacer en software.

CAN Capa Física

La especificación CAN define el enlace de datos y las capas físicas del modelo de referencia de red OSI. Existen muchos circuitos integrados de 8 pines económicos, como el NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 y TI SN65HVD1050 para implementar la capa física. La implementación de la capa física con convertidores D / A o amplificadores operacionales sería difícil, si no imposible, por lo que estos circuitos integrados valen la pena $ 1 o lo que cuestan.

Enlace de datos CAN / Capa de protocolo

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

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

Para fundamentar esta afirmación, aquí hay algunos micros populares en versiones CAN y no CAN, desde:

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

Para ser justos, solo comparé microcontroladores con tamaños de memoria equivalentes, sin embargo, muchas de las versiones que no son CAN están disponibles con tamaños de memoria más pequeños por menos. Los controladores CAN externos, como el Microchip MCP2515 , cuestan casi $ 2, por lo que obviamente es más rentable tener el CAN integrado en el microcontrolador si tiene la opción.

Curiosamente, la parte ATmega es, con mucho, la parte más barata equipada con CAN en el 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 un buffer / control de mensajes. El motor de protocolo CAN maneja todas las funciones para recibir y transmitir mensajes en el bus CAN. Los mensajes se transmiten cargando primero los registros de datos apropiados. El estado y los errores se pueden verificar leyendo los registros apropiados. Cualquier mensaje detectado en el bus CAN se verifica en busca de errores y luego se compara con los filtros para ver si se debe recibir y almacenar en uno de los registros de recepción.

Esto parece bastante factible en software.

La pregunta

¿Se puede usar una capa de protocolo de software para implementar la especificación CAN con solo un microcontrolador económico equipado con UART y un transceptor CAN? Si es así, ¿existen implementaciones de código abierto?

Alternativamente, ¿se pueden usar los transceptores CAN con los UART para implementar un protocolo personalizado? Estoy de acuerdo con una topología de maestro único; Entiendo que el arbitraje puede ser difícil de lograr en un protocolo personalizado.


CAN también tiene 12v, ya que fue desarrollado para uso automotriz.
kenny

@Kenny: los niveles de voltaje utilizados en los transceptores anteriores son 5V.
Kevin Vermeer

Si va a considerar la serie STM32F, ¿puedo sugerir esta parte de NXP también? Es un núcleo Cortex-M0. search.digikey.com/scripts/DkSearch/…
Jon L

@ Jon - Esos no estaban necesariamente bajo consideración, y un M0 sería ideal para este caso de uso. Sin embargo, tenga en cuenta que las piezas del Nuvoton M052LAN también son Cortex-M0, y aproximadamente la mitad del precio en cantidad ($ 1.21 frente a $ 2.35), pero no tiene el módulo CAN. Ese tipo de diferencia de precio es mi motivación.
Kevin Vermeer

es posible que desee considerar la calificación operativa también. La mayoría de las piezas con soporte CAN serán industriales o automotrices versus comerciales para variantes que no sean CAN.
Mark

Respuestas:


11

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

Sin embargo, sus precios son altos. Acabo de comprobar, y un dsPIC 33FJ64GP802 en el paquete QFN se vende por 3.68 USD en microchipdirect por 1000 piezas. El precio será más bajo para los volúmenes de producción reales.

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

Adicional:

Como parece estar decidido a probar la ruta del firmware, estos son algunos de los problemas obvios que le vienen a la mente. Lo más probable es que haya otros problemas que aún no se me han ocurrido.

Quiere hacer CAN a 20 kbit / s. Esa es una tasa muy lenta para CAN, que sube a 1Mbit / s durante al menos 10s de metros. Para darle un punto de datos, el estándar de señalización a bordo NMEA 2000 se superpone en CAN a 200 kbits / s, y está destinado a ir de un extremo de un barco grande al otro.

Puede pensar que todo lo que necesita es una interrupción por bit y puede hacer todo lo que necesite en esa interrupción. Eso no funcionará porque hay varias cosas sucediendo en cada bit de tiempo CAN. Dos cosas en particular deben hacerse a nivel de sub-bit. El primero es detectar una colisión, y el segundo es ajustar la velocidad de bits sobre la marcha.

Hay dos estados de señalización en un bus CAN, recesivo y dominante. Recesivo es lo que sucede cuando nada conduce el autobús. Ambas líneas se unen por un total de 60 Ω. Un bus CAN normal implementado por chips comunes como el MCP2551, debe tener terminadores de 120 Ω en ambos extremos, por lo tanto, un total de 60 Ω que une las dos líneas diferenciales de forma pasiva. El estado dominante es cuando ambas líneas se separan activamente, en algún lugar a unos 900 mV del estado recesivo, si no recuerdo mal. Básicamente, esto es como un bus 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 ir), verifica si algún otro nodo está escribiendo un 0. Cuando encuentra el bus en estado dominante (0) cuando cree que está enviando y el El bit actual que está enviando es un 1, entonces eso significa que alguien más también está enviando. Las colisiones solo 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 sucedió. Así es como funciona el arbitraje en un bus CAN.

Las reglas de arbitraje del bus CAN significan que debe estar observando el bus a la mitad de cada bit que está enviando como un 1 para asegurarse de que otra persona no envíe un 0. Esta verificación generalmente se realiza aproximadamente 2/3 del camino en el bit , y es la limitación fundamental en la longitud del bus CAN. Cuanto más lenta sea la velocidad de bits, más tiempo hay para el peor caso de propagación de un extremo del bus al otro y, por lo tanto, más largo puede ser el bus. Esta verificación se debe hacer cada vez que crees que eres el propietario del autobús y estás enviando 1 bit.

Otro problema es el ajuste de la velocidad de bits. Todos los nodos en un bus deben estar de acuerdo con la velocidad de bits, más de cerca que con RS-232. Para evitar que las pequeñas diferencias de reloj se acumulen en errores significativos, cada nodo debe poder hacer un bit un poco más largo o más corto que su valor nominal. En hardware, esto se implementa ejecutando un reloj en algún lugar alrededor de 9x a 20x más rápido que la velocidad de bits. Los ciclos de este reloj rápido se llaman cuantos de tiempo. Hay formas de detectar que el inicio de nuevos bits está vagando con respecto a dónde crees que deberían estar. Las implementaciones de hardware luego agregan u omiten quanta una vez en un bit para volver a sincronizar. Hay otras formas de implementar esto siempre que pueda ajustarse a pequeñas diferencias en la fase entre los tiempos de bits esperados y los tiempos de bits medidos reales.

De cualquier manera, estos mecanismos requieren que se hagan varias cosas en varios momentos dentro de un bit. Este tipo de sincronización se volverá muy difícil en el firmware, o requerirá que el bus se ejecute muy lentamente. Supongamos que implementa un sistema de cuantos de tiempo en firmware a 20 kbits / s. Con un mínimo de 9 cuantos de tiempo por bit, eso requeriría una interrupción de 180 kHz. Eso es ciertamente posible con algo como un dsPIC 33F, pero consumirá una fracción significativa del procesador. Con la tasa de instrucción máxima de 40 MHz, obtienes 222 ciclos de instrucción por interrupción. No debería llevar tanto tiempo hacer todas las comprobaciones, pero probablemente 50-100 ciclos, lo que significa que se utilizará el 25-50% del procesador para CAN y que tendrá que adelantarse a todo lo demás que se está ejecutando. Eso evita muchas aplicaciones que estos procesadores suelen ejecutar, como pulso por control de pulso de una fuente de alimentación conmutada o controlador de motor. La latencia del ciclo 50-100 en cualquier otra interrupción sería un completo obstáculo para muchas de las cosas que he hecho con chips como este.

Entonces vas a gastar el dinero para hacer CAN de alguna manera. Si no está en el periférico de hardware dedicado destinado para ese propósito, obtenga un procesador más grande para manejar la importante sobrecarga de firmware y luego lidiar con la latencia de interrupción grande impredecible y posible para todo lo demás.

Luego está la ingeniería inicial. El periférico CAN simplemente funciona. Según su comentario, parece que el costo incremental de este periférico es de $ .56. Eso me parece una ganga. A menos que tenga un producto de muy alto volumen, no hay forma de recuperar el tiempo y los gastos considerables necesarios para implementar CAN solo en el firmware. Si sus volúmenes son tan altos, los precios que hemos mencionado no son realistas de todos modos, y el diferencial para agregar el hardware CAN será menor.

Realmente no veo que esto tenga sentido.


Valoro su opinión, pero tengo curiosidad por saber por qué nadie ha tratado de solucionar las dificultades. ¡Cada proyecto tendrá esos problemas! Te diré cómo resulta si termino intentándolo.
Kevin Vermeer

En cantidades de 1000, encuentro un precio de $ 3.12 para el dsPIC33FJ64GP202 de microchipdirect - ¡Una diferencia de valor total de $ 560! Al menos vale la pena intentarlo. Yo estaba citando precios por cada uno, simplemente porque era más fácil conseguir los números de piezas individuales sin tener que preocuparse por el devanado, la cantidad paquete estándar etc
Kevin Vermeer

2
@Kevin, los precios de cantidad baja no siempre son proporcionales a los precios de cantidad alta. No sé cuántas de estas cosas planea hacer, pero $ 560 no comenzarán a pagar por la ingeniería para hacer CAN en el firmware. Agregaré a muchas respuestas explicando algunas de las dificultades que encontrará.
Olin Lathrop

WTF !? Acabo de agregar algunas cosas a mi respuesta, y la mayoría del salto de párrafo desapareció. Definitivamente había líneas en blanco en la ventana de edición que estaba escribiendo.
Olin Lathrop

1
La respuesta es sí, puedes, pero estoy totalmente de acuerdo con Olin aquí. De hecho, trabajo a tiempo completo en este campo. Yo uso el chip dsPIC33FJ256. El tiempo dedicado a hacer que las cosas escriban con el enfoque de bit-bang elimina la ventaja de tener hardware que lo hace por usted y reinventa la rueda. Sin mencionar que cualquier otra cosa que esté haciendo en hardware debería planificarse cuidadosamente además de las cosas. Además, me pregunto si está buscando otros protocolos de nivel superior como ISO14229 o OSEK / Autosar NetworkManagement.
Eric M

2

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


No busqué ECAN. Nombre tonto de Microchip, ¡pero tendré que leer más de cerca la próxima vez! Como dije, mis necesidades de procesamiento de señal son bajas, por lo que no creo que necesite un DSP real.
Kevin Vermeer

2

Si estoy leyendo esto correctamente, parece que quiere criticar la funcionalidad CAN utilizando solo un UART y un firmware inteligente. Confía en mí, esto nunca funcionará. Sugiero leer un buen texto sobre las complejidades de CAN o CANopen. Habrás erradicado cualquier ahorro de costos que estés buscando al seguir esta ruta.

¿Usaría un microcontrolador con un módulo CAN y pasaría los $ 2 adicionales, o ha pensado en un protocolo diferente que sea compatible con un UART, como Modbus sobre RS-485 ?


Lo estás leyendo bien. He leído a fondo el folleto de capacitación de Vector sobre CAN. Parece que cada mensaje necesitará algo de preprocesamiento para CRC, pero el resto del paquete debería ser el mismo y tendré que seguir revisando la línea de recepción para ver si hay un conflicto. Realmente no parece tan difícil como la gente cree que es, pero definitivamente tomaré en cuenta su consejo.
Kevin Vermeer

Sin embargo, me gusta la idea Modbus sobre RS485. Parece que la mayoría de esos transceptores también tienen un suministro de 5V; Tenía la impresión de que requería un voltaje de entrada +/- como RS232. Tendrá que investigar eso.
Kevin Vermeer

golpear sin duda funcionará! No es trivial como Olin, arriba, menciona, pero se puede hacer. Personalmente lo logré tanto en una serie PIC18F como en una micro serie dsPIC33. Puedo subir la fuente PIC18F si realmente quieres verla. Sin embargo, no puedo entregar la fuente dsPIC porque es parte de un proyecto comercial en el que trabajo. En ambos casos usamos MCP2551 y también tengo código LIN. LIN es un poco más simple en la capa de protocolo, pero implementar cronogramas LIN es un poco más difícil ...
Eric M

1
@EricM: ¿Cuál fue la velocidad de bits y pudo implementar la especificación CAN completa en el software? Me encantaría ver el código PIC18F para esto.
Rocketmagnet

Sí, implementé la especificación CAN completa para no duplicar el módulo ECAN en el dsPIC que se ocupa de muchos aspectos. En la implementación PIC18 golpeé el bus a la especificación completa y más tarde y este código funcionará en un dsPIC haciendo uso de líneas GPIO. Actualizaré en unos días con un enlace al código.
Eric M

0

También estoy pensando en el protocolo CAN de bit-banging en un PIC µC, así que, por favor, EricM, si realmente lo hizo, responda y diga al menos qué tasa de bits a qué frecuencia de núcleo de PIC18F o DSPic obtuvo. ¡Gracias!

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

Pero en UART / V24 / RS232, el dúplex completo se usa principalmente sin pensarlo en detalle, por lo que tal vez deba poner algo de cerebro en el superloop o la máquina de estado de su aplicación ...

Pero volviendo al CAN-bitbanging: estoy trabajando con CAN durante muchos años y nunca vi una implementación de bitbanging, pero por lo que puedo pensar, eso debería funcionar para tiempos de bits de hasta 100 kBit con µC moderno como DSPic o ARM, etc. (teniendo núcleos a 80MHz o más ...)

Al menos si solo se considera la relectura ... El envío significaría cierta sobrecarga en la preparación de las estructuras de bits para que no se pueda alcanzar el 100% de la carga del bus, pero en CAN más del 65% es raro en absoluto ...


2
Bienvenido a StackExchange de Ingeniería Eléctrica. La primera parte de su respuesta no es realmente una respuesta, por lo que hace una nueva pregunta si eso es lo que desea. El OP le preguntó específicamente sobre la implementación de software del protocolo CAN y su respuesta parece vagar sin abordar esa pregunta; Por favor, trate de mantenerse en el tema de la pregunta.
Joe Hass
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.