Searching \ for '[PIC]: Re: Re: 16F84 and I2C Bit Banging Routines' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/i2cs.htm?key=i2c
Search entire site for: 'Re: Re: 16F84 and I2C Bit Banging Routines'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Re: Re: 16F84 and I2C Bit Banging Routines'
2002\04\23@161333 by James Paul

picon face
Olin,

Thanks for the response.   And responding to your questions, the answer
is yes and no.   By "Sub-Address", I mean I am sending a second byte
whose purpose is to select one of three variables to send back to the
requesting computer.  And as an FYI, the transaction is started as a
read operation.  I have modified the list below to more accurately show
the steps I take in getting the information back into the PC from the PIC.


 1 The PIC receives a START Condition... then
 2 The PIC receives an address byte... (Device address and LSB set to 1)
 3 The PIC acknowledges receipt of the address byte...
 4 The PIC receives a second byte (tells PIC which variable to send back
   to the PC)..
 5 The PIC acknowledges receipt of the second byte...
 6 The PIC fetches the variable contents and proceeds to send
   it back to the PC...
 7 The PIC has fulfilled the request and does not acknowledge so that
   a STOP condition can be generated by the PC.

 But here again, I can see the correct data coming from the PIC except
 that it is only about 800mV high instead of 4.8+ V like the rest.  And
 this is only seen on the return data.   All other bit coming from the
 PC to the PIC and the acknowledge bit from the PIC to the PC are at the
 correct level (4.8+V). I just do not understand why the data going back
 to the PC from the PIC is such a small value and all the other bit are at
 the correct level.   And then also, after the first access, it takes
 two accesses to get any more data until you reset the PIC.   It kind of
 like there is a command missing or one too many and it loses itself
 until another command comes along and clears the way.

 I know I'm not giving you much to go on, but I was told not to release
 too many details of the software that isn't included in the "Serial
 PIC'n" book.  IMHO, it isn't all that proprietary, but unfortunately I'm
 not the one with the say so.

 Generally speaking, I'm using the I2C protocol and the I2C specification
 with a slight amount of customization to allow my application code to be
 able to operate within the confines of the I2C bit bang routines.

 Boy, that was a mouthful...

 Its kind of along the same lines as a read from an EEPROM.  You send a
 device address, get an acknowledge, send the byte address, get an
 acknowledge, do a restart, then invoke the read command to get the data.

 If you have any more insight, I'd love to hear it.   And thanks again
 for the reply.


                                                  Regards,

                                                    Jim









{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\04\23@162411 by Andrew Warren

flavicon
face
James Paul <spam_OUTPICLISTTakeThisOuTspammitvma.mit.edu> wrote:

> I can see the correct data coming from the PIC except that it is
> only about 800mV high instead of 4.8+ V like the rest.  And this is
> only seen on the return data.   All other bit coming from the PC to
> the PIC and the acknowledge bit from the PIC to the PC are at the
> correct level (4.8+V). I just do not understand why the data going
> back to the PC from the PIC is such a small value and all the other
> bit are at the correct level.

James:

The acknowledge bit from the PIC to the PC is at 4.8V, but the other
"1" bits from the PIC to the PC are only 800mV?  Sounds as though the
PC is trying to hold the data line low while the PIC is sending data
to it.

-Andy

=== Andrew Warren -- .....aiwKILLspamspam@spam@cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\04\23@162958 by Olin Lathrop

face picon face
>  Thanks for the response.   And responding to your questions, the answer
>  is yes and no.   By "Sub-Address", I mean I am sending a second byte
>  whose purpose is to select one of three variables to send back to the
>  requesting computer.  And as an FYI, the transaction is started as a
>  read operation.  I have modified the list below to more accurately show
>  the steps I take in getting the information back into the PC from the
PIC.
{Quote hidden}

Again, this is a violation of IIC.  If the address byte has the LSB set to
1, then the whole rest of the sequence is a read, meaning the slave passes
data to the master.  Step 4 is wrong.  The master shouldn't be sending
anything after an address byte with the RW bit set to read, and the slave
shouldn't be trying to receive anything.  I'm not surprised this messes
things up.

The right way to do this is to do a write sequence with one data byte that
indicates what you want to read next.  Then do a read sequence and have the
slave return whatever data was requested by the write sequence.  Each is a
separate sequence with its own start and stop conditions.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\04\23@163358 by James Paul

picon face
Yep, I know.  I thought of that too and it was the first thing I
checked out.   Turns out that that isn't the problem.  Or at least
so it appears.   We have the same basic program (on the PC) talking
to an EEPROM, and it works fine.   This program (on the PC) is a
subset of the EEPROM program.

Thanks for the reply.

                                             Regards,

                                               Jim



{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\04\23@190129 by Mike Mansheim

flavicon
face
>  1 The PIC receives a START Condition... then
>  ...
>  7 The PIC has fulfilled the request and does not acknowledge so that
>    a STOP condition can be generated by the PC.

When reading, the master acks/no acks the slave, not the other way around
as in step 7.  I'm assuming the pc is the master and the pic is the
slave here.  Getting acks messed up can result in one of the devices
holding a line low forever.  As Andy mentioned, this can cause the low
voltage if something else is trying to drive the line up (although they
shouldn't be driving i2c lines high, they should be floating high).

You mentioned the pc program works with an eeprom, but I don't think
you can assume the pc side is working properly.  This is different
because of the customization.  If you were doing just a one byte read
without first setting the eeprom address, the sequence is:
 start
 send device address, bit set (slave acks)
 read the data (master no acks)
 stop

you've inserted a second send into this - so it can't really be tested
with an eeprom.

I would back up to the point where I got the pc to read one byte from
the pic, with the pic acting exactly like an eeprom.  Once that was
working, then extend to the other stuff.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\04\24@034159 by Alan B. Pearce

face picon face
>  But here again, I can see the correct data coming from the PIC except
>  that it is only about 800mV high instead of 4.8+ V like the rest.  And
>  this is only seen on the return data.   All other bit coming from the

The problem is that between steps 5 and 6 you need a restart condition with
another address byte, but with the R/W bit set to read. At the moment you
have two transmitting devices fighting each other which is why you see such
low voltages.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


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