- never pull a bus high by the pic! pulling high is done by the pull-up
resistors.
- only use the tris register for the whole communication, i.e. clearing
tris bit is 'send 0', setting tris bit is 'send 1' or 'input'.
- on each write access to a tris bit, clear the appropriate port bit (set
it to 0)!!!
(if you use the same 8bit port of the pic for other purposes, i.e. bits
0 and 1 are i2c and bits 2..7 are other outputs, then any bit-write access
to bits 2..7 may set port bits 0 and 1 to '1', while they are used as
inputs (tris bit is '1')). pic's don't know any bit manipulations. always
the whole byte is read and written!!
therefore it is mandatory to always set port bits, used for i2c back to
'0' again.
maybe, this can help a bit.
tino
Jai Dhar <jd...@ENGMAIL.NotNeeded.UWATERLOO.CA>
Gesendet von: pic microcontroller discussion list <PIC...@MITVMA.We.Hate.SP.AM.MIT.EDU>
03.02.03 14:56
Bitte antworten an pic microcontroller discussion list
An: PIC...@MITVMA.We.Hate.SP.AM.MIT.EDU
Kopie:
Thema: Re: [PIC]: f877 I2C routines
Quoting Olin Lathrop <olin_p...@EMBEDINC.RemovE.COM>:
> > > You should do a bus STOP here, followed by a bus START before the
next
> > > command.
> >
> > Regarding this, in the command sequence diagram, it shows just to just
> send a
> > BUS Start bit, not stop and start. I was doing this, but neglected to
> mention
> > it.
>
> That should be OK. All devices are supposed to reset their bus logic on
a
> start, regardless of what state it was in at the time. In multi-master
> mode doing just a start is actually a good idea so that no other master
> can get in there between commands.
>
> > And yes, on the ninth clock cycle, I set the TRIS bit so that SDA
> becomes an
> > input.
>
> You should do that in the low phase before the ninth clock cycle, not
"on"
> the ninth clock cycle (whatever that means).
>
> > That's how it seems to get pulled low successfully.
>
> Huh? Setting the TRIS bit should cause SDA to float high. Something is
> very wrong if setting the TRIS bit causes SDA to go low.
My mistake (again). SDA doesn't get pulled low BEACUSE of the TRIS bit.
All I
meant was that I know I was setting the TRIS bit at the right time since
it
was successfully getting pulled low by the Slave :-) Like I mentioned,
when I
changed the address to something not of the slave, it didn't respond by
pulling it low, so that's how I know the TRIS part is ok. I am afraid that
it
might be something in my reading sequence that is wrong - but I'm not sure
what.
>
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways. See http://www.piclist.com/#archives for details.
>
----------------------------------------
This mail sent through www.mywaterloo.ca
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
> i haven't read the whole discussion, so i don't exactly know what's the
> original problem.
> as i've used i2c software drivers for a long time, i think i can tell you
> what my main mistakes were when implementing this on a pic:
>
> - never pull a bus high by the pic! pulling high is done by the pull-up
> resistors.
Are you saying that I should be using pull-up resistors on the bus? Because as
it is, I am not... what is the reason for this?
>
> - only use the tris register for the whole communication, i.e. clearing
> tris bit is 'send 0', setting tris bit is 'send 1' or 'input'.
>
And I shouldn't be communicating using bsf/bcf on the ports.. instead use the
TRIS bits? This seems odd.
> - on each write access to a tris bit, clear the appropriate port bit (set
> it to 0)!!!
> (if you use the same 8bit port of the pic for other purposes, i.e. bits
> 0 and 1 are i2c and bits 2..7 are other outputs, then any bit-write access
> to bits 2..7 may set port bits 0 and 1 to '1', while they are used as
> inputs (tris bit is '1')). pic's don't know any bit manipulations. always
> the whole byte is read and written!!
>
> therefore it is mandatory to always set port bits, used for i2c back to
> '0' again.
>
> maybe, this can help a bit.
> tino
>
>
I'm not sure why I would be getting successful ACK pull-downs from the slave
if I was doing this wrong. Maybe you would know why since you have had more
experience... do you have some example code that sends/reads bytes from a
device?
>
>
>
> Jai Dhar <jd...@ENGMAIL.NotNeeded.UWATERLOO.CA>
> Gesendet von: pic microcontroller discussion list <PIC...@MITVMA.AntiSpam.MIT.EDU>
> 03.02.03 14:56
> Bitte antworten an pic microcontroller discussion list
>
>
> An: PIC...@MITVMA.NoThiS.MIT.EDU
> Kopie:
> Thema: Re: [PIC]: f877 I2C routines
>
>
"Alan B. Pearce" <A.B.P...@RL.Delete.AC.UK>
Gesendet von: pic microcontroller discussion list <PIC...@MITVMA.AntiSpam.MIT.EDU>
03.02.03 16:33
Bitte antworten an pic microcontroller discussion list
An: PIC...@MITVMA.NO.SPAM.MIT.EDU
Kopie:
Thema: Re: [PIC]: f877 I2C routines
>And I shouldn't be communicating using bsf/bcf on
>the ports.. instead use the TRIS bits? This seems odd.
What is even more odd is why you seem to be using a software bit bang of
the
I2C instead of using the internal MSSP I2C hardware. Your subject line
says
you are using an 877 which has this and it is real easy to use.
And yes, you should be using pull up resistors on both the clock and data
line as your PIC should have both lines as "open collector" types. This is
done automatically by the MSSP hardware, but is why you need to use the
TRIS
registers to set the bits to a 0 state when doing a bit bang
implementation.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email list...@mitvma.Bogus.mit.edu with SET PICList DIGEST in the body