Tengo 64 dispositivos i2c conectados entre sí. Todos parecen funcionar correctamente hasta que, de forma aleatoria, entre 30 s y 1 m de envío de señales, el bus se bloqueará.
Así es como lo tengo conectado:
Actualmente está cableado como el diagrama A. ¿Necesito una configuración como B? ¿Hay algo más que pudiera causar que un dispositivo al azar y un tiempo aleatorio agoten el bus?
La forma del autobús no importa tanto. Lo que usualmente importa más es la capacitancia total del bus. Un buen enfoque conservador es mantener la capacitancia por debajo de 400pF. A veces, es posible ejecutar I 2 C bus a una capacidad más alta, si baja la velocidad. Los pull-ups más rígidos [menos] también ayudan, pero si son demasiado rígidos, los buses no funcionarán.
Normalmente, la alta capacitancia del bus se aborda con (1) almacenamiento en búfer y / o (2) conmutación.
Hay IC especializados para el almacenamiento en búfer de capacitancia de 2 C. PCA9515 , por ejemplo.
Cada rama del bus tiene una capacitancia suficientemente baja. Pero si todas las ramas están conectadas juntas, su capacitancia combinada se vuelve demasiado alta. Agregue un multiplexor de modo que pueda conectar una rama a la vez. El maestro "verá" la capacidad de una sola rama.
Nota útil de la aplicación: Solución de problemas del protocolo del bus I2C . Muestra ambos métodos.
Sugerencia de diagnóstico. Reduzca el tamaño del bus (quizás, a la mitad, si puede) y vea si cuelga menos o lo mismo.
Más información ayudaría. Las imágenes en el O.P. no muestran: dimensiones mecánicas, cómo se construye su circuito (PCB, cables o placa de pruebas).
Una captura de pantalla de osciloscopio también ayudaría.
Ya que funciona por un tiempo, parece que básicamente está bien conectado, pero se están dañando los datos. Cuando se cuelga, la dirección del esclavo probablemente se corrompió en el receptor, no resultó ser una dirección que ninguno de los otros dispositivos piense que es de ellos (ya sea en realidad o después de la corrupción), no se envía ACK y el transmisor el firmware se cuelga. Es sorprendente lo deficientes que son la mayoría de las implementaciones de firmware de IIC para no recibir ACK. Hay una gran cantidad de firmware IIC irresponsable por ahí.
Si la suposición anterior es correcta, entonces hay que arreglar dos cosas. Primero, el firmware debe comportarse de manera responsable cuando no se recibe ACK en el momento que se espera. Esto podría ser a una dirección o byte de datos. En segundo lugar, la corrupción del bus necesita ser reparada.
64 dispositivos es mucho, pero debería ser factible si todos los dispositivos están en la misma placa. Tomar a la CII fuera de servicio es pedir problemas, y con muchos dispositivos lo es doblemente. La topología exacta de cómo se conecta el bus no debería importar mucho, ya que, en cualquier caso, debería ser mucho más corta que la longitud de onda más corta de interés.
Coloque el pullup más rígido permitido en algún lugar del autobús. El máximo que un nodo IIC debe hundir para conducir la línea baja es de 3 mA si recuerdo correctamente. Asegúrese de que no se exceda, pero de lo contrario use la resistencia de extracción más baja permitida. Por ejemplo, supongamos una potencia de 3.3V. 3.3V / 3mA = 1.1 kΩ. En teoría, un pullup de 1.1 kΩ debería estar bien, pero en este caso lo haría 1.2 kΩ. Sigue siendo casi la misma capacidad de recuperación y deja un pequeño margen frente a la corriente máxima desplegable. Si el bus es en su mayoría lineal, podría colocar una resistencia de 2.4 kΩ en cada extremo, aunque será una mejora menor, si la hay.
Eche un vistazo a los bordes ascendentes y descendentes con un alcance y vea cuánto tiempo tardan, luego reduzca la velocidad de bits lo suficiente como para que todo se acomode dentro de poco. Todos esos nodos agregarán capacitancia, lo que ralentizará los bordes, particularmente el tiempo de subida. Habrá un límite de velocidad de bits que no puede superar debido a esto. Es posible que no sea posible ejecutar el bus IIC tan rápido como lo hacen los dispositivos. Esa es una compensación que hiciste cuando decidiste poner 64 dispositivos en el bus.
Si todavía tiene problemas después de abordar todo lo anterior, implementaría el maestro IIC en el firmware sin utilizar ningún hardware IIC incorporado. He visto que algunas implementaciones de fabricantes bien conocidos tienen condiciones de carrera. Tales implementaciones son particularmente susceptibles a una diferencia de velocidad de giro relativa entre SCL y SDA. Mis implementaciones de solo firmware garantizan que nunca más de una cosa suceda por tiempo de bit. Hay un retraso mínimo entre cada acción que garantiza que el autobús se haya instalado. Esto puede ejecutar el bus más lento de lo que lo haría el periférico de hardware, pero es una buena implementación robusta. De hecho, por lo general utilizo un maestro IIC solo de firmware para la robustez, a menos que la velocidad sea crítica.
Sugiero echar un vistazo a los buses con el osciloscopio. He visto problemas similares incluso con menos dispositivos. Con un osciloscopio puede observar el tiempo de subida de la señal y ver si la forma de onda viola las especificaciones de cualquier chip en el bus. I2C es básicamente un juego de constantes RC y no puedes ejecutarlo más rápido de lo que crea. Asegúrese al 100% de que todos los dispositivos estarán contentos con la forma de onda y dése espacio para la velocidad; de lo contrario, el calor y otros efectos podrían hacer que las comunicaciones fuesen exitosas. Si lo necesitas absolutamente a prueba de errores, incluso utilizaría un spray enlatado para enfriar y un soplador de aire caliente en la placa.
Uno de los mejores enfoques que he visto que cualquiera que ejecute estas interfaces debería hacer es ejecutar estadísticas comunicándose a todos los dispositivos durante un largo período de tiempo (horas) y leyendo algunos registros. Registre cualquier falla (y cualquier causa posible) en algunas variables del contador y luego regrese y mírelas. No debe haber fallas. Usando este método nunca he tenido un problema.