asignación automática de direcciones i2c

Hice la pregunta aquí y alguien se ofreció a preguntar aquí para obtener mejores respuestas, así que aquí está:

Historia:

Decidí diseñar un circuito con algunos circuitos integrados periféricos. Aunque SPI puede lograr grandes velocidades de datos, debido a su arquitectura maestro-esclavo y al requisito de pin de selección de chip separado, decidí usar I2C debido a su diseño multimaestro y en serie real. (SPI no es un protocolo completamente serial, es más como un protocolo híbrido: puerto serial para intercambio de datos, puerto paralelo para líneas de selección de chips)

Problema:

He estado planeando agregar algunos adc, dac, gpio ic a un microcontrolador, pero estos módulos se producen con algunas direcciones esclavas disponibles. Los fabricantes están incorporando direcciones de esclavos en el hardware ic. ¡Qué mala idea! Entonces, me he enfrentado al problema de direccionamiento del protocolo i2c.

Algunos de los pines de asignación de direcciones actuales del ic (3 pines, lo que significa que no usaría más de 7 de ellos). Eso no es suficiente en mi caso.

Algunas personas ofrecen escaneo de direcciones de 0x00 a 0xff, pero este no es un buen enfoque porque es una pérdida de tiempo (creo). Alguien dice "Hay búfer i2c o i2c MUX que puede usar" o incluso otro microcontrolador para la traducción de direcciones (enfoque similar a NAT), pero ¿no elegimos y usamos i2c por simplicidad (como menos rutas a bordo, flexibilidad, etc.) en el primer ¿lugar?

Hay personas que tienen este problema de asignación de direcciones (por ejemplo, http://www.linkedin.com/groups/Methods-enumerating-I2C-slaves-autoassigning-4023060.S.113408032 )

Sugerencia:

La asignación automática de direcciones se podría hacer con un algoritmo algo así:

  1. Los componentes esclavos tendrían 2 bytes de memoria no volátil para mantener sus direcciones de forma permanente.
  2. Los esclavos tendrán una dirección predeterminada (por ejemplo, 0x01).
  3. En el encendido, si al esclavo no se le ha asignado una dirección diferente a la predeterminada, los esclavos se convertirán en maestros y solicitarán una dirección del host (por ejemplo, en la dirección 0x00).
  4. Nuestro nodo maestro real (microcontrolador, el host) (en este ejemplo, que tiene la dirección "0x00") actuará como un esclavo de forma natural, porque hay otro maestro en el bus y responderá (asignará) la siguiente dirección disponible al esclavo.
  5. La dirección 0x01 se reservará para la transmisión. El maestro puede usar esta dirección para hacer que los esclavos restablezcan sus direcciones asignadas.

Eso sería suficiente para la asignación automática de direcciones.

Sí, conozco SMbus. Tiene un protocolo de resolución automática de direcciones, pero tiene otras limitaciones (velocidad, tiempo de espera, etc.), lo que hace que no prefiera SMbus a I2C.

Este protocolo de asignación de direcciones puede ser opcional y podría activarse con un solo pin en el paquete ic. Por lo tanto, será compatible con versiones anteriores.

Pregunta:

Probablemente no soy la persona más inteligente del universo pero,

  1. ¿Existe un protocolo de asignación de direcciones que los proveedores ya implementen en i2c?
  2. si no, ¿qué tendría de malo este protocolo?
  3. si no pasa nada, ¿por qué no comienzan a implementar un protocolo como este?
¿Por qué no usar SPI para su aplicación? La transferencia de datos es más rápida y puede generar tantas señales de selección de chip como desee por muchos medios diferentes.
@ThePhotonbut weren't we choosing and using i2c for simplicity (like fewer routes on board, flexibility etc) in the first place?
@Passerby, la simplicidad y la flexibilidad suelen ser objetivos competitivos.
OP, tenga en cuenta que i2c tal como está, es un estándar patentado de 31 años (ahora vencido) con piezas oficiales "i2c", todas pasando por NXP/Phillips para la asignación de direcciones. La asignación automática de direcciones sería un gran cambio para i2c y no valdría la pena, ya que incluso smbus ARP no ha sido demasiado popular (o eso dice wiki)
@ThePhoton ¿Por qué no usar SPI para mi aplicación? Porque quiero reutilizar los dibujos de mi placa más adelante si necesito agregar otro ADC o GPIO. Si uso SPI, necesito dibujar una línea para el pin CS del nuevo componente. Además, aunque no es obligatorio en este momento, SPI no admite interrupciones. De hecho, dado que SPI es 10 veces más rápido que la mayoría de las implementaciones de I2C, la verificación cíclica de cambios es una opción sensata. Tal vez, como sugiere, debo usar SPI para el intercambio de datos y un microcontrolador de gama baja con su propia pila de protocolos en serie para las líneas de selección de chips...
...y solo SPI no permite circuitos modulares.
Eche un vistazo a la patente número US 6629172 B1 . Puede hacerlo con una E/S adicional.
Esta no es una gran pregunta ("genera discusión"), por lo que estoy comentando en lugar de responderla. Parece que ya sabe la respuesta a su pregunta: Sí, hay un protocolo de resolución de direcciones (ARP) SMBus estándar, pero simplemente no le gusta. Un problema importante con su concepto es que requiere que los esclavos tengan memoria no volátil. Eso es molesto para el diseñador y el proveedor de circuitos integrados y agrega un costo no trivial a cada parte, así como al diseño. Sin mirar, supongo que SMBus ARP no tiene tal requisito (digo esto sin saber nada sobre SMBus ARP).
¿Ha considerado "SPI en cadena" o (prácticamente lo mismo) "JTAG en cadena" , que solo requiere 4 pines en la CPU host? (No requieren más pines en el host sin importar cuántos periféricos se agreguen).

Respuestas (5)

Su problema se puede resolver con SMBus, que es lógicamente una extensión en I2C. SMBus admite un ARP, en el que puede detectar múltiples IC de la misma dirección y asignarles una dirección diferente. El proceso ARP básicamente lee un UUID (una identificación única por dispositivo; todos los diferentes dispositivos en el mismo lote tendrán un UUID diferente) de la dirección esclava (puede haber varios dispositivos en esta dirección esclava). Debido al proceso de arbitraje del bus I2C, solo un esclavo tendrá éxito a la vez y el maestro leerá correctamente su UUID. Luego, el maestro asigna una dirección única usando ese UUID como referencia. El proceso se repite hasta que todos los esclavos obtienen una dirección resuelta.

¿Existe un protocolo de asignación de direcciones que los proveedores ya implementen en i2c [?]

El protocolo actual es que cada fabricante de dispositivos escribe en NXP y solicita que se asigne una dirección para cada dispositivo que fabrican.

¿Qué estaría mal con este protocolo [propuesto] [?]

I2C a menudo se implementa en piezas de muy bajo costo.

Su propuesta requiere agregar memoria no volátil a partes que en su mayoría aún no la tienen.

La memoria no volátil generalmente requiere pasos de proceso especializados en la fabricación de circuitos integrados.

Agregar pasos de proceso aumenta el costo de un IC.

Entonces su propuesta no es compatible con mantener el bajo costo de muchas piezas I2C.

Además, su propuesta requiere que cada dispositivo maestro implemente algún protocolo para asignar las nuevas direcciones cuando se solicite. Esto agrega una complejidad que muchos usuarios pueden no querer.

si no pasa nada, ¿por qué no empiezan a implementar un protocolo como este?

Esta es una pregunta de marketing, no una pregunta de diseño electrónico.

Bien, entiendo que la memoria no volátil es un costo enorme. Aquí hay otra propuesta (compatible con versiones anteriores de nuevo):
@ceremcem, Stackexchange no está realmente diseñado para discusiones de ida y vuelta. Mejores lugares para ese tipo de interacción serían nuestro chat ( chat.stackexchange.com ) o los foros de discusión de allaboutcircuits.com o los foros "ECE" y "AskElectronics" en Reddit.
Hmm... Ok, puedo mover la pregunta de inmediato.

El problema de la asignación automática de direcciones parece ser un concepto utilizable en los casos en los que se fabrican dispositivos con microcontroladores de bajo costo.

Intentar colocar este protocolo en chips de gama baja como expansores de puertos, muxes, sensores de temperatura, eeproms y chips similares realmente impone más carga de diseño y área de silicio en el chip. Esto hace que los chips simples cuesten cada vez más y sean más difíciles de implementar en una implementación a nivel de plataforma.

Hacer que el maestro asigne una dirección, y algunas de las otras funciones que describe, simplemente no forman parte del estándar i2c. El resultado podría funcionar pero no sería i2c. Pierde muchos de los beneficios de usar un estándar.

Sin embargo , es parte del estándar smbus. Consulte la sección sobre Protocolo de resolución de direcciones.

Si realmente necesita esta capacidad de asignación de dirección por host en absolutamente todos los periféricos que necesita usar, debe agregar un microcontrolador de puerta a cada periférico e implementar SMBus ARP en ellos. Esos microcontroladores también traducen la dirección emitida en el bus a la dirección descubierta por el dispositivo al que está conectado.

Tenga en cuenta que esto hará que tenga que golpear I2C de alguna manera. Pero dado que ya está utilizando microcontroladores que traducen protocolos, también podría diseñar su propia pila de protocolos.

asignación automática de direcciones i2c
RespuestasAquíPolítica de privacidad1y, 0v