Searching \ for 'i2c help please' 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: 'i2c help please'.

Truncated match.
PICList Thread
'i2c help please'
2000\01\11@135157 by dvdmods

flavicon
face
Hi
please help!
I have a small problem with i2c bus,I am using 12c508 pin 7 for data and pin
3 for clock (internal clock,masterclear off )
the i2c device is  standard  < startbit/address/data/stopbit >

The code will work fine if  I have my scope lead connected to data line(pin
4) ,I think this is adding capacitance to this line
so i removed the scope lead and fitted 33pf capacitor between the data pin
and ground, this also worked fine
But if I remove the cap the pic 12c508 wont talk to the i2c device ..
I have also moved the data and clock to other pins on pic but have the same
problem.
I also tried to slow down the rate the pic sends data to i2c device still no
good..
The code I am using, is one I have used many times to talk to other i2c
devices
but on this device I am having no joy.
the device has pull up10k resistors on data and clock lines
Can anyone help??

any help will be greatly appreciated
many thanks
Tom

2000\01\11@153802 by Ken Webster

flavicon
face
What device are you trying to talk to?
Is there a chance that it doesn't ACK on address and the device in your
prior application did?  If the last bit of the address sent is low then the
capacitor would keep the data line low long enough for your code to think it
received an ACK and keep going.  Without the cap, your code sees no ACK and
stops.  Just a hunch.  Seeing your code and knowing what device you are
trying to talk to would help.

Ken

{Original Message removed}

2000\01\11@172206 by dvdmods

flavicon
face
Hi Ken
Thhe device is sending ack,but all i am doing for this is wasting one clock
pulse
so my code cant hang there.And infact when i use my emulator i can see that
the code is flowing fine .

here is the output code


DATOUT_
           CLRF COUNT1
           MOVLW .8
           MOVWF   COUNT1           ;this is the sub that i use to send out
the 8 bits of data and the ack wast clock pulse
           LOOP1_                               ;sclk is i2cbus clock and
sdata is i2c bus data
           BCF SCLK
           BCF SDATA
           RLF TXBUF  ;SENDS DATA TO EEPROM
           BTFSC C
           BSF SDATA
           NOP
           NOP
           NOP
           NOP
           BSF SCLK
           NOP
           NOP
           NOP
           NOP
           NOP
          BCF SCLK
          NOP
          NOP
          NOP
         NOP
         DECFSZ COUNT1
         GOTO LOOP1_
         CLRF TXBUF
         BSF SCLK
         NOP
         NOP
          NOP
          BCF SCLK
         RETURN

2000\01\11@180410 by Giles L. Honeycutt

flavicon
face
Are you operating at a faster speed than you have in the past?
If so try putting a NOP between any 2 writes to the port.
Example:
sdata is i2c bus data
           BCF SCLK
           nop ; ADD to make sure port is correct.
           BCF SDATA


Best regards,
Giles

2000\01\11@182654 by quozl

flavicon
face
On Tue, Jan 11, 2000 at 06:48:54PM -0000, dvdmods wrote:
> The code will work fine if I have my scope lead connected to data line(pin
> 4) ,I think this is adding capacitance to this line

Do you have _MCLR_OFF in your __CONFIG?  Just checking.

--
James Cameron   spam_OUTquozlTakeThisOuTspamus.netrek.org   http://quozl.us.netrek.org/

2000\01\11@184614 by Ken Webster

flavicon
face
I don't immediately see anything wrong other than the back-to-back BCF's
mentioned by Giles.  These should definitely be avoided at high clock speeds
yet this doesn't seem to explain your original observation that it DOES work
with added capacitance on the SDATA line and not with the capacitance
removed.

I would be interested in seeing the code that generates the start condition
and the stop condition.

Ken



>DATOUT_
>            CLRF COUNT1
>            MOVLW .8
>            MOVWF   COUNT1           ;this is the sub that i use to send
out
{Quote hidden}

2000\01\11@185244 by Quitt, Walter

flavicon
face
The scope adds capacitance.
That menas the waveform will be skewed.
Translated that, I believe, causes the signal
to "strech" or causes the period to change.
You may try to slow that signal down some.
Or perhaps there is a rise time issue.
Maybe you can use a better probe and see
what happens.

GL,
Walt...

{Original Message removed}

2000\01\11@190523 by Dennis Gearon

flavicon
face
I'd be interested in the wiring and grounding.........LOTS of projects
don't work because of that. I use 1/2" copper tape or a solid ground
plane to bread board things. I even got a promotion once for fixing an
'engineer's' design that used 3/32 ground RUNS to a 10 Mhz disk drive
head amplifier design.

--
________________________________________________________________
Dennis K. Gearon (Kegley)
Scientific Instrument Technician, School of EIT
Oregon Institute of Technology - One of USA's 100 Best College Buys
3201 Campus Drive
Klamath Falls, OR 97601
Voice   1-541-885-1563
FAX     1-541-885-1689
email   .....gearondKILLspamspam@spam@oit.edu
I am here only to be truly helpful
________________________________________________________________

2000\01\12@143646 by dvdmods

flavicon
face
i2c probem stil>>>>>

Thankx to all that are looking at this problem
Speed........ Is there any way i can make the pic clock through the code
slower, but still use the internal 4mhz osc
and change this speed half way into my programme?( i dont think its
possible)
Good piont about the back to back bcf`s they now have 2 nops in-between
here is the start and stop code  ect

BSTART_
       CLRF GPIO
       MOVLW B'00101110'
       TRIS GPIO
       BCF SCLK
       BCF SDATA
       NOP
       NOP
       NOP
       NOP
       BSF SDATA
       NOP
       NOP
       NOP
       NOP
       BSF SCLK
       NOP
       NOP
       NOP
       NOP
       BCF SDATA
       NOP
       NOP
       NOP
       NOP
       BCF SCLK
       NOP
       NOP
       NOP
       NOP
       RETLW 0
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
BSTOP
       MOVLW B'00101110'    (loooking at my code i cant remember why i have
this here)
       TRIS GPIO
       BCF SCLK
       BCF SDATA
       NOP
       NOP
       NOP
       BSF SCLK
       NOP
       NOP
       NOP
       NOP
       BSF SDATA
       NOP
       NOP
       NOP
       NOP
       BCF SCLK
       NOP
       NOP
       NOP
       BCF SDATA
       NOP
       NOP
       NOP
       RETLW 0
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATAOUT_
        CLRF COUNT
        MOVLW .8
        MOVWF   COUNT
LOOP3_
        BCF SCLK
        NOP
        NOP
        BCF SDATA
        NOP
        RLF TXBUF
        BTFSC C
        BSF SDATA
        NOP
        NOP
        BSF SCLK
        NOP
        NOP
        BCF SCLK
        NOP
       NOP
       DECFSZ COUNT
      GOTO LOOP3_
      CLRF TXBUF
      BSF SCLK
      NOP
      NOP
      BCF SCLK
      RETURN

2000\01\12@155016 by Terry A. Steen

flavicon
face
I have never tried this, but how about using the TMR0 interupt. Have it
'burn' a few cycles then return on every instruction cycle (if you are not
using it). Then, when you want to go slow, just enable it, disable to
resume normal speed.

Sounds goofy and alot of good clock cycles will just go down the drain, but
what the heck, try it and let me know if it worked.

TAS

At 07:30 PM 1/12/2000 -0000, dvdmods wrote:
{Quote hidden}

-----------------------------------------------------------------
Sent from the desk of:
Terry Allen Steen, EE              engineeringspamKILLspammarinapower.com
332 McLaws Circle, Ste 111         757-258-8800 (Voice)
Williamsburg, Va   23185           757-258-8805 (FAX)
-----------------------------------------------------------------
!I AM A WHALE MAIL USER! If you have a large file to send, goto
   http://www.whalemail.com    send them to:   mplengineer
       Give me your account and I will use it also
-----------------------------------------------------------------
Visit our web-site: http://www.marinapower.com
-----------------------------------------------------------------

2000\01\12@160834 by jamesnewton

flavicon
face
After watching this thread for a while, it occurs to me that a scope lead or
cap could possibly change the signal level just a bit in addition to
delaying it as has been suggested. Have you tried biasing the signal up or
down with a very large resister?

James Newton .....jamesnewtonKILLspamspam.....geocities.com phone:1-619-652-0593
http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)

{Original Message removed}

2000\01\12@161701 by Ken Webster

flavicon
face
>i2c probem stil>>>>>
>
>Thankx to all that are looking at this problem
>Speed........ Is there any way i can make the pic clock through the code
>slower, but still use the internal 4mhz osc
>and change this speed half way into my programme?( i dont think its
>possible)

No, but, if you have stack space free you could make a delay subroutine ...
something like:

DELAY    NOP            ;2 cycles for CALL +1 = 3
        NOP            ;+1 = 4
        RETURN         ;+2 = 6 .. 6 cycles total delay

Then call it before toggling the clock line .. i.e. replace:
        BSF SCLK
        NOP
        NOP
        NOP
        NOP
        NOP
        NOP
        BCF SCLK
with:
        BSF  SCLK
        CALL DELAY
        BCF  SCLK



As for your code .. it appears to be generating the start and stop
conditions correctly but one thing it does that is a little odd is leave the
clock and data lines low by default.  I don't think that this will cause any
problems (Microchip's literature doesn't say anything about what goes on
inbetween a stop condition and the next start condition so I assume that
clock cycles occuring in this interval are ignored) but it will cause your
circuit to draw more current if you are using a typical I2C bus with
external pullup resistors.  Leaving these lines high inbetween operations is
typical.  Are you using pullup resistors?  If so, what size?

Another thing .. are the pins you are using (particularly for the SDATA)
open-drain outputs?  If not, you should change the code at the bottom of the
data output loop from:
>       GOTO LOOP3_
>       CLRF TXBUF
>       BSF SCLK
>       NOP
>       NOP
>       BCF SCLK
>       RETURN

To:
      GOTO LOOP3_
      CLRF TXBUF
      BSF SCLK
      NOP
      NOP
      BCF SCLK
      NOP
      BCF SDATA            ;Make sure SDATA is low so ACK doesn't collide
      RETURN

This will prevent high currents from flowing when the EEPROM is driving
SDATA low for an ACK and the PIC is driving it high because the last bit
clocked out was high.  Note that a collision will still occur for a coupple
of microseconds but this is better than leaving this condition for a longer
period of time.

Ideally, you should use the external pullup resistors (or at least the one
on the SDATA line) and toggle the line(s) by toggling the bit in the TRIS
register instead of the bit in the PORT register -- set the bit in the PORT
register low so that when the TRIS bit is low the line is driven low and
when the TRIS bit is high the line is not driven and is pulled high by the
resistor unless it is being pulled low by the EEPROM.

(ignore the above if the line you are using is an open-drain output)



One final note, the sequence:
>         BSF SCLK
>         NOP
>         NOP
>         BCF SCLK

will violate the timing requirements of many EEPROMS if your PIC is using a
4MHz clock.  Insert at least one additional NOP unless you have a fast
EEPROM.


Other than these recommendations I see nothing wrong.  I'm still not sure
why adding capacitance should make it work unless the start condition setup
time of your EEPROM is greater than 5 microseconds.  If so, change:
>        BSF SCLK
>        NOP
>        NOP
>        NOP
>        NOP
>        BCF SDATA
To include at least one additional NOP (or call the DELAY subroutine I
suggested).  If your EEPROM is slow, you should probably increase all of the
delays a bit just to provide a little extra margin.

Good luck,

Ken



------ Remainder of original message ------

{Quote hidden}

have
{Quote hidden}

2000\01\12@170831 by paulb

flavicon
face
dvdmods wrote:

> BSTART_
>         CLRF GPIO
>         MOVLW B'00101110'
>         TRIS GPIO
>         BCF SCLK
>         BCF SDATA
... NOPs etc.
>         BSF SDATA
...
>         BSF SCLK
...
>         BCF SDATA
...
>         BCF SCLK
... and such.

 Uck!  This is *not* how you do it, at least according to the IÓC
specs.  You clear both SDATA and SCLK in the initialisation code and
*never* alter them again.

 Now, you should have four macros defined called something like DLOKLO,
DHIKHI, DLOKHI and DHIKLO or such, each based on the construct:

DHIKHI  macro
       MOVLW B'00101110'
       TRIS GPIO
       GOTO $+1
       endm

 I've not specified the others because I don't happen to know which of
your bits are SDATA and SCLK, but you'll figure that.  Significant
points:

1} GOTO $+1 is two NOP (cycle)  delays but takes only one instruction.
Repeat as necessary to obtain desired delay.
2} Using MOVLW plus TRIS takes two cycles anyway, you didn't want to
do it any faster anyway, so it's as efficient as it gets.  It avoids
spurious setting of bits for three reasons; firstly it sets bits
*explicitly*, not dependent on their current states, secondly it uses
the TRIS bits which theoretically should not be easily "glitched" by
port status and thirdly, it is two instructions and allows settling time
anyway.
3} The standard defines open-collector; this does it.

 I'm just re-inforcing Ken Webster's comments really.
--
 Cheers,
       Paul B.

2000\01\12@172135 by Ken Webster

flavicon
face
Paul B. Webster wrote:

>DHIKHI  macro
>        MOVLW B'00101110'
>        TRIS GPIO
>        GOTO $+1
>        endm


Slick!  I like that.  Especially the GOTO $+1 trick.  Good call!  Now I may
have to go back and update some of my old libraries.

Regards,


Ken

2000\01\12@174313 by Scott Dattalo

face
flavicon
face
On Wed, 12 Jan 2000, Ken Webster wrote:

> Paul B. Webster wrote:
>
> >DHIKHI  macro
> >        MOVLW B'00101110'
> >        TRIS GPIO
> >        GOTO $+1
> >        endm
>
>
> Slick!  I like that.  Especially the GOTO $+1 trick.  Good call!  Now I may
> have to go back and update some of my old libraries.

and if you want a 4-cycle single-instruction delay:

       call  some_return_in_your_code

Of course, you run the risk of stack overflow on a 12c50x part.

Scott

2000\01\12@175551 by Tony Nixon

flavicon
picon face
Scott Dattalo wrote:

> and if you want a 4-cycle single-instruction delay:
>
>         call  some_return_in_your_code
>
> Of course, you run the risk of stack overflow on a 12c50x part.

I had to use something similar once when I had no room whatsoever to
create a delay of about 5 or 6 instructions. I was lucky enough to be
able to CALL the last part of a subroutine because those instructions
did not upset anything.

--
Best regards

Tony

http://www.picnpoke.com
EraseMEsalesspam_OUTspamTakeThisOuTpicnpoke.com

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