Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
System Management Bus
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===Protocols=== ====ACK and NACK usage==== There are the following differences in the use of the NACK bus signaling: In I²C, a slave receiver is allowed to not acknowledge the slave address, if for example it's unable to receive because it's performing some real time task. SMBus requires devices to acknowledge their own address always, as a mechanism to detect a removable device's presence on the bus (battery, docking station, etc.) I²C specifies that a slave device, although it may acknowledge its own address, may decide, some time later in the transfer, that it cannot receive any more data bytes. I²C specifies that the device may indicate this by generating the not acknowledge on the first byte to follow. Other than to indicate a slave's device-busy condition, SMBus also uses the NACK mechanism to indicate the reception of an invalid command or datum. 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. This difference in the use of the NACK signaling has implications on the specific implementation of the SMBus port, especially in devices that handle critical system data such as the SMBus host and the SBS components. ====SMBus protocols==== 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 can be accessed through one of the SMBus protocols are compatible with the SMBus specifications. I²C devices that do not adhere to these protocols cannot be accessed by standard methods as defined in the SMBus and [[Advanced Configuration and Power Interface]] (ACPI) specifications. ====Address Resolution Protocol==== The SMBus uses I²C hardware and I²C hardware addressing, but adds second-level software for building special systems. In particular its specifications include an Address Resolution Protocol that can make dynamic address allocations. Dynamic reconfiguration of the hardware and software allow bus devices to be ‘hot-plugged’ and used immediately, without restarting the system. The devices are recognized automatically and assigned unique addresses. This advantage results in a plug-and-play user interface. In both those protocols there is a very useful distinction made between a System Host and all the other devices in the system that can have the names and functions of masters or slaves. In the context of motherboard [[PCI Express]] slots, the PCIe Electromechanical Specification expects ARP to be provided for the SMBus pins. However, because ARP is marked "optional" in the SMBus specification, it's commonly left unimplemented.<ref name=pci-2023/> ====Time-out feature==== SMBus has a time-out feature which resets devices if a communication takes too long. This explains the minimum clock frequency of 10 kHz to prevent locking up the bus. I²C can be a ‘DC’ bus, meaning that a slave device stretches the master clock when performing some routine while the master is accessing it. This will notify to the master that the slave is busy but does not want to lose the communication. The slave device will allow continuation after its task is complete. 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. The 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. Slave devices are not then allowed to hold the clock LOW too long. ====Packet Error Checking==== SMBus 1.1 and later define optional '''Packet Error Checking''' ('''PEC'''). In that mode, a PEC (packet error code) byte is appended at the end of each transaction. The byte is calculated as [[CRC-8]] [[checksum]], calculated over the entire message including the address and read/write bit. The polynomial used is x<sup>8</sup>+x<sup>2</sup>+x+1 (the CRC-8-[[Asynchronous Transfer Mode|ATM]] [[CRC-based framing|HEC]] algorithm, initialized to zero).<ref>{{cite web|url=http://sbs-forum.org/marcom/winter01/Designing%20with%20SMBus%202.pdf|title=Designing with SMBus 2.0|website=Sbs-forum.org|access-date=27 October 2017}}</ref><ref>{{cite web|url=http://www.smbus.org/faq/crc8Applet.htm|title=CRC-8 Calculator|website=Smbus.org|access-date=27 October 2017}}</ref><ref>{{cite web|url=http://www.picbasic.co.uk/forum/showthread.php?t=6231|title=CRC-8 for SMBus|website=Picbasic.co.uk|access-date=27 October 2017}}</ref> ====SMBALERT#==== 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 also defines a less common "Host Notify Protocol", providing similar notifications but passing more data and building on the I²C multi-master mode.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)