---
title: Using I2C host for SMBus commands
---

The I2C host can generate all the SMBus commands listed in the Rev 3.0 SMBus specification.

### Quick Command

The Quick command is a rare case where the Start and Stop properties are both set on the same write to the I2C FIFO, along with an address and single bit of data.

![Quick Command](01-Quick.svg)

### Simple commands

The simple SMBus commands are essentially single byte I2C transactions.
A Start is attached to an address with either the write or read flag.
There follows a single byte transfer in the appropriate direction with the Stop flag attached.

![Send Byte](02-SendByte.svg)
![Receive Byte](03-ReceiveByte.svg)


### Writes

The set of SMBus Writes (Byte, Word, 32-bit and 64-bit) follow the address with a command byte and then the appropriate number of data bytes.

![Write Byte](04-WriteByte.svg)
![Write Word](04-WriteWord.svg)
![Write 32-bit](10-Write32.svg)
![Write 64-bit](12-Write64.svg)

Host Notify is the same as Write Word but uses special addresses (and would come from a device).

![Host Notify](09-HostNotify.svg)

### Reads

The SMBus read commands start by writing a command byte then have a repeated start before the data transfer.
Note that read entry in the I2C fifo includes the data length, so only one entry is needed for all the cases, and it will always include the Stop.
The data received from the device is read from the RDATA FIFO.
The interface will automatically NACK the last byte in the transfer.

![Read Byte](05-ReadByte.svg)
![Read Word](05-ReadWord.svg)
![Read 32-bit](11-Read32.svg)
![Read 64-bit](13-Read64.svg)

### Process Call

The SMBus Process Call consists of a command and two bytes transferred in each direction.
As with the Reads there is a repeated start before the transfer from the device.
Note that in the write direction each byte is written to the fifo, and for the read direction just the single entry with the 2 byte transfer size.

![Process Call](06-ProcessCall.svg)

### Block Write

A Block Write is a potentially longer write that includes the command and an explicit length byte (N) before N bytes of data.
Since this may transfer up to 255 bytes the driver code is likely to need to manage the I2C fifo becoming full.

![Block Write](07-BlockWrite.svg)

### Block Read

A Block Read is a potentially longer read where the length of data being transferred is reported by the device during the transaction.
This requires the transaction to be split into two stages.
The first part of the transaction is similar to a Byte Read, except instead of the Stop flag the RCont flag is set on the one-byte read.
The RCont flag causes the interface to read the byte and generate an ACK to keep the transaction alive.
Since the I2C fifo will be empty at this point the interface will extend the clock low time.
The driver then needs to read the value (N) from the RDATA fifo to know the size of the rest of the transaction and write the I2C fifo with N and the Read and Stop flags set.
The transaction now completes with N bytes read from the device.
If the RDATA fifo fills then the clock will again be stretched until there is space for more data.

![Block Read](07-BlockRead.svg)

### Block Write Read Process Call

The most complex transaction combines a block write and a block read.
(Note that there may be a different number of bytes transferred in each direction despite the same N being shown in the diagrams below and SMBus specification.)
This has the same split character as Block Read.

![Block Write Read Process Call](08-BlockWrRdPCall.svg)