i2c communication

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
hello you all

i've been working on an i2c communication among a unique master and
several slaves...
(the source code i based on were the microchip application notes 734
and 735)
The first thing i need to do in my application is verifying the
presence of the slaves and a problem has rised: once the master sends
an address that produces a NOT acknowledge, no other slave responds to
the next call even though the address is correct...
the source code  has a routine to handle acknowledge errors, so that
such routine sets the bus free when a NOT acknowledge is received
(AN735)

PDD   the application has been simulated in proteus6

does anybody have any idea of what i could be doing wrong?

thanks for your help

Re: i2c communication
snipped-for-privacy@yahoo.es says...
Quoted text here. Click to load it
You can try doing the following :
Pull the data and clock both low (active) for 10ms.
Release them and wait 10ms.
Goto the next address.

I don't know if that is an "Official" bus reset or not,
but I remember having to do that with some EEPROMs once.


Re: i2c communication
Quoted text here. Click to load it
That might functions if you run it on SMBus (a newer variant of i2c for PC
hardware).
But definitely it will not work on i2c! There doesn't exists an time-out in
the spec.
Timing is not a great issue with i2c. What counts is where a edge on SCL
oder SDA comes in relation to logic states (on bus and inside the state
machines).

regards -
Henry

--

<Schau auch mal auf meine Homepage www.ehydra.dyndns.info>
<u.a. Versand von Wasserflohzuchtansatz, Wasserpflanzen/-schnecken,
We've slightly trimmed the long signature. Click to see the full one.
Re: i2c communication
Quoted text here. Click to load it
Sorry! Read "oder" as "or" - it's german.

- Henry

--

<Schau auch mal auf meine Homepage www.ehydra.dyndns.info>
<u.a. Versand von Wasserflohzuchtansatz, Wasserpflanzen/-schnecken,
We've slightly trimmed the long signature. Click to see the full one.
i2c communication
Quoted text here. Click to load it

thank you very much for your help...

the problem with the verification of slaves has been finaly solved:
as I could not find the literarature regarding the "bus reset" i tried
something that worked out:
in the main cycle of the slave program the sspbuf is read (in each
cycle) if such slave is not in the middle of a communication... in
this way it is sure
that when the master calls it its sspbuf register will be clear and
ready to answer

but another problem has rised:

when working with a slave as transmitter, after setting sspcon2.RCEN,
the SDA line is supposed to get the value of the most significant bit
contained in SSPBUF and then shifting out the next bits with the
falling edges of the SCL line (so that the second bit of the byte to
be transmitted is shifted out with the falling edge of the first
clock pulse, the third bit with the second falling edge... and so on),
but what happens in my case is that the first bit shifted out is not
the MSB (bit 7), but the next (i.e. the sixth). With this, data like
10000000 is received by the master as 0 because the first bit shifted
out is a 0 (bit 6) and both, the first and second clock pulses read 0;
and data like 01000000 is received as 11000000 because with the first
and second clock pulses a 1 is read. Using a scope probe to view the
state of the SDA & SCL lines -simulation in proteus 6- i saw that the
first change in the bits to be shifted out is not happening at the
first falling edge of SCL but in the second....

I have been thinking and i see no reason for this to happen, and i
was wondering if it was possible that the error is being caused by
the environment (proteus 6), not by the source code. And if it is
not so, what could i be doing wrong?

Again, thank you very much

Re: i2c communication
Quoted text here. Click to load it

Usually, there are two control bits for the clock: polarity and phase.
Check (against the spec sheets) that both are correctly set for your
hardware.

HTH

Tauno Voipio
tauno voipio (at) iki fi


Re: i2c communication
Quoted text here. Click to load it


Those control bits are CKP (clock polarity) which must be set after
writing sspbuf (according to i2c specs), and i am not sure about which
is that control bit for clock phase, but maybe you're referring to
(please correct me if i'm wrong) CKE (clock edge select) that, when
working in i2c mode, must be set for SMBUS specs input levels or
cleared for i2c specs input levels ...

in my code CKE is always clear in the slaves [which are (like the
master) PIC16f877], and CKP is set after writing sspbuf (as sugested
above)

but what should i check by that control bits besides that?

Sorry for not having this very clear but, as you already know, Im
just a beginner...

thank you very much

juan

Re: i2c communication
Quoted text here. Click to load it
I don't think that Proteus is enough evolved to say it is virtually bugless.
Please try first Taunos' hint.

- Henry

--

<Schau auch mal auf meine Homepage www.ehydra.dyndns.info>
<u.a. Versand von Wasserflohzuchtansatz, Wasserpflanzen/-schnecken,
We've slightly trimmed the long signature. Click to see the full one.
Re: i2c communication
On Sat, 23 Oct 2004 14:01:59 +0200, "Roland Zitzke"
Quoted text here. Click to load it

Just download the free specs of I2C from the Philips website.

Pieter Hoeben
http://www.hoeben.com


Site Timeline