Electronic – BMA180 accelerometer. How does it manage to share pins between I2C and SPI

I don't agree with Madmanguruman's statement: "For both 'normal' I2C and 'normal' SPI, each slave needs a direct connection to the master, so all the slaves are in parallel regardless of the physical placement of the devices." Shift registers are very often wired in series, which makes a big loop that requires several shifts to circulate the data. That's just one example of a valid series connection and there are many more. Parallel is likely more common as I'll explain below whenever the slave devices aren't simple or literally shift registers. How you do it completely depends on the requirements of your design as well as the functionality of your slave devices.

More details:

Using the word series does actually make sense. What you're saying is the MOSI (master out / slave in) pin on the master is connected to the serial data input of slave 1. The serial data output of slave 1 is connected to the serial data input of slave 2 and the serial data output of slave 2 is connected to the serial data input of slave 3. Finally, to complete the loop (assuming you want bidirectional communication), you would connect the serial data output of slave 3 to the serial data input of the master. To make this work, the clock generated by the master has to be connected to every slave. Additionally, every slave will likely need to be on the same chip select signal to make sure the SPI hardware will respond. To read from all three slaves, you'd have to send three transmissions from the master.

If you connect everything in parallel, now you need a discrete chip select for each slave. The capacitance of the data signals should be trivially higher in this configuration and the clock signal capacitance is unlikely to be drastically different.

As far as routing goes, it probably won't matter as long as you're staying below 100 MHz or so. Higher frequencies start to introduce other issues. Regardless, there are plenty of reasons to go either way. It can certainly depend on your firmware constraints. Edit: As pointed out by MartinThompson, if your route is long with a strong (fast edge rate) driver, it's possible that reflections can cause issues. If you're making a multi-drop route and you expect fast edge rates, terminating the signal should significantly help. This could be another conversation, but suffice it to say that you can add series or ground referenced terminators to absorb the energy and prevent reflections.

For example, many microcontrollers will allow you to interact with SPI devices using DMA. If all of the slaves are on the same chip select, it's less code to communicate with all of them, but the latency is higher as you have to shift more data to complete the transaction. Slaves can also signal that they want to transmit, but since the master generates the clock the series connection can cause some headaches here. If you don't care about that use case, though, then wiring in series will simplify the DMA configuration. It's possible to use DMA to communicate with multiple peripherals by embedding the chip select in the data, which causes the DMA controller to handshake with the appropriate slave. You may not even have DMA, but I thought I should explain this to give you an example of why a series configuration may be advantageous in some circumstances. DMA trivializes parallel connections as well, to be fair, and quite frequently parallel connections are much more desirable in this type of situation.

Wiring in parallel is probably the more traditional way to do it based on my experience if the slave device functions at a higher level than simple shifting. I wire shift registers in series all the time, but I frequently attach multiple slave microcontrollers on the SPI bus in parallel so they each get their own chip select and slave select (the slave select is allocated for slave -> master communication, which basically says "hey I need to send data, give me a clock").

Lastly, you can't wire I2C in series unless you want to use different I2C buses for downstream devices. I2C requires that all devices be connected in parallel. The only thing you have to care about electrically is that you picked the right value for the external pull-up resistor. Because there can be many devices (7 bits worth) attached to the I2C bus, a weak pull-up could cause the bus signals to be metastable from the perspective of everything that's watching the bus for incoming data. You want to make sure the SDA line is firmly high before the next clock cycle and you do that by properly sizing the pull-up resistor.

Don't use internal pull-ups for I²C. Use external resistors.
In other words, it's a design error when you attempt to use internal pull-ups for I²C (pretty much on any microcontroller).

The datasheet says that internal pull-up current is 50μA min and 400μA max. First, look at the huge variability of the pull-up current. Second, even 400μA is too weak for I²C. Even a 2.5kΩ resistor with Vcc=3.3V would generate a 1.3mA pull-up current.

Related threads:
What happens if I omit the pullup resistors on I2C lines? The O.P. was using internal pull-ups without knowing it. Illuminating oscilloscope plots in that thread.
Is there a correct resistance value for I2C pull-up resistors?