> > The SPI clock line is generated by the master, and I am wondering
> > how to slow it down from the PIC side if the I2C transfer is taking
> > too long (since I2C slaves can stretch the clock at will) to avoid
> > the SPI rx buffer in the PIC being overrun with data that cannot
> > be handled in time.
>
>Do you have any control over the protocol the master ARM uses to
>communicate with the PIC? If so, you could either provide responses
>to the master that would indicate flow control,

I do have some control over the SPI master side, yes. It is this
kind of flow control I was thinking about in the first place, but
I am unsure how to do it. This is I was asking for experiences of
others, to know in advance which kind of pitfalls I'll find :)

>or you could add a
>"request to send" handshaking output from the PIC to the ARM.

Could you elaborate on this?

Thanks!
G.

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