Creo que implementar el protocolo CAN en el firmware solo 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 paquete QFN se vende por 3,68 USD en microchipdirect por 1000 piezas. El precio será menor para los volúmenes reales de producción.

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

Agregado:

Dado que 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 1 Mbit/s durante al menos decenas de metros. Para darle un punto de datos, el estándar de señalización de a bordo NMEA 2000 se superpone en CAN a 200 kbits/s, y eso está destinado a ir de un extremo al otro de un barco grande.

Puede pensar que todo lo que necesita es una interrupción por bit y puede hacer todo lo que necesita en esa interrupción. Eso no funcionará porque hay varias cosas sucediendo en cada tiempo de bit CAN. Hay que hacer dos cosas en particular a nivel de subbits. El primero detecta una colisión y el segundo ajusta la tasa 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 están unidas 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 Ω uniendo pasivamente las dos líneas diferenciales. El estado dominante es cuando ambas líneas se separan activamente, en algún lugar alrededor de 900mV desde el estado recesivo si mal no recuerdo. Básicamente, esto es como un bus de colector abierto, excepto que se implementa con un par diferencial. La barra 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 suelta), 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 1 para asegurarse de que alguien más no esté enviando 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 tasa de bits, más tiempo habrá para la propagación del peor de los casos de un extremo al otro del bus y, por lo tanto, más largo puede ser el bus. Esta verificación debe realizarse cada bit donde crea que es el propietario del bus y esté enviando un bit 1.

Otro problema es el ajuste de la tasa de bits. Todos los nodos de un bus deben estar de acuerdo con la tasa de bits, más estrechamente 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 el hardware, esto se implementa ejecutando un reloj entre 9 y 20 veces más rápido que la tasa de bits. Los ciclos de este reloj rápido se denominan cuantos de tiempo. Hay formas de detectar que el comienzo de nuevos bits se está desviando con respecto a donde cree que deberían estar. Las implementaciones de hardware luego agregan u omiten los cuantos de una vez en un bit para volver a sincronizar. Hay otras formas de implementar esto, siempre que pueda ajustarse a pequeñas diferencias de fase entre los tiempos de bit esperados y los tiempos de bit medidos reales.

De cualquier manera, estos mecanismos requieren que se hagan varias cosas en varios momentos dentro de un bit. Este tipo de temporización será muy complicado en el firmware o requerirá que el bus funcione muy lentamente. Supongamos que implementa un sistema de cuantos de tiempo en el 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. A la velocidad de instrucción máxima de 40 MHz, obtiene 222 ciclos de instrucción por interrupción. No debería llevar tanto tiempo realizar todas las comprobaciones, pero probablemente entre 50 y 100 ciclos, lo que significa que el 25-50 % del procesador se usará para CAN y tendrá que adelantarse a todo lo demás que se esté ejecutando. Eso evita que muchas aplicaciones que estos procesadores ejecutan a menudo, como el control pulso por pulso de una fuente de alimentación conmutada o un controlador de motor. La latencia de 50-100 ciclos en cualquier otra interrupción sería un obstáculo total 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 es en el periférico de hardware dedicado diseñado para ese propósito, entonces en obtener un procesador más grande para manejar la sobrecarga significativa de firmware y luego lidiar con la latencia de interrupción impredecible y posible grande 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 $0,56. Eso me parece una ganga. A menos que tenga un producto de gran volumen, no hay forma de que recupere el tiempo y los gastos considerables que llevará implementar CAN solo en el firmware. Si sus volúmenes son tan altos, los precios que hemos estado mencionando no son realistas de todos modos, y el diferencial para agregar el hardware CAN será menor.

Realmente no veo que esto tenga sentido.

Usamos el PIC18F25K80 . Si bien no tiene un DSP, cuesta ~ $ 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 transfirió desde Microchip. Funciona bien para todo lo que he necesitado y probado.

Si estoy leyendo esto correctamente, parece que desea utilizar la funcionalidad CAN bit-bash utilizando solo un UART y algún firmware inteligente. Confía en mí, esto nunca funcionará. Sugiero leer un buen texto sobre las complejidades de CAN o CANopen. Habrá erradicado cualquier ahorro de costos que esté buscando siguiendo 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 modificar el protocolo CAN en un PIC µC, así que, por favor, EricM, si realmente lo hiciste, responde e indica al menos qué tasa de bits y qué frecuencia central de PIC18F o DSPic obtuviste. ¡Gracias!

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

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

Pero volvamos al bitbanging de CAN: he trabajado 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 bit de hasta 100kBit con µC modernos como DSPic o ARM, etc. (con núcleos a 80 MHz o más...)

Al menos si solo se considera la relectura... El envío significaría algunos gastos generales 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...