Searching \ for '[PIC] I2C between two PICs' 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 between two PICs'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] I2C between two PICs'
2005\04\12@215124 by Jinx

face picon face
part 1 3384 bytes content-type:text/plain; (decoded 7bit)

Following on from the "Hot swappable PIC boards" thread, I've
started work on the I2C buss. I've got the basic transfer from the
master 452 to the slave 88s working OK (see attached analyser
o/p and code snippets)

My question is about Figure 10.7 of the F88 d/s (DS30487C) and
what I should be doing, if anything, about generating a NACK (or
not generating an ACK, however you want to look at it). Presently
the F88 waits for an "X" in the data stream and then simply hops
out of the I2C section. The plan currently is to send a constant-length
packet over the buss from the 452 to the appropriate F88, so is a
NACK necessary ?

Also, what could be the explanation for the double-blip of the PortB,3
marker in the F88 code ? Presumably it has something to do with BF,
but that should have been cleared by reading SSPBUF

TIA

=============

18F452

        mov     b'00101000',sspcon1
;                    1               SSPEN
;                      1000          master

        mov     b'10000000',sspstat
;                  1                 slew rate off

        mov     0x61,sspadd        ;97kHz @ 39.3216MHz

        call    d2p

        bsf     startb             ;start bit
        btfsc   startb
        bra     $-2

        call    d2p

        mov     "0",sspbuf         ;slave address - write
        btfsc   sspstat,r_w
        bra     $-2

        call    d2p

        mov     "T",sspbuf
        btfsc   sspstat,r_w
        bra     $-2

        call    d2p

        mov     "e",sspbuf
        btfsc   sspstat,r_w
        bra     $-2

        call    d2p

        mov     "s",sspbuf
        btfsc   sspstat,r_w
        bra     $-2

        call    d2p

        mov     "t",sspbuf
        btfsc   sspstat,r_w
        bra     $-2

        call    d2p

        mov     "0",sspbuf
        btfsc   sspstat,r_w
        bra     $-2

        call    d2p

        mov     "X",sspbuf
        btfsc   sspstat,r_w
        bra     $-2

        call    d2p

        bsf     stopb              ;stop bit
        btfsc   stopb
        bra     $-2

here     bra     here

d2p      bsf     portd,2  ;marker ;nb latd
        nop
        nop
        nop
        nop
        bcf     portd,2
        return

=============

16F88

        banksel sspadd
        mov     "1",sspadd   ;device I2C address

        banksel sspcon
        mov     b'00000110',sspcon
;                       11    ;I2C slave 7-bit address

        banksel sspbuf
        movfw   sspbuf       ;clear BF

        banksel sspcon
        bcf     sspcon,sspov ;clear overflow bit
        bsf     sspcon,sspen ;enable I2C module
        bsf     sspcon,ckp   ;clock enable

        movlw   r_byte1
        movwf   fsr

next_in  bank1
wait_bf1 btfss   sspstat,bf
        goto    $-1

        bank0
        bsf     portb,3   ;marker
        nop
        nop
        nop
        bcf     portb,3

        bcf     pir1,sspif

cpy1     movff   sspbuf,indf
        xorlw   "X"
        bz      flash
        incf    fsr
        goto    next_in

here     goto    here

flash    bsf     led
 etc

===============================================
If you aren't part of the solution, you're part of the precipitate





part 2 4901 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\04\12@224057 by Jinx

face picon face
> Also, what could be the explanation for the double-blip of the
> PortB,3 marker in the F88 code ? Presumably it has something
> to do with BF, but that should have been cleared by reading
> SSPBUF

To answer my own question -

I see in Fig 10.6 that BF is re-set on the 8th clock (and the wait_bf1
loop picks that up), although I don't think that's mentioned explicity
in the text. More probably it's implied by the explanation of something
else


2005\04\17@003249 by Jinx

face picon face
No takers for my question ? - What is the purpose of a NACK ?

Is it a terminating  /ACK in a data stream with an indeterminate
number of bytes ? Which needs to be detected by the status of
the ACKSTAT and ACKDT bits ?

Is that right ?

This thoroughly boggled me

http://www.piclist.com/techref/microchip/i2c77x.htm

>From 18F452 manual, DS39564B, p137

ACKSTAT : Acknowledge Status bit (Master Tx mode only)

1 = Acknowledge was not received from slave
0 = Acknowledge was received from slave

ACKDT : Acknowledge Data bit (Master Rx mode only)

1 = Not Acknowledge
0 = Acknowledge sequence idle

which doesn't seem to fit with descriptions in Philips' I2C
Peripherals book. Am I a victim of poor terminology ?

Cn someone please break this down into words of one syllable

2005\04\17@095048 by olin_piclist

face picon face
Jinx wrote:
> No takers for my question ? - What is the purpose of a NACK ?
>
> Is it a terminating  /ACK in a data stream with an indeterminate
> number of bytes ? Which needs to be detected by the status of
> the ACKSTAT and ACKDT bits ?

I'm not sure what your question is, but the ACK bit is sent by the receiver
after receiving each byte.  It lets the transmitter know that someone was
out there and received the byte.  A IIC transfer can not continue after a
NACK.  A deliberate NACK can used to indicate the end of variable length
transfers.  The ACK or NACK response to the address byte is also used by the
master to determine whether there is any slave out there responding to that
address.

Beware of the MSSP bug where the master can see NACK even when a slave sent
ACK.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\17@105202 by Bob Axtell

face picon face
The ACK signal is the way that the Master knows that everything is working.
Here's how it works:

The normal state of the I2C system is always both signals high, normally
two open collector devices with pullups. The START FLAG occurs when the
DATA line goes LOW before the CLOCK line. When all slaves on a I2C bus
see a START FLAG, they are suddenly attentive, because they know that
and ADDRESS byte is coming, i.e. the start of a new transmission.

WRITING DATA FROM MASTER TO SLAVE

1, The Master sends and address out to one (or more) I2C preipherals. The
Master supplies the clock. (If the Master stops supplying the clock,
it is NO LONGER a Master).

2. The data travels from the Master to the slave. The data is clocked by
8 clock
cycles. At the NINTH clock cycle, The SLAVE responds with an ACK, by simply
driving the DATA line low for one clock cycle.  The fact that the CORRECT
peripheral sent its ACK in response  indicates WITHOUT QUESTION that
the peripheral is alive, present, and can accept more commands. The slave
will ALWAYS respond to this (unless it to doing some extraordinary thing,
such as "flashing" data into a memory cell array if it is a flash chip).
This is
the COMMAND / DEVICE ADDRESS byte

3. Usually there are one or more bytes of address bytes (depends on what
the
SLAVE chip does) and again, after the 8 bits of data, a 9th bit is
expected as
long as that data byte is required.

4. Finally, if data is to be written to the slave, it acknowledges that
it is taking
each byte by pulling down during the 9th. When the chip can no longer take
anymore data, it no longer acknowledges by pulling down, indicating to the
Master that fact.

5. The Master then  carefully raises the CLOCK followed by the DATA, a STOP
FLAG,  which signals to all devices on the  I2C bus that they can stand
down.
In fact, some I2C chips drop into a low power mode after receiving a
STOP FLAG.

READING DATA FROM SLAVE TO MASTER

1, The Master sends and address out to one (or more) I2C preipherals. The
Master supplies the clock. (If the Master stops supplying the clock,
it is NO LONGER a Master).

2. In order to set the address before sending the data, the read cycle looks
exactly like a WRITE transmission, except that after the addresses are
sent, the Master issues a STOP FLAG. This leaves att the address values
set internally.

3. The master then immediately sends a START FLAG, then sends a
special version of the COMMAND / DEVICE ADDRESS byte Command
which has the A0 bit changed to indicate that the SLAVE must return
data.

4. The slave now places ITS data onto the DATA line, and 8 clocks are
provided (by the Master, or course), but THIS TIME, the Master tells the
slave that it got the data and wants more be pulling down the DATA line
on the 9th bit. When the Master no longer wants anymore data, it no longer
acknowledges by pulling down, indicating to the Slave that the transmission
will be done. The SLAVE expects a STOP FLAG to occur after this.

5. The Master then  carefully raises the CLOCK followed by the DATA, a STOP
FLAG,  which signals to all devices on the  I2C bus that they can stand
down.

NOTES: ON POWER UP

About the only time that I2C devices become unsynchronized is at powerup.

This happens because the internal state machine can power up in any state,
A device can even powerup locking down the DATA line!  If that occurs,
simply
clock  at least 9 bits with the DATA line undriven and the offending
slave will
release the bus. Usually I simply loop until  the data line is clear .

Once the DATA line is clear, execute a  START FLAG followed by a STOP FLAG.
All slaves are then in synch.

- - - - -

This transmission scheme, developed in the 1970s to send control info on TV
chassis, remains to this day the most efficient 2-wire signalling method
ever
developed.

--Bob Axtell



Jinx wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
spam_OUTattachTakeThisOuTspamengineer.cotse.net .
1-866-263-5745 USA/Canada
http://beam.to/azengineer

2005\04\17@124922 by olin_piclist

face picon face
Bob Axtell wrote:
> The ACK signal is the way that the Master knows that everything is
> working.

It is important to distinguish between master/slave and sender/receiver.
The ACK bit is always driven by the receiver, whether that is the master or
the slave.

> 3. Usually there are one or more bytes of address bytes (depends on
> what the
> SLAVE chip does)

There are only 2 types of IIC addresses, 7 bit and 10 bit.  I've found chips
that support only 7 bit to be far more common.  While it is possible that
there is an additional address byte since 10 bit addressing could be used, I
would NOT say that it is "usual".  For most ordinary purposes you can
consider IIC to be a 7 bit addressed bus and forget about 10 bit address
mode.  In no cases are there more than 2 address bytes.

> 4. Finally, if data is to be written to the slave, it acknowledges
> that
> it is taking
> each byte by pulling down during the 9th. When the chip can no longer
> take anymore data, it no longer acknowledges by pulling down,
> indicating to the Master that fact.

This is correct.  I just want to point out that this is only one way of
ending a write sequence.  The master can chose to stop at any time by
issuing a BUS STOP, whether the slave ACKed the last byte or not.

> 2. In order to set the address before sending the data, the read
> cycle looks exactly like a WRITE transmission, except that after the
> addresses are sent, the Master issues a STOP FLAG.

No!  Whether a IIC sequence is a read or a write is indicated by the LSB of
the first address byte.  Both master and slave then know which direction
subsequent bytes will be sent.  When the master writes a BUS STOP, the IIC
sequence is over.  Any new sequence will need to start with a new BUS START
and address byte, and therefore can be read or write indpendently of the
previous.  In IIC, there is no requirement to preserve state from before the
last BUS START or BUS STOP.  Whatever happens in one sequence has no effect
on the next as far as the IIC bus is concerned.

> This transmission scheme, developed in the 1970s to send control info
> on TV chassis, remains to this day the most efficient 2-wire
> signalling method ever
> developed.

That's a very general statement, which is neither useful nor correct.  IIC
can be a good solution to particular problems, but can't possibly be the
"most efficient" because each application has its own set of tradeoffs and
"efficiency" will have many different meanings in different contexts.
Comparing IIC to RS-485 to CAN, for example, outside the context of a
particular problem is like comparing apples to cars to fenceposts.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\17@151845 by Bob Axtell

face picon face
Gee Whiz, Olin, I'll check with you first next time, OK?
What I said is the way my I2C works. Nobody was answering
so I took a crack at it.

--Bob

Olin Lathrop wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
.....attachKILLspamspam@spam@engineer.cotse.net .
1-866-263-5745 USA/Canada
http://beam.to/azengineer

2005\04\17@182424 by Jinx

face picon face
Thanks to both Bob and Olin for replying

> A IIC transfer can not continue after a NACK.  A deliberate NACK
> can used to indicate the end of variable length transfers.  The ACK or
> NACK response to the address byte is also used by the master to
> determine whether there is any slave out there responding to that
> address

>From Dr Dobb's Journal, reprinted by Philips

The steps involved in an I2C master receive transaction are almost
identical to those in transmission

1. The master polls the bus to see if it is in use
2. The master generates a start condition on the bus
3. The master broadcasts the the slave address and expects an ACK
from the addressed slave
4. The master receives 0 or more bytes of data and sends an ACK
to the slave after each byte......(so far so good)...... The master signals
the last byte by not sending an ACK
5. The master generates a STOP condition and releases the bus

Now, (4) is repeated throughout the literature **. I don't understand
how the master-receiver knows when the last byte is. You tell it ?

** for example, exchange with an EEPROM

S - Slave address (W) - Slave Ack - Word address - Slave Ack -
S - Slave address (R) - Slave Ack - n data bytes - Slave Ack -
last byte - Master NACK - P

2005\04\17@193810 by olin_piclist

face picon face
Jinx wrote:
> 4. The master receives 0 or more bytes of data and sends an ACK
> to the slave after each byte......(so far so good)...... The master
> signals the last byte by not sending an ACK
>
> Now, (4) is repeated throughout the literature **. I don't understand
> how the master-receiver knows when the last byte is. You tell it ?

The master decides when the last byte is, at least at the bus level.  The
slave could possibly tell it how many bytes to expect by using higher level
protocol, but that has nothing to do with raw IIC.

> S - Slave address (R) - Slave Ack - n data bytes - Slave Ack -
> last byte - Master NACK - P

Ah, I see the misconception.  The N data bytes are transferred from slave to
master, since this is a read sequence.  The master sends the ACKs for all
those data bytes, since it is the receiver.  It therefore ACKs but the last,
which it NACKs.  However, since the master controls the bus, it could also
just abort the sequence with a BUS STOP.  That and the BUS START of the next
sequence is supposed to reset any slave logic.  The NACK to the last data
byte is therefore really redundant on a read transfer.  On a write transfer
it's not, since the slave generates the ACKs.  This is the only means the
slave has of telling the master that it's done and ain't gonna listen no
more.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\17@194233 by Lindy Mayfield

flavicon
face
Can the slave at times be the master?  For example, what if I had a Pic that was controlling the wheels of a robot as well as obstacle detection sensors, like a couple of whiskers.  The master tells the Pic to move the wheels forward.  Would the master have to continually poll to ask if there was a collision?  Or if there was a collision could the slave then switch to be the master to let the former master know it needs to do something, like stop the wheels moving?  

Or is there a better way to do this?  I was thinking that an interrupt line would be a way to let the master know that something is up, but this seems not so good because it would take an extra I/O pin, and also if there are many slaves the master would have to go through each one to see which one generated the interrupt.  

{Original Message removed}

2005\04\17@202617 by Jinx

face picon face
> Or is there a better way to do this?  I was thinking that an interrupt
> line would be a way to let the master know that something is up, but
> this seems not so good because it would take an extra I/O pin, and
> also if there are many slaves the master would have to go through
> each one to see which one generated the interrupt.  

My end goal is a collection of several (maybe 10) F88 daughter
boards, which will be either interface drivers or sensors, supervised by
an F452. One of my considerations was along that line. A common
I2C bus with a separate common /INT from the F88s to the F452.
What I envisaged happening is that an event occurs on or to one of the
F88 boards. It generates an /INT to alert the F452, which wakes up.
The F452 then polls each F88 by I2C until it finds which woke it. The
F452 then extracts the data/message from that F88. Each F88 board
would hold its own flag in the case of multiple/simultaneous events. There
are pins/resources enough for this scheme and it seems uncomplicated

==============

Have I interpreted correctly from Figure 10-7, DS30487C, and the
text in the right-hand column at the top of page 94 that an F88 as a
slave transmitter sends just one byte at a time ?

2005\04\17@224552 by Jinx

face picon face
> The master decides when the last byte is........

> Ah, I see the misconception........

Thanks, the ducks are starting to line up

There are going to be some paint-by-numbers diagrams coming
out this !!

2005\04\18@023853 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
>
> My end goal is a collection of several (maybe 10) F88 daughter
> boards, which will be either interface drivers or sensors, supervised by
> an F452. One of my considerations was along that line. A common
> I2C bus with a separate common /INT from the F88s to the F452.
> What I envisaged happening is that an event occurs on or to one of the
> F88 boards. It generates an /INT to alert the F452, which wakes up.
> The F452 then polls each F88 by I2C until it finds which woke it. The
> F452 then extracts the data/message from that F88. Each F88 board
> would hold its own flag in the case of multiple/simultaneous events. There
> are pins/resources enough for this scheme and it seems uncomplicated
>
Since the SDA is wired or (open collector with pullup) you could do like this to speed up the interrupt processing:

Allocate 1 bit number for each device. Use a control code for interrupt acknowledge. When the slaves (the F88's) sees this control code and a read sequence, they reply by holding their own bit low on the SDA (and only this bit) when it has requested attention on the INT line. The master can then read 8 bits at a time (for as many bytes it needs) until it reads a non FF data byte. The master will then know the device with the highest priority (or all devices if all bytes are read) that has requested the INT and can go on to access just this device. This is a lot quicker than to have to address all devices in turn. It requires 1 byte for each 8 devices though.

Another possibility is to do something that CAN does (perhaps this is what You need instead). Instead of allocating a single bit, each device is putting out their own address but when a slave sees that another slave has put the SDA line low during one bit transfer and itself has kept this bit high, it backs of and doesn't send another bit in this sequence. This way only 1 byte is needed for 255 devices but only the one with the highest priority is known by the master at the end of the transaction. The other way, the master can have its own priority allocation and it doesn't have to be fixed.

I don't know if this is possible using the built in IIC hardware but it sure is if the bus is bit banged.

Also, another way of thinking about the ACK/NACK thing is that during the ACK/NACK bit of a master read operation (master is reading the slave), this is the only time the master owns the SDA line and the only time it for sure can stop further byte transactions by doing a NACK followed by a STOP (or simply a STOP without a NACK). At all other times the slave can hold the SDA low, making it impossible for the master to send a STOP sequence. This is also why reads have to be done 8 bits a time (something to think about with the INT scheme - always finish the ongoing byte and do a STOP before handling interrupts during a read sequence). I haven't checked the specs but it may be undefined to do a STOP sequence also in the middle of a byte write transaction using the IIC hardware, but with bit banging it is possible.
Regards / Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
rubenspamKILLspampp.sbbs.se
==============================

2005\04\18@034952 by Jinx

face picon face
From: "Ruben Jönsson" -

Thank you so much for your comments Ruben. I've not decided
on what the final configuration is and I appreciate your ideas

Regarding the ACK/NACK thing - I've not had problems with
basic I2C peripherals up until now but have gotten a little lost at
sea now that several intelligent devices are bussed. But the nits
are slowly being bashed out of it. Lordy Lou, I'd be here guessing
forever without a logic analyser so that's something on the bright
side at least

2005\04\18@035001 by Howard Winter

face
flavicon
picon face
Jinx,

On Mon, 18 Apr 2005 10:23:09 +1200, Jinx wrote:

> ** for example, exchange with an EEPROM
>
> S - Slave address (W) - Slave Ack - Word address - Slave Ack -
> S - Slave address (R) - Slave Ack - n data bytes - Slave Ack -
> last byte - Master NACK - P

I don't know anything about I2C, but I think calling this last transaction "NACK" is confusing.  In "classic"
serial protocols NACK means "Negative Acknowledge", meaning "I received your transmission but it had errors"
and would usually cause a retransmission.  This is completely different from the lack of an acknowledgement,
which is what I think we are dealing with here.  Perhaps calling it "!ACK" would be less confusing?  (To me,
anyway! :-)

Cheers,


Howard Winter
St.Albans, England


2005\04\18@035616 by Alan B. Pearce

face picon face
>which doesn't seem to fit with descriptions in Philips' I2C
>Peripherals book. Am I a victim of poor terminology ?

Check the Philips I2C spec at
www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf
for all the relevant terminology and how the NACK should be used.

2005\04\18@040945 by Alan B. Pearce

face picon face
>> Now, (4) is repeated throughout the literature **. I don't understand
>> how the master-receiver knows when the last byte is. You tell it ?
>
>The master decides when the last byte is, at least at the bus level.  The
>slave could possibly tell it how many bytes to expect by using higher level
>protocol, but that has nothing to do with raw IIC.

I have done exactly this to transfer an unknown amount of data to the
master. My protocol had a status byte in each slave that the master could
obtain by sending a certain opcode. One bit of the status was a "slave
busy", and when the slave went not busy and indicated data available, then
the next read of the slave returned a one byte count of the length of the
data message, which the slave would supply on the next read. The count
allowed the master to know how when to terminate the transfer.

This is not a problem with a device such as an eeprom, as it is capable of
supplying an endless amount of data by effectively wrapping around in the
address space. It is up to the master to know what should be where in the
address space and start at an appropriate point, and then read what it
needs.

2005\04\18@041143 by Jinx

face picon face
> Check the Philips I2C spec at
> www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf
> for all the relevant terminology and how the NACK should be used.

I've d/l it and will have a look. Hopefully it'll have been re-written
(wrt the I2C manual) so I can compare texts and try to get my foot
in the door

> Perhaps calling it "!ACK" would be less confusing?

Howard, whenever I look at a page now I hear those ruddy
Martians from Mars Attacks ! "ack-ack ack ack-ack"

I'm sick of I2C for today. I'll do something that's going to get a
result, try and cheer myself up. Maybe play with some LEDs...


2005\04\18@050018 by Hopkins

flavicon
face
If possible can you share your I2C code and the insights that allow for
the multiple intelligent devices to work together.


_______________________________________
Roy
Tauranga
New Zealand
_______________________________________


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.14 - Release Date: 16/04/2005


2005\04\18@053649 by Michael Rigby-Jones

picon face


{Quote hidden}

To add considerably to the confusion of the I2C novice is that an ACK is
a logic low, and the 'N' in NACK could be misinterpreted to mean the
logic level of the ACK bit rather than the status of the acknowledge.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\04\18@061603 by Jinx

face picon face


> If possible can you share your I2C code and the insights that
> allow for the multiple intelligent devices to work together.

Who, me ? Sure, when it's all done, which shouldn't (famous
last words) be too long

2005\04\18@074348 by olin_piclist

face picon face
Lindy Mayfield wrote:
> Can the slave at times be the master?

Then it wouldn't be a slave anymore, would it?  IIC does allow for
multi-master mode.  When the bus is idle, any device can assert BUS START
and act as master until the BUS STOP.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\18@083608 by Russell McMahon

face
flavicon
face
> Lindy Mayfield wrote:
>> Can the slave at times be the master?

> Then it wouldn't be a slave anymore, would it?  IIC does allow for
> multi-master mode.  When the bus is idle, any device can assert BUS
> START
> and act as master until the BUS STOP.

ie He's saying "Yes, the processor that is at some times acting as a
slave can at other times act as a master".

The IIC bus when idle is simply two lines with pullup resistors. Any
device can start acting as a mater from this idle condition. However,
for this to make anything useful happen something else has to act as a
slave in response.

If you have only two devices and one has been acting as the master and
a transaction has finished then the other may indeed start acting as a
master, but the prior master must be able to now respond as a slave.
In software this extra step is trivially easy to achieve, once you
have the slave and master software working.

If you have N processor based devices on an IIC bus then all could act
as combined masters/slaves as above. The greatest problem would
probably be in handling potential multimaster contentions at the start
of messages. There are multimaster protocols available for IIC so this
would just involve including these. AFAIR (And I may R incorrectly)
some of the Scenix demonstration virtual peripherals provided master &
slave code for use in a multimaster situation.



   Russell McMahon


2005\04\18@091847 by olin_piclist

face picon face
Alan B. Pearce wrote:
> slave_dnld      equ 0x07    ; slave processor requires code download
> slave_busy      equ 0x06    ; slave busy processing command
> slave_data      equ 0x05    ; data to be returned to host available
> ;unused         equ 0x04    ;
> ;unused         equ 0x03    ;
> slave_NI        equ 0x02    ; command not implemented
> slave_ER        equ 0x01    ; command processing error
> slave_OK        equ 0x00    ; command processed normally
>
> /FLAG   slave_OK        ; command processed normally
> /FLAG   slave_ER        ; command processing error
> /FLAG   slave_NI        ; command not implemented
> /FLAG   slave_i2c_err   ; slave had unexplained i2c error in
> /FLAG   slave_unused    ; place holder to make this a complete
> /FLAG   slave_data      ; data to be returned to host available
> /FLAG   slave_busy      ; slave busy processing command
> /FLAG   slave_dnld      ; slave processor requires code download

Why are you using /FLAG then defining the bit number of those flags
separately?  This seems dangerous because they could get out of sync and
there are now two places to change when modifications are made.  Each /FLAG
command defines, among other things, the bit number of the flag within its
flag byte.  For example, "slave_OK_bit" is defined by the first /FLAG
command to have the value 0.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\18@105602 by Alan B. Pearce

face picon face
>Why are you using /FLAG then defining the bit number of those flags
>separately?  This seems dangerous because they could get out of sync

I agree, and cannot remember why it happened. It is now a couple of years
since I did that project, and the reason it happened are lost in the mists
of time. I suspect it was mostly because I did not think things out well in
the first place.

2005\04\18@123032 by ThePicMan

flavicon
face
At 07.43 2005.04.18 -0400, you wrote:
>Lindy Mayfield wrote:
>>Can the slave at times be the master?
>
>Then it wouldn't be a slave anymore, would it?  IIC does allow for
>multi-master mode.  When the bus is idle, any device can assert BUS START
>and act as master until the BUS STOP.

What if two devices in the same instant decide to become master (collision)?


2005\04\18@124533 by Lindy Mayfield

flavicon
face
part 1 2503 bytes content-type:text/plain; (decoded base64)

Yes, thank you Olin and Russell.  That answered my question.  What I was trying to ask but didn't do so so well, was if I have a master and say three slave devices and one of the slave devices needs to generate an interrupt, would it be a viable solution to have the slave switch to being the master in order to talk to the former master?  (-:  The other solution Jinx was talking about which was using an interrupt line that when set causes the master to poll the slaves to find out who generated the interrupt.  I was trying to work out in my head the pro's and con's of each method.  

       {Original Message removed}
part 2 6023 bytes content-type:application/ms-tnef; (decode)

part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\04\18@130302 by Lindy Mayfield

flavicon
face
part 1 1595 bytes content-type:text/plain; (decoded base64)

Good question.  I think it could be worked out, though.  If the lines are not in use and a slave decided it needed to let the master know something like an interrupt condition, then it would assume master and only the former master could assume slave.  And no other slaves could talk because the bus would be busy.

Then when the bus was free again, the next slave could assume master, etc.

But you bring up a good point that I hadn't thought of.  What if we have an interrupt line and one slave decids to generate an interrupt condition to get the master's attention.  Then let's say another slave has an interrupt condition as well.  Then this would be a better solution because as the master went through polling the slaves then it would catch both of them.  

Good catch!

       {Original Message removed}
part 2 5059 bytes content-type:application/ms-tnef; (decode)

part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\04\18@150751 by olin_piclist

face picon face
ThePicMan wrote:
> What if two devices in the same instant decide to become master
> (collision)?

In theory sooner or later one master will try to release one of the lines
while the other is holding it low.  The master that is trying to release the
line but sees it low anyway detects this and goes back to idle state.  In
practise it seems a lot of chips are sloppy in this area.  If you really
want to do multi-master, you might want to think of arbitrating this
exteranally from the IIC bus.

Or use CAN instead.  This kind of collision and arbitration is well defined
in CAN and is built into the chips.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\18@165952 by At van Wijk

flavicon
face
Q: Olin, what is the 'MSSP' bug, I mean where stands MSSP for ?

At van Wijk.


----- Original Message -----
From: "Olin Lathrop"   Sent: Sunday, April 17


> Beware of the MSSP bug where the master can see NACK even when
> a slave sent ACK.



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.9 - Release Date: 13-4-2005

2005\04\18@174959 by olin_piclist

face picon face
At van Wijk wrote:
> Q: Olin, what is the 'MSSP' bug, I mean where stands MSSP for ?

Master Slave Serial Port.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\18@180505 by Paul James E.

picon face


 At van Wijk,

 Master Synchronous Serial Port

 Regards,

  Jim



{Quote hidden}

> --

2005\04\18@192036 by Lee Jones

flavicon
face
>> Q: Olin, what is the 'MSSP' bug, I mean where stands MSSP for ?

> Master Slave Serial Port.

Close...  In the Microchip data sheets I've read, it stands for

   Master Synchronous Serial Port (MSSP) module.

See
   DS39564B, 18FXX2 (18F252), section 15 on page 125
   DS39612A, 18F6X2X/8X2X (18F6621), section 18 on page 175
   DS39631A, 18F2420/2520/4420/4520, section 17 on page 161
   DS39646B, 18F8722, section 19 on page 205

Similar is

   Synchronous Serial Port (SSP) module

See
   DS30487B, 16F88, section 10 on page 87


                                               Lee Jones

2005\04\19@000037 by Jinx

face picon face
part 1 1504 bytes content-type:text/plain; (decoded 7bit)

Why would "0011000R" be rejected as an address ? If sent
"0011000W" it will move on to the 2nd byte. AFAICT the
address is matched to <7:1> and bit0 is not considered

Whether the F88 is assigned an address of  h30 or h31, it will
not respond to h31

==================

Master transmitter, F452

        mov     "1",sspbuf         ;slave address - read
        btfsc   sspstat,r_w
        bra     $-2

or

        mov     "0",sspbuf         ;slave address - write
        btfsc   sspstat,r_w
        bra     $-2

==================

Slave receiver, F88

        banksel sspadd
        mov     "1",sspadd   ;device I2C address, 0011000x

        banksel sspcon
        mov     b'00000110',sspcon
;                      0110   ;I2C slave 7-bit address
        bsf     sspcon,sspen ;enable I2C module
        bcf     sspcon,sspov ;clear overflow bit
        bsf     sspcon,ckp   ;clock enable

        banksel sspbuf
        movfw   sspbuf       ;clear BF

        banksel sspstat
        clrf    sspstat

        banksel pir1
        bcf     pir1,sspif

        banksel sspstat
det_s    btfss   startb
        goto    $-1
        banksel sspbuf
        movfw   sspbuf

        call    pb3

        banksel sspstat
wait_adr btfss   sspstat,bf   ;wait for address match
        goto    $-1
        banksel sspbuf
        movfw   sspbuf
        banksel pir1
        bcf     pir1,sspif



part 2 1450 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\04\19@040455 by Alan B. Pearce

face picon face
>>Then it wouldn't be a slave anymore, would it?  IIC does allow for
>>multi-master mode.  When the bus is idle, any device can assert BUS START
>>and act as master until the BUS STOP.
>
>What if two devices in the same instant decide to become master
(collision)?

Read the Philips spec document I posted the link for - there is a protocol
for bus collisions.

2005\04\19@075117 by olin_piclist

face picon face
Jinx wrote:
> Why would "0011000R" be rejected as an address ? If sent
> "0011000W" it will move on to the 2nd byte. AFAICT the
> address is matched to <7:1> and bit0 is not considered
>
> Whether the F88 is assigned an address of  h30 or h31, it will
> not respond to h31

I didn't look at the code, but keep in mind that the address register holds
the slave address shifted left 1 bit.  In other words, it holds the address
pattern as expected in the address byte, not simply the "address" as the
documentation might lead you to believe.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\19@082115 by Jinx

face picon face

> I didn't look at the code, but keep in mind that the address register
> holds the slave address shifted left 1 bit.  In other words, it holds the
> address pattern as expected in the address byte, not simply the
> "address" as the documentation might lead you to believe

I've seen no reference to the address being shifted left. As I read it,
the address matching is done on the upper 7 bits and the  LSb is the
Read/Write. For example with an EEPROM, A0 to W, A1 to R

It was a little premature to say the F88 doesn't respond. Now I think
it does (need to prove that), but I'd neglected to wholly set the F452
up as a Master Receiver. Which I'm trying to do now but it's not
producing any SCL pulses to clock the data out of the F88

2005\04\19@085053 by Alan B. Pearce

face picon face
>> I didn't look at the code, but keep in mind that the address register
>> holds the slave address shifted left 1 bit.  In other words, it holds the
>> address pattern as expected in the address byte, not simply the
>> "address" as the documentation might lead you to believe
>
>I've seen no reference to the address being shifted left. As I read it,
>the address matching is done on the upper 7 bits and the  LSb is the
>Read/Write. For example with an EEPROM, A0 to W, A1 to R

The effect is that the address is shifted left. From your previous email you
showed 00110000 as an address, and that is 0x28 as an address, with the R/W
bit set to write, and 00110001 is address 0x28 with the R/W bit set to read.

>It was a little premature to say the F88 doesn't respond. Now I think
>it does (need to prove that), but I'd neglected to wholly set the F452
>up as a Master Receiver. Which I'm trying to do now but it's not
>producing any SCL pulses to clock the data out of the F88

This can occur because the F88 is not sending an ACK to the address byte, so
the master thinks there is no device out there, and terminates the transfer.

2005\04\19@090704 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote :

> The effect is that the address is shifted left. From your
> previous email you showed 00110000 as an address, and
> that is 0x28 as an address, with the R/W bit set to write,
> and 00110001 is address 0x28 with the R/W bit set to read.

Not 0x18 ??

0x28 = 00101000 which doesn't look as a shifted 0011000x...

Regards,
Jan-Erik.



2005\04\19@091240 by Michael Rigby-Jones

picon face


{Quote hidden}

I make it 0x18

Bit weight (hex)  40 20 10  |  08 04 02 01  |  R/W
Binary Address     0  0  1  |  1  0  0  0   |  0
Hex Address             10  |  8            |  -

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\04\19@092453 by Jinx

face picon face
> The effect is that the address is shifted left. From your previous email
> you showed 00110000 as an address, and that is 0x28 as an address,
> with the R/W bit set to write, and 00110001 is address 0x28 with the
> R/W bit set to read

OK, so in effect you mentally add a leading 0 to make an 8-bit address.
So in describing A1 & A0 as the R /W addresses for a chip, they could
be thought of as being base 50 (b0101 0000) + (R or /W)

> This can occur because the F88 is not sending an ACK to the address
> byte, so the master thinks there is no device out there, and terminates
the
> transfer

That's what I'm trying to get to the bottom of. If you look at the last gif
I sent (30-31-3f.gif) it does appear that an ACK is sent. At least, SDA
is low during the 9th clock in both the 30 and 31 examples

2005\04\19@103719 by olin_piclist

face picon face
Jinx wrote:
> I've seen no reference to the address being shifted left. As I read it,
> the address matching is done on the upper 7 bits and the  LSb is the
> Read/Write.

That's right.  I found the documentation a little misleading the first time
I used IIC.  If you want a slave address of 7, you'd think you need to set
the address register to 7, but it actually needs to be set to 14 because the
address register contents is compared directly to the high 7 bits of the
address byte.  The address byte contains the 7 bit address in the high bits,
and the R/W bit in the low bit.  The address field is therefore shifted left
one bit within the address byte, and this same positioning is used in the
built in slave address register (SPADD if I remember right, don't have that
manual in this office).

I ran into this on a 16F877 originally.  I haven't looked at the
documentation of a 16F88, but I expect it uses the same MSSP and therefore
works the same way.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\19@104151 by Alan B. Pearce

face picon face
>>0x28 as an address, with the R/W bit set to write, and
>>00110001 is address 0x28 with the R/W bit set to read.
>
>
>I make it 0x18

Doh, your correct, of course. I was thinking in terms of Jinx describing it
as address 0x30/31 that he was using.

2005\04\19@104155 by Herbert Graf

flavicon
face
On Tue, 2005-04-19 at 07:52 -0400, Olin Lathrop wrote:
> Jinx wrote:
> > Why would "0011000R" be rejected as an address ? If sent
> > "0011000W" it will move on to the 2nd byte. AFAICT the
> > address is matched to <7:1> and bit0 is not considered
> >
> > Whether the F88 is assigned an address of  h30 or h31, it will
> > not respond to h31
>
> I didn't look at the code, but keep in mind that the address register holds
> the slave address shifted left 1 bit.  In other words, it holds the address
> pattern as expected in the address byte, not simply the "address" as the
> documentation might lead you to believe.

Very true, in fact this has been a area of confusion that I'm sure has
hit many people.

Personally I think of addressing on the I2C bus as even addresses are
write address, odd addresses are read addresses, keeps code alot
cleaner. TTYL


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\04\19@104832 by olin_piclist

face picon face
Jinx wrote:
> OK, so in effect you mentally add a leading 0 to make an 8-bit address.

I think it's important to distinguish between the "address", and the pattern
you have to write to the address register for a slave to respond to that
address.  IIC addresses are (in most cases) 7 bits, so therefore range from
1-127 with 0 reserved as the broadcast address.  These are the numbers you
will be given when reading data sheets for IIC chips.

If a chip says it responds to slave address 5, then that means the address
byte the master sends to that chip must be (0000 101x), where X is the
read/write bit.  If you want to set up a PIC as a IIC slave at address 5,
you have to set the slave address register to 0000 1010, not 0000 0101 as
you might think when reading the documentation.  However, the *address* is
still 5.  The fact that you have to write 10 to the slave address register
is an artifact of the way the PIC MSSP works.  This is perfectly reasonable,
although poorly documented (at least back when I first tried to use PIC
IIC).


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\04\19@115332 by Alan B. Pearce

face picon face
>IIC addresses are (in most cases) 7 bits, so therefore range from
>1-127 with 0 reserved as the broadcast address.  These are the
>numbers you will be given when reading data sheets for IIC chips.

However within that range you also need to steer clear of the addresses used
to extend into 10 bit address mode. Also note that some are reserved for
various other purposes - probably not a problem for most things, but it does
pay to be aware that they exist else you'll get grabbed where it hurts when
you least expect it.

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