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.

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.

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.

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 ?

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 ...