Searching \ for '[PIC]: F877 I2C module' 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: 'F877 I2C module'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: F877 I2C module'
2002\08\01@200856 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- ----- Original Message -----
From: "Jinx" <spam_OUTjoecolquittTakeThisOuTspamCLEAR.NET.NZ>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Thursday, August 01, 2002 3:14 PM
Subject: ]PIC]: F877 I2C module

{Quote hidden}

Ya got the left bracket backwards ont he original post.

I've not used the I2C module yet, however, it was my understanding
that much of I2C is contained within the hardware.  I suspect that
it's primarily interrupt driven.  From the I2C datasheet, I
understand that all contention detection and arbitration is done in
hardware.  My best advice for you at this point is to go through the
datasheet for the 877 and set up what needs to be setup step by step.
After that, I believe that you could do it based on interrupts.  If
it's only a 2 device bus, it should be easy to get everything
working.  I recommend reading up on I2C, which you can do at the
Philips website (grab the I2C spec from their buses section).  I
expect someone else will give you more useful information

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPUnBNwVk8xtQuK+BEQLWFwCfV53KR/SuueoMjvhRxCSvGmTwJccAnA4c
6aHB7/oQF+gz2i9S611Irg3O
=qn8q
-----END PGP SIGNATURE-----

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


2002\08\01@210116 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Virtually required reading for working with I2C:
www.semiconductors.philips.com/acrobat/various/I2C_BUS_SPECIFIC
ATION_3.pdf
They invented it, get the info from them.

Hope it helps, and I'll have a look at the assembly requirements to
get a simple flow of infomration for ya.

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPUnRtwVk8xtQuK+BEQL/sACdECdqCuVIGtlSp84rSNcWGUroSk4An14d
Y2KXLOyGdJRoeTSnmSpENxif
=/djH
-----END PGP SIGNATURE-----

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


2002\08\01@234437 by Jinx

face picon face
> http://www.piclist.com/techref/microchip/i2c-eeprom.htm

12C508 bit-banging. Been there done that got the T-shirt

Sorry

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


2002\08\01@234550 by Jinx

face picon face
> Virtually required reading for working with I2C:
> www.semiconductors.philips.com/acrobat/various/I2C_BUS_SPECIFIC
> ATION_3.pdf
> They invented it, get the info from them.

Got the Philips I2C book. Doesn't mention the 16F877 though ;-(

> Hope it helps, and I'll have a look at the assembly requirements to
> get a simple flow of infomration for ya

"simple". Nice word, "simple"

I'm a great believer in manuals, don't get me wrong, but there's
is just so much info in there it really is tough going when you've
not got a good code example to sing along to

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


2002\08\01@234755 by Jinx

face picon face
> I've not used the I2C module yet, however, it was my understanding
> that much of I2C is contained within the hardware.

Very true. MSSP is a complex module, more so than the UART, which
is why it has so many registers and flags associated with it. The
operation is analogous to the UART though, with data being transmitted
and received through buffers, but the I2C bus is more "active" than the
UART, so to speak, with two-way traffic even if data flow is generally
one-way and it's that firmware interaction that needs to be considered
and accounted for in the coding. Or hopefully in a simple implementation
much of it can be ignored

>  If it's only a 2 device bus, it should be easy to get everything
> working.

"should be easy" - a phrase, along with "all you have to do is",
that should be consigned to the darkest depths of Hades

> I recommend reading up on I2C, which you can do at the
> Philips website (grab the I2C spec from their buses section).  I
> expect someone else will give you more useful information

I'm reasonably comfortable with I2C, it's simply Ignorance of the
16F877's I2C module that's today's headache

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


2002\08\02@073243 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Hi,

Jinx wrote:
> Does anyone have simple, repeat simple, code to show
> setup and operation of said module to read / write bytes
> to an EEPROM ? Examples I've found so far are convoluted
> over-blown state machines for multi-device systems that are
> way OTT for my needs. So much use of collision and error

Hmm... what I have are pretty simple, however as it is an general
routine intended to be used be used inside the isr one might call
them overblown. But it's easy to rip out or simplify by omitting
as desired. But in case you stand by your request that an state machine
is out of the question I'll refrain from posting the complete code
unless
you perhaps have a second thought :)
> routines I found it hard to pick out the basics. Normally I'd
> nut it out myself but I've read that some examples (MC in
> particular) aren't worth the screen they're printed on, so I'd
> rather not waste time on published code that doesn't work
>
> TIA

Agreed, but mine is actually based on an m-chip example but polished
until
is actually have some uses :) BTW it's two 'modules' one for the i2c master (isr) functions and one
for the
eechip functions.

State = 0 -> local i2c idle State = 1-3 -> i2c read
State = 4-8 -> i2c write
Uses BuffBankFsr (defined to any fsrX ) to read from any memory location
within an dedicated buffer bank (only low adress used) when writing.
Uses FSR0 for reding to any memory location when reading.


Here's the main i2c state machine handler ( all of it ):


;
***********************************************************************
;
;  I2C_INT_HANDLER - Handles read/writes to/from i2c bus devices
;  Uses an state variable i2c_State to preserv state between calls
;
I2C_INT_HANDLER
       GLOBAL  I2C_INT_HANDLER
       BCF     _i2c_timetick ; clear timeout detect bit
       MOVF    i2c_State,W,A
       TABLE_JUMP_ISR_GTO I2C_JumpWrite
I2C_JumpWrite   ; address were jump table branch occurs, this addr also
used in fill         ; jump to processing for each state             = i2cState value
for each state
       GOTO    I2C_WrtStart            ; write start sequence
=  0
       GOTO    I2C_SendWrtAddr         ; write address, R/W=1
=  1
       GOTO    I2C_WrtAckTest          ; test ack,write data
=  2
       GOTO    I2C_WrtStop             ; do stop if done
=  3
I2C_JumpRead
       GOTO    I2C_ReadStart           ; read start sequence
=  4
       GOTO    I2C_SendReadAddr        ; read address, R/W=0
=  5
       GOTO    I2C_ReadAckTest         ; test acknowledge after address
=  6
       GOTO    I2C_ReadData            ; read more data
=  7
       GOTO    I2C_ReadStop            ; generate stop sequence
=  8

I2C_JumpEnd                      Fill (RETURN),  (I2C_JumpWrite-I2C_JumpEnd) + ( i2c_SizeMask*4 )
;----------------------------------------------------------------------
;   ********************* Write data to Slave   *********************
;----------------------------------------------------------------------
; Generate I2C bus start condition       [ I2C STATE -> 0 ]
I2C_WrtStart
       INCF    i2c_State,F,A           ; update I2C state variable
       BSF     SSPCON2,SEN,A           ; initiate I2C bus start
condition
       MOVLW   LOW(I2C_Buffer)         ; setup buffer pointer to start
of i2c buffer
       MOVWF   i2c_write_ptr,A         ;
       RETURN                          ;
; Generate I2C address write (R/W=0)             [ I2C STATE -> 1 ]
I2C_SendWrtAddr
       MOVF    i2c_temp_address,W,A     ; get 7-bit address
       INCF    i2c_State,F,A            ; update I2C state variable
       MOVWF   SSPBUF,A                 ; initiate I2C bus write
condition
       RETURN                           ;
; Test acknowledge after address and data write  [ I2C STATE -> 2 ]
I2C_WrtAckTest
       BTFSS   SSPCON2,ACKSTAT,A        ; test for acknowledge from
slave
       GOTO    I2C_WrtData              ; go to write data module
       BSF     _i2c_ackerror            ; set acknowledge error
       CLRF    i2c_State,A              ; reset I2C state variable
       BSF     SSPCON2,PEN,A            ; initiate I2C bus stop
condition
       RETURN                           ;
; Generate I2C write data condition
I2C_WrtData
       ; first check if write count is zero
       MOVF    i2c_write_count,F,A     ; reload
       BTFSC   STATUS,Z
       GOTO    I2C_no_error            ; no bytes to write
       MOVF    i2c_write_ptr,W,A        ; retrieve ptr address
       MOVWF   BuffBankFSR              ; initialize FSR for indirect
access
       INCF    i2c_write_ptr,F,A        ; inc. pointer for next byte
       MOVF    BuffBankINDF,W,A         ; retrieve byte into w
       DECFSZ  i2c_write_count,F,A      ; test if all done with writes
       GOTO    I2C_send_byte            ; not end of string
       INCF    i2c_State,F,A            ; update I2C state variable
I2C_send_byte
       MOVWF   SSPBUF,A                ; initiate I2C bus write
condition
       RETURN                          ;
; Generate I2C bus stop condition                [ I2C STATE -> 3 ]
I2C_WrtStop
       BTFSS   SSPCON2,ACKSTAT,A        ; test for acknowledge from
slave
       GOTO    I2C_no_error             ; bypass setting error flag
       BSF     _i2c_ackerror            ; set acknowledge error
       CLRF    i2c_State,A              ; reset I2C state variable
       GOTO    I2C_stop
I2C_no_error
       CLRF    i2c_State,A              ; reset I2C state variable ( to
idle )
       BSF     _i2c_writedone           ; set write done flag
I2C_stop
       BSF     SSPCON2,PEN,A            ; initiate I2C bus stop
condition
       RETURN                           ;
;----------------------------------------------------------------------
;   ********************* Read data from Slave   *********************
;----------------------------------------------------------------------
; Generate I2C start condition                   [ I2C STATE -> 4 ]
I2C_ReadStart
       INCF    i2c_State,f              ; update I2C state variable
       BSF     SSPCON2,SEN              ; initiate I2C bus start
condition
       RETURN                           ;
; Generate I2C address write (R/W=1)             [ I2C STATE -> 5 ]
I2C_SendReadAddr         MOVF    i2c_temp_address,W,A     ; get 7-bit address
       INCF    i2c_State,F,A            ; update I2C state variable
       MOVWF   SSPBUF,A                 ; initiate I2C bus write
condition
       RETURN                           ; ; Test acknowledge after address write           [ I2C STATE -> 6 ]
I2C_ReadAckTest
       BTFSS   SSPCON2,ACKSTAT,A        ; test for acknowledge from
slave
       GOTO    I2C_StartReadData        ; good ack, go issue bus read
       BSF     _i2c_ackerror            ; set acknowledge error
       CLRF    i2c_State,A              ; reset I2C state variable
       BSF     SSPCON2,PEN,A            ; initiate I2C bus stop
condition
       RETURN                           ;
I2C_StartReadData
       BSF     SSPCON2,RCEN,            ; generate receive condition
       INCF    i2c_State,F,A            ; update I2C state variable
       RETURN
; Read slave I2C                                 [ I2C STATE -> 7 ]
I2C_ReadData
       MOVF    i2c_read_ptrH,W,A        ; retrieve high ptr address
       MOVWF   FSR0H                    ; initialize FSR0 high reg for
indirect access
       MOVF    i2c_read_ptrL,W,A        ; retrieve low ptr address
       MOVWF   FSR0L                    ; initialize FSR0 low reg for
indirect access
       INCF    i2c_read_ptrL,F,A        ; inc. pointer for next byte
       MOVFF   SSPBUF,INDF0             ; save recieved byte         DECFSZ  i2c_read_count,F,A       ; test if all done with reads
       GOTO    I2C_SendReadAck          ; not end of string so send ACK

; End of data Send Not Acknowledge
I2C_SendReadNack
       INCF    i2c_State,F,A            ; update I2C state variable (
nxt is stop )
       BSF     SSPCON2,ACKDT,A          ; acknowledge bit state to send
(not ack)
       BSF     SSPCON2,ACKEN,A          ; initiate acknowledge sequence
       RETURN

; Send Acknowledge
I2C_SendReadAck
       BCF     SSPCON2,ACKDT,A          ; acknowledge bit state to send
       BSF     SSPCON2,ACKEN,A          ; initiate acknowledge sequence
I2C_SendReadAck_Wait
       BTFSC   SSPCON2,ACKEN,A          ; ack cycle complete?
       GOTO    I2C_SendReadAck_Wait     ; no, so loop again
       NOP
       BCF     PIR1,SSPIF,A    ; clear SSP H/W flag for ack
       NOP
       BSF     SSPCON2,RCEN,A           ; generate receive condition
       RETURN                           ;
; Generate I2C stop condition                    [ I2C STATE -> 8 ]
I2C_ReadStop
       BSF     SSPCON2,PEN,A            ; initiate I2C bus stop
condition
       CLRF    i2c_State,A              ; reset I2C state variable
       BSF     _i2c_readdone            ; set read done flag
       RETURN
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@083639 by Olin Lathrop

face picon face
> I've not used the I2C module yet, however, it was my understanding
> that much of I2C is contained within the hardware.  I suspect that
> it's primarily interrupt driven.  From the I2C datasheet, I
> understand that all contention detection and arbitration is done in
> hardware.  My best advice for you at this point is to go through the
> datasheet for the 877 and set up what needs to be setup step by step.
>  After that, I believe that you could do it based on interrupts.  If
> it's only a 2 device bus, it should be easy to get everything
> working.  I recommend reading up on I2C, which you can do at the
> Philips website (grab the I2C spec from their buses section).  I
> expect someone else will give you more useful information

Before you get too far thinking that IIC will solve all communications
problems between PICs, note that the Microchip implementation only allows
for flow control from slave to master, not from master to slave.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@083644 by Olin Lathrop

face picon face
> Virtually required reading for working with I2C:
> www.semiconductors.philips.com/acrobat/various/I2C_BUS_SPECIFIC
> ATION_3.pdf
> They invented it, get the info from them.

Fine, but then look at the PIC data sheet **very carefully** to get the
implementation-specific details.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@083647 by Dave

flavicon
face
Hey,

I have a PDF document of a microchip presentation entitled "I2C™ Master
Mode Overview and Use of the PICmicro® MSSP I 2 C Interface" I found it
was really useful when I was writing my I2C code.
It's about 400k and I can't remember where I got it from so if anyone
wants it I'd be happy to email it off list.

Regards,
David Stubbs

> {Original Message removed}

2002\08\02@083900 by Olin Lathrop

face picon face
> I'm reasonably comfortable with I2C, it's simply Ignorance of the
> 16F877's I2C module that's today's headache

OK, then here are some points about the MSSP module that you want to think
about up front:

1  -  There is a bug in master mode.  The ACK bit from the slave is sampled
on the falling edge of SCL instead of the rising edge.  This causes a race
condition between SCL falling and SDA being released from ACK.  Even though
the master is controlling the clock, its internal circuitry looks at the
actual bus level to react to SCL.  If the slave threshold for a 1 on SCL is
higher than that of the master's, then the slave sees the falling SCL edge
before the master.  This can cause the slave to release the SDA line from
ACK before the master samples SDA to read the ACK bit.  The result is that
the slave wrote ACK, but the master reads NACK.

This may sound like a rather unlikely scenario, but I have seen it happen.
That's how I found this bug in the first place.  Consider the effect of
slightly more stray capacitance on the SCL line than SDA, and you can start
to believe it might be possible.  My workaround is to use the minimum pullup
resistors for both lines, then add about 100pF to the SDA line.  That delays
SDA rising edges enough to get past the short race condition.  In practice
I've seen 47pF always work, although something like 36pF (don't remember
exactly) worked most of the time but not always.

2  -  Note that a slave in clock stretch mode holds SDA according to the
high bit of SSPBUF.  When the SSPCON,CKP is set to release clock stretch,
clock is released immediately.  While this makes sense, the fix to #1 can
cause trouble here at high CPU clock speeds (has nothing to do with IIC
clock speed).  The fix for #1 slows down SDA a little with respect to SCL.
With a 20MHz slave, one instruction is not enough time to start driving SDA
appropriately before clock is released.  This can cause the high bit of the
data byte to be read as 0 by the master when it 1 inside the slave.  The fix
is to set SSPBUF a few instructions before setting SSPCON,CKP.  Insert a few
NOPs if necessary.

3  -  The MSSP module does not directly support slave flow control during a
write.  The master can always slow down communications to avoid being
overrun of underrun because it controls the clock.  A slave during a read
sequence can (automatically does) do clock stretch to avoid underrun.
However, there is nothing a slave can do to avoid overrun during a write, at
least not directly using just the IIC bus via the MSSP.

4  -  The SSPADD register in slave mode holds the slave address shifted left
one bit.  This makes sense because that is how the address is aligned in the
address byte, but the docs don't come right out and tell you that.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@093248 by Jinx

face picon face
Thanks to Dave, Tony and Olin. I daresay all will be obvious
with hindsight. I'll write it up myself when I've got a grip on it

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@130514 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've written a begun writing a guide to the use of the I2C master
mode on the 877, which I will submit for scrutiny here when it's
done.  I've gotten some 33% written already, if you want that while I
go on to the next step, I'll post it, but if you want the whole thing
at once, I'll continue working on it as I have time.

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPUq7iAVk8xtQuK+BEQJc+ACgv0sCDExI8xaXLCy+glfOQhNhDB0An3TZ
PmEobL7u4oWDrUnSWTaCIXUR
=Ktlx
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@152703 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As promised, here's the guide.  I hope it helps, and doesn't contain
too many glaring omissions or errors.  I suspect Olin will at least
be able to comment on the validity of this info.  All it really is,
is condensed info from he datasheet, but the datasheet has info in it
that's just not necessary for someone who just wants to get the
interface up.

- --Brendan
- ----------------------------------------------------------------------
- -----------
[General]
There are 6 registers used in I2C operation:
SSPCON
SSPCON2
SSPSTAT
SSPBUF
SSPSR (not directly accessible)
SSPADD

[Initialization]
To initialize the I2C module, follow these steps information in "()"s
explains the use of various segments.
Set SDA to input
Set SCL to input

(For 100kHz/1MHz operation)
Set SMP
(For 400kHz operation)
Clear SMP


(For Standard I2C operation)
Clear CKE
(For SMBus operation)
Set CKE

Set SSPEN

Configure SSPM3:SSPM0
(SSPM3:SSPM0: Synchronous Serial Port Mode Select bits)
(0000 = SPI Master mode, clock = FOSC/4)
(0001 = SPI Master mode, clock = FOSC/16)
(0010 = SPI Master mode, clock = FOSC/64)
(0011 = SPI Master mode, clock = TMR2 output/2)
(0100 = SPI Slave mode, clock = SCK pin. SS pin control enabled.)
(0101 = SPI Slave mode, clock = SCK pin. SS pin control disabled.) SS
can be used as I/O pin.)
(0110 = I2C Slave mode, 7-bit address)
(0111 = I2C Slave mode, 10-bit address)
(1000 = I2C Master mode, clock = FOSC / (4 * (SSPADD+1)))
(1011 = I2C Firmware Controlled Master mode (slave idle))
(1110 = I2C Firmware Controlled Master mode, 7-bit address with START
and STOP bit interrupts enabled)
(1111 = I2C Firmware Controlled Master mode, 10-bit address with
START and STOP bit interrupts enabled)
(1001, 1010, 1100, 1101 = Reserved)

Done!

Review the datasheet for additional information, and for register
addresses.

[Use of the I2C interface]
You'll have 6 functions for I2C, once the port ins initialized.  They
are:

Start
Repeated Start (that's start when there's already been a start, but
no stop)
Send
Stop
Set receive
Acknowledge a received byte

I assume that these are implemented in software, not hardware, though
*I* think that a start an Ack should be automatic.

- From the datasheet,

{Quote hidden}

- From the looks of things, it's a pretty SSPIFy systems ;)

The CPU needs to check the S and P bits before any attempt to take
control of the I2C bus.  If P is set, then it can proceed, if not, it
must wait for P to be set, and can be interrupted when it is.


Start should consist of:
- --
Set SEN (SSPCON2<0>)
- --
S (SSPSTAT<3>) is set, and, when SEN is automatically cleared, the
start condition is complete, and a SSPIF interrupt occurs to handle
the data write.
If the bus is in use when the start function is called, the BCLIF
interrupt flag will be set.
A data write can occur before the start condition is complete, but
will not be sent because queuing is not allowed.  WCOL is set to
indicate that the data has not been transmitted.
When a start is detected on the bus, the S bit is set.


Repeated Start
- --
Set RSEN (SSPCON2<1>)
- --
Similar to Start


Send
- --
Load SSPBUF with the data to send.
- --
The BF flag will be set, indicating that the buffer is full until the
transmission is complete, at which point an interrupt will occur
(SSPIF).
If a write to SSPBUF is attempted while a shift is in progress, WCOL
is set, and the buffer is unchanged.
If the is an acknowledge, the ack bit in SSPCON2<6> will be clear.
If not, it will be set.


Stop
- --
set PEN (SSPCON2<2>)
- --
When a stop is complete, the P bit (SSPSTAT<4>) is set.
Also, when a stop is detected on the bus, the P bit is set.


Recv
- --
set RCEN (SSPCON2<3>)
- --
When the SSPSR receive buffer is full, the BF flag is set, and there
is a SSPIF interrupt.  The BF flag is cleared automatically when the
CPU reads SSPSR.
The SSPOV status flag is set when a receive occurs while the BF flag
is already set.
If the user writes to SSPBUF while a receive is in progress, WCOL is
set, and SSPBUF is unchanged.
An Ack can be set after a receive is complete.


Acknowledge
- --
Set ACKDT
Set ACKEN (SSPCON2<4>)
- --
If an ack is desired, set ACKDT if an ack is not desired, clear
ACKDT.  Either way, Ack should be used after a receive has occurred.
As usual, any write to SSPBUF while an Ack is in progress will cause
WCOL to be set, and SSPBUF will remain unchanged.
Once the Ack process is complete, ACKEN will be cleared
automatically.


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPUrcvQVk8xtQuK+BEQJ5IACeP0Sx+ETQfw7pQrq1daeoH9hfHSAAnAkI
Af07hpkKCzK5plTOE17Hted3
=JMhD
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@184207 by Welch, Ken

flavicon
face
its a tutorial on MicroChip web site

http://www.microchip.com/download/lit/suppdoc/toots/i2c.pdf



{Original Message removed}

2002\08\02@184224 by Jinx

face picon face
Thanks for the effort Brendan. I'm planning on this being an
I2C weekend (sob, I have neither friends nor life so what else
have I got to do ?) and will be keen to see the module in action.

I suspect that the various timing and sequence diagrams in the
manuals will be valuable too

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@190303 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I suspect that the various timing and sequence diagrams in the
> manuals will be valuable too

You have your own storage scope then?  You lucky beggar!  I've had my
eyes on the Fluke 123 ScopeMeter for about 4 years now.  By the time
I can afford it, there will be one I like better for more money.
*sob*.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPUsPkAVk8xtQuK+BEQJofwCgrRVvWyeidSjfr8SyQTOE87kYHQUAoIsw
+Jir8GW60yWk86dlVa99/ma8
=LWwC
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@193047 by Jinx

face picon face
> > I suspect that the various timing and sequence diagrams in the
> > manuals will be valuable too
>
> You have your own storage scope then?  You lucky beggar!

You're 1/3rd correct. Storage scope. No. Lucky. No

I've a Jinxbuilt logic analyser though which is very helpful getting
the nits out of time-dependent or time-based software

I meant the drawings in the manuals which show the relationships
between registers and line activity

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@194757 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I've a Jinxbuilt logic analyser though which is very helpful
> getting the nits out of time-dependent or time-based software
>
> I meant the drawings in the manuals which show the relationships
> between registers and line activity

If any more comments follow this, I'm taking it over to [EE] or [OT]
because it will likely have fallen outside the range of the [PIC]
topic.  I think it might be time for me to build a Annirak-built
logic analyser (Annirak and Brendan are one and the same,
incidentally)  It would make a good use of the 4MHz 877 I've got
kicking around.

- --Brendan aka Annirak in slightly less PIC/more anonymous areas (;

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPUsZ9AVk8xtQuK+BEQKRJwCg4Ye4sp5cEF3oYSc+HtnS00e0iiIAnjQQ
YSuaP1utwWeADb2vrYGIV00e
=4vBE
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\02@200258 by Jinx

face picon face
> I think it might be time for me to build a Annirak-built logic analyser
> (Annirak and Brendan are one and the same, incidentally)  It would
> make a good use of the 4MHz 877 I've got kicking around

It's not too difficult, although I had to wait until I had a scope fast
enough to get the circuit running properly. It's based on an F628
running at 3.6864MHz (all I had to hand at the time) which does
some simple line controlling and RS232 back to the PC. The
data collection is done by a dividable 40MHz clock driving 32k
fast cache RAM via address drivers / latches. It could use a heap
of improvement, as time permits, and I think it would be worth
something to others as a complete project

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\03@004923 by Jinx

face picon face
Tony, why do some of your instructions include the ,A ?

eg

INCF    i2c_State,F,A           ; update I2C state variable
BSF     SSPCON2,SEN,A   ; initiate I2C bus start condition

but not with

BSF    SSPCON2,RCEN  or  MOVWF   BuffBankFSR

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


2002\08\03@062514 by Jinx

face picon face
Just curious - am I right in thinking that you can use either
7-bit or 10-bit addressing with the I2C module ? If so, does
that mean an EEPROM > 1k x 8 can't be accessed above
03FF ? I plan to use at least one 64k x 8 and need to know
if I'm wasting my time (at the moment) figuring out the I2C
module and should go back to bit-banging for large memories

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


2002\08\03@062529 by Jinx

face picon face
Forget enquiry about addressing - obviously (??) you send
as many address bits as necessary. Reading too many data
sheets. Some smaller EEPROMs use block selection and
the larger ones use direct access by 2 x 8-bit addressing.
Should have just stuck to the sheet for the memory I'm going
to use

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


2002\08\03@085446 by Byron A Jeff

face picon face
On Sat, Aug 03, 2002 at 04:36:21PM +1200, Jinx wrote:
> Tony, why do some of your instructions include the ,A ?

It's the 18XXXX "access bank". It's a special memory designation that consists
of the special function registers + 128 bytes of handily accessible general
purpose RAM in bank 0. It's special because you can access it directly without
having to switch/setup the bank select register. It's described in secton 4.10
of the 18FXXX datasheet.

{Quote hidden}

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


2002\08\03@085802 by Dave

flavicon
face
Yup. That's the one. That must be where I originally got it from then.
Dave

{Quote hidden}

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


2002\08\03@085841 by Olin Lathrop

face picon face
> Just curious - am I right in thinking that you can use either
> 7-bit or 10-bit addressing with the I2C module ?

Yes.

> If so, does
> that mean an EEPROM > 1k x 8 can't be accessed above
> 03FF ?

No, different address space.  The 7 or 10 bit address refers to the
addresses of slave modules on the IIC bus.  This has nothing at all to do
with the EEPROM's internal address space.  By the way, almost everyone uses
7 bit addressing.  127 possible slaves is usually WAAAAAYYYY more than
enough.  Also, most EEPROM chips only use 7 bit addressing, and often have
most of those hard wired.  Usually you only get to chose the low 1 or 2
address bits the chip will respond to.  Yes, that means you can't put more
than 2 or 4 of these chips on the same IIC bus without some external
selection scheme.


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

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


2002\08\03@095209 by Jinx

face picon face
> > Tony, why do some of your instructions include the ,A ?
>
> It's the 18XXXX "access bank"

OK, thought it might have been something like that. It sounds
like the group of 16 RAM locations across the top of the 877's
banks

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


2002\08\03@095426 by Olin Lathrop

face picon face
> Start
> Repeated Start (that's start when there's already been a start, but
> no stop)
> Send
> Stop
> Set receive
> Acknowledge a received byte
>
> I assume that these are implemented in software, not hardware, though
> *I* think that a start an Ack should be automatic.

They are implemented in hardware in the MSSP.  You only set the appropriate
bit and ACK or NACK is automatically sent.  You want control over this in
software because sometimes you want to NACK a byte instead of ACK it.

> - From the datasheet, ...

So just read the data sheet.  At best you didn't introduce any errors.

There is still no substitute for reading the data sheet.  I strongly
recommend to anyone using the MSSP module to read the entire IIC section,
except that you can skip the multi-master stuff if you are not doing
multi-master.  Otherwise, read it thru entirely.

Of course the tricky parts come from the stuff not mentioned in the data
sheet.  It covers the basic normal cases just fine, but these don't cause
the trouble.  This is why you need to read the whole IIC section very
carefully.  You need to try to understand the implementation so that you can
make educated guesses about what happens when something out of the ordinary
is being done.  Even then you will have to do some experimenting.

For example, what exactly happens when a slave is overrun on a write?  Sure,
an overflow bit gets set, but how exactly do you recover?  What does this do
to the slave state machine?  What implications does this have to the higher
level protocol that you have to design?

This is just one example of what would be useful to include in additional
documentation.  I don't see any value in a document that just reads the data
sheet to you.  At best it doesn't introduce errors.  IIC via the MSSP is not
the kind of thing you want to distill down to "cookbook" level because there
are subtle complexities that will bite you.

Someone else posted a link to a Microchip PDF about IIC.  At least it has
added value because it introduces IIC concepts in small baby steps suitable
for beginners.  However, I flipped thru it quickly and quit after the first
blatant error confounded by an outright wrong example.  Argh!!



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

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


2002\08\03@095454 by Jinx

face picon face
> > that mean an EEPROM > 1k x 8 can't be accessed above
> > 03FF ?
>
> No, different address space.

I realised my mistake of misreading the contents of the control
byte which comes after the start bit. It depends on which memory
chip you're using, eg 24C32 or eg 24AA174. My fault for giving
myself a little scare by reading too much. But a little adrenaline is
a great focussing aid ;-)

> The 7 or 10 bit address refers to the addresses of slave modules
> on the IIC bus.  This has nothing at all to do with the EEPROM's

Until I pick up the AMD 64k device I'm testing code on an Atmel
24C32 (8k). This, as you say, has 1010 + xxx + R/W after the start
bit, then the address bytes. The 256 and 512 devices also do it
this way so the C32 code should work OK

> internal address space.  By the way, almost everyone uses 7 bit
> addressing.  127 possible slaves is usually WAAAAAYYYY more
> than enough.

I would expect you'd have problems with signal quality, although if
the device is in power-down mode after an operation maybe the
SDA and SCL pins in turn do not present as high a load on the bus
as when the chip is active. It doesn't say in any of the datasheets
one way or another AFAICT

> Also, most EEPROM chips only use 7 bit addressing, and often have
> most of those hard wired.  Usually you only get to chose the low 1 or 2
> address bits the chip will respond to.

The 8-pin memory chips all seem to have A0 A1 and A2 (8 chips per
bus, 000 to 111) available for hard wiring, whereas ICs like the PCF2116
or PCF8583 have just A0

> Yes, that means you can't put more than 2 or 4 of these chips on the
> same IIC bus without some external selection scheme

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


2002\08\03@095736 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Hi,

Jinx wrote:
>Tony, why do some of your instructions include the ,A ?

well I noticed you already got an reply, but to recap, it's an special ram bank than can always be accessed on the 18xxx chip without needing to set the ram bank selection bits.
Sort of similar to the 16F8xx series 'mirrored ram'. Quite
handy for isr routines or to pass variables between routines.
Supposedly one should be able to omitt the ',A' when using reloctable
code and the linker, but that just didn't work in the early versions. This snippet was form that 'era' :)

Anyway some minor points to the state handler:

Only allows one tx/rx at a time, i.e. no i2c 'stack'.

- before statring the i2c write, the following should be
 performed:
 - check that state=0 and that there are no activity on the bus
 - setup i2c slave adress (if not done before)
 - fill i2c buffer with relevant data, count=no.of.bytes
- call isr state handler *outside* the isr when everything is setup
 it will initiate the start condition and set state=1,
 form hereon everything will be handled inside the isr.


- before statring the i2c read, the following should be
 performed:
 - check that state=0 and that there are no activity on the bus
 - setup i2c slave adress (if not done before)
 - setup dest adress pointers (where the data will be stored)
 - setup number of bytes to read
- setup state=4 and call isr state handler *outside* the isr   when everything is setup it will initiate the start condition and set
state=5,
 form hereon everything will be handled inside the isr.


Some example snippets:

*example isr handler*
INT_TEST_I2C_IRQ
       
       ; TEST FOR COMPLETION OF VALID I2C EVENT         BTFSS   PIE1,SSPIE,A    ; test if interrupt is enabled
       GOTO    INT_TEST_ANOTHER_FLAG
       BTFSS   PIR1,SSPIF,A    ; test for SSP H/W flag
       GOTO    INT_TEST_ANOTHER_FLAG ; optionally test for bus
collision (if multi master)
       BCF     PIR1,SSPIF,A    ; clear SSP H/W flag
       TSTFSZ  i2c_State,A     ; if non zero then continue i2c seq.
       CALL   I2C_INT_HANDLER  ; service valid I2C event              



*wait for idle* ( potential dangerous code, can loop forever, I also
use an timer to detect timeout conditions so this is circumvented )

;+++++
;       I2C_WAIT_IDLE Holds execution until there is no activity on the
i2c bus
;       Either local or remote

I2C_WAIT_IDLE
       GLOBAL  I2C_WAIT_IDLE
       ; check that there are no local activity ( all rx/tx's are done
)
I2C_WAIT_IDLE_BUSY
       TSTFSZ  i2c_State,A
       GOTO    I2C_WAIT_IDLE_BUSY

I2C_WAIT_IDLE_FLUSH
       ; test for i2c bus idle state
       BTFSC   SSPSTAT,R_W,A     ; test if transmit is progress         GOTO    I2C_WAIT_IDLE_FLUSH ; module busy so wait
I2C_WAIT_IDLE_BUS
       MOVF    SSPCON2,W,A       ; get copy of SSPCON2 for status bits
       ANDLW   0x1F            ; mask out non-status bits
       BTFSS   STATUS,Z        ; test for zero state, if Z set, bus is
idle
       GOTO    I2C_WAIT_IDLE_BUS ; bus is busy so test again

       RETURN

*start write* (can be outside isr)
;+++++
;       I2C_START_TX Starts an transmission with data in i2c buffer
;       and current adress
I2C_START_TX
       GLOBAL  I2C_START_TX
       CLRF    i2c_eventflags,A
       CALL    I2C_INT_HANDLER
       RETURN

*start read* (can be outside isr)
#define I2C_RXSTART_STATE       0x04 ; i2c state for starting an rx
sequence

;+++++
;       I2C_START_RX Starts an transmission with number of byte in w
;       and current adress, data will be stored in i2c_buffer
I2C_START_RX
       GLOBAL  I2C_START_RX
       MOVWF   i2c_read_count,A; save byte counter
       CLRF    i2c_eventflags,A
       MOVLW   I2C_RXSTART_STATE       ; setup i2c state variable
       MOVWF   i2c_State,A
       CALL    I2C_INT_HANDLER ; and issue the start condition
       RETURN

/Tony

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


2002\08\03@112939 by Jinx

face picon face
> Anyway some minor points to the state handler

Thanks once again for your code examples, and to Olin
for his "what can go wrong" comments

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


2002\08\04@200434 by Jinx

face picon face
I got MSSP I2C code working (just squeaked in before
midnight Sunday - a good end to the weekend)

http://home.clear.net.nz/pages/joecolquitt/i2c.html

I'd be interested in any comments

This is basically in-line code that follows the manual diagrams
and seems to work OK with any data at any address. It doesn't
do anything fancy such as error detection, block writes etc
which can come later, now that there's something to build on

Undoubtedly it can be optimised, for example Olin's gotchas
such as the SDA capacitance, and can be broken down into
macros or calls, but it's a start

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamspamEraseMEmitvma.mit.edu


2002\08\05@121604 by Harold M Hallikainen

picon face
On Sat, 3 Aug 2002 07:19:45 -0400 Byron A Jeff <KILLspambyronspamBeGonespamCC.GATECH.EDU>
writes:
> On Sat, Aug 03, 2002 at 04:36:21PM +1200, Jinx wrote:
> > Tony, why do some of your instructions include the ,A ?
>
> It's the 18XXXX "access bank". It's a special memory designation
> that consists
> of the special function registers + 128 bytes of handily accessible
> general
> purpose RAM in bank 0. It's special because you can access it
> directly without
> having to switch/setup the bank select register. It's described in
> secton 4.10
> of the 18FXXX datasheet.
>

       But, the Microchip assembler automatically decides whether to use the
access bank or not, so you need not include the last parameter in your
source code. If the address is in the access bank, access bank addressing
is used. If not, the assembler tells the processor to use the BSR to get
to the memory location. That can be kind of a pain, since you may have to
keep changing bsr. You can (as in all PICs) use an FSR to access all of
RAM without messing with banks. Also, on the 18 series is the movff
instruction. It lets you access all of RAM without use of the bsr. Also,
since the wreg has a RAM address, you can do stuff like movff something,
wreg.

Harold


FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

Reach broadcasters, engineers, manufacturers, compliance labs, and
attorneys.
Advertise at http://www.hallikainen.com/FccRules/ .


________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/web/.

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


2002\08\05@122155 by Olin Lathrop

face picon face
> You can (as in all PICs) use an FSR to access all of
> RAM without messing with banks.

This is not true of the 16 family.  The FSR is only 8 bits wide, so can only
cover half the 9 bit RAM address space at a time.  The remaining address bit
comes from the indirect bank select bit in the STATUS register.


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

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


2002\08\05@140118 by Harold M Hallikainen

picon face
On Mon, 5 Aug 2002 12:21:37 -0400 Olin Lathrop
<EraseMEolin_piclistspamEraseMEEMBEDINC.COM> writes:
> > You can (as in all PICs) use an FSR to access all of
> > RAM without messing with banks.
>
> This is not true of the 16 family.  The FSR is only 8 bits wide, so
> can only
> cover half the 9 bit RAM address space at a time.  The remaining
> address bit
> comes from the indirect bank select bit in the STATUS register.
>

       Oops!  Thanks for the clarification! Gotta watch what I say!

Harold


FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

Reach broadcasters, engineers, manufacturers, compliance labs, and
attorneys.
Advertise at http://www.hallikainen.com/FccRules/ .


________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/web/.

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



'[PIC]: F877 I2C module'
2002\09\11@054056 by Alan B. Pearce
face picon face
Back in August Olin wrote

>3  -  The MSSP module does not directly support slave flow control
>during a write.  The master can always slow down communications to
>avoid being overrun of underrun because it controls the clock.  A
>slave during a read sequence can (automatically does) do clock stretch
>to avoid underrun. However, there is nothing a slave can do to avoid
>overrun during a write, at least not directly using just the IIC bus
>via the MSSP.

Is this correct? I understood that a slave can avoid overrun during a write
by clock stretching the acknowledge bit. Using the code from AN734 (Slave
I2C using SSP) this is what I see happening on the I2C bus, because it
collects the byte out of SSPBUF before releasing the clock for the ACK.

I came across this while going through my archive of mails which I squirrel
away as useful potential problem solvers.

The problem I have is the slave device seems to hold the clock low after a
read of a byte. I suspect that what I see may be corrected by applying what
Olin says below, though I doubt it for reasons I give after the quote.

{Quote hidden}

First my clock rate is much slower, the PIC is clocked at 3.6MHz, and the
I2C is currently running at about 50KHz. The I2C clock rate was run at this
speed for other problems which have now been resolved, and has not yet been
put back to 100kHz. Both devices are 16F876's. The master device writes and
reads some EEPROM chips and DAC chips satisfactorily on the I2C bus, so I
believe the code in this is satisfactory.

From reading the AN734, it would seem that once the byte is put in the
buffer of the slave for transfer to the master, everything should be
automatic for the data to transfer and the NAK to be generated by the
master, once the slave releases the clock. I see the eight clock pulses for
the data, but the clock for the ACK never occurs. The other thing that
puzzles me is that the byte that is supposed to be transmitted is 01, but
what I see on the I2C bus is 00, and the bus never gets released after the
eight clock pulses. Has anyone else had to deal with a problem like this,
and give an idea of the remedy?

TIA

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\11@064623 by Jason Harper

picon face
"Alan B. Pearce" <@spam@A.B.Pearce@spam@spamspam_OUTRL.AC.UK> wrote:
> From reading the AN734, it would seem that once the byte is put in the
> buffer of the slave for transfer to the master, everything should be
> automatic for the data to transfer and the NAK to be generated by the
> master, once the slave releases the clock. I see the eight clock pulses
for
> the data, but the clock for the ACK never occurs.

The data transfer is automatic, the NACK/ACK isn't - how would the master
know which of the two you wanted to send?  You have to set or clear ACKDT
as desired, and then set ACKEN (both in SSPCON2) at the master side for the
9th bit to be transferred.
       Jason Harper

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\11@074353 by Alan B. Pearce

face picon face
>The data transfer is automatic, the NACK/ACK isn't - how would the master
>know which of the two you wanted to send?  You have to set or clear ACKDT
>as desired, and then set ACKEN (both in SSPCON2) at the master side for the
>9th bit to be transferred.

Yes I appreciate that, and the code in the master is working correctly.

However on digging somewhat deeper into what is happening in the slave
device which is where the malfunction happens, I find that somehow the TRIS
bit for the SDA line is getting set to output, and the port bit is set to 0
:))))

The TRIS bit is getting changed somehow while another couple of pins are
having their tris bits changed to change direction, and it is occurring
during an independent operation. Most of the time the code is working
because the I2C is not being accessed during the critical times, so the
problem is not seen.

Now I just have to work out precisely which instructions sure misbehaving.
:))

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\11@082123 by Olin Lathrop

face picon face
> Back in August Olin wrote
>
> >3  -  The MSSP module does not directly support slave flow control
> >during a write.  The master can always slow down communications to
> >avoid being overrun of underrun because it controls the clock.  A
> >slave during a read sequence can (automatically does) do clock stretch
> >to avoid underrun. However, there is nothing a slave can do to avoid
> >overrun during a write, at least not directly using just the IIC bus
> >via the MSSP.
>
> Is this correct?

Nah, I just made it up.  August was a slow month.

> I understood that a slave can avoid overrun during a write
> by clock stretching the acknowledge bit.

No, it can't.

> The problem I have is the slave device seems to hold the clock low after a
> read of a byte.

Right.  Like I said, the MSSP does clock stretch on a read, but not on a
write.  Therefore after a read transfer, the slave will hold clock low until
SSPCON,CKP is set to release it.

{Quote hidden}

That means you have a minimum of 1.1uS between setting SSPBUF and releasing
the clock by setting SSPCON,CKP.  This is fine as long as your worst case
SDA rise time is less than 1.1uS.  If not, insert NOPs to increase the delay
between SDA being set to the new value and SCL released.

> and the I2C is currently running at about 50KHz.

This has nothing to do with the problem above, which is a function of SDA
rise time, not bus clock speed.  Of course the maximum SDA and SCL rise
times do dictate the upper limit of the clock speed.

> From reading the AN734,

Personally I don't find the Microchip app notes of much use.  It is much
more important to read the data sheet very carefully.  You probably need to
read the MSSP chapter and IIC section several times.

> it would seem that once the byte is put in the
> buffer of the slave for transfer to the master, everything should be
> automatic for the data to transfer and the NAK to be generated by the
> master, once the slave releases the clock.

Not quite.  First the master must be tring to do a read, else the clock
pulses will never be generated whether the slave releases the clock or not.
Second the master does not automatically generate ACK or NACK.  This must be
done separately by the master code after the byte is received.  It sets
SSPCON2,ACKDT to select ACK or NACK, then sets SSPCON2,ACKEN to start the
ACK/NACK sequence.  You really need to read the data sheet, screw the app
notes.

> I see the eight clock pulses for
> the data, but the clock for the ACK never occurs.

That is consistant with your misconception above.

> The other thing that
> puzzles me is that the byte that is supposed to be transmitted is 01, but
> what I see on the I2C bus is 00, and the bus never gets released after the
> eight clock pulses. Has anyone else had to deal with a problem like this,
> and give an idea of the remedy?

Strange and undocumented things can happen when a slave is overrun on a
write, but it seems you are having problems with reading.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\11@095312 by Jason Harper

picon face
"Alan B. Pearce" <spamBeGoneA.B.PearcespamKILLspamRL.AC.UK> wrote:
> The TRIS bit is getting changed somehow while another couple of pins are
> having their tris bits changed to change direction

Let me guess, you used BSF or BCF on TRISC?  There is a problem with
read-modify-write instructions on the TRIS registers with certain
peripherals active.  TRISC<3:4> have to be inputs (1) for the SSP module to
work, however if you do an RMW operation to TRISC at a moment when the SSP
module is using one of those pins as an output, the bit will read as a 0,
and get written back as a 0.  See section 3.3 of the 16F877 datasheet.
       Jason Harper

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\11@115732 by Alan B. Pearce

face picon face
>Let me guess, you used BSF or BCF on TRISC?  There is a problem with
>read-modify-write instructions on the TRIS registers with certain
>peripherals active.  TRISC<3:4> have to be inputs (1) for the SSP module to
>work, however if you do an RMW operation to TRISC at a moment when the SSP
>module is using one of those pins as an output, the bit will read as a 0,
>and get written back as a 0.  See section 3.3 of the 16F877 datasheet.

yeah that is exactly what I am doing, and had come to the same conclusion
from what I was seeing as the problem. I am going to modify the hardware to
move the lines that need their direction changing to port A (port B is
already fully in use). I hadn't appreciated the dirty way they deal with the
TRIS register, while the data register is properly multiplexed. talk about
spoil the unit for a ha'porth of tar :))

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


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