Historia del convertidor Ethernet-CAN

Un día claro y soleado para el trabajo necesitaba un convertidor de interfaz CAN a Ethernet económico. Naturalmente, la búsqueda comenzó con soluciones listas para usar, pero, como suele suceder, al final se decidió desarrollar su propia muestra. Naturalmente, el entusiasmo del autor no pudo resistirse y se limitó a una funcionalidad tan "truncada". Lo que surgió, cómo y por qué, debajo del corte.



Resumen general La foto de arriba muestra un modelo 3D de la placa que desarrollé usando CAD Altium Designer. Características y funcionalidad clave:

• Ethernet de 10 \ 100 Mb
• Rtc
• MicroSD (FAT12, FAT16, FAT32) 4GB
• RS232 \ RS485
• PUEDE
• Zumbador
• 3 LED de usuario
• GPIO
• EEPROM 32 KB
• FLASH 2 MB
• I2C
• SPI
• UART
• SW \ JTAG
• USB serie (puerto COM)
• Potencia: miniUSB 5V \ Externo 9..24V

El costo del tablero recolectado es ~ 5000 R. El proyecto es de código abierto en la naturaleza, las fuentes se pueden encontrar en github . Lo que resultó al final, además de la funcionalidad principal, puede considerarse una buena placa de depuración para trabajar con el microcontrolador STM32.

Y ahora a los detalles de la creación.

Hardware

El estudio de este problema comenzó con la búsqueda y evaluación de soluciones preparadas. Los requisitos principales fueron:

1. conversión de tramas entrantes CAN2.0B a paquetes TCP \ IP y viceversa;
2. bajo costo, como resultado, la implementación de un dispositivo basado en un microcontrolador.

Los colegas de China tienen varias soluciones industriales, pero no económicas, por lo que un representante del convertidor de interfaz PIRS CAN-Ethernet de producción nacional fue entregado a nuestra oficina para una prueba. De acuerdo con las capacidades y características descritas, el dispositivo satisfizo la modesta T.Z., solo quedó verificar el rendimiento en la práctica, lo que hice, armado con Wireshark y el osciloscopio. Por una razón desconocida, al enviar paquetes al dispositivo TCP en la salida del dispositivo, donde se suponía que debían aparecer tramas CAN, se escuchan secuencias con niveles físicos de CAN (par diferencial) pero protocolo lógico de interfaz UART (con bits de inicio y parada). Al abrir la caja, abrir la documentación de los microcircuitos y hacer sonar las pistas de la placa, descubrí que, de hecho, los pines RX y TX (UART) del microcontrolador están conectados al transceptor CAN y están conectados a un conector externo. Por lo tanto, no se esperaba soporte de hardware para el estándar CAN2.0B.

Esto es lo que vi en la salida CANL de "PIRS CAN-Ethernet" al enviar dos bytes de datos [ 0xF0 ] y [ 0x0A ] a través de TCP \ IP:



El orden de los bits está al revés, pero puede manejarlo mediante programación, pero ya es más difícil hacer algo a nivel de aplicación con los bits de inicio y parada a través de cada byte, porque Se insertan en el hardware.

Y así es como debería verse la trama CAN2.0B "verdadera" con los mismos dos bytes de datos:



Como puede ver en el oscilograma, además de los bytes de datos, la trama contiene muchos bits de servicio del protocolo más bits de relleno, y lo más importante, ¡van continuamente sin ningún bit de inicio y parada! (Para aquellos que estén interesados, debajo del spoiler, una descripción detallada de este paquete).


Por lo tanto, no me fue posible resolver el problema de incompatibilidad de los marcos CAN y UART con un método de software y, al observar los resultados de la investigación intermedia con una mirada decepcionada, se decidió desarrollar nuestro propio prototipo del dispositivo requerido.

Debido al hecho de que ahora era posible tomar el control de una gama más amplia de características técnicas del dispositivo, se agregaron los siguientes requisitos:

3. La capacidad de alimentar de 12-24 V en sistemas de transporte;
4. La presencia de memoria externa para almacenar registros;
5. Las dimensiones de la placa no son más de 86x80 mm.
6. Rango de temperatura de funcionamiento -40..85 °

La conocida plataforma STM32F407VET6 [2] fue seleccionada como el cerebro del nuevo dispositivo, que tiene soporte de hardware para todas las interfaces necesarias y un buen suministro de memoria RAM y FLASH. Después de pulir Internet, el transceptor DP83848IVV [3] fue elegido como PHY Ethernet, que tiene, en mi opinión, buena documentación y suficientes ejemplos de esquemas de conexión y enrutamiento. Como memoria externa no volátil para almacenar registros, elegí SPI FLASH 2 MB y SPI EEPROM para almacenar una variedad de configuraciones. Además, se agregó protección de energía contra sobretensión, inversión de polaridad. Después de N noches y M fines de semana, se compiló un diagrama de circuito y un rastro de la placa de circuito impreso del dispositivo de la primera versión. Porque había suficiente espacio en el tablero, pero no quería dejar las patas MK inactivas, además de la funcionalidad principal, se agregó el tablero:

• herramientas de depuración SW, JTAG;
• Interruptor 8-DIP;
• micro-USB (serie USB);
• RS-232;
• UART
• I2C;
• GPIO

La idea era que, si fuera necesario, la placa estuviera lista para ampliar la funcionalidad mediante la instalación de componentes adicionales. Además, los asientos de repuesto no afectan el costo de producción. Por un lado, desafortunadamente, debido a esto, no fue posible ajustar todo, por lo que el tablero resultó ser bilateral 86x80mm, min. ancho de vía 0.25 mm, diámetro mínimo del agujero 0.6 mm.


La primera versión del diseño de PCB

Más tarde, se ordenaron dos muestras de prueba y se ensamblaron con un conjunto completo de periféricos para investigación. Para ahorrar dinero, el tablero se hizo sin máscara y, por lo tanto, tiene un color tan inusual.



Con la ayuda de STM32CubeMX, esbocé un firmware de prueba con una prueba de operatividad de los principales módulos periféricos del dispositivo y, como primera aproximación, todo funcionó, excepto para iniciar el MC desde un cuarzo externo de 8 MHz. Resultó que, debido a mi error al elaborar la especificación, se soldaron los condensadores de carga incorrectos. Pero esto no impidió que el STM32F407 funcionara con un generador RC interno. Cuando pude hacer ping a mi dispositivo, no hubo alegría alentadora. He tomado más tiempo con el rastreo PHY Ethernet. Luego, en el navegador, vi mi página http de prueba y me tranquilicé con las pruebas.

La producción de las primeras muestras de tableros se ordenó en Zelenograd. Y, a pesar del hecho de que el costo de "con" la máscara y "sin" fue casi dos veces diferente, no recomiendo hacerlo incluso en la etapa de prototipo, porque, por regla general, es en esta etapa donde aparecen los errores de rastreo y sucede algo soldadura Pero emborracharse en las pistas "desnudas" es extremadamente desagradable, ahorrar dinero, pero casi ningún nervio. Sí, y adivinar si hubo un breve descanso en alguna parte o si la traza es incorrecta, es un placer. Debido a mi inexperiencia, soldando un resonador de cuarzo y condensadores de carga, maté una muestra.

En ese momento, en el trabajo, en los contenedores había una pieza de hierro capaz de resolver la tarea de conversión en el proyecto actual, pero, además del gran tamaño y costo, al tener un firmware escrito, me encontré con problemas relacionados con el tamaño de RAM y la funcionalidad truncada de la pila TCP \ IP MK LPC2368. Entonces, el deseo de hacer que su dispositivo solo se intensifique.
Después de estudiar cuidadosamente las deficiencias de la primera versión, yo, sin pensarlo dos veces, pasé a la segunda. Y de nuevo, quería agregar un "trabajo atrasado para el futuro", incorporando los siguientes componentes en el factor de forma anterior:

• Soporte RTC con batería;
• RS-485;
• micro-SD;
• zumbador tweeter;
• la capacidad de alimentar desde USB;
• SPI al conector externo;
• Alimentación de 5V y 3.3V a un conector externo.

Entre otras cosas, se agregaron protección de corriente y diodos TVS en los conectores de usuario.

El resultado es una especie de placa de desarrollo con la capacidad de conectar módulos externos. Esta vez pedí una tabla en China. La asamblea se llevó a cabo con nosotros.




La segunda versión del tablero.

En la segunda versión, descubrí el modelado 3D en Altium Designer, que ayudó mucho a evitar errores en el posicionamiento relativo de los componentes en dos lados (resultó que Internet ya está llena de modelos listos para usar de componentes SMD [4] ). Por lo tanto, todos los errores de la primera versión fueron corregidos, las innovaciones mostraron su eficiencia, lo que me hizo muy feliz.

Firmware

La descripción del código está más allá del alcance de esta parte, sin embargo, me gustaría decir algunas palabras sobre el componente de software. En mi dispositivo, decidí usar la pila FreeRTOS + LwIP. Hay un número suficiente de artículos sobre ellos, por ejemplo, [5] y [6] , por lo que no debería ser difícil vincularlos a su proyecto. En resumen, LwIP es una pila TCP \ IP para sistemas embebidos, caracterizada por un bajo consumo de RAM y una API conveniente (incluso hay un shell de socket BCD). Usé la API de netconn. Por medio de FreeRTOS, todo el trabajo de la pila TCP \ IP se coloca en una secuencia separada de la aplicación. Además del trabajo principal (conectar un servidor TCP externo al bus CAN), un servidor web independiente gira en una secuencia independiente para acceder a la configuración del dispositivo. Dicha interfaz web está diseñada para monitorear y configurar los ajustes del dispositivo, estableciendo diferentes modos de operación, velocidades de transmisión, direcciones, etc. Todavía no sé si será posible realizar una actualización de firmware a través de él.

Conclusión

Este fue mi primer (y espero que no el último) proyecto de hardware de tanta complejidad y, a pesar de los errores cometidos, creo que la segunda versión del tablero puede considerarse exitosa. En cada iteración, había muchas dudas, pero, sin embargo, una vez más, estoy convencido de que si no lo intentas, seguramente nada resultará.

Fuentes utilizadas

1. Wikipedia / Controller_Area_Network
2. Hoja de datos STM32F407VET6
3. Hoja de datos DP83848
4. Modelos 3D
5. Introducción a FreeRTOS
6. Introducción a LwIP