Sistema de medios para Toyota Prius (Parte 2)

Continuación del proyecto para reemplazar el sistema de medios Toyota Prius.

En este artículo: PHY, transporte y entrega de paquetes al dispositivo host, que finalmente se pudo verificar en el verdadero jefe nativo del Prius.

Rápidamente el cuento de hadas afecta, pero no rápidamente se hace. Hoy continúo el proyecto prolongado sobre el rediseño del sistema de medios en Prius, que comenzó hace 2 años.

Offtopic histórico
— USB-AVC , . , , .. ++ — , .

, , , , .

, , , PHY- .

Entonces, desde el principio. Buscando en Internet adaptadores para AVC-LAN, a menudo veía soluciones similares a esta . Y en la discusión, tales comentarios a menudo se escapan:
Honestamente, no funciona muy bien, o más bien no funciona bien con todas las cabezas.

Si bien el neumático es perfectamente legible en alguna radio antigua con un Spacio de 99 años.
Inicialmente me opuse fundamentalmente a hacer algo, y las soluciones con inestabilidad estructural no me convienen.
Repetiremos el camino de la ingeniería inversa del neumático. Vamos.

En primer lugar, nos conectamos al autobús en un automóvil en vivo y eliminamos la forma de onda:


el comienzo del paquete.


Los bits están en algún lugar en el medio, más grandes.


Algo muy similar a ACK.

Un poco más sobre este extraño paso, a continuación.

Ya hice capturas de pantalla de las formas de onda de los datos almacenados, mientras los tomaba, no presté atención de inmediato al rango de voltaje en el que tomé los datos. Y cuando lo dibujó, tuvo que bajar al auto nuevamente para asegurarse de que no había sobrevivido de la mente. Sí, el tramo del bus diferencial es de solo 200 mV (!!!).

A continuación, vamos a la hoja de datos utilizada por los colegas ST485, y vemos lo siguiente allí:



Aquí, de hecho, se encontró la raíz de todos los problemas, por lo que tenemos que jugar con resistencias y rezar a los dioses de la colofonia para que el convertidor funcione en una máquina específica. Trabajar cerca de los umbrales es malo. Pero aún más interesante es que para AVC-LAN, que en su física es un clon de algún IE-Bus de NEC, de acuerdo con su especificación (el enlace será un poco más), el estado activo es un voltaje superior a 120 mV, mientras que ST485 tiene el derecho de considerar Cualquier cosa menor que 200mV es cero. Bueno, es decir, si, debido a desviaciones de fabricación, el ST485 tiene un nivel de umbral ligeramente más bajo, y aparece en el bus por un margen ligeramente superior a la norma (se permiten hasta 6 voltios), entonces, por supuesto, el ST485 podrá recibir dicha señal. Y estas inexactitudes de fabricación son la única cosa que obliga a los dispositivos con ST485 en la composición vecestrabajo. Por supuesto, no tendremos tanta felicidad en el desarrollo.

La segunda solución disponible basada en el mismo ST485 y un amplificador operacional, no me gustó la abundancia de componentes. Bueno, en el siglo XXI vivimos, después de todo.

Solución:
Hay convertidores especiales para AVC-LAN. Pero no pude obtenerlos a un precio asequible para este dispositivo. La fraternal China volvió al rescate, donde se descubrió el HA12240FP , que tiene una diferencia de voltaje para percibir un registro. "1" por hoja de datos es 80..110 mV. Esto permitirá que nuestro neumático establezca un nivel activo con un margen casi doble. Arreglos

Damos a luz al esquema en el STM32F103 mencionado en la primera parte:


UPD: El esquema nació con prisa, contiene un error. Los conductores de autobuses deben estar alimentados por 5V. Si es así, como en el diagrama, su diferencial aumenta. umbral, y no se aceptan todos los paquetes.

Creo que todo es simple para el primitivismo, no necesita una descripción. Excepto, quizás, el hecho de que la elección de las piernas para RX1 / 2 no es accidental, y la primera versión del circuito requirió "refinamiento de archivo" para obtener señales a las entradas de captura / comparación, porque quiero usarlo para medir la longitud del pulso. Soluciones alternativas: el sondeo y la interrupción del cambio de estado pierden precisión y complejidad en la implementación del software. Además, me gustaría recibir al menos dos líneas en paralelo (hay tres en la cabeza), y si los frentes coinciden en dos, puede decir adiós a la idea de cualquier precisión aceptable si no utiliza captura / comparación.

Un análisis más detallado de los datos en el paquete está bien escrito aquí . Pero, dado que los enlaces son inconsistentes, repetiré brevemente aquí:

  • El bus diferencial, aquí escriben sobre la interpretación de los niveles del registro. "1" a <20mV, log. "0" -> 110mV.
  • La longitud del bit es de 40 µs, los primeros 20 µs siempre son “0”, los últimos 7 µs siempre son “1”, en el medio está el valor del bit.


    Bueno, el semáforo:


  • Bit de inicio: más de 180 μs
  • (ACK). «», - :



    ACK- , Dallas 1-wire, , , , . , . 1 , «0» ( , ), .2 , , , . .3 , (1), , , 7 , . «1».

Bueno ... descubrimos el nivel físico, dibujamos el circuito y separamos el tablero. Resultó algo como esto: la





placa de circuito impreso salió algo sin éxito, y no porque el código QR no funcionara en la serigrafía. Hay un error en el circuito en él (en el diagrama anterior ya lo corregí) con respecto a la selección de patas para el RX, y tres conductores de línea están divorciados. En el proceso de escribir y depurar el programa, me di cuenta de que es bueno si puede ejecutar al menos dos de manera constante. Sí, y más no es necesario.

Bueno ... el dispositivo resultó ser simple y efectivo, mientras que el problema constructivo con la falta de coincidencia de niveles se ha resuelto.

Además en el programa:

  1. . , . : * USB — , , «» . . * , 8, 6- , 4.4 . , , .
  2. Monitor de Android para el reverso completo de la lógica del bus. Si alguien es fuerte en Android y Kotlin, agradeceré la oportunidad de consultar. Estos son intentos tímidos para dominar todo a la vez, por lo tanto, no ingrese al repositorio por referencia sin un nuevo pase :)


UPD: temporales fija s de datos electrónicos en lugar microsegundos eran ms.

All Articles