1. Yes, the Edison does provide two available I2C interfaces but this is on the Compute Module. What does this mean? It means that if you are using the Edison as a Standalone device you have two interfaces available in the 70 pin connector. I2C1 is found on pins 41 and 43, I2C6 is found on pins 45 and 47 according to the Intel® Edison Compute Module Hardware Guide on section 4.2. On the Arduino Expansion Board on the other hand, the I2C1 interface is used to control the programmable pull ups as you can see in the Intel® Edison Arduino* Expansion Board Schematic on sheet 6. Also, if you check the Intel® Edison Arduino* Expansion Board Schematic on sheet 6, you'll find that A4 and A5 are connected through a MUX to I2C6_SCL and I2C6_SDA as well as the SCL and SDA pins.
2. It depends on the voltage your device operates, as you may assume, the Arduino Expansion Board has its own level shifters (since the Compute Module works at 1.8v and 3.3v), so if your device works at 5v, no you shouldn't need a level shifter.
3. Yes, you do. You can find the configuration in section 11.6 of the Intel® Edison Arduino* Expansion Board Hardware Guide.
4. As I said on 1. if you check the http://www.intel.com/support/edison/sb/CS-035272.htm on sheet 6 you'll find that I2C1 is connected to the programmable pull ups and what seems to be the SPI driver.
5. I'm not sure about this one but by looking on mraa/I2c-compass.cpp at master · intel-iot-devkit/mraa · GitHub I believe that if you state "i2c = new mraa::I2c(0);" it means that you are selecting I2C6.
If you were to build your own hardware, and you wanted to use an open drain device, you shouldn't need a level translator if you set VDD to 1.8v (output voltage of the Compute Modules GPIOs). If you decide to do so, make sure that you are receiving a high state of 1.8v.
But to resume, no you shouldn't need a level translator if you use an open drain device.
Related to your answer of:
"3. Using i2cdetect
Do I have to configure anything before using i2cdetect?"
I think your answer is wrong. I was able to use i2cdetect without enabling/setting specific pins.
Related to the level shifter: I used a power supply unit and an oscilloscope. It is definitely necessary to use voltage level shifters what is completely strange, because normaly I2C is open drain and does not care whether high is 1.8V, 3.3V, 5V or whatever. This is a very strange hardware design of the intel edison in my opinion. Furthermore, the I2C signal looks really bad. I did not connect any slaves to the I2C of the intel edison (Mini Breakout Board) and used the following command:
i2cset 1 0x22 0xaa (Trying to write 0xaa to the non-existing slave 0x22 with I2C-1)
Have a look here:
The signal looks really really bad. I saw sth. similar in some posts of KurtE. No sharp flanks at all. It seems like a capacity is involved within the edison hardware layout. To be honest: I was totally surprised that my PCF8574 ICs reacted on these signals when connecting them to the mini breakout board (but of course only with a I2C high voltage of 1.8V ...).
Maybe Intel should rethink about the I2C design within the next version?
I'm sorry, I must have gotten confused. The settings I provided were for the Arduino Expansion Board, which I thought you were using.
When using the Mini Breakout board you need to set the muxing from gpio to i2c with the following commands as you mentioned.
echo mode1 > /sys/kernel/debug/gpio_debug/gpio28/current_pinmux
echo mode1 > /sys/kernel/debug/gpio_debug/gpio27/current_pinmux
Also, for a Mini Breakout you should use a logic shifter if the i2c device requires a voltage different than 1.8V. On an Edison Arduino board, there is no need for a level shifter since most i2c devices require 3.3V or 5V which can be obtained from the Arduino headers.
Regarding the i2c signals, the SCL is clocked at around 290 kHz when using I2C via Linux. At these speeds we can observe the rising/falling edge of a pulse. When running an I2C Arduino sketch the SCL is clocked at around 211 Hz and the square signals can be observed. Observing the signals with a logic analyzer we can conclude that the pulses are being detected correctly. Please take a look at the following file: