i2c problemas de comunicación a menos que el equipo de prueba esté conectado

Navega tus respuestas
0

Tengo un RaspberryPi que actúa como maestro para un esclavo Atmel ATTiny861A sobre i2c, que envía continuamente un comando más 3 bytes de datos para encender un LED RGB. Esto funciona perfectamente, pero SOLO si el programador AVR está conectado (comparte los mismos pines que estoy usando para i2c) O si mi analizador Saleae Logic está conectado a SDA y SCL. Si ninguno de ellos está conectado, el código Python que se ejecuta en RaspberryPi informa de un "Error de entrada / salida" aproximadamente cada 50 a 100 comandos y, finalmente, la línea se bloqueará; el esclavo mantiene un SDA bajo y no lo soltará.

Mi pregunta es, ¿qué tiene de especial el programador o las sondas que permiten que esto funcione? ¿Qué debo cambiar para permitir el funcionamiento normal cuando no están conectados?

No sé qué condiciones llevan al código Python a dar el error (es difícil detectar el analizador con el flujo constante de datos), pero supongo que el esclavo simplemente no responde con un ACK cuando debería.

Detalles adicionales; Estoy ejecutando aproximadamente 5 pies de cable plano desde el RaspberryPi al esclavo (no puede estar más cerca). El RPi i2c funciona a 3.3 V, por lo que hay un cambiador de nivel / repetidor ( enlace ) que yo conectar a. El lado de salida Vcc es 5V. Además, en la salida del TCA9509, tengo resistencias pullup de 5k en las líneas SDA y SCL. La distancia entre el TCA9509 y el ATTiny861 es de aproximadamente 2 pulgadas.

Si es útil, este es el código que se ejecuta en el ATTiny861A:

enlace

Utiliza el código del controlador USI TWI Slave de Donald Blake, modificado para eliminar las definiciones relacionadas con dispositivos que no son ATTiny861.

    
pregunta Garth Winter Webb

2 respuestas

0

Considere el bus I2C que necesita resistencias de extracción, ya que la mayoría de los controladores I2C deben ser del tipo open collector . Por ejemplo, aquí 2 resistencias de 10K ohmios hacen que las líneas I2C vuelvan a ser altas cuando no son bajas por una salida de colector abierto:

    
respondido por el st2000
0

Le sugiero que use un par de cambios para mejorar su bus I2C.

  1. Use resistencias de pull-up de valor más bajo. Su cable largo es altamente capacitivo y provocará daños en los niveles de señal y Gnd.
    Utilice este documento de TI para establecer el mejor valor de recuperación a 100 kHz (la velocidad predeterminada) en la frambuesa pi). (Personalmente, siempre termino en ambos extremos de los cables largos utilizando dos veces el valor calculado de pull-up) Su TCA9509 complica un poco el problema. Ya tiene fuentes de corriente de pull-up de 1 mA en su lado A (la Rasberry Pi), así que pondría valores de pull-ups de un solo valor de 2,5 k-Ohm solo en el extremo de la fuente del bus.

  2. Baje la velocidad de su bus I2c. Puedes hacerlo de varias maneras.

Si está usando copias anteriores de Raspian, entonces necesita usar modprobe. Por ejemplo: Sudo modprobe i2c_bcm2708 baudrate = 50000 ... esto ajustará la velocidad del bus a 50 kHz
Si está utilizando las últimas compilaciones de Raspian, entonces utiliza el árbol de dispositivos y tiene que agregar elementos para configurar el BCM2708 en el archivo config.txt.
Por ejemplo, agregue estas líneas a config.txt:
dtparam = i2c1 = on (esto ya debería estar allí ya que I2C está habilitado) dtparam = i2c_arm_baudrate = 50000
.... esto bajará el I2C a 50 kHz
Todo lo que necesita saber acerca del control de configuración a través del árbol de dispositivos es aquí .

El I2C funcionará hasta 10 kHz sin ningún problema y puede llegar a 1 Mhz sin problemas ... aunque no podría conducir su cable largo a estas velocidades.

    
respondido por el Jack Creasey

Lea otras preguntas en las etiquetas

Bus paralelo de 27 bits a 65 MHz: ¿Usar 3.3V o 1.8V? Prueba de generador de media tensión