Searching \ for 'I2C sharing lines with Dallas serial' 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 sharing lines with Dallas serial'.

Truncated match.
PICList Thread
'I2C sharing lines with Dallas serial'
1996\08\27@185530 by Wireless Scientific

flavicon
face
Folks,

I'm running a little tight on PIC I/O pins, namely I have three lines
available. I would like to tie a Dallas DS1302 RTC and Philips 8570 serial
RAM onto these three lines.

PIC     RTC     RAM
B0      RST\
B1      IO      SDA
B2      SCLK    SCL

My question deals with possible protocol collisions with these two devices.
It's easy to not select the RTC with RST line when talking to the RAM.
However the reverse is not true. Do you think talking to the RTC with its
protocol on B1 and B2 could inadvertantly issue legitimate commands to the
RAM?

I know some of you have pondered this condition, any ideas?

Thanks,
craig

1996\08\27@190337 by John Payson

flavicon
face
> PIC     RTC     RAM
> B0      RST\
> B1      IO      SDA
> B2      SCLK    SCL
>
> My question deals with possible protocol collisions with these two devices.
> It's easy to not select the RTC with RST line when talking to the RAM.
> However the reverse is not true. Do you think talking to the RTC with its
> protocol on B1 and B2 could inadvertantly issue legitimate commands to the
> RAM?
>
> I know some of you have pondered this condition, any ideas?

To avoid selecting the RAM, you must prevent its SDA pin from falling while
its SCL pin is high, or else ensure that if its SDA pin does fall while SCL
is high that when it rises again SCL either high or 'still high'.

1996\08\27@204210 by Henry Carl Ott

picon face
At 07:02 PM 8/27/96 -0400, you wrote:
>Folks,
>
>I'm running a little tight on PIC I/O pins, namely I have three lines
>available. I would like to tie a Dallas DS1302 RTC and Philips 8570 serial
>RAM onto these three lines.
>

-----------snip------------------------
>
>Thanks,
>craig

Why not use the Phillips PCF8583?
RTC with 256 bytes of SRAM in one package.


carl

----------------------------------------------------------------
Henry Carl Ott   N2RVQ   | talk/chat  carlott@204.74.7.186
spam_OUTcarlottTakeThisOuTspaminterport.net    | http://www.interport.net/~carlott/
----------------------------------------------------------------
"A day job...in an office? My worst nightmare!"-Ticknophobia

1996\08\27@231004 by Wireless Scientific

flavicon
face
At 08:41 PM 8/27/96 -0400, Henry Carl Ott wrote:
{Quote hidden}

Carl,

It appears like I need to do a little more "research" into Philips'
offerings. Thanks for the tip!

craig

1996\08\27@232855 by Wireless Scientific

flavicon
face
At 08:41 PM 8/27/96 -0400, Henry Carl Ott wrote:
{Quote hidden}

Carl,

I did actually look around immediately after I received your mail. The
PCF8583 is not listed at the Philips site. It is however on various chip
directories.
Is this a new part?

craig

1996\08\28@130528 by Jimmie Curry

flavicon
face
----------
> I'm running a little tight on PIC I/O pins, namely I have three lines
> available. I would like to tie a Dallas DS1302 RTC and Philips 8570
serial
> RAM onto these three lines.
>
> My question deals with possible protocol collisions with these two
devices.
> It's easy to not select the RTC with RST line when talking to the RAM.
> However the reverse is not true. Do you think talking to the RTC with its
> protocol on B1 and B2 could inadvertantly issue legitimate commands to
the
> RAM?
>
> craig

Things to consider:

Many I2C devices do not have a reset line which would assure proper initial
conditions.  These devices often depend on a "power up" to reset to initial
conditions. It is prudent to issue a sequence of signals which would
effectively abort any ongoing commands.  This is important in embedded
systems which may be reset without going through a "power up".  An I2C buss
will not work properly as a shared resource!  Care must be taken in a
multitasking system to allow one and only one task to control the buss.  A
common pitfall is to attempt to control the buss in foreground and also
allow access by an ISR.

The Phillips data book titled "I2C Peripherals for Microcontrollers", 1992
is an excellent reference.  I may be able to find code which issues the
sequence of signals needed to resync the devices if your interested.

Thanks,
Jimmie

       Jim Curry and Associates
       13339 N. Central Expy.
       Dallas, TX 75243
       Voice:    214 680-1540
       Fax:      214 680-1562
       Email:    .....jcurryKILLspamspam@spam@airmail.net
       Web Page: http://web2.airmail.net/jcurry/

1996\08\28@143322 by Wireless Scientific

flavicon
face
At 12:03 PM 8/28/96, Jimmie Curry wrote:
>Many I2C devices do not have a reset line which would assure proper initial
>conditions.  These devices often depend on a "power up" to reset to initial
>conditions. It is prudent to issue a sequence of signals which would
>effectively abort any ongoing commands.  This is important in embedded
>systems which may be reset without going through a "power up".  An I2C buss
>will not work properly as a shared resource!  Care must be taken in a
>multitasking system to allow one and only one task to control the buss.  A
>common pitfall is to attempt to control the buss in foreground and also
>allow access by an ISR.
>
>The Phillips data book titled "I2C Peripherals for Microcontrollers", 1992
>is an excellent reference.  I may be able to find code which issues the
>sequence of signals needed to resync the devices if your interested.
>
>Thanks,
>Jimmie



Jimmie,

Thanks for the information, I'll order the I2C data book ASAP. After the
recent comments from this list, I'm leaning towards I2C only. Now if I can
only get availibility.

Thanks,
craig

1996\08\28@154325 by Henry Carl Ott

picon face
At 11:27 PM 8/27/96 -0400, you wrote:
----snip--------------
>Carl,
>
>I did actually look around immediately after I received your mail. The
>PCF8583 is not listed at the Philips site. It is however on various chip
>directories.
>Is this a new part?
>
>craig
>

Well, the 8583 part is listed in the 1992 Philips/Signetics data handbook
(which has been already mentioned as a good reference for I2C).
If you can't find it in the current data books/sites it might be
discontinued. It's certainly worth finding out, because it's handy part.
How big is your production run? If it's low I might be a able to point you
to a cheap surplus source of SMD PCF8583.

hope this helps...

carl

----------------------------------------------------------------
Henry Carl Ott   N2RVQ   | talk/chat  carlott@204.74.7.186
carlottspamKILLspaminterport.net    | http://www.interport.net/~carlott/
----------------------------------------------------------------
"A day job...in an office? My worst nightmare!"-Ticknophobia

1996\08\28@174032 by Wireless Scientific

flavicon
face
At 3:43 PM 8/28/96, Henry Carl Ott wrote:
{Quote hidden}

The newest I2C databook is on the way. After it arrives, I'll verify that
8583 is still in production. Both Marshall and Newark have it listed.


Have you used it with a battery to keep time and NVRAM across power downs?

craig

1996\08\28@191522 by Henry Carl Ott

picon face
At 05:46 PM 8/28/96 -0400, you wrote:
>>----snip--------------

>>
>>carl
>
>The newest I2C databook is on the way. After it arrives, I'll verify that
>8583 is still in production. Both Marshall and Newark have it listed.
>
>
>Have you used it with a battery to keep time and NVRAM across power downs?
>

Craig,

The actual project was battery powered to begin with. I used a 16c54 to
talk to the 8583 RTC and log switch closure events into a 93LC66. I wanted
EE storage so that data would be saved even with battery failure. On demand
the device would dump the logged data into a pc via the serial port. I only
used a couple of bytes of the 8583 SRAM as a sanity check to see if battery
power had ever failed. Everything ran on a 3volt lithium coin cell.
The fun part of the project was fitting the I2C code, the eeprom support,
and a small rs232 mini monitor routine into a 16c54. When I was done I had
broken a whole slew of programming rules, but I still had one program
location free.  I would have killed for two more levels in the hardware
stack. Don't ask why I used the parts I did, they were on the shelf.


And as a bonus to anybody else following this thread:

I have a quantity of SMD PCF8583 on the shelf collecting dust. If anyone
wants a couple (with crystals) send a SASE to the below snailmail address
and I'll drop them in the post. You are on your own for the data sheets.
The fine print: I'm doing this as a favor to experimenters on the pic
mailing list that might have trouble getting samples from the manufacturer.
So first come, first serve till I run out of the ones I set aside.

later...

carl

H. Carl Ott
22 Nixon Ave.
Staten Island, NY 10304-2210

1996\08\28@193220 by Robert Lunn

flavicon
face
>Many I2C devices do not have a reset line which would assure proper initial
>conditions.  These devices often depend on a "power up" to reset to initial
>conditions. It is prudent to issue a sequence of signals which would
>effectively abort any ongoing commands.  This is important in embedded
>systems which may be reset without going through a "power up".

       I have successfully run an I2C eeprom and a non-I2C LCD controller
       chip on the same clock/data lines.  There is no intrinsic reason
       this can't be done, as long as due attention is given to the
       generation of I2C start and stop states.

       However, the comments quoted above are correct.  You should never
       assume the state of the I2C component when you begin a transaction.

___Bob

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