I have a question about the implementation of 'reseting' the I2C module
(SSP) on the 16C63.
I have a pin on PORTB that I read occaisonally, if the pin is low, I
wish to 'reset' the SSP. To reset, is it
appropriate to do the following:


                BCF     SSPCON , SSPEN
                BSF     SSPCON, SSPEN

Are there any timing issues involved between disabling and then ENABLING
the SSP? Is this the proper way to ENABLE/DISABLE the SSP?

Thanks in advance.
> -----Original Message-----
> From: john.day@Microchip.COM [SMTP:john.day@Microchip.COM]
> Sent: Thursday, February 05, 1998 4:04 PM
> To:   Najemy, Daniel
> Subject:      Re: SSP Module Robustness
>
>      HI Daniel-
>
>         Congrats on getting your sofware to work!
>
>         In slave mode, the I2C port is a "slave" to the SCL line.
> This
>      allows the slave port to support clock frequencies from 0 Hz to
> 400
>      Khz.  If the master should "suddenly kill the clock" in the
> middle of
>      the transfer, the slave (PICmicro) would not be able to dectect
> this
>      automatically since the slave hardware is simply waiting for the
> clock
>      to assert.  It has no way to distinguish between a slow clock and
> a
>      dead clock.   So by default, this is not automatic, but of
> course, you
>      can build this functionality into your communication protocol
>
>      1) If you are worried about dead clocks, then add a background
> timeout
>      routine that will reset the SSP (by turning it off and then back
> on
>      again) if the slave is expecting another byte but it has not been
>
>      recieved after this timout period has expired
>
>      2) Add a packet checksum and ignore the packet if the checksum is
> bad.
>
>      3) Have the master send an extra stop bit before each packet
> transfer
>      (preceeding the start bit) to reset the slave SSP.
>
>      4) Have a status read command from the master to read slave
> status for
>      acknowledment of reception (and execution) of a command sent.
>
>      You could go on and on adding more robust features.  Depending on
> the
>      noise, line length, etc. some of these techniques may be
> overkill, but
>      they are worth considering if you want to improve error recovery.
> Of
>      course, you should test out various failure modes once you
> complete
>      your software to make sure you get your expected results.  You
> are
>      wise to investigate how your system reacts to error conditions.
>
>      Regards,
>
>      John
>
>
> ______________________________ Reply Separator
> _________________________________
> Subject: SSP Module Robustness
> Author:  "Najemy; Daniel" <DNajemy@imps0014.us.dg.com> at
> Internet_Exchange
> Date:    2/5/98 1:04 PM
>
>
>
> Hi John -
>
> I just got my I2C slave code to work - and had a ? for you. Is the SSP
>
> module hardware clever enough
> to be able to deal with various abnormal data sequences from a master?
>
> ie. What would happen if the
> master clock died in the middle of a transfer?
>
> Since the software only has access to the various flag bits - I would
> hope that the hardware would know enough to abort. I couldn't find
> anything to this effect in the text.
>
> Thanks
> Daniel Najemy -  Data General Corporation, Numaliine Power Systems
>       << File: cc:Mail note part >>