Hi Krzysztof, > > However, > > EEPROMs are also often found on SMBus busses, those controller only > > implement a subset of all possible I2C commands. > > You mean one can't drive clock and data lines at will, and the > controller (some hardware) does it instead, based on commands received > from the program (and, for example, the program interface is parallel, > not 2-wire serial). Right? Partly right. Actually, most SMBus controllers work the following way: you program a number of registers (typically SMBus transaction type, target chip address, target register address or command, and the data to send in the case of a write transaction), then you tell the chip to initiate the transaction. Then you poll for the transaction to be over (or use an interupt, but most our SMBus drivers use polling), and read the result in some register in the case of a read transaction. > But wait, even then does the controller really know anything about > I^2C commands? How would it differentiate between, say, 8-bit and > 16-bit reads? Or is it just an 8-bit EEPROM bus? No, it is still physically a 2-wire serial bus. The limitation is due to the fast that the SMBus controller knows of a limited number of transactions, such as Send Byte, Read Byte, Read Word etc. If the SMBus controller doesn't know of the SMBus command you want to use (in my case, I2C block read), then there is no way to do it, because we have no direct control over the serial line. > Does it do START and STOP automatically as well? Absolutely. The good thing is that SMBus masters are not CPU intensive, contrary to bit-banging I2C adapters. -- Jean Delvare
