Bus de gestión del sistema

Al mezclar dispositivos, la especificación I²C define los niveles de entrada como el 30 % y el 70 % de la tensión de alimentación V _DD , ^{[ 5 ] : 9} que puede ser 5  V, 3,3  V o cualquier otro valor. En lugar de relacionar los niveles de entrada del bus con V _DD , SMBus los define como fijos. SMBus 2.0 define V _IL,max en 0,8  V y V _IH,min en 2,1  V, y admite un V _DD que va de 3 a 5  V, mientras que en SMBus 3.0, los niveles se definen en 0,8 y 1,35  V, con un V _DD que va de 1,8 a 5  V. ^{[ 4 ]}

SMBus 2.0 define una clase de "alta potencia" que incluye una corriente de sumidero de 4 mA que no puede ser controlada por chips I²C a menos que la resistencia pull-up tenga un tamaño acorde a los niveles del bus I²C.

Los dispositivos NXP tienen un conjunto de características eléctricas de mayor potencia que SMBus 1.0. La principal diferencia radica en la capacidad de absorción de corriente, con V _OL = 0,4  V.

• SMBus de baja potencia = 350 μA
• SMBus de alta potencia = 4 mA
• Bus I²C = 3 mA

Los dispositivos SMBus de "alta potencia" y los dispositivos I²C-bus funcionarán juntos si la resistencia pull-up tiene un tamaño de 3  mA.

La frecuencia de reloj de SMBus está definida entre 10 y 100  kHz, mientras que la de I²C puede ser de 0 a 100  kHz, de 0 a 400  kHz, de 0 a 1  MHz y de 0 a 3,4  MHz, según el modo. Esto significa que un bus I²C que funcione a menos de 10  kHz no será compatible con SMBus, ya que los dispositivos SMBus podrían agotar el tiempo de espera. Sin embargo, muchos dispositivos SMBus admiten frecuencias más bajas.

SMBus 3.0 añade velocidades de bus de 400  kHz y 1  MHz.

• SMBus define un tiempo de espera bajo para el reloj, TIMEOUT, de 35  ms. I²C no especifica ningún límite de tiempo de espera.
• SMBus especifica T _LOW:SEXT como el tiempo acumulativo de extensión baja del reloj para un dispositivo esclavo. I²C no tiene una especificación similar.
• SMBus especifica T _LOW:MEXT como el tiempo acumulativo de extensión baja del reloj para un dispositivo maestro. Nuevamente, I²C no tiene una especificación similar.
• SMBus define tanto el tiempo de subida como el de bajada de las señales del bus. I²C no lo hace.
• Las especificaciones de tiempo de espera del SMBus no impiden que los dispositivos I²C cooperen de forma fiable en el SMBus. Es responsabilidad del diseñador asegurarse de que los dispositivos I²C no infrinjan estos parámetros de temporización del bus.

Existen las siguientes diferencias en el uso de la señalización de bus NACK: En I²C, un receptor esclavo puede no confirmar la dirección del esclavo si, por ejemplo, no puede recibir porque está realizando alguna tarea en tiempo real. SMBus requiere que los dispositivos confirmen siempre su propia dirección, como mecanismo para detectar la presencia de un dispositivo extraíble en el bus (batería, estación de acoplamiento, etc.).

El estándar I²C especifica que un dispositivo esclavo, aunque reconozca su propia dirección, puede decidir, tiempo después durante la transferencia, que no puede recibir más bytes de datos. I²C indica que el dispositivo puede comunicar esto generando la señal de no reconocimiento en el primer byte siguiente.

Además de indicar que un dispositivo esclavo está ocupado, SMBus también utiliza el mecanismo NACK para indicar la recepción de un comando o dato no válido. Dado que esta situación puede ocurrir en el último byte de la transferencia, es necesario que los dispositivos SMBus puedan generar el NACK tras la transferencia de cada byte y antes de que finalice la transacción. Esto es importante porque SMBus no proporciona ninguna otra señalización de reenvío. Esta diferencia en el uso de la señalización NACK tiene implicaciones en la implementación específica del puerto SMBus, especialmente en dispositivos que manejan datos críticos del sistema, como el host SMBus y los componentes SBS.

Cada transacción de mensajes en SMBus sigue el formato de uno de los protocolos SMBus definidos. Los protocolos SMBus son un subconjunto de los formatos de transferencia de datos definidos en las especificaciones I²C. Los dispositivos I²C que se pueden acceder mediante uno de los protocolos SMBus son compatibles con las especificaciones SMBus. Los dispositivos I²C que no cumplen con estos protocolos no se pueden acceder mediante los métodos estándar definidos en las especificaciones SMBus y ACPI ( Advanced Configuration and Power Interface ).

El SMBus utiliza hardware I²C y direccionamiento por hardware I²C, pero añade software de segundo nivel para la creación de sistemas especiales. En particular, sus especificaciones incluyen un Protocolo de Resolución de Direcciones (DRP) que permite la asignación dinámica de direcciones. La reconfiguración dinámica del hardware y el software permite conectar y usar los dispositivos del bus de forma inmediata, sin reiniciar el sistema. Los dispositivos se reconocen automáticamente y se les asignan direcciones únicas. Esta ventaja se traduce en una interfaz de usuario plug-and-play. En ambos protocolos se establece una distinción muy útil entre el host del sistema y los demás dispositivos, que pueden tener nombres y funciones de maestro o esclavo.

En el contexto de las ranuras PCI Express de la placa base , la especificación electromecánica PCIe espera que se proporcione ARP para los pines SMBus. Sin embargo, dado que ARP está marcado como "opcional" en la especificación SMBus, generalmente no se implementa. ^{[ 7 ]}

SMBus cuenta con una función de tiempo de espera que reinicia los dispositivos si una comunicación tarda demasiado. Esto explica la frecuencia mínima de reloj de 10  kHz para evitar el bloqueo del bus. I²C puede ser un bus de CC, lo que significa que un dispositivo esclavo prolonga el reloj maestro al realizar alguna rutina mientras el maestro accede a él. Esto notifica al maestro que el esclavo está ocupado, pero no desea perder la comunicación. El dispositivo esclavo permitirá continuar una vez que su tarea esté completa. El protocolo del bus I²C no tiene límite en cuanto a la duración de este retardo, mientras que en un sistema SMBus estaría limitado a 35 ms. El protocolo SMBus simplemente asume que si algo tarda demasiado, significa que hay un problema en el bus y que todos los dispositivos deben reiniciarse para salir de este modo. Por lo tanto, los dispositivos esclavos no pueden mantener el reloj en BAJO durante demasiado tiempo.

SMBus 1.1 y versiones posteriores definen la comprobación de errores de paquete ( PEC ) opcional. En este modo, se añade un byte PEC (código de error de paquete) al final de cada transacción. El byte se calcula como una suma de comprobación CRC-8 , calculada sobre todo el mensaje, incluyendo la dirección y el bit de lectura/escritura. El polinomio utilizado es x⁸ ⁺ x² ⁺ x + 1 (el algoritmo CRC-8- ATM HEC , inicializado a cero). ^{[ 8 ] [ 9 ] [ 10 ]}

El SMBus cuenta con una señal de interrupción compartida opcional adicional llamada SMBALERT#, que los dispositivos esclavos pueden usar para indicarle al host que consulte a sus esclavos sobre eventos de interés. SMBus también define un protocolo menos común, el "Host Notify Protocol", que proporciona notificaciones similares pero transmite más datos y se basa en el modo multi-maestro de I²C.