hextejas:
Does this mean that any device attached to the SDA pin is talking to it even though the sketch may have no intention to try and control(signal ?) it ?
As an example, the Blink example sketch does not use the SDA pin but there might be an SDA device attached to it. Is there interaction between the pin and the processor ? ( I don’t know who/what controls the SDA pin. Is there a separate chip on the Feather board that handles this ?)
I2C is designed around the idea of 1 master and 1 or more slaves. If you look at any I2C slave device (an I2C OLED display for example) it will have an address. Usually it will have a choice of addresses that you can set with jumpers, for example I have some OLED displays that can have the address 0x78 or 0x7a, this is set by a solder bridge on the board. All I2C devices on the same bus must have different addresses. When the master wants to communicate with a slave it send the address first, this tells the slaves which one is to respond. The others then ignore the data on SDA. The master sends commands and data to the slave. If the master wants data from the slave it sends a command telling the slave to reply with the required data. SCL clocks the data on the bus in either direction.
I2C is normally taken care of by dedicated hardware in the microcontroller that is designed to do in hardware all the I2C functions. This means the processor can instruct the hardware to transfer some data then go and do something else while the hardware takes care of the data transfer.
It is also possible to implement I2C in software, you will see this referred to as ‘bit banging’, which is a crude way of saying the processor has to set and clear SCL and SCA using software for every single bit. Software I2C is very processor intensive and very slow. My first use of I2C was on a Z80, I wrote a soft I2C interface in Z80 assembly language and it took, so far as I can remember, about 1 second to read the temperatures from 4 I2C temperature sensors.