Parece que la solución real está en un nivel más alto de protocolo. En un nivel superior, debes saber cuándo está bien enviar y cuándo no.

No estoy familiarizado con LIN en particular, pero probablemente hay un medio para abordar este problema ya definido como parte de LIN. Una posibilidad es que los nodos se envíen cuando tengan ganas, y las colisiones resultantes se detecten y traten de manera ordenada. Así es como funciona CAN, por ejemplo. O bien, hay una lógica de nivel superior para garantizar que solo un nodo a la vez deba transmitir. La mayoría de las implementaciones de bus RS-485 funcionan de esa manera, por ejemplo. El autobús de un cable de Dallas también funciona de esa manera.

Implemente cualquier mecanismo que ya haya sido decidido.

¿Qué causa conflictos en el bus LIN?

El protocolo LIN está diseñado para que la mayoría de las veces no haya conflictos. La tarea maestra sondea las tareas del esclavo individualmente, a los esclavos solo se les permite transmitir de forma inmediata en respuesta al maestro sondeando.

Hay algunas razones por las que puede ocurrir un conflicto:

• Estás transmitiendo cuando no se supone que debes
• Otro esclavo está transmitiendo cuando no se supone que debe
• La red ha sido mal definida, por lo que varios esclavos están configurados para responder a la misma solicitud de sondeo
• Estás transmitiendo un fotograma controlado por eventos

Las 3 primeras razones son problemas importantes que deben resolverse en el diseño del bus. El último es intencional: se supone que debes tener conflictos en los marcos controlados por eventos, así es como funcionan y el maestro los resolverá.

¿Cómo detecto conflictos en el bus LIN?

El transceptor LIN (y los circuitos circundantes) tiene algunos propósitos. Lo principal que nos importa es que convierte la señal UART de 2 hilos de su procesador en una señal LIN de 1 cable. El transceptor es todo circuito pasivo, está continuamente enviando y recibiendo continuamente. Esto significa que todo el byte que envíes también lo recibirás.

La única vez que esto cambia es si alguien más está transmitiendo al mismo tiempo que usted. Si esto sucede, el transceptor Y sus transmisiones se unirán y usted recibirá el resultado. Este será un byte diferente al que transmitiste.

Cada vez que transmites un byte, debes verificar que recibas exactamente el mismo byte de nuevo . Si no lo hace, hay otro nodo que transmite al mismo tiempo que usted.

¿Qué hago cuando detecto un conflicto en el bus LIN?

Tan pronto como detectes un conflicto, deja de transmitir. El maestro detectará la transmisión abortada y actuará en consecuencia.

Si esto sucede con regularidad, y no es un marco controlado por eventos, debe examinar todo el bus:

• ¿Uno de los nodos actúa fuera de especificaciones y se comunica cuando no debería?

  Necesitas arreglar o reemplazar este nodo.

• ¿Están dos nodos configurados para responder al mismo encabezado?

  Debe reconfigurar uno de los nodos para usar un encabezado diferente

• ¿Está utilizando varias instancias del mismo nodo esclavo?

  Debe pensar en usar un sistema de direccionamiento dinámico, como la Detección de posición del nodo esclavo (SNPD).

Con la excepción de los marcos de eventos (que sabrá si los está utilizando) no hay colisiones posibles en el bus LIN. Solo puede haber un maestro, y todas las transmisiones de un esclavo a ese maestro son inicializadas por ese mismo maestro.

Su código no debe estar transmitiendo hasta que haya recibido un encabezado de mensaje apropiado del maestro (BREAK + SYNC + PID). Una vez que haya recibido esto, su código debe saber exactamente cuántos bytes enviar (esto se acuerda cuando se diseña el bus), y el maestro le permitirá a su dispositivo el 140% del tiempo de transmisión mínimo para enviar esto antes de un error es detectado (garantizará que el bus permanezca inactivo durante este tiempo).

Solo hay otra situación en la que puede ocurrir algo así como una colisión, y es si el maestro interrumpe una transacción enviando una nueva secuencia BREAK (13 bits en el estado dominante). Un esclavo adecuadamente diseñado debería poder reconocer una secuencia BREAK en cualquier momento, abandonar la transacción actual y recibir el nuevo encabezado. En la práctica, normalmente es suficiente detectar un error de lectura y dejar de transmitir cuando esto ocurre.