Searching \ for 'Master/Slave' 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/index.htm?key=masterslave
Search entire site for: 'Master/Slave'.

No exact or substring matches. trying for part
PICList Thread
'Master/Slave bus'
1998\01\09@093713 by Charles Laforge

picon face
Hi all

I am looking for information on implementing a data bus between a master
mcu, perhaps an HC11 or Pic, and other slave Pics.  What I need is
something that would take up no more than two or three i/o pins on the
pics.

Can anyone point me in the right direction?  Anybody have an example out
there on the www?  I appreciate any help you can give me on this.

Charles

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


'I2C master/slave mode for PIC to PIC comms'
1998\12\30@233452 by Jon Petty
picon face
Hello everyone,

I am trying to understand the difference between I2C master and slave modes.
I thought this would be intuitive, but after looking at the data sheet for the
PIC16C74, I see that it appears only I2C slave mode is available.  It mentions
I2C master mode with firmware and I am not sure what they mean by "firmware"?

Are I2C EEPROMS and other peripherals are the I2C master?

I am looking at using I2C to communicate between two PIC processors.  How do
they have two way communication if both are in slave mode?  I am sure one has
to be master.

I am sure I am missing something.  I thought the PIC would be master and
peripherals would be slave.

I see master and slave modes for SPI, is that the best way for two PICS to
talk?


Confused

Jon

1998\12\31@002801 by Clyde Smith-Stubbs

flavicon
face
On Wed, Dec 30, 1998 at 11:32:13PM -0500, Jon Petty wrote:
> I thought this would be intuitive, but after looking at the data sheet for the
> PIC16C74, I see that it appears only I2C slave mode is available.  It mentions

In hardware, yes, only slave mode is supported.

> I2C master mode with firmware and I am not sure what they mean by "firmware"?

Firmware is software that's in a ROM. What they mean is that you can do master
mode by bit-bashing in software.

> Are I2C EEPROMS and other peripherals are the I2C master?

No, they are slave devices.

> I am looking at using I2C to communicate between two PIC processors.  How do
> they have two way communication if both are in slave mode?  I am sure one has
> to be master.

Correct, one has to be a master. The I2C hardware on the 16C74 is intended to
allow the PIC to be addressed as a peripheral from something else.

But the good news is that master mode is not too hard to do in software - slave
mode is considerably harder, which is perhaps why it has hardware support.

Cheers, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: spam_OUTclydeTakeThisOuTspamhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger .....clydeKILLspamspam@spam@htsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1998\12\31@003445 by Tjaart van der Walt

flavicon
face
Jon Petty wrote:
>
> Hello everyone,
>
> I am trying to understand the difference between I2C master and slave modes.
> I thought this would be intuitive, but after looking at the data sheet for the
> PIC16C74, I see that it appears only I2C slave mode is available.  It mentions
> I2C master mode with firmware and I am not sure what they mean by "firmware"?

Mchip's claim for hardware support for I2C on PIC's is optimistic, if not bull.
It is very easy to implement master mode in software, but slave mode is not
trivial, because the timing constraints for the slave are much, much tighter.

>
> Are I2C EEPROMS and other peripherals are the I2C master?
No, they are always the slaves. Your micro will be the master.

>
> I am looking at using I2C to communicate between two PIC processors.  How do
> they have two way communication if both are in slave mode?  I am sure one has
> to be master.
The only two ways would be :
1) Place one in slave mode, and the other in master mode (do-able).
2) Place both in master mode, and implement the multi-master protocol (very hairy).

The better way would be to use async comms (serial).

>
> I am sure I am missing something.  I thought the PIC would be master and
> peripherals would be slave.
They are.

>
> I see master and slave modes for SPI, is that the best way for two PICS to
> talk?
Serial is better.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
tjaartspamKILLspamwasp.co.za  / \ AGAINST HTML MAIL

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS .....tjaartKILLspamspam.....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\12\31@103118 by Matt Bonner
flavicon
face
Clyde Smith-Stubbs wrote:
>
> But the good news is that master mode is not too hard to do in software - slav
e
> mode is considerably harder, which is perhaps why it has hardware support.
>
I believe it's because Philips' I2C patents - they demand a royalty for
hardware implementations of master mode, but not slave.  Didn't MChip
announce plans for a PIC with master mode hardware?  (I can't find my
copy of their latest product line card - maybe they already have one.)

--Matt

1998\12\31@114925 by Andy Kunz

flavicon
face
>I believe it's because Philips' I2C patents - they demand a royalty for
>hardware implementations of master mode, but not slave.  Didn't MChip
>announce plans for a PIC with master mode hardware?  (I can't find my
>copy of their latest product line card - maybe they already have one.)

The 14000 has it I believe.  The 17C parts do also.

Andy

==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\12\31@124741 by John Payson

flavicon
face
> I am trying to understand the difference between I2C master and slave modes.
> I thought this would be intuitive, but after looking at the data sheet for the
> PIC16C74, I see that it appears only I2C slave mode is available.  It mentions
> I2C master mode with firmware and I am not sure what they mean by "firmware"?

|Mchip's claim for hardware support for I2C on PIC's is optimistic, if not bull.
|It is very easy to implement master mode in software, but slave mode is not
|trivial, because the timing constraints for the slave are much, much tighter.

Implementing I2C slave mode in software is apt to be, for all
practical purposes, impossible without either:

[1] At least some hardware support (could probably be handled with
   a couple of 74HC chips), or

[2] The ability to run a 20MHz part, doing nothing except looking
   for stuff to happen on the I2C bus; even here you'd probably
   have a hard time meeting the spec 100%.

The problem is that I2C requires the slave to respond within about
a microsecond to anything that happens on the bus.  Although the
slave can buy a lot of time by asserting the clock wire for awhile
on each bit (preventing the master from pulling it high until the
slave can deal with it), the line has to be grabbed within about 1us
of when the master pulls it low; in addition, slaves should avoid
pulling the clock low for data in which they're not interested.

I've not used the PIC's hardware I2C support, but it certainly is
much more full-featured than that of, say, the Philips 87C751 which
requires CPU intervention after each bit is received.  The hardware
there for detecting start/stop conditons and holding the clock wire
after each bit makes I2C slave mode possible, though not much fun.

Compared with slave mode, master mode is a breeze.  Especially when
you consider that most devices can accept/supply data as fast as
it's clocked in/out, all an I2C master has to do is clock bits at
whatever rate it likes (though it should check the clock line every
time it raises it, to ensure that it has in fact risen and wait up
to 1ms if it hasn't).  It's this difference in response requirements
(read the data whenever vs respond within 1us) which prompts many
vendors to supply I2C slave--but not master--support in hardware.

Note, btw, that it may be possible to put the SSP hardware to some
use in I2C communications.  If you set the thing up in SPI mode and
hand-bit-bang the start/stop sequences, I think you should be able
to use the SPI port to read/write data as needed.  The one potential
problem with this method is that the SPI port will not respond to
handshaking requests on the clock line--it will clock data at the
requested speed regardless of whether its intended recipient is
ready.  For most chips this is not a problem (they're always ready)
but for others it should be bourne in mind.

1998\12\31@131239 by Jon Petty

picon face
In a message dated 12/30/98 10:35:21 PM US Mountain Standard Time,
EraseMEtjaartspam_OUTspamTakeThisOuTWASP.CO.ZA writes:

<< > I am looking at using I2C to communicate between two PIC processors.  How
do
> they have two way communication if both are in slave mode?  I am sure one
has
> to be master.
The only two ways would be :
1) Place one in slave mode, and the other in master mode (do-able).
2) Place both in master mode, and implement the multi-master protocol (very
hairy).

The better way would be to use async comms (serial).
 >>

If I use the on chip UART to talk to another PIC do I have to use  MAX232 to
convert signal?

What is the easiest way? My last project I used software in two PICS for
serial comms. It worked great at 9600 inverted baud with handshaking. I wanted
to use a hardware UART on one PIC to help with other timing issues.

I guess hardware can't create an inverted signal. I really didn't want to add
another part (MAX232).

What do you think?

Jon

1998\12\31@132041 by Keith M. Wheeler

flavicon
face
I2C master mode takes a lot of real estate in silicon, however it
is trivial in software.  Take a look at the I2C portion of a 17C756
die (it has master mode), it's a bit bigger than I2C chunk of a 16C74.

>From what I've heard from Microchip, the low and mid-range parts
didn't have I2C master for cost savings.

-Keith Wheeler
ARMA Design                             http://www.ARMAnet.com/


At 08:31 AM 12/31/98 -0700, Matt Bonner wrote:
>Clyde Smith-Stubbs wrote:
>>
>> But the good news is that master mode is not too hard to do in software
- slave
{Quote hidden}

1998\12\31@134930 by Matt Bonner

flavicon
face
Jon Petty wrote:
>
> If I use the on chip UART to talk to another PIC do I have to use  MAX232 to
> convert signal?

You only need the MAX232 to drive a lengthy cable and/or to provide the
logic levels a PC expects.
>
> What is the easiest way? My last project I used software in two PICS for
> serial comms. It worked great at 9600 inverted baud with handshaking. I wanted
> to use a hardware UART on one PIC to help with other timing issues.

Like other posters, I stay away from I2C for PIC-PIC communication (in
my case because the oscillator is *way* to slow to do it reliably).  I
would suggest using software and/or hardware UARTs (no hardware
handshaking if IO is tight).  In one project, I've got a 16C74 talking
with multiple 16c63s - I use the hardware UART on the '63s (no level
conversion) and several bit-banged UARTs on the '74.  The maximum baud I
can get out of the '63 is a non-standard 2048bps (32.768kHz osc) and
since the '74 has a 4MHz clock, there's no problem talking with several
at a time.  Right now each '63 "slave" uses 2 comm lines on the '74 but
I'll change that to a total of 2 when IO gets tight.
>
>  I guess hardware can't create an inverted signal. I really didn't want to add
> another part (MAX232).

Again, you don't need a line driver if you're talking to another PIC
UART over a relatively short distance.

--Matt

1998\12\31@144342 by Mike Keitz

picon face
On Thu, 31 Dec 1998 13:08:41 EST Jon Petty <PHXSYSspamspam_OUTAOL.COM> writes:

>I wanted
>to use a hardware UART on one PIC to help with other timing issues.
>
> I guess hardware can't create an inverted signal. I really didn't
>want to add
>another part (MAX232).

The hardware UART works with only one polarity, where start bits are
logic 0 and stop bits are logic 1.  If you connect this signal to a
MAX232 or similar chip, the output is correct to use for an RS-232 line.

Since the transmitter and receiver use the same polarity, a PIC can talk
to another PIC just by connecting them directly.  Make sure the baud rate
is the same on both of course.

If you only have 2 PICs, it's real simple, just connect transmit on one
to receive on the other and vice versa, making a full-duplex connection.
With more than 2 PICs, it would be possbile to commect all the transmits
and all the receives to make a 1-wire bus, with some protocol arranged so
only one is transmitting at a time.  The ones that are not transmitting
would set their transmit pins to TRIS off.  A pull-up resistor would be a
good idea to be sure the bus stays idle when all the PICs are TRIS off.
Another option, depending on how data flows among the PICs would be to
connect them in a ring.  Transmit of one to receive of the next, etc.
More port pins can be used as handshaking signals if desired.  A software
UART can be used on one or more PICs, making sure the output polarity is
correct.


___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1998\12\31@152231 by Jon Petty

picon face
THANKS FOR THE HELP EVERYONE

JON

1998\12\31@200310 by Kelly J Kohls

picon face
On Thu, 31 Dec 1998 08:31:36 -0700 Matt Bonner <@spam@mbonnerKILLspamspamSUNADA.COM>
writes:
>Clyde Smith-Stubbs wrote:
>>
>> But the good news is that master mode is not too hard to do in
>software - slave
>> mode is considerably harder, which is perhaps why it has hardware
>support.
>>
>I believe it's because Philips' I2C patents - they demand a royalty
>for
>hardware implementations of master mode, but not slave.  Didn't MChip
>announce plans for a PIC with master mode hardware?  (I can't find my
>copy of their latest product line card - maybe they already have one.)

I believe the new 16F876/877 does implement both master and slave modes
in hardware.  Page 71 of the datasheet covers these modes.

Kelly Kohls
Amateur Radio Callsign: N5TLE
Home E-Mail Address: KILLspamkkohlsKILLspamspamjuno.com or RemoveMEn5tleTakeThisOuTspamqsl.net
Homepage URL: http://www.qsl.net/n5tle

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]


'I2C master/slave mode for PIC to PIC comms'
1999\01\03@234747 by Tjaart van der Walt
flavicon
face
Jon Petty wrote:
>
> In a message dated 12/30/98 10:35:21 PM US Mountain Standard Time,
> spamBeGonetjaartspamBeGonespamWASP.CO.ZA writes:
>
> << > I am looking at using I2C to communicate between two PIC processors.  How
> do
>  > they have two way communication if both are in slave mode?  I am sure one
> has
>  > to be master.
>  The only two ways would be :
>  1) Place one in slave mode, and the other in master mode (do-able).
>  2) Place both in master mode, and implement the multi-master protocol (very
> hairy).
>
>  The better way would be to use async comms (serial).
>   >>
>
> If I use the on chip UART to talk to another PIC do I have to use  MAX232 to
> convert signal?

No, as long as you are not using them more than a few meters apart.

>
> What is the easiest way? My last project I used software in two PICS for
> serial comms. It worked great at 9600 inverted baud with handshaking. I wanted
> to use a hardware UART on one PIC to help with other timing issues.

The UARTS on the PICs are extremely easy to get going.

>
>  I guess hardware can't create an inverted signal. I really didn't want to add
> another part (MAX232).
>
> What do you think?
Async comms is very forgiving, and a lot easier to debug than I2C (if you
want to implement slave mode, that is).

For Async comms debugging, I use 12V from the PC side, and 5V from the
dev board side, with simple transistor inverters. 4 resistors and 2
transistors. I hope this won't start a thread on TTL<->RS232.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
TakeThisOuTtjaartEraseMEspamspam_OUTwasp.co.za  / \ AGAINST HTML MAIL

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS RemoveMEtjaartspamTakeThisOuTsms.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          |
|--------------------------------------------------|

1999\01\16@075035 by Goovaerts

flavicon
face
To implement ' master of the bus ' with the SSP module --> completely
software

For more info go to the site of PHILLIPS and search for I2C info (pdf file
!!)

Greetings Glenn Goovaerts

{Original Message removed}


'[PIC]:1 wire master/slave problem'
2003\07\21@195936 by Dave Stowe
picon face
I have a PIC reading 1 wire devices, some on a bus, and some through a receptacle. My problem is I need to get the data in the PIC out through the receptacle. Can the PIC be made a Slave ? ( a PIC 16F877 ). I am storing data in the pic of who's key and date, and the most convenient way of retrieval is through the button receptacle. Are there any dummy keys available with wires coming out, and how do I turn the oic into a slave ?
All my thanks in advance Dave



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 20/07/2003

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\07\22@073659 by Nigel Orr

flavicon
face
pic microcontroller discussion list <> wrote on Tuesday, July 22, 2003
12:59 AM:

> I have a PIC reading 1 wire devices, some on a bus, and some
> through a receptacle. My problem is I need to get the data in
> the PIC out through the receptacle. Can the PIC be made a
> Slave ? ( a PIC 16F877 ).

Assuming the device is for production, the most legitimate way to turn the
PIC into a slave is probably to attach a memory device to it and 'hi-jack'
its identity.  On boot, read the real 1-wire device, and use its identity
for the PIC circuit.  Then respond to memory requests with the contents of
the PIC memory instead.

I've not implemented this, but had it in mind for another purpose... the
open drain outputs should be usable as a 1-wire slave port, but you might
need to connect the bus to an interrupt pin as well to avoid missing
traffic!

I _think_ there are dummy iButtons available, but it might be easier to put
a standard connector on the bus and use it instead.  Alternatively, you
could use a memory iButton, dump the PIC data to it, then take it to
another reader to read the data into another PIC.

Nigel
--
Nigel Orr, Design Engineer                 nigelEraseMEspam.....axoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

--
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

2003\07\22@080402 by Mauricio Jancic

flavicon
face
Dave,
       Take a look at this...

http://dbserv.maxim-ic.com/quick_view2.cfm?qv_pk=2977

I think this is what you need

Mauricio Jancic
Janso Desarrollos
(54) 11 4542 3519
Republica Argentina
Microchip Consultant Program Member


{Original Message removed}

'[PIC]:Re: 1 wire master/slave problem'
2003\07\22@090806 by j. d. s.

flavicon
face
actually i believe this is the interface part you need:
http://pdfserv.maxim-ic.com/arpdf/DS2404S-C01.pdf

it's basically a dual port RAM; one side faces the uP
and the other side faces the onewire net.  the data sheet
indicates that it is designed expressly for the type of
situation you are describing below.


> -----Original Message-----
> <> wrote on Tuesday, July 22, 2003 12:59 AM:
>
>> I have a PIC reading 1 wire devices, some on a bus, and some through
>> a receptacle. My problem is I need to get the data in the PIC out
>> through the receptacle. Can the PIC be made a Slave ? (a PIC 16F877).

--
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

2003\07\22@200622 by Dave Stowe

picon face
Fantastic !. Thanks to all who replied. Problem solved.
Thanks again !

----- Original Message -----
From: "j. d. s." <EraseMEjds-picspamOPQUA.COM>
To: <RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU>
Sent: Tuesday, July 22, 2003 1:56 PM
Subject: [PIC]:Re: 1 wire master/slave problem


> actually i believe this is the interface part you need:
> http://pdfserv.maxim-ic.com/arpdf/DS2404S-C01.pdf
>
> it's basically a dual port RAM; one side faces the uP
> and the other side faces the onewire net.  the data sheet
> indicates that it is designed expressly for the type of
> situation you are describing below.
>
>
> > {Original Message removed}


'[PIC]: Master/slave devices in LaLa Land'
2003\11\26@133233 by Charles Craft
picon face
Only in the land of Fruits and Nuts

http://www.cnn.com/2003/TECH/ptech/11/26/master.term.reut/index.html

'Master' and 'slave' computer labels unacceptable, officials say
Wednesday, November 26, 2003 Posted: 11:33 AM EST (1633 GMT)

LOS ANGELES, California (Reuters) -- Los Angeles officials have asked that manufacturers, suppliers and contractors stop using the terms "master" and "slave" on computer equipment, saying such terms are unacceptable and offensive.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


'[SX] SX28 Master/Slave I/O series resistor questio'
2005\11\29@191015 by Thomas Taylorn/a
flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Thomas Taylor wrote:

Greetings from the Pacific Northwest,

First, is it necessary to provide some value of series limiting resistor between the transmitting output pins on a Master SX and the receiving input pins on a Slave SX? (And what value would be best?)

If the preceding is true, with multiple Slave chips, would the resistors be best placed on each interconnected input pin of each Slave (to provide isolation from each other), as opposed to one resistor on each output pin of the Master. (I'm thinking the former would be the preferred configuration because of the following thoughts.)

I think the fundamental question I have is:  With several SX28s powering up at the same time - therefore several programs all starting near the same time - in this not so perfect world - all of the I/O pins will not arrive at their assigned mode at the same time. I suppose wonderful things could happen in all those undefined combinations of I/O conditions. Is this true?


It would be nice to save the real-estate on the PCBs by not having to add more resistors, but I want to be as safe as possible.


To resist or not resist...That is the question.


Thanks for reading.


Tom

(The creek is up and the micro-hydro is making watts!)
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=98680
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\11\30@033357 by naten/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, nate wrote:

Tom,
Perhaps someone with intricate knowledge of the inner workings of the SX will give a better answer, but I would not bother to put in resistors.  If momentary undefined pins were an issue, any SX design that had certain pins grounded (eg. an active high pushbutton) at startup could be a potential problem.  The same would hold true for the inverse situation (I/O pins held high).  I would assume the  design rules used when making the SX prohibited such a problem.

Nate
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=98680#m98702
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\11\30@034745 by g_daubachn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Thomas,
fortunately, at power-on or reset, all SX I/O pins are automatically configured as inputs, until the software clears certain bits in the port's TRIS registers. So it is up to your software to make sure that no interconnected I/O pins generate offending states. If this is not the case, I think series limiting resistors are not required.

If you want to add resistors as an additional safety measure, let's assume the worst case: One output pin being low (0V) and the other pin being high (+5V). According to the SX datasheet, the max. allowable sink or source current per I/O pin is 45mA. A resistor of 111Ohm would limit the current to that value. So, a value between 150 and 220Ohm would be fine.

During the relatively long time I'm prototyping SX-based applications, it happened more than once that I had shorts on output pins, and so far, this never destroyed any of my SXes. Seems as if the output circuits are relatively robust, and possibly have some internal current protection. Nevertheless, I don't want to encourage you to ignore output protection :-) .

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=98680#m98703
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\11\30@064606 by Coriolisn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Coriolis wrote:

If you are confident you will not make programming errors, they won't be needed. Since everyone does on occasion, you may want to incorporate them as an additional safty measure. If you are connecting more than two SXs to the same line, each should have a smaller resistor (say around 110?) to protect all possible combinations of IO error. Though the standard method of connecting multiple devices together is using an open collector configuration. This is done in an SX by switching between an output whose value is always 0 and input (High-Z), and each line is pulled up to Vdd through a resistor. In this configuration, there is never a situation where the line is driven an active high (it is left alone (input), or it is pulled down (output of 0)), since there is never a situation where an output high and an output low happen at the same time, there is no chance of an IO error.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=98680#m98720
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)


'[pic] Some questions about I2C Master/Slave Modes'
2005\12\03@112236 by regen / Mailinglists
flavicon
face
Hi all,

I did a lot of projects now with I2C Bus on a 16F872. All of those
projects had the I2C Bus in Master-Mode in Single Master Enviroments.

Now, I want to use it the first time in a Multi-Master-Mode. The 16F872
has a MSSP and support that. But how do I have to handle the collision
issue in software, or otherway round, do I have to do anything, or is ot
handled completly by the MSSP?

Is there any assembler code out there, I can use a template?

Another issue is to use the I2C as master and slave. What is the best
way to do that? My idea is to set up the MSSP as slave and - if needed -
to change to a master, sending data, and then return to slave mode?

Thanks for any idea.

Best Jens

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