Velocidad de comunicación I2C entre sensores

Tengo curiosidad por saber qué tan rápido puedo comunicarme entre múltiples sensores. Tengo una placa con un acelerómetro digital adxl345 y un giroscopio MEMS de 3 ejes itg3200 en I2C. Estoy tratando de construir una IMU que requiere un sondeo rápido de ambos sensores. Cuanto más rápido intento sondear, más códigos de error recibo. ¿Cómo puedo calcular el retraso óptimo requerido para la comunicación simultánea? Además, ¿qué tan rápido puede I2C realmente comunicarse entre múltiples sensores?

PD. Estoy en un chip atmega128 a 16 MHz.

¿Qué quiere decir con más rápido : un reloj I2C más alto o un intervalo más corto entre las encuestas? ¿Y qué tipo de errores obtiene, son códigos de error de los dispositivos o errores de comunicación I2C?
Son códigos de error I2C. Sí, estoy interesado en el intervalo más corto entre las encuestas.

Respuestas (1)

I 2 C es un protocolo serial sincronizado, lo que en general significa que hay muy poco que limite la velocidad eléctricamente. Mayoría I 2 C los buses funcionan a 100 kHz o 400 kHz, lo que superará con creces la capacidad de la mayoría de las IMU para generar datos.

Por ejemplo, yo estaba en un equipo de robótica que usaba una nIMU de Memsense y si observa la hoja de datos, dice que el ancho de banda es de 50 Hz y genera 34 bytes en un paquete. Esto significa que, en teoría, podría detenerse en 50 34 8 = 13 , 600 bits por segundo o 13,6 Kbps. El chip con el que lo ejecutamos podía funcionar hasta 400 kHz, por lo que podía manejar bastantes de estos en el bus con el máximo rendimiento de datos.

Al mirar la hoja de datos del atmega128 que proporcionó, dice que la interfaz "TWI" o de dos cables está limitada a 400 kHz. conociendo el I 2 C protocolo, serán 2 relojes para la condición de inicio, 1 reloj para la condición de parada y 9 relojes para la dirección, y 9 relojes por byte. Entonces, usando la nIMU a la que me referí antes, esto da una virtual 34 b y t mi s 9 C yo o C k s pag mi r b y t mi + 9 a d d r mi s s C yo o C k s + 2 s t a r t b i t + 1 s t o pag b i t = 318 relojes por paquete. Esto significa que no había límite en la tasa de muestreo, podríamos leer 400 , 000 / 318 = 1257 paquetes por segundo. Dado que estamos limitados por el muestreo a 50 paquetes por segundo, en su lugar podríamos tener 25 IMU enviando datos.

Al mirar la hoja de datos de ITG, necesitará hacer algunos cálculos matemáticos para calcular exactamente la frecuencia de muestreo máxima, pero creo que 125 Hz parece una buena línea de base (consulte la sección 8.2). Emite 3 números de 16 bits dando 48 bits por muestra. 48 125 = 6 , 000 bits por segundo. Bien dentro del rango de los 400kHz a los que también tiene acceso. Con el adxl345 parece que la velocidad máxima de salida de datos es de 3200 bits por segundo (¿creo?).

Por lo que parece, el rendimiento máximo combinado de los dos dispositivos que ha elegido es de 9200 bits por segundo, y el atmega128 tiene un rendimiento de ~400 000 bits por segundo. No creo que tengas que preocuparte por la capacidad de I 2 C empantanando el sistema.

¡Lindo! Estaba haciendo cálculos similares, sin embargo, cuando sondeaba ambos sensores con menos de 5 ms de diferencia, comencé a recibir errores de código de estado I2C. ¿Alguna idea de por qué fue esto? 5 ms debería ser tiempo suficiente para que ocurran ambas transacciones.
Por lo tanto, debería usar el pin INT en su ITG si aún no lo ha hecho. Mire la sección 8.4 y configúrelo para que RAW_RDY_EN esté configurado. Si solicita datos con más frecuencia que cuando ese pin se activa, obtendrá errores. Si esa interrupción ocurre con menos frecuencia de lo que espera, verifique los otros valores de configuración para el dispositivo, hay muchas cosas diferentes (consulte la sección 8.2). Hay algo similar (INT1 e INT2) para adxl345 que debe descubrir y usar. ¡No debería estar sondeando a intervalos regulares, use las funciones provistas de sus chips!