Raspberry Pi SPI interface with PIC-16f877A

A few points. That Maxim article targets a specific type of spi device. Mainly ones that are write only. Notice only MOSI is shown, not MISO. Additionally, these devices are chained, so data is shifted from one device to the other, like a shift register. (One common use of SPI peripherals on a microcontroller is to use them to drive common shift registers.)

SPI does not require the master to receive data. A slave is not required to respond. You can even have read only SPI devices, where the Master just clocks in data from the Slave (Only uses MISO). You can even have a 3 wire variation where MOSI and MISO are tied together (half duplex only). It all depends on the type of spi device you are using. Additionally, SPI can do Full Duplex transfers, but not all devices support this. As Wikipedia states, most devices do half duplex, even when wired in 4-wire mode.

In that note, the SPI devices are write only.

As for the clock frequency question, there is no auto negotiation of clock speeds. This is decided while the master is being programmed. You have to account for it.

Some I2C slave devices use hardware handshaking, which entails having slave devices which are not immediately ready for a cycle holding SCK low until they are, and having master devices which release SCK wait until the line actually rises before processing the next cycle. Such devices will not coexist nicely with an SPI bus.

If the I2C device won't accept 00 or FF as an addressing byte, one may avoid any possibility of interference by either configuring the SPI bus so the data state will only change when the clock is high, or else by ensuring that the I2C device will see any falling clock edges as happening after any associated data change. Depending upon what sort of SPI device one is connecting to, that may be the natural state of affairs or it may be somewhat awkward. If one is bit-banging SPI, there will generally be no difficulty ensuring that the sequence of highs and lows on SCK/SDA will continually reset the I2C chip without it ever being able to say anything. If one needs to use hardware SPI but can bit-bang I2C, wiring SCK to something other than the SPI clock may allow one to avoid trouble [e.g. if one wires SCK to MOSI and SDA to MCK, then it would be impossible for SCK to see more than two consecutive cycles without having a rising or falling edge on SDA occur while SCK was sitting high].

An important caveat with this approach, however, is that many I2C devices do not specify their behavior if transitions on SCK or SDA happen above a certain speed, and SPI devices are often run far above the speeds that I2C devices can accommodate. If practical, it may be good to either have I2C share one pin with SPI but not both, or add some hardware to ensure the I2C doesn't see fast signals on both SCL and SDA