Mi recomendación es que siempre termine cada transacción con cada dispositivo con una secuencia de detención. Tendrá muchas más posibilidades de éxito al hablar con varios tipos de dispositivos alternativos que intente adjuntar en el futuro.
He visto específicamente dispositivos que se comportan mal cuando falta una parada al final de la transacción.
De hecho, hubo trabajo que hice, algunos años atrás, diseñando algunos dispositivos esclavos en partes de tipo FPGA. Me pareció esencial descodificar la condición de parada y usarla para restablecer la máquina de estado de transacción del esclavo. La razón principal de esto es que pueden ocurrir cosas extrañas en el autobús, cosas que el lado maestro del autobús ni siquiera esperaba que sucedieran. Cuando una operación en curso se corrompe por estas "cosas inesperadas", pueden surgir estragos que requieren cierto trabajo para recuperarse. La mejor estrategia de diseño para los dispositivos es que diseñan y utilizan la secuencia de parada para producir el restablecimiento de la interfaz. Cuando se sigue esta estrategia, el fabricante de dispositivos recibe mucho menos llamadas de soporte y un grupo de clientes más feliz. Del mismo modo, el cliente que se está conectando a los dispositivos sabrá de esto y simplemente podrá proporcionar un "restablecimiento de bus" de su red I 2 C que consiste en un START - > PARAR secuencia de pares. Esto se puede utilizar en el software del controlador de nivel superior del lado maestro como parte de un bucle de reintento para cuando las comunicaciones del dispositivo han fallado por una razón u otra.
Si realiza una exploración en la web, puede encontrar ciertas notas de aplicación que describen varios tipos de esquemas de "reinicio de bus" I 2 que intentan recuperar dispositivos que se han bloqueado debido a eventos inesperados en el autobús. Algunos de estos incluyen hacer secuencias de inicio-parada con 9 o 27 ciclos de reloj entre ellas. Otros han mostrado cómo conectar la alimentación al dispositivo de destino utilizando un FET en la línea Vcc para efectuar un "restablecimiento interno" en el dispositivo esclavo.
Si todo el mundo está diseñado para simplemente restablecer la secuencia de parada, todos los problemas extraños de I 2 C que pueden ocurrir se pueden resolver de una manera sencilla sin tener que recurrir a los esquemas que se explican en estos notas de la aplicación. He experimentado una gran mejora en la robustez de los dispositivos I 2 C más nuevos que uso en mis propios proyectos de diseño integrado. Este es un gran alivio en comparación con los sensores de temperatura LM75 de hace 10 a 15 años que necesitaban una conexión de potencia de sus pines Vcc para proporcionar un funcionamiento confiable O C DAC / ADC de 8 bits sin nombre I 2 que requería Relojes extra tipo restablecimientos de recuperación.
Entonces, basándome en años de experiencia, quiero recomendar nuevamente que no intente hacer este esquema de dirección de secuencia de inicio / cambio repetido. Siempre siga la secuencia más simple que realiza el trabajo para un dispositivo I 2 C específico. Y asegúrese de que cada transacción finalice con una secuencia de detención y proporcione una función de restablecimiento del bus que sea un par de secuencias de inicio-parada.
Sé que probablemente hay muchos lectores aquí que están implementando el software de comunicaciones I 2 C que está diseñado bajo el supuesto de que los dispositivos siempre funcionarán. Me gustaría señalar que hay una gran cantidad de aplicaciones integradas de misión crítica donde esta técnica es inaceptable. Se hace necesario detectar todos los errores posibles en una transacción y luego agregar otra capa por encima de esto que incluya reintentos y un intento de recuperación del restablecimiento del bus. Y, por último, si el comportamiento crítico del producto depende del canal I 2 C que ha fallado, tome medidas cuidadosas para apagar el dispositivo de manera ordenada y segura.