I know that SMBus refers to the System Management Bus with specs found at http://www.smbus.org. This post may come across as pedantic even though that's not my normal style, but I'm wondering how the SMBus Class in the ECMA-419 spec relates to the standard and I believe this does need clarification. I normally don't care too much about such details, but I'm trying to wrap my mind around atomicity and the proposed async modes of the I2C and SMBus classes and the questions about "what is SMBus?" is related to that but I thought I'd split it out.
Anyway, the SMBus standard has sections about the physical layer, sections about the protocol, and in there a section about address resolution (and there's probably some more that I'm ignoring). Some observations I've made:
The ECMA-419 SMBus class supports only a subset of the SMBus protocol, e.g. the read/write 32/64-bit portions are not included and the address resolution protocol is neither, and a few more pieces are also missing.
SMBus specifies timeouts on bus transactions, limiting the duration of clock stretching, for example, but I do not see a mention of timeout in the ECMA-419 spec or the ability to specify it in the SMBus constructor. I believe that in order to implement the SMBus spec the controller must implement the timeouts and perform specific actions if a timeout occurs.
The SMBus protocol requires devices to ack the address byte (i.e. first byte transferred in a bus transaction) however the I2C spec does not (the SMBus spec claims this, I have not gone back to double-check). On an SMBus, if the device doesn't ack its address then there is a problem and the transaction is to be aborted. On an I2C bus, apparently not.
The SMBus protocol for reading registers uses a repeated-start condition, but after re-reading the spec multiple times I can't actually tell whether a repeated-start is required or whether it's just the typical usage and the controller may use a stop followed by a start instead. Also, it is not clear whether the controller may issue a repeated-start for another device and thereafter continue with the second portion of the original operation. (This is related to atomicity and async.) The I2C spec is pretty clear about the fact that repeated start is functionally the same as a stop plus a start.
There are many popular devices that use an "SMBus-like protocol" for reading/writing registers but are not SMBus devices. For example, the BME280 and the Si7021 both use what surely looks like the SMBus protocol but I cannot find the term "SMBus" in either's datasheet. I don't know whether this is due to royalties or other legal requirements, whether it is due to not following the physical spec (which is a very minor concern here), or perhaps not meeting the timeout requirements (e.g. the Si7021 can have very long clock stretching), or some other difference I haven't discerned. The datasheets of neither of these two devices provides a clear indication whether or how they deviate from the SMBus network layer protocol spec.
I have written several dozen drivers for I2C devices (not using Javascript) and a majority uses SMBus-like reading and writing of registers, but I have never used an "SMBus" library or bus driver in the process, I have always used I2C. If I want to use ECMA-419 async then for devices that use an "SMBus-like protocol" but that do not state anywhere that they are SMBus compliant I may have to use the SMBus class in order to get atomic read-register operations, but it leaves me wondering whether that's a correct use of the SMBus class or whether I may run into incompatibility issues.
I suspect that the intent of the ECMA-419 SMBus class is to support the very common "SMBus-like protocol" (maybe "SMBus network layer bus protocols" is the correct term looking at the spec?) and that "details" such as timeout and address ack are handled "leniently". Anyway, I do believe that ECMA-419 should be a little more precise about what the SMBus class refers to, even if that is a bit pedantic.
(I'm actually wondering whether it would not be better to fold the SMBus-like register access methods into the I2C class and side-step the whole issue. At least that's what some other libraries do.)
I know that SMBus refers to the System Management Bus with specs found at http://www.smbus.org. This post may come across as pedantic even though that's not my normal style, but I'm wondering how the SMBus Class in the ECMA-419 spec relates to the standard and I believe this does need clarification. I normally don't care too much about such details, but I'm trying to wrap my mind around atomicity and the proposed async modes of the I2C and SMBus classes and the questions about "what is SMBus?" is related to that but I thought I'd split it out.
Anyway, the SMBus standard has sections about the physical layer, sections about the protocol, and in there a section about address resolution (and there's probably some more that I'm ignoring). Some observations I've made:
I have written several dozen drivers for I2C devices (not using Javascript) and a majority uses SMBus-like reading and writing of registers, but I have never used an "SMBus" library or bus driver in the process, I have always used I2C. If I want to use ECMA-419 async then for devices that use an "SMBus-like protocol" but that do not state anywhere that they are SMBus compliant I may have to use the SMBus class in order to get atomic read-register operations, but it leaves me wondering whether that's a correct use of the SMBus class or whether I may run into incompatibility issues.
I suspect that the intent of the ECMA-419 SMBus class is to support the very common "SMBus-like protocol" (maybe "SMBus network layer bus protocols" is the correct term looking at the spec?) and that "details" such as timeout and address ack are handled "leniently". Anyway, I do believe that ECMA-419 should be a little more precise about what the SMBus class refers to, even if that is a bit pedantic.
(I'm actually wondering whether it would not be better to fold the SMBus-like register access methods into the I2C class and side-step the whole issue. At least that's what some other libraries do.)