The SMBus was defined by Intel in 1995.

The SMBus clock is defined from 10 – 100 kHz while I²C can be 0 – 100 kHz, 0 – 400 kHz, 0 – 1 MHz and 0 – 3. 4 MHz, depending on the mode.

Each message transaction on SMBus follows the format of one of the defined SMBus protocols.

The SMBus protocols are a subset of the data transfer formats defined in the I²C specifications.

I²C devices that do not adhere to these protocols cannot be accessed by standard methods as defined in the SMBus and ACPI specifications.

( Accordingly, these EEPROMs aren't usable by pure SMBus hosts, which only support single byte commands or addresses.

( That data transfer part of the protocol also makes trouble for SMBus, since the data bytes are not preceded by a count and more than 32 bytes can be transferred at once.

SMBus has a ‘ High Power ’ version 2. 0 that includes a 4 mA sink current that cannot be driven by I²C chips unless the pull-up resistor is sized to I²C-bus levels.

The SMBus has an extra optional shared interrupt signal called SMBALERT #, which can be used by slaves to tell the host to ask its slaves about events of interest.

SMBus devices are supported by FreeBSD, OpenBSD, NetBSD, DragonFly BSD, Linux, Windows 2000 and newer.

One purpose of SMBus is to promote robustness and interoperability.

SMBus is restricted to nine of those structures, such as read word N and write word N, involving a single slave.

In this case, the host performs a 1-byte read from the reserved " SMBus Alert Response Address " ( 0x0c ), which is a kind of broadcast address.

The SMBus is used to communicate with other devices on the motherboard ( e. g., system temperature sensors, fan controllers ).

The System Management Bus ( abbreviated to SMBus or SMB ) is a single-ended simple two-wire bus for the purpose of lightweight communication.

The SMBus is generally not user configurable or accessible.

SMBus is used as an interconnect in several platform management standards including: ASF, DASH, IPMI.

While SMBus is derived from I²C, there are several major differences between the specifications of the two busses in the areas of electricals, timing, protocols and operating modes.

SMBus ‘ high power ’ devices and I²C-bus devices will work together if the pull-up resistor is sized for 3 mA.

Since such a condition may occur on the last byte of the transfer, it is required that SMBus devices have the ability to generate the not acknowledge after the transfer of each byte and before the completion of the transaction.

This is important because SMBus does not provide any other resend signaling.

There is no limit in the I²C-bus protocol as to how long this delay can be, whereas for an SMBus system, it would be limited to 35 ms.

SMBus protocol just assumes that if something takes too long, then it means that there is a problem on the bus and that all devices must reset in order to clear this mode.

Using romcc, it is relatively easy to make SMBus accesses to the SPD ROMs of the DRAM DIMMs, that allows the RAM to be used.

Communication is carried over an SMBus two-wire communication bus.

The SPD EEPROM is accessed using SMBus, a variant of the I²C protocol.

Not only can the communication lines be shared among 8 memory modules, the same SMBus is commonly used on motherboards for system health monitoring tasks such as reading power supply voltages, CPU temperatures, and fan speeds.

Accordingly, modern I²C systems incorporate policies and rules from SMBus, sometimes supporting both I²C and SMBus with minimal re-configuration required.

With only a few exceptions, neither I²C nor SMBus define message semantics, such as the meaning of data bytes in messages.

Those exceptions include messages addressed to the I²C general call address ( 0x00 ) or to the SMBus Alert Response Address ; and messages involved in the SMBus Address Resolution Protocol ( ARP ) for dynamic address allocation and management.

I²C EEPROMs smaller than 32 kbits, such as 2 kbit 24c02 ones, are often used on SMBus with inefficient single byte data transfers.

While I²C only arbitrates between masters, SMBus uses arbitration in three additional contexts, where multiple slaves respond to the master, and one gets its message through.

When mixing devices, the I²C specification defines the V < sub > DD </ sub > to be 5. 0 V ± 10 % and the fixed input levels to be 1. 5 and 3. 0 V. Instead of relating the bus input levels to V < sub > DD </ sub >, SMBus defines them to be fixed at 0. 8 and 2. 1 V. This SMBus specification allows for bus implementations with V < sub > DD </ sub > ranging from 3 to 5 V.

This means that an I²C bus running at less than 10 kHz will not be SMBus compliant since the SMBus devices may time out.

* SMBus defines a clock low time-out, TTIMEOUT of 35 ms. I²C does not specify any timeout limit.

* The SMBus time-out specifications do not preclude I²C devices co-operating reliably on the SMBus.

I²C devices that can be accessed through one of the SMBus protocols are compatible with the SMBus specifications.

The SMBus uses I²C hardware and I²C hardware addressing, but adds second-level software for building special systems.

* SMBus defines both rise and fall time of bus signals.

SMBus also defines a less common " Host Notify Protocol ", providing similar notifications but passing more data and building on the I²C multi-master mode.

PMBus extends SMBus with a Group protocol, allowing multiple such SMBus transactions to be sent in one combined message.

Most SMBus operations involve single byte commands.

( That's another incompatibility with SMBus: SMBus devices must always respond to their bus addresses.

To ensure a minimum bus throughput, SMBus places limits on how far clocks may be stretched.

It seizes the bus and writes a 3-byte message to the reserved " SMBus Host " address ( 0x08 ), passing its address and two bytes of data.

* SMBus.

PCI add-in cards may connect to a SMBus segment.