Tom,

I think I can help some, but partly, you are running into some of the
limitations of I2C and especially the PIC SSP.
> The address
> match, receive, transmit works good except for the fact that the receive
> generates an automatic Ack every time it receives a valid byte transmission.
If the PIC is a slave, it should ACK a valid byte.  But if your
protocol lets the slave stop the transfer by NACKing a byte, then
you can't use purely hardware methods.

You could try simulating an overflow by setting the SSPOV bit
and see if you can fool the SSP into NACKing.  This is just a guess.

Otherwise you'll need to change SSP modes or go to "bit-banging"
at least the last byte.
> The problem is that a)sometimes one needs to stretch the data / ack so the
> micro has time to operate
Clock stretching by the PIC as slave is supported correctly by the
SSP.

> and b) The I2C protocol has many instances of the
> slave Not issuing an Ack.
All the devices that I have used either NACK (ignore) their address
to signal busy, (the PIC SSP *can* do this) or ACK the address and
accept a data burst whose length is controlled completely by the
Master.

But couldn't you just ring off after sending your last byte by
disabling the SSP?  If its turned off, it ain't going to generate
ACK.  But the problem then, is that I haven't figured out (yet)
how to get the SSP to reset to Start-bit-hunt mode.

>Our instance is that the end of message in a variable length reply
>is signaled by not issuing the Ack.
Slightly off the subject of getting the job done, does that procedure
meet the I2C spec?

> Any ways around the problem such as grabbing the data port, etc. I already
> have a suggesting to insert a bogus byte that falls into an unaccessed SSP
> Buffer and causes a buffer full and no ack,
That bears an experiment, but I'd try just setting SSPOV first.

> but the Pic is a slave on the
> bus that already has a protocol established by the other, better behaved
> devices.
I disagree about whether the slave device telling the master to
shut up is "better" behavior.  But I understand what you are doing,
and it AUGHT to work.  But the SSP doesn't give us full control.

---------------------------------------------------
Barry King
Engineering Manager
NRG Systems "Measuring the Wind's Energy"
barry@nrgsystems.com
"The witty saying has been deleted due to limited EPROM space"