B+, i2c-0, and Jessie

[Richard-TX]

I added that requisite line to cmdline.txt and both buses appear. However the i2c-0 bus does not communicate with devices.

Are there any other tricks that need to be performed to get that bus functional?

[ShiftPlusOne]

Nope, there's nothing else. I'd check the pin functions to make sure that only the pins you're interested in are set up for I2C. If that's all good, then maybe taking a look at what's happening on a scope would help.

[Richard-TX]

It isn't just Jessie that is having an issue. It is Wheezy as well. I had assumed that the i2c-0 was working on the B+ once the bus was enabled. I was wrong.

Has anyone actually used i2c-0 on the B+?

[joan]

I've just bunged a PCF8591 on pins 27/28 etc., did the business in cmdline.txt, changed some gpio modes, and it's working fine.

Code: Select all

harry ~ $ i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
harry ~ $

[ShiftPlusOne]

I have been able to poke a HAT eeprom as well.

[mahjongg]

i2c-0 doesn't have the 1K8 pullups included that the normal I2C port has, so you need to add them externally, like a HAT board does.

[joan]

i2c-0 doesn't have the 1K8 pullups included that the normal I2C port has, so you need to add them externally, like a HAT board does.

My PCF8591 worked without adding any external pull-ups. I suppose the internal ones could be enabled by default.

[Richard-TX]

I've just bunged a PCF8591 on pins 27/28 etc., did the business in cmdline.txt, changed some gpio modes, and it's working fine.

Here is what I use to enable communications on the i2c-0 bus. Is there something else that needs to be done?

Code: Select all

#!/usr/bin/python
#!/usr/bin/env python
#
# W. Greathouse 13-Feb-2013
#
#   Enable I2C on P1 and P5 (Rev 2 boards only)
#

# #######
# For I2C configuration test
import os
import mmap

BCM2708_PERI_BASE=0x20000000
GPIO_BASE=(BCM2708_PERI_BASE + 0x00200000)
BLOCK_SIZE=4096

def _strto32bit_(str):
    return ((ord(str[3])<<24) + (ord(str[2])<<16) + (ord(str[1])<<8) + ord(str[0]))

def _32bittostr_(val):
    return chr(val&0xff) + chr((val>>8)&0xff) + chr((val>>16)&0xff) + chr((val>>24)&0xff)

def get_revision():
    with open('/proc/cpuinfo') as lines:
        for line in lines:
            if line.startswith('Revision'):
                return int(line.strip()[-4:],16)
    raise RuntimeError('No revision found.')

def i2cConfig():
    if get_revision() <= 3:
        print "Rev 2 or greater Raspberry Pi required."
        return
    # Use /dev/mem to gain access to peripheral registers
    mf=os.open("/dev/mem", os.O_RDWR|os.O_SYNC)
    m = mmap.mmap(mf,BLOCK_SIZE, mmap.MAP_SHARED,
            mmap.PROT_READ|mmap.PROT_WRITE,offset=GPIO_BASE)
    # can close the file after we have mmap
    os.close(mf)
    # Read function select registers
    # GPFSEL0 -- GPIO 0,1 I2C0   GPIO 2,3 I2C1
    m.seek(0)
    reg0=_strto32bit_(m.read(4))
    # GPFSEL2 -- GPIO 28,29 I2C0
    m.seek(8)
    reg2=_strto32bit_(m.read(4))
    # print bin(reg0)[2:].zfill(32)[2:]
    # print bin(reg2)[2:].zfill(32)[2:]

    # GPFSEL0 bits --> x[26] SCL0[3] SDA0[3]
    #                        GPIO    GPIO
    m0 = 0b00000000000000000000111111111111
    s0 = 0b00000000000000000000100100000000
    b0 = reg0 & m0
    if b0 <> s0:
        #print "reg0 I2C configuration not correct. Updating."
        reg0 = (reg0 & ~m0) | s0
        m.seek(0)
        m.write(_32bittostr_(reg0))

    # GPFSEL2 bits --> x[2] SCL0[3] SDA0[3] x[24]
    m2 = 0b00111111000000000000000000000000
    s2 = 0b00100100000000000000000000000000
    b2 = reg2 & m2
    if b2 <> s2:
        #print "reg2 I2C configuration not correct. Updating."
        reg2 = (reg2 & ~m2) | s2
        m.seek(8)
        m.write(_32bittostr_(reg2))

    # No longer need the mmap
    m.close()


if __name__ == '__main__':
    i2cConfig()

[joan]

I'm not sure but you appear to be setting gpios 28/29 to ALT0 (I2C), I set them as INPUTS so that the hardware uses gpios 0/1 for I2C.

Looking again at the code it seems to be setting gpios 0/1 as INPUT and gpios 28/29 as ALT0, the opposite of what you need to do for a B+ (but perfect for a Rev.2 B board with P5).

[Richard-TX]

Joan,

Can you suggest a way to set the proper modes for GPIO-0 and 1?

Maybe something from the command line using the shell.?

[joan]

Joan,

Can you suggest a way to set the proper modes for GPIO-0 and 1?

Maybe something from the command line using the shell.?

I thought I had seen some bash script to set the mode but it may have been false memory as I can't find it now.

The following is a stand alone C program which can be modified to set the modes you want.

Code: Select all

/*
2014-10-30
set_mode.c
Public Domain

gcc -o set_mode set_mode.c
sudo ./set-mode
*/
#include <stdio.h>
#include <unistd.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>

#define GPIO_BASE 0x20200000
#define GPIO_LEN  0xB4

#define GPLEV0    13
#define GPLEV1    14

/* mode: 0-7 */

#define PI_INPUT  0
#define PI_OUTPUT 1
#define PI_ALT0   4
#define PI_ALT1   5
#define PI_ALT2   6
#define PI_ALT3   7
#define PI_ALT4   3
#define PI_ALT5   2

static volatile uint32_t  * gpioReg = MAP_FAILED;

int gpioSetMode(unsigned gpio, unsigned mode)
{
   int reg, shift;

   reg   =  gpio/10;
   shift = (gpio%10) * 3;

   gpioReg[reg] = (gpioReg[reg] & ~(7<<shift)) | (mode<<shift);

   return 0;
}

int gpioGetMode(unsigned gpio)
{
   int reg, shift;

   reg   =  gpio/10;
   shift = (gpio%10) * 3;

   return (*(gpioReg + reg) >> shift) & 7;
}

main()
{
   int fd;

   fd = open("/dev/mem", O_RDWR | O_SYNC) ;

   gpioReg = mmap(0,
      GPIO_LEN,
      PROT_READ|PROT_WRITE|PROT_EXEC,
      MAP_SHARED|MAP_LOCKED,
      fd,
      GPIO_BASE);

   close(fd);

   if (gpioReg != MAP_FAILED)
   {
      gpioSetMode(17,  PI_ALT3);
   }
}

The Python you posted should work on the B+ with the following changes.

Code: Select all

s0 = 0b00000000000000000000100100100100

s2 = 0b00001001000000000000000000000000

[joan]

Oops, I made a mistake. The bit pattern to set INPUT mode is 000. I used 001 for 28/29 which would set them to mode OUTPUT.

s2 should be all 0s.

Code: Select all

s2 = 0b00000000000000000000000000000000

[mahjongg]

i2c-0 doesn't have the 1K8 pullups included that the normal I2C port has, so you need to add them externally, like a HAT board does.

My PCF8591 worked without adding any external pull-ups. I suppose the internal ones could be enabled by default.

the normal I2C doesn't have external 1K8 pullups for nothing you know! Internal pullups are extremely weak, in the 50K region, to0 weak to reliably work as I2C pullups.

Been there ... got burned by it!

When I2C doesn't work, add them, even when you think you don't need them!

[joan]

...
the normal I2C doesn't have external 1K8 pullups for nothing you know! Internal pullups are extremely weak, in the 50K region, to0 weak to reliably work as I2C pullups.

Been there ... got burned by it!

When I2C doesn't work, add them, even when you think you don't need them!

On my (unmodified) B+ gpios 0 and 1 appear to have hard wired pull ups to 3V3.

The gpios read back as 1 regardless of the state of the internal pull-ups being off, pull-down, or pull-up.

Code: Select all

harry ~ $ i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
harry ~ $ pigs mg 28 mg 29 # check 28/29 mode
4
4
harry ~ $ pigs m 28 r m 29 r # set 28/29 as inputs (r)
harry ~ $ i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
harry ~ $ pigs mg 0 mg 1
4
4
harry ~ $ pigs m 0 r m 1 r # set 0/1 as inputs
harry ~ $ i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
harry ~ $ pigs r 0 r 1 # read 0/1
1
1
harry ~ $ pigs pud 0 o pud 1 o # 0/1 pull-ups off
harry ~ $ pigs r 0 r 1
1
1
harry ~ $ pigs pud 0 d pud 1 d # 0/1 pull-down
harry ~ $ pigs r 0 r 1
1
1
harry ~ $ pigs w 0 0 w 1 0 # 0/1 output low
harry ~ $ pigs r 0 r 1
0
0
harry ~ $ i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
harry ~ $ pigs m 0 0 m 1 0 # change mode 0/1 to ALT0 (0)
harry ~ $ pigs r 0 r 1
1
1
harry ~ $ i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
harry ~ $ 

[Richard-TX]

Here is my updated code

Code: Select all

#!/usr/bin/python
#!/usr/bin/env python
#
# W. Greathouse 13-Feb-2013
# Richard A. - Nov, 17 2014 - Now works for B, B+ and CM
#   Enable I2C on P1 and P5 (Rev 2+ boards only)
#

# #######
# For I2C configuration test
import os
import mmap
bplus=0
BCM2708_PERI_BASE=0x20000000
GPIO_BASE=(BCM2708_PERI_BASE + 0x00200000)
BLOCK_SIZE=4096

def _strto32bit_(str):
    return ((ord(str[3])<<24) + (ord(str[2])<<16) + (ord(str[1])<<8) + ord(str[0]))

def _32bittostr_(val):
    return chr(val&0xff) + chr((val>>8)&0xff) + chr((val>>16)&0xff) + chr((val>>24)&0xff)

def get_revision():
    with open('/proc/cpuinfo') as lines:
        for line in lines:
            if line.startswith('Revision'):
                return int(line.strip()[-4:],16)
    raise RuntimeError('No revision found.')

def i2cConfig():
    if get_revision() >= 10:
       print "B+ or CM detected."
       s0 = 0b00000000000000000000100100100100
       s2 = 0b00000000000000000000000000000000
    if get_revision() <=9:
       s0 = 0b00000000000000000000100100000000
       s2 = 0b00100100000000000000000000000000
    if get_revision() <= 3:
        print "Rev 2 or greater Raspberry Pi required."
        return
    # Use /dev/mem to gain access to peripheral registers
    mf=os.open("/dev/mem", os.O_RDWR|os.O_SYNC)
    m = mmap.mmap(mf,BLOCK_SIZE, mmap.MAP_SHARED,
            mmap.PROT_READ|mmap.PROT_WRITE,offset=GPIO_BASE)
    # can close the file after we have mmap
    os.close(mf)
    # Read function select registers
    # GPFSEL0 -- GPIO 0,1 I2C0   GPIO 2,3 I2C1
    m.seek(0)
    reg0=_strto32bit_(m.read(4))
    # GPFSEL2 -- GPIO 28,29 I2C0
    m.seek(8)
    reg2=_strto32bit_(m.read(4))
    # print bin(reg0)[2:].zfill(32)[2:]
    # print bin(reg2)[2:].zfill(32)[2:]

    # GPFSEL0 bits --> x[26] SCL0[3] SDA0[3]
    #                        GPIO    GPIO
    m0 = 0b00000000000000000000111111111111
    #s0 = 0b00000000000000000000100100100100
    b0 = reg0 & m0
    if b0 <> s0:
        #print "reg0 I2C configuration not correct. Updating."
        reg0 = (reg0 & ~m0) | s0
        m.seek(0)
        m.write(_32bittostr_(reg0))

    # GPFSEL2 bits --> x[2] SCL0[3] SDA0[3] x[24]
    m2 = 0b00111111000000000000000000000000
    b2 = reg2 & m2
    if b2 <> s2:
        #print "reg2 I2C configuration not correct. Updating."
        reg2 = (reg2 & ~m2) | s2
        m.seek(8)
        m.write(_32bittostr_(reg2))

    # No longer need the mmap
    m.close()


if __name__ == '__main__':
    i2cConfig()

[mahjongg]

On my (unmodified) B+ gpios 0 and 1 appear to have hard wired pull ups to 3V3.

appear is the significant word here, There are four 1K8 pullups (real external resistors) on the B+, R21, R22, R23 and R24.
Two are on GPIO 2 and 3 (SDA1 and SCL1 pins 3 and 5 of the GPIO header) the other two are on GPIO's 28 and 29 (SDA0 and SCL0 for the camera connector. There are NO pullups on GPIO's 0 and 1 (ID_SD and I_SC pins 27 and 28 for the HAT EEPROM, those 1K8 pullups are on the HAT boards). I2C can be finicky about it's pullups, for some functions slow pullups are okay, for other functions, not so much.

It could be that the presence of pullups on GPIO's 0 and 1 is actually used as a simple and fast way to detect the presence of a HAT.

[Richard-TX]

Joan,

Thanks so much for your help. It is greatly appreciated.

richard

[joan]

On my (unmodified) B+ gpios 0 and 1 appear to have hard wired pull ups to 3V3.

appear is the significant word here, There are four 1K8 pullups (real external resistors) on the B+, R21, R22, R23 and R24.
Two are on GPIO 2 and 3 (SDA1 and SCL1 pins 3 and 5 of the GPIO header) the other two are on GPIO's 28 and 29 (SDA0 and SCL0 for the camera connector. There are NO pullups on GPIO's 0 and 1 (ID_SD and I_SC pins 27 and 28 for the HAT EEPROM, those 1K8 pullups are on the HAT boards). I2C can be finicky about it's pullups, for some functions slow pullups are okay, for other functions, not so much.

It could be that the presence of pullups on GPIO's 0 and 1 is actually used as a simple and fast way to detect the presence of a HAT.

I just tested gpios 0/1 when not attached to the PCF8591.

They do then read 0 when pulled low by the internal resistor.

However if I plug the PCF8591 in they read high, which is rather worrying as it presumably has pull-ups. I had better stop powering it from 5V.

Code: Select all

harry ~ $ pigs mg 0 mg 1 # get 0/1 mode
4
4
harry ~ $ pigs r 0 r 1 # read 0/1
1
1
harry ~ $ pigs pud 0 o pud 1 o # 0/1 PUD disabled
harry ~ $ pigs r 0 r 1 # read 0/1
0
0
harry ~ $ pigs pud 0 u pud 1 u # 0/1 PUD up
harry ~ $ pigs r 0 r 1 # read 0/1
1
1
harry ~ $ pigs pud 0 o pud 1 o # 0/1 PUD disabled
harry ~ $ pigs r 0 r 1 # read 0/1
0
0
harry ~ $ pigs r 0 r 1 # connect PCF8591  and read 0/1
1
1
harry ~ $ pigs r 0 r 1 # disconnect PCF8591 and read 0/1
0
0
harry ~ $ 

[Richard-TX]

Powering a PCF8591 with 5 volts is something I do not do. I use those chips a lot and while I do power MCP23017 with 5 volts I do not power the 8591 that way. It has to do with how the the 8591 modules I have are designed. It has it's own pullups (10k) to VCC. If I had raw chips and my own circuitry, I would likely power them with 5 volts with pullups to 3 volts. Maybe that is not a good idea with that chip. I would have to measure the SDA and SCL lines.

[Massi]

Ok, going to the n00b site of the moon.
Why powering devices at 5V if they correctly work at 3,3V?
Is it for the limited juice rPI can give at 3,3V?
But in this way, aren't you going to need to manage the level of i2c signals?

If you power a MCP23017 at 5V, i2c signals will be at 5V high, isn't it?

Thanks

(i power both mcp23017 and PCF8591 at 3,3V )

[Richard-TX]

The reason for powering the MCP23017 is to avoid the additional cost and complexity of a level shifter. Yes, powering the MCP23017 with +5 will also result in a 5 volt TTL compatible outputs. I makes interfacing to +5 volt devices easy.

The reason that it works is because there are no internal pullups on the MCP23017. Since the SDA and SCL lines are open, there are no worries.

Some will say that it does not meet spec when powered by +5 volts and that it won't work properly. I have deployed about 50 of those chips and not one has failed to work. Adafruit also runs some of their MCP23017 peripherals powered with 5 volts and with a 3 volt I2C bus without issue.

In my case, each MCP23017 has it's own 10k ohm pullups to +3 volts.

If it is good enough for Adafruit....who am I to argue.

[sukisan]

Hi

the normal I2C doesn't have external 1K8 pullups for nothing you know! Internal pullups are extremely weak, in the 50K region, to0 weak to reliably work as I2C pullups.

Been there ... got burned by it!

When I2C doesn't work, add them, even when you think you don't need them!

How do you read resistor values? Isn't 50k > 1,8k? Why is it "too weak" in this context?

@mahjongg: Can you elaborate what you mean by burned? Just "not working" or did anything (or anybody) got harmed?

And you'd only add them if I2C isn't working? How does a malfunctioning look like? Is it not working at all (easy to spot) or are there random transmission errors? Are these errors reported?

Thanks,
Suki

[rpdom]

How do you read resistor values? Isn't 50k > 1,8k? Why is it "too weak" in this context?

The higher the resistance the smaller the current that can flow, so the "pull" is weaker.

[Richard-TX]

Hi

Can you elaborate what you mean by burned? Just "not working" or did anything (or anybody) got harmed?

And you'd only add them if I2C isn't working? How does a malfunctioning look like? Is it not working at all (easy to spot) or are there random transmission errors? Are these errors reported?

Thanks,
Suki

"Burned" in this context mean wasted time.
I use 10k pullups at every device that I put on the I2c bus. These are in addition to the main pullups that is usually on the bus.
Malfunctions due to a lack of pullup generally show as data errors or a disappearance of devices when the bus speed is increased. Errors can show up as device not detected, devices that momentarily do not exist, random data garbage, etc.

Data errors are not reported as there is no error detection on the I2C bus apart from the error returned when attempts are made to read non-existent devices.

I2c is easy provided you follow a few simple rules. It is actually easier to program a mcp23017 than it is to program the GPIO pins.

[jam1]

Hi,

With the B+ with Raspbian, I also have a problem getting /dev/i2c-0 to appear in the dev list.

I have /dev/i2c-1 only. The gpio readall command shows 2 locations for SDA/SCL pairs , on pins 27-28 and on pins 3-5.

Code: Select all

+-----+-----+---------+------+---+--B Plus--+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5V      |     |     |
 |   3 |   9 |   SCL.1 | ALT0 | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 0 |  7 || 8  | 1 | ALT0 | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | ALT0 | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |   IN | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |   IN | 1 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI |   IN | 0 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO |   IN | 0 | 21 || 22 | 0 | IN   | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK |   IN | 0 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |
 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
 |   5 |  21 | GPIO.21 |   IN | 1 | 29 || 30 |   |      | 0v      |     |     |
 |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |
 |  13 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v      |     |     |
 |  19 |  24 | GPIO.24 |   IN | 0 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |
 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | IN   | GPIO.28 | 28  | 20  |
 |     |     |      0v |      |   | 39 || 40 | 0 | IN   | GPIO.29 | 29  | 21  |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+--B Plus--+---+------+---------+-----+-----+

I ran the program pi-modes with a few modifications to get pin 3 and 5 settings but still no /dev/i2c-0

In the program pi-modes.c, is it the pin number or the GPIO number that is required? It seems that it is the pin number in my test by looking at the readall output.

Is there something else specific to do to get /dev/i2c-0 and /dev/i2c-1 on the B+ ?
Thanks