Protocolos I²C, SPI, CAN y el modelo OSI

¿Hay una referencia o cuál es la explicación de que I²C y SPI sean solo protocolos de capa física en el modelo OSI (sé que este modelo es para comunicación y tal vez no exactamente para buses integrados) o el protocolo de capa de enlace de datos está definido dentro? ¿a ellos?

¿Qué tal el protocolo CAN?

Esta pregunta parece estar fuera de tema porque no se trata de diseño electrónico.
Hola, quería cuestionarlo en stackoverflow, pero creo que la gente dirá que no es una pregunta de programación a pesar de que las etiquetas SPI e I2C se encuentran en ambos grupos. Puede ver mi última pregunta sobre el protocolo UART en stackoverflow y los elogios y puntos negativos que obtuve porque la gente cree que la pregunta debería hacerse en electronics.stackexchange.com y es por eso que abrí esta cuenta ayer.
Los protocolos de hardware de bajo nivel como SPI, IIC y CAN son relevantes para la ingeniería eléctrica, por lo que creo que este es el tema aquí, incluso si la pregunta específica es bastante teórica y su respuesta no tiene sentido en un sentido práctico.

Respuestas (3)

Ambos. La pila OSI es tan abstracta que es muy probable que prácticamente cualquier protocolo utilizado en la industria contenga consideraciones prácticas que implementen efectivamente múltiples niveles.

si estos protocolos tienen su definición de capa de enlace de datos dentro, significa que no soy yo quien define cómo se llena el marco (combinación de dirección, datos y comandos), ya está definido en SPI o I2C que, por ejemplo, los primeros 3 bits son bits de dirección, luego tenemos 4 bits de datos, luego nuevamente tenemos 2 bits de dirección, etc. pero en ninguna parte de la red encontré esta información. ¿Podría explicar más?
Estos protocolos de la industria casi siempre contienen definiciones de múltiples capas, si no explícitamente, implícitamente, por su suposición de que estos formatos de bits se utilizarán de cierta manera. La verdadera prueba de si algo como un formato de bits es solo una capa de datos sería mostrar que múltiples protocolos aislados usan la misma capa de datos, sin modificaciones. Este rara vez es el caso, ya que cada protocolo tiene necesidades específicas que comienzan a filtrarse en las capas de datos y físicas.

I2C opera en términos de transacciones definidas, con arbitraje y protocolo de enlace, por lo que puede considerarse razonablemente como una capa de enlace de datos además de una capa física, aunque no necesariamente se ajusta muy bien al patrón OSI. SPI no es realmente un estándar sino un término que se usa para describir una amplia variedad de diseños de comunicaciones. Como tal, apenas califica como un protocolo de capa física.

Tanto con SPI como con I2C, uno puede avanzar a capas superiores si restringe su enfoque a estilos particulares de chip. Por ejemplo, hay un estándar común para EEPROM I2C de hasta 2 Kbytes, y otro que sería aplicable a EEPROM I2C de hasta 512 Kbytes (aunque no he visto dispositivos tan grandes que lo usen). Dichos estándares no solo definen cómo realizar transacciones en el chip, sino que también especifican qué hará el chip con los datos que contiene.

Nada tan explícito. Puede intentar definir ciertas partes del protocolo I²C para diferentes capas OSI, pero la forma en que las define y cómo las define otra persona no coincidiría (pregunte a cinco ingenieros y obtenga siete respuestas diferentes).

Mi opinión es que la capa física es la más simple. I²C requiere dos líneas de bus de colector abierto, vinculadas a V CC con resistencias pull-up de valor X, limitadas a Y pF de capacitancia (donde X e Y se calculan en función de la frecuencia deseada del bus I²C). Los dispositivos I²C deben liberar la línea cuando están inactivos y solo bajar la línea cuando se comunican activamente. Esa es la capa física.

La capa de datos es un poco más compleja. Los maestros I²C, especialmente en un sistema multimaestro, al intentar comunicarse, deben verificar si las líneas están bajas, si están libres, intentar la comunicación y verificar la línea nuevamente. Si en algún momento es inesperadamente bajo, siga los protocolos de arbitraje . Los esclavos I²C (y maestros) también pueden implementar la ampliación del reloj , controlando la comunicación evitando los pulsos del reloj.

El direccionamiento físico y lógico se encuentra tanto en la capa de enlace de datos como en la capa de red, si incluye expansores de bus/multiplexores/búferes/IC de intercambio en caliente. I²C realmente no tiene una topología de red o un equivalente de IP , y los expansores de bus son una solución pirateada sin especificación que han ideado los fabricantes.

entonces, cuando compro un microcontrolador que tiene una interfaz de comunicación I²C y quiero conectarlo a un periférico integrado que también tiene una interfaz I²C, a través de cables en serie, puedo seguir la definición del circuito I²c (capa física), creando dos líneas con las resistencias anteriores , luego defina mi marco (dirección, datos, comando) con casi total libertad, luego defina algún tipo de lógica que haga arbitraje, protocolo de enlace, ... (materiales de capa de enlace de datos).
Al leer su explicación, me parece que estoy preguntando: ¿Cómo definir un modelo OSI para un circuito RLC paralelo? ¿Mi pregunta se parece a eso? gracias
@Michelle no, no libertad total. Los dispositivos i2c esperan que el "marco" sea de inicio, dirección de 7 bits + 1 bit de lectura/escritura, n bytes de datos, parada (o reinicio).
Protocolos I²C, SPI, CAN y el modelo OSI
RespuestasAquíPolítica de privacidad1y, 7v