Yes, this is right. but if you want to follow the standard (which I =
would
like to do) there is some differences in voltage levels, timing etc.

I have included a description of the differences in timing.

The differences aren't too big so it wouldn't be a big task to change =
the
I2C code to match the specifications, but as everyone else (or perhaps =
I'm
just lazy) I try to make things as simple as possible and took a chance =
that
someone would know about some existing application with the code ready =
made.

Tomas

Timing specification differences between SMBus and I2C
There are differences in the timing specifications between I2C and =
SMBus. As
in the case of DC
specification, proper understanding of the parameters is needed in order =
to
combine reliably I2C with
SMBus devices.
SMBus defines a minimum bus clock frequency FSMB of 10 KHz. I2C does not
specify any minimum bus
frequency. Besides maintaining effective bus throughput, this SMBus
specification parameter can be used
as a simple way to detect a bus idle condition (in addition or in lieu =
of
detecting each STOP condition) as
well as to implement bit timeout.
SMBus defines a data hold time, the time during which SMBDAT must remain
valid from the falling edge
of SMBCLK, of 300 nS. I2C defines this hold time as zero.
Maximum clock frequency for SMBus is defined at 100 KHz. I2C provides =
two
modes of operation. The
STANDARD MODE up to 100 KHz and the FAST-MODE up to 400 KHz.
SMBus defines a clock low time-out, TTIMEOUT of 35 ms. I2C does not =
specify
any timeout limit.
SMBus specifies TLOW: SEXT as the cumulative clock low extend time for a
slave device. I2C does not
have a similar specification.
SMBus specifies TLOW: MEXT as the cumulative clock low extend time for a
master device. Again I2C
does not have a similar specification.
SMBus defines both rise and fall time of bus signals. I2C does not.
The SMBus time-out specifications do not preclude I2C devices =
co-operating
reliably on the SMBus. It is
the responsibility of the designer to ensure that I2C devices are not =
going
to violate these bus timing
parameters.

Other differences

ACK and NACK usage

There are the following differences in the use of the NACK bus =
signaling:
In I2C, a slave receiver is allowed not to acknowledge the slave =
address, if
for example is 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.)
I2C specifies that a slave device, although it may acknowledge its own
address, some time later in the
transfer it may decide that it cannot receive any more data bytes. The =
I2C
specifies, that the device may
indicate this by generating the not acknowledge on the first byte to =
follow.
Besides to indicate a slave device busy condition, SMBus is using the =
NACK
mechanism also to indicate
the reception of an invalid command or data. 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.




> For most intents and purposes SMbus and I2C are synonymous, and there =
is a
> ton of I2C code out there. TTYL
>
> > -----Original Message-----
> > From: pic microcontroller discussion list
> > [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Tomas Hansson
> > Sent: Thursday, February 14, 2002 06:37
> > To: PICLIST@MITVMA.MIT.EDU
> > Subject: [PIC]: SMBus ?
> >
> >
> > Hi there,
> >
> > I am working on project where I need to connect a PIC to a SMBus.
> > Does anyone out there have any experience in this. I know that
> > Microchip has an application note about it but the code for that
> > application is in C and I would prefer assembler.
> >
> > Does anyone have any idea where I could find an application in
> > asm for this ?
> >
> >
> > /Tomas
> >
> > --
> > http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body
> >
> >
> >
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads