Searching \ for 'Detecting start and stop on I2C bus?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'Detecting start and stop on I2C bus?'.

Truncated match.
PICList Thread
'Detecting start and stop on I2C bus?'
1999\03\09@054159 by Quentin

My brain must be on vacation today.

I am writing I2C Slave software routines for a 12C508. The I2C Master is
a PIC that controls 2 other I2C devices (Philips) as well together with
the 12C508.
The 12C508 does what it has to do and then I want it to go back and wait
for it's address from the master and have a chat. If the master doesn't
get an Ack from the 12C508, then it carries on with its own thing, till
next time.
In other words, the 12C508 must synch with the I2C bus by detecting a
start (or stop?) condition on the bus, and then wait for its own address
to come up.

So how does the software distinguish between a start/stop and data
transfer on the bus?

I am working on this principle, when the 12C508 connects to the bus,
(excuse my funny logic):
1. If SDA and SLC is high, then the bus could either be in the wait
period between start and stop or master is sending a high bit. So look
if SLC goes low before SDA then it's data, otherwise if SDA goes low
before SCL, it's a start condition.
2. If SDA is low and SCL high, either a start has just occurred or a
stop is about to occur, or the master is sending a low bit. If SDA goes
high, before SCL goes low, then it's a stop, any other will be data.
3. If SCL low then SDA don't care, because the bus is in data, wait for

I'll carry on slaving ('scuse the pun) with this code, but if anybody
got some light on how to do this, please let me know.


1999\03\09@055647 by Tjaart van der Walt

Quentin wrote:
> Hi
> My brain must be on vacation today.
Hey, we live in a country where the health ministry staples
condoms to AIDS prevention pampflets! You can't beat *that*.

{Quote hidden}

You are looking for a high-low transition on the data line
*while the clock line is high*. You can look for the bits
on their own, but I prefer a more robust error-proof way.

The easiest (reliable) way is to keep on sampling the two pins.
Shift the bits into two bytes. The 'Clock' byte must be all
highs (0xFF), while the 'Data' byte must show a high-to-low
transition (0xF0). This will only work if you can fit no more than 8
samples in one minimum clock cycle. If not, you must mask off some
of the bits : Clock = 0x?F (0b????1111), and Data = 0x?C (0b????1100)

Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN  / \ AGAINST HTML MAIL
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
| Mobile :  (160 text chars) |
|     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...