AH-HA You have hit the nail right on the head - with a club hammer - I was also wondering about that and got my poor old brain in a complete taffle - mixing the two "I wonder how it works" up together. humm - could you point me to some text or descriptio how the various pin mode switches are done ? Auto-Magically ? or do I have to trigger macros - somehow.
Thanks 3 you all.
Mike
Well to see how it really works, you have to do a deep dive into the library sources and also read the processor manual for the particular processor involved.
In general, each pin has several modes that it can be in, and when you use the library function for a particular library and/or use the
pinMode function, it sets the mode automatically. In the case of alternate pins, you have to call a function to set that you are using an alternate pin.
Usually you don't have to worry about doing the switch, as it happens behind the scenes. Sometimes you do. For example, I have this script (uncannyEyes) that was written by somebody at Adafruit to rapidly draw two eyes on two 128x128 bit displays. I wanted to add ws2812b (neopixel) support because it wasn't gaudy enough, and I used the prop shield to do level shifting for the ws2812b LEDs. The prop shield uses the SPI pins (11, 13), and it has another pin that says do the level shifting. When I add the LEDs, I have to manually stop those pins from being in SPI mode, and put them into normal mode, and then reverse the process after the LEDs are emitted so I could use SPI to write to the screens (note, somebody else did the deep dive to figure out how to reset the pins).
For displays it becomes more complicated, since some of the libraries have optimizations that they will do the SPI writes in the background using DMA, and when you are switching, you have to wait until the DMA requests have all been handled.
On the SPI bus, you can have multiple devices on the bus, each device has a CS (chip select) pin, and when the pin is set to a certain state, the device will look for commands. If the CS pin is not in that state, the device will ignore the SPI commands. The Prop Shield that I mentioned uses pin 7 to enable voltage translation on pins 11/13, and pin 6 to enable reading/writing the flash memory chip in the prop shield. If neither pin 6 or 7 are set, the prop shield doesn't use pins 11 and 13. In terms of SPI, there are some devices that don't play nicely with other devices on the bus (and there are ways to deal with this).
The I2C bus is slightly different in that instead of a separate CS pin for each device, each device has an address, and the device will only talk to the master on requests where the address is the one specified in the request.
On the SPI bus, if you randomly turn the LED on/off, it may interfere with other SPI devices that you might be using.
BTW, some of the overlap pins such as the pin 13 being used for the SPI clock and for the LED was first used in the Arduino Uno and the Teensy just copied those pin assignments.