Ahora tengo diez sensores de aceleración (ADXL345) conectados a un solo PIC16F887 usando I2C. El problema es que el ADXL345 sólo tiene 2 direcciones I2C esclavas configurables. Así que trae conflicto.
Sé que NXP proporciona un multiplexor I2C que soluciona este tipo de problema, pero tengo diez sensores. Así que parece que no es de ayuda.
Diez ADXLs serían 5 pares con el pin ALT_ADDRESS.
NXP hace interruptores I2C de 2, 4 y 8 canales, por lo que podrías usar un interruptor de 8 canales, lo que te permitiría hasta 16 ADXLs.
También puedes desarrollar tu propio interruptor en un ASIC o CPLD.
Una tercera opción sería prescindir de I2C y utilizar la interfaz SPI en el ADXL. Esto significaría más pines del PIC para seleccionar los 10 chips, pero si se combina con un decodificador de 4 a 16 se puede seleccionar cualquiera de ellos para comunicarse en el bus SPI con sólo 4 pines del PIC (permitiría hasta 15 ADXLs si se reserva una dirección para "ningún chip seleccionado").
O pon unos registros de desplazamiento en el mismo bus SPI que utilizas para controlar los sensores. Los registros de desplazamiento controlan las líneas de selección de los sensores, de modo que sólo tienes una línea de selección desde tu MCU a todos los registros de desplazamiento. Conecta los shift regs en serie entre sí y con tu matriz de sensores. Una lectura cuidadosa de los diagramas de sincronización debería revelar una forma de hacer que esto funcione, con la siguiente dirección del sensor inherentemente incluida en el protocolo. Eso te daría tantos sensores como necesitas con sólo 4 líneas de la MCU. Yo separaría todo ese código en su propia sección para que sea más fácil de mantener.
Utilicé un esquema similar para utilizar un número ilimitado de E/S digitales vía SPI. Utilicé el único chip select para controlar todas las entradas de carga/sujeción de los registros de desplazamiento de entrada/salida para poder capturar todo a la vez y mostrar todo a la vez, sin verlos desplazarse. Tuve que enviar un byte entero sólo para tener un reloj disponible para cargar las entradas, así que terminé con un byte ficticio que se sale del final de la cadena de salida. Pero funciona, y estoy contento con ello. IIRC, los cambiadores que utilicé ni siquiera estaban anunciados para usar SPI, pero la hoja de datos de los bits se acercaba lo suficiente como para funcionar de todos modos.
@AaronD Cierto - Ya he utilizado expansores IO MCP23S17 para manejar otros dispositivos en el mismo bus.
Mientras que probablemente sería posible hacer algún hardware adicional que sólo permitiera que un dispositivo I2C viera cada transacción, hacer eso sin depender de ningún comportamiento indocumentado puede ser más trabajoso que usar SPI. Podría ser posible usar un selector de uno de diez para manejar los cables de selección de dirección en los dispositivos y sólo usar una dirección cuando se habla con cualquiera de los dispositivos [el selector de uno de diez controlaría qué dispositivo respondería a esa dirección], pero no vi nada en la hoja de datos que indicara exactamente cuándo el dispositivo muestrearía ese pin. Aún así, si quieres usar I2C, y puedes encontrar algo que documente que el pin de dirección puede ser usado de esa manera, o estás dispuesto a apostar que si puede ser usado de esa manera en los chips de hoy, seguirá siendo válido en futuras ejecuciones, esa podría ser la manera más limpia de hacerlo.
I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
2 votos
¿Consideraste la posibilidad de cambiar el bit de la interfaz I2C? No es tan difícil, pero será más lento y utilizará más recursos (CPU, Flash).
0 votos
Pensé en el golpeo de bits, pero lo dejé por no ser adecuado al requisito de velocidad mínima.