Searching \ for 'i2c on '73' 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 on '73'.

Truncated match.
PICList Thread
'i2c on '73'
1998\09\05@163649 by Steve Smith

picon face
I need a little help on coding i2c for a '73 it is required to interface with
a 24LC01 to hold fixed constants (Havent used i2c before). There is also an
RS232 interface required opperation reruired is 32 bytes from PC to PIC (via
232) then after verification to EErom (via i2c) these will be the opperational
constants for the program. I can find enough reference material on the RS 232
but very little on the I2C section

Any help / pointers / pitfalls would be appreacated.......

Thanks Steve..........

1998\09\06@062200 by tjaart

flavicon
face
Steve Smith wrote:

> I need a little help on coding i2c for a '73 it is required to interface with
> a 24LC01 to hold fixed constants (Havent used i2c before). There is also an
> RS232 interface required opperation reruired is 32 bytes from PC to PIC (via
> 232) then after verification to EErom (via i2c) these will be the opperational
> constants for the program. I can find enough reference material on the RS 232
> but very little on the I2C section
>
> Any help / pointers / pitfalls would be appreacated.......

I've got a list of I2C links. I have also updated it with two new links :1) A list of I2C products
by Philips
2) The original I2C specs by Philips

http://www.wasp.co.za/~tjaart/electronicsearch.html

--
Friendly Regards

Tjaart van der Walt
spam_OUTtjaartTakeThisOuTspamwasp.co.za

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS .....tjaartKILLspamspam@spam@sms.wasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1998\09\07@064626 by Clewer,Brian

flavicon
face
Steve Smith wrote:

>I need a little help on coding i2c for a '73 it is required to interface
with
>a 24LC01 to hold fixed constants (Havent used i2c before). There is also
an
>RS232 interface required opperation reruired is 32 bytes from PC to PIC
(via
>232) then after verification to EErom (via i2c) these will be the
opperational
>constants for the program. I can find enough reference material on the
RS 232
>but very little on the I2C section
>
>Any help / pointers / pitfalls would be appreacated.......
>
>Thanks Steve..........


I have IIC code on my web page.  All code has full comments, but I do
think you need to understand the protocol before trying to implement it.
There is a reasonable description of this protocol in the 16C7x data
sheet.  One thing I might add though, both the SDA (data line) and SCL
(clock) should be open drain.  You can simulate an open drain pin with a
10k pull up resistor on the required pin and making the pin an INPUT for
a high output and an OUTPUT for a low output BUT you also need to set the
data pin itself to a low first (usually in the initialisation).

e.g..

#define SCL trisc,1
#define SDA trisc,2

bsf status,rp0  ;bank 1
movlw 0xFFh   ;set port to inputs
movwf trisc   ; ''
bcf status,rp0  ;bank0
movlw 0x00h   ;set the output register to 0 (see note above)
movwf portc   ; ''


when you need to set the pin to a high:

bsf status,rp0  ;bank 1
bsf SDA   ;set the SDA pin high
bsf SCL   ;set the SCL pin high
bcf status,rp0  ;bank0

when you need to set the pin low:

bsf status,rp0  ;bank 1
bcf SDA   ;clear the SDA pin low
bcf SCL   ;clear the SCL pin low
bcf status,rp0  ;bank0


BTW: my web page is at http://www3.mistral.co.uk/brian.clewer/

1998\09\07@103555 by wwl

picon face
On Mon, 7 Sep 1998 11:27:00 PDT, you wrote:

{Quote hidden}

Wrong - only SDA needs to be open drain unless you are using a
multi-master system.

    ____                                                           ____
  _/ L_/  Mike Harrison / White Wing Logic / wwlspamKILLspamnetcomuk.co.uk  _/ L_/
_/ W_/  Hardware & Software design / PCB Design / Consultancy  _/ W_/
/_W_/  Industrial / Computer Peripherals / Hazardous Area      /_W_/

1998\09\07@111050 by Clewer,Brian

flavicon
face
Mike Harrison wrote:

>>I have IIC code on my web page.  All code has full comments, but I do
>>think you need to understand the protocol before trying to implement
it.
>> There is a reasonable description of this protocol in the 16C7x data
>>sheet.  One thing I might add though, both the SDA (data line) and SCL
>>(clock) should be open drain.

>Wrong - only SDA needs to be open drain unless you are using a
>multi-master system.

Mike,
As I said above, on page 89 of the data sheet 16C7X there is an overview
on the IIC protocol.  Paragraph 6 says 'The output stages of the clock
(SCL) and data (SDA) lines must have an open-drain or open-collector in
order to perform the wired-AND function of the bus.'  However, I can see
that the implementation of the IIC bus would work with just a single
master if the SCL was not open drain.  But it's not my preference to
start changing the rules laid down in a documented protocol and nor would
I advise anybody else to.

Brian.

1998\09\07@111922 by tjaart

flavicon
face
Clewer,Brian wrote:

{Quote hidden}

You don't need open drain outputs. You can simulate it with any of the
IO pins by toggle-ing it between input and output with 0 value.
Thus :
inactive : tris = 1, ouput = don't care
active   : tris = 0, output = 0

Make sure you understand all about read-modify-writes before doing this,
because you are changing direction on a port. You will, of course, still need
pull-up resistors.

--
Friendly Regards

Tjaart van der Walt
.....tjaartKILLspamspam.....wasp.co.za

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS EraseMEtjaartspam_OUTspamTakeThisOuTsms.wasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1998\09\07@113824 by Keith H

flavicon
face
Mike Harrison wrote:
>
> On Mon, 7 Sep 1998 11:27:00 PDT, you wrote:
>
> >Steve Smith wrote:
> >
> >both the SDA (data line) and SCL (clock) should be open drain.
> Wrong - only SDA needs to be open drain unless you are using a
> multi-master system.

Nope, Steve is right.
SCL _does_ have to be open drain.
Or open-drain simulated as per Tjaart's mail.

I2C devices are able to insert wait states by holding SCL low
with their open drain outputs.

If a master is driving the clock with a normal totem-pole output,
you'll get a conflict of course.

Some naughty programmers get away with it because the slave I2C
devices are so fast they never need to hold SCL low.
Their sins can catch up with them when they need
to add a slow slave device that does!

It's not hard to do it right in the first place.
Knowingly doing it the wrong way is inexcusable! :-)

1998\09\07@115313 by Steve Lawther

flavicon
face
Mike Harrison" [SMTP:wwlspamspam_OUTNETCOMUK.CO.UK] wrote:-

>>I have IIC code on my web page.  All code has full comments, but I do
>>think you need to understand the protocol before trying to implement
>> There is a reasonable description of this protocol in the 16C7x data
>>sheet.  One thing I might add though, both the SDA (data line) and SCL
>>(clock) should be open drain.

>Wrong - only SDA needs to be open drain unless you are using a
>multi-master system.

    Wrong again - even in single master systems, if you stick to the
    LETTER of the full I2C spec. you need open drain, as slow slave
    devices are allowed to extend the SCL low, as an indication for the
    master to wait until the slave is ready. This said, other than some of
    the older philips chips, I've not seen any other manufacturers design
    this 'wait' into their I2C stuff.


    Steve Lawther

    http://ourworld.compuserve.com/homepages/steve_lawther/ucindex.htm

1998\09\07@140147 by wwl

picon face
On Mon, 7 Sep 1998 16:39:49 +0100, you wrote:

{Quote hidden}

I have never encountered a device that does this - can you give an
example?
Certainly none of the standard eeproms do, and this is what most
people will be interfacing to most of the time.
Surely the master would also need to monitor the line - I can't
recall seeing this being done in any I2C implementations.    
>Their sins can catch up with them when they need
>to add a slow slave device that does!
And how often does anyone add extra devices to anexisting  I2C bus ?
Of this small subset, how often will the new device be 'slow', and of
this sub-subset, the chances are the the new device will need some
software change to talk to the new device. I won't lose any sleep over
this one!

>It's not hard to do it right in the first place.
But why waste the time and code space if it isn't necessary?
>Knowingly doing it the wrong way is inexcusable! :-)
Adding an unnecessary component (i.e. pullup resistor) to a
production design,  wasting code space (and in some cases increasing
power consumption) are  inexcusable in cost-sensitive areas.


    ____                                                           ____
  _/ L_/  Mike Harrison / White Wing Logic / @spam@wwlKILLspamspamnetcomuk.co.uk  _/ L_/
_/ W_/  Hardware & Software design / PCB Design / Consultancy  _/ W_/
/_W_/  Industrial / Computer Peripherals / Hazardous Area      /_W_/

1998\09\08@073152 by Keith H

flavicon
face
You're quite right.
If your system works and you're happy with it, then fine.
For amateur hobby projects, and some commercial projects,
it's not critical.

However, I'm developing code for a complex professional system.
I've got a power amp board with an I2C master,
a front panel PIC which can be slave or master,
zero, one or more expansion boards which may be slave or master, and
sometimes a PC to squirt test messages in and read the EEPROM for
debugging.

The system must cope with current and future expansion boards.
I have no idea how much of the I2C spec they will require.
Therefore I have to stick to the letter of the I2C spec.

Taking the SCL point, most chips can live without wait-states.
But systems could get so complex that I need an I2C bus monitor
that will monitor the I2C bus traffic bit by bit so it can record
problems exactly.

I could do this with a PC if I had a little logic to hold
the SCL line low to wait state the bus while it processes info.

If my code did not allow SCL to be held low, then such an I2C monitor
would not be able to work. If someone made an expansion board that
held SCL low then it would not work.

There would be a meeting to discuss these problems,
everyone else can say "well, our code obeys the I2C spec.
We're in the right, you're in the wrong, and you knowingly
wrote buggy software for thousands of units in the field that
we can't use our I2C monitor or fit this expansion board in
without an upgrade. Why can't you write code to the spec you're
given?".

> Surely the master would also need to monitor the line

True. It should. That's how the master obeys wait states.

> - I can't recall seeing this being done in any I2C implementations.

Then those are not obeying the I2C spec.

> how often does anyone add extra devices to an existing  I2C bus?

Even if someone needs to do it once, my code has to cope.

> how often will the new device be 'slow', and of this sub-subset,
> the chances are the new device will need some software change

Well, in my system the new device runs the application code.
The PIC is a smart front panel, and its code is complete.
The expansion board can tell it to transmit kbd and rotor events.

> I won't lose any sleep over this one!

Great. I sleep better knowing I've implemented specs thoroughly.

>> It's not hard to do it right in the first place.
> But why waste the time and code space if it isn't necessary?

Because sometimes it becomes necessary.
If I write and debug a full spec I2C code library,
I'll only have to do it once.
If I take short cuts, I might have to patch them in future.
I save the time I might spend wondering if a problem is due to
SCL conflict. A covered ass gathers no dick!

>  Adding an unnecessary component (i.e. pullup resistor) to a
> production design,  wasting code space (and in some cases increasing
> power consumption) are  inexcusable in cost-sensitive areas.

FWIW, correct SCL handling does not affect code size or power
significantly.

Developing complex multi-master multiprocessor
I2C network protocols can drive you crazy.
The only thing keeping me sane is my
splendid collection of singing potatoes.

1998\09\08@115039 by Adam Bryant

flavicon
face
John Hyland's web site at http://www.huv.com has a link to an excellent  
description of the I2C protocol.

{Original Message removed}

1998\09\08@213138 by wwl

picon face
y.
>
>>> It's not hard to do it right in the first place.
>> But why waste the time and code space if it isn't necessary?
>
>Because sometimes it becomes necessary.
But this is usually forseeable.
>
>>  Adding an unnecessary component (i.e. pullup resistor) to a
>> production design,  wasting code space (and in some cases increasing
>> power consumption) are  inexcusable in cost-sensitive areas.
>
>FWIW, correct SCL handling does not affect code size or power
>significantly.
'significantly' takes on a whole new meaning when you have to squeeze
a few bytes of extra code into an app that is already completely
filling the device, and has already been squeezed several times
before!

    ____                                                           ____
  _/ L_/  Mike Harrison / White Wing Logic / KILLspamwwlKILLspamspamnetcomuk.co.uk  _/ L_/
_/ W_/  Hardware & Software design / PCB Design / Consultancy  _/ W_/
/_W_/  Industrial / Computer Peripherals / Hazardous Area      /_W_/

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