Searching \ for 'I2C Read and Write a byte from EEPROM' 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 Read and Write a byte from EEPROM'.

Truncated match.
PICList Thread
'I2C Read and Write a byte from EEPROM'
1998\01\23@074158 by Keith Howell

flavicon
face
You have two major problems.

1. The application note code does not do I2C properly

The code does not let slaves wait-state the master.

2. EEPROMs have non-intuitive behaviour.

You can't read them back immediately.
They go off-line during their write-cycle of about 10 ms.
That is, they don't respond to their I2C bus address.

So your code needs to either wait say 20ms, or
retry until the slave EEPROM responds.
The latter is better because it automatically waits as
long as is needed. No code-re-write if you change
EEPROM type.

1998\01\23@133507 by Tony Vilches

flavicon
face
I've been trying to do this  for over a month. I've read all the
FAQs/ notes, etc and still can't get it to work.

As many have asked for usuable code and no-one has posted, either
there are _Very_ few people who can access I2C eeproms from a 16-84
or they are deliberately holding back because amateurs tend to use
these devices.

I'm still trying.
Tony.

1998\01\23@140229 by Stevenson, Brad

flavicon
face
Or...People are reluctant to publish their source code on the internet
because they could receive alot of flack from their employer, who the
source code ultimately belongs to, atleast here anyway.

I can't send source code but I can give a few tips,
1)Don't rely on the MC app notes.
2)The eeprom manufacturer's data sheets should provide you with all the
info you need (timing diagrams, etc)
3)Be aware of the eeproms write time. (Usually around 10 ms)
4)Use the tris registers instead of the port registers to make the pins
go high and low
5)The rest of it is just bit banging.
6)Be patient and take it one step (bit) at a time.
7)The best advice is to forget i2c unless absolutely neccessary, use SPI
if you can!


Brad Stevenson, CET
The DPL Group - Telecom Techniques
506-635-1055 or 1-800-561-8880
http://www.dpl.ca

> I've been trying to do this  for over a month. I've read all the
> FAQs/ notes, etc and still can't get it to work.
>
> As many have asked for usuable code and no-one has posted, either
> there are _Very_ few people who can access I2C eeproms from a 16-84
> or they are deliberately holding back because amateurs tend to use
> these devices.
>
> I'm still trying.
> Tony.

1998\01\23@155359 by John Payson

picon face
> Or...People are reluctant to publish their source code on the internet
> because they could receive alot of flack from their employer, who the
> source code ultimately belongs to, atleast here anyway.
>
> I can't send source code but I can give a few tips,
> 1)Don't rely on the MC app notes.
> 4)Use the tris registers instead of the port registers to make the pins
> go high and low
> 7)The best advice is to forget i2c unless absolutely neccessary, use SPI
> if you can!

There's nothing wrong or particularly hard with using I2C; SPI can be a
little faster, but only if you're using a >4MHz CPU or one with built-in
SPI hardware; if you really need the speed in such a case, you could use
two or four EEPROM chips and read/write them in parallel (you'd have to
deal with data in 16 or 32 bit chunks, but that shouldn't be a problem).
Using two I2C EEPROMs would get you speed as good or better than SPI with
the same number of port pins.

Also, note that while I2C in the general case is quite complex the subset
of the protocol needed for one CPU "master" to talk to one or more EEPROM
chips is quite simple.  Although I2C generally requires the clock to be
open-collector, and for the master to wait if slaves hold the clock low,
I have never seen an EEPROM chip which required bit-level waiting.  I'd
therefore suggest treating the clock as a standard output, saving yourself
a pull-up resistor.

Additionally, the protocol will seem much simpler if you roll the "ack"
pulses into the start of the read-byte routine.  I don't have the exact
sequence handy, but if you use the proper definitions for "start", "stop",
"read", and "write", you can forget all about acking (even on multi-byte
reads).  This makes the main code MUCH easier to write and understand;
the only caveat is that after you send a byte the data line will be low
until you read a byte or send a stop/restart; if left in this state the
device will draw some extra power through the pullup.

1998\01\23@163424 by Wayne Foletta

flavicon
face
Tony:

We have all had trouble getting PIC to EEProm I2C code to work the first
time. It may be that others like me are relutant to post hand-tweaked
code. We know any post will generate even more questions. I have code
that works in production products. If you can use code that works for
32.7678KHz or 4 MHz or 8 MHz only let me know which one you could use. I
will have to extract the I2C stuff from the complete program and take
out the company sensitive information.

- Wayne Foletta
BMI - Saratoga, CA

{Quote hidden}

1998\01\23@180925 by Steve Baldwin

flavicon
face
> 1)Don't rely on the MC app notes.
> 2)The eeprom manufacturer's data sheets should provide you with all the
> info you need (timing diagrams, etc)
> 3)Be aware of the eeproms write time. (Usually around 10 ms)
> 4)Use the tris registers instead of the port registers to make the pins
> go high and low
> 5)The rest of it is just bit banging.
> 6)Be patient and take it one step (bit) at a time.
> 7)The best advice is to forget i2c unless absolutely neccessary, use SPI
> if you can!

I'd add to that,
8) Remember the read-modify-write thing. Reading another port pin can stuff
up your i2c.
9) Addresses wrap on different boundaries for eeprom read and writes.

Steve.

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: stevebspamKILLspamkcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1998\01\23@184847 by Mitchell D. Miller

flavicon
face
Does number 8 apply when you're changing the TRIS register, as opposed to the
actual data register?

-- Mitch


------------------------------
Mitch Miller
.....mdmillerKILLspamspam.....nque.com
------------------------------


{Original Message removed}

1998\01\24@035836 by Steve Baldwin

flavicon
face
>> 8) Remember the read-modify-write thing. Reading another port pin can
stuff
>> up your i2c.

> Does number 8 apply when you're changing the TRIS register, as opposed to
the
>  actual data register?

Sorry. I was in a hurry at the time, otherwise I would have expanded on it.

Yes. It's a gotcha for when you are pin bashing I2C using the TRIS
register.
You write a 0 into the data latch and then swap the pin between input and
output using the TRIS register. When it's an output, it's outputting a 0.
When it's an input, the external pullup makes the bus a 1, also allowing
other things on the bus to pull it low if needed.
This bit you know.

The catch is when you execute an instruction that does a read-modify-write
on another port bit.
It reads the port as a byte (reading the pins) gets the bit it needs and
then writes the data byte back to the port (latches). If your bus was idle
at the time, the read gets a 1 from the bus and writes it into the data
latch. You wanted the 0 that you originally wrote.
If you don't fix it when you start to use the bus properly, you don't get
any 0's on the bus.
If you have an interrupt that can occur while you are using the i2c bus and
it tests a bit on the port, you'll pull out a lot of hair.

BTW. This isn't a problem particular to PICs.

Steve.

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: EraseMEstevebspam_OUTspamTakeThisOuTkcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1998\01\29@131941 by Tony Vilches
flavicon
face
Hi Wayne,

Code for a 4 MHz setup would be perfect.

I truly appreciate your help in this.

Tony.

1998\01\29@165853 by Wayne Foletta

flavicon
face
Tony and others:

It is taking a bit longer to extract, comment and test the code and
circuit. I should finish it over the weekend (2/1/98). I will post the
Web / FTP site for downloading the PIC 16C84 / 24LCxx assembly code and
demo circuit schematic.

- Wayne Foletta
BMI - Saratoga, CA

{Quote hidden}


'I2C Read and Write a byte from EEPROM'
1998\02\11@121322 by Wayne Foletta
flavicon
face
Hi PicListers

Sorry for the delay but this Microsoft Exchange server has been down.
The EEProm example code I promised is under the section "Engineering
Design and Support Files" at:

http://www.siliconsoft.com/ftp1site.htm

- Wayne Foletta
Saratoga, CA

{Quote hidden}

1998\02\11@194527 by Mitch Robbins

flavicon
face
Off list-

Thanks Wayne,

I haven't tried it yet, but I've been anxiously waiting.

Mitch Robbins

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