jabss
Posts: 65
Joined: Thu May 09, 2013 11:47 am

Sharing my use of I2C GPIOs

Mon May 05, 2014 6:24 pm

Hi,

Not sure how right I might be, but I suspect I’m one of the minority that uses I2C as GPIO with the gpio_pcf857x driver. At least that is my impression whenever I do a search for “I2C GPIO” in the forum.
Anyway, before telling me to use another method, allow me to share with you my use of it. This way, everyone can choose the method that is easier for their requirements. The only catch in this method is that you might need to load the gpio_pcf857x kernel module.

For instance, let’s assume you have a PCF8574 that you intend to use as GPIO expander. Let’s also assume you have properly wired it and connected it to the RPI I2C bus (directly or via a I2C level shifter – it’s up to you), and its I2C address is 0x39. You can initialize it simply by:

Code: Select all

echo pcf8574 0x39 > /sys/bus/i2c/devices/i2c-1/new_device
echo 248 > /sys/class/gpio/export
echo 249 > /sys/class/gpio/export
echo 250 > /sys/class/gpio/export
echo 251 > /sys/class/gpio/export
echo 252 > /sys/class/gpio/export
echo 253 > /sys/class/gpio/export
echo 254 > /sys/class/gpio/export
echo 255 > /sys/class/gpio/export
The first command initialize the PCF8574 chip and the remaining ones initialize each pin. From this point onwards, the Operating System treats each of the PCF8574 pins as they were internal GPIO’s. Cool huh? BTW, this commands only need to be issued once every boot, so a good practice would be to include it in a boot script like /etc/rc.local.

Now, what to do with it? Well, if you go to the /sys/class/gpio/gpio248 directory you’ll see some files, namely “direction”, “value” and “active_low”. As the name implies, If you want to define the direction of that pin, you can use this file by issuing:
echo in > /sys/class/gpio/gpio248/direction
or
echo out > /sys/class/gpio/gpio248/direction
If you have defined it as input, and you want to know what state it is it you can do it by reading the contents of the “value” file. To do it, just issue:
cat /sys/class/gpio/gpio248/value
(the result will either be 0 or 1, corresponding to 0 or 3.3/5V – Positive logic). In the other hand, if you have defined it as output, you might want to change its value and for that you can issue:
Echo 1 > / sys/class/gpio/gpio248/value
or
Echo 0 > /sys/class/gpio/gpio248/value
If you want to change to negative logic (where the logical level 1 corresponds to 0 Volts) you can also configure it in the “active_low” file by issuing:
echo 1 > /sys/class/gpio/gpio250/active_low
(the default is 0, which corresponds to positive logic).

I’m not a programing guy, and truly prefer shell scripting. Using this method, I’m able to read/edit each pin individually with "normal" command line commands such as "echo" and "cat".

A typical bash function I’m using to test the presence in a room (I have a PIR sensor connected to a PCF8574 pin, defined as input) would be, for instance:

Code: Select all

start()
{
 presence=`cat /sys/class/gpio/gpio248/value`
 while [ "$presence" != "1" ]
 do
  sleep 3
  presence=`cat /sys/class/gpio/gpio248/value`
 done
 action
}
Can't get easier that this!
So, how many more people have tried to use it this way?

Hope this helps in any way!

Good luck!
Jabss

User avatar
joan
Posts: 14015
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Sharing my use of I2C GPIOs

Mon May 05, 2014 7:03 pm

That's an interesting way of using the I2C device. I was vaguely aware that you could load modules for some I2C chips but have never done so myself.

You are programming, it's just that your language of choice is a shell script.

User avatar
Richard-TX
Posts: 1549
Joined: Tue May 28, 2013 3:24 pm
Location: North Texas

Re: Sharing my use of I2C GPIOs

Mon May 05, 2014 7:35 pm

I think that someone should write modules for things like the MPC23017, MCP23S17, PCF8591,PCA9544. It might help the beginner with modest I2C based projects.
Richard
Doing Unix since 1985.
The 9-25-2013 image of Wheezy can be found at:
http://downloads.raspberrypi.org/raspbian/images/raspbian-2013-09-27/2013-09-25-wheezy-raspbian.zip

User avatar
Richard-TX
Posts: 1549
Joined: Tue May 28, 2013 3:24 pm
Location: North Texas

Re: Sharing my use of I2C GPIOs

Mon May 05, 2014 7:47 pm

The only thing missing in your document is telling how to load the module(s), a listing of all the modules available and what chips each module is for.
Richard
Doing Unix since 1985.
The 9-25-2013 image of Wheezy can be found at:
http://downloads.raspberrypi.org/raspbian/images/raspbian-2013-09-27/2013-09-25-wheezy-raspbian.zip

sparaflesh
Posts: 5
Joined: Sun May 04, 2014 4:09 pm

Re: Sharing my use of I2C GPIOs

Mon May 05, 2014 8:04 pm

Richard-TX wrote:The only thing missing in your document is telling how to load the module(s), a listing of all the modules available and what chips each module is for.
+1! I'm interested in too.

User avatar
Richard-TX
Posts: 1549
Joined: Tue May 28, 2013 3:24 pm
Location: North Texas

Re: Sharing my use of I2C GPIOs

Mon May 05, 2014 8:29 pm

+1! I'm interested in too.
Here is some data to peruse.

http://git.kernel.org/cgit/linux/kernel ... 138652e60c
Richard
Doing Unix since 1985.
The 9-25-2013 image of Wheezy can be found at:
http://downloads.raspberrypi.org/raspbian/images/raspbian-2013-09-27/2013-09-25-wheezy-raspbian.zip

jabss
Posts: 65
Joined: Thu May 09, 2013 11:47 am

Re: Sharing my use of I2C GPIOs

Mon May 05, 2014 11:40 pm

Hi,

Running the risk of going slightly off-topic, I've prepared a mini-procedure that explains how to include the needed modules in the kernel. This requires the re-compilation of the kernel, but don't get scared, its easy.

I admit at the very beginning I got scared with the "kernel compilation" stuff as I'm not even close to really understand how does it work, but I've found very good pieces of information online and I've came up with a lazy guide that helps me through every time I need to to it. It is based on this procedure (http://sysprogs.com/VisualKernel/tutori ... ildkernel/) and I guess that if you follow these steps it would be simple.


Let's assume you have another "normal" PC with some linux distro. The following commands have worked with ubuntu. Compiling the kernel in other PC with a different architecture is called cross-compiling.


# create a directory where the compiling is going to happen. Ensure you have some available gigabytes. Go to that directory
mkdir RPI4
cd RPI4


These commands are needed in order to be able to download the code and the compilers. It will download the latest version of the repository.
git init
git clone --depth 1 git://github.com/raspberrypi/linux.git
git clone https://github.com/raspberrypi/tools
Create an alias to the compiler (beware, my path is /mnt/storage/RPI4... so you'll have to adapt the command according to yours)
export CCPREFIX=/mnt/storage/RPI4/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-

Go to your working raspberry pi and copy the /proc/config.gz file to the RPI4/linux directory in your PC that was just created by the above git commands. Apparently this file is the kernel compilation configuration file used in your running system and can be used as a "skeleton" for your compilation.
Uncompress the file and name it .config
gunzip -c config.gz > .config
Do some stuff (Sorry, I don't really understand why should we do this, but it seems to be important)
ARCH=arm CROSS_COMPILE=${CCPREFIX} make oldconfig
grep -v DEBUG_INFO < .config > newconfig
mv newconfig .config
ARCH=arm CROSS_COMPILE=${CCPREFIX} make oldconfig
Now, using the menuconfig option in the make you'll have access to a text-based menu system where you can select which drivers/modules should be included in your compilation.
Selecting an option with (*) makes it loading automatically when the system boots, selecting (M) makes it available as long as you load the module and not selecting it, it will not be available.

When exiting, the .config file will be updated with your selections. Right now I don't have the list of options I usually select but have the .config file of my last compilation
http://pastebin.com/F1W3TSnv (for kernel 3.12.18+).

This configuration file includes the modules for:
- BMP085 I2C pressure sensor
- PCF857x GPIO Expanders
- PCF8581 DAC/ADC
- LM75 I2C temperature sensor
- DS1307 I2C Real Time Clock

(by the way, I've also included some stuff for W-1 protocol, such as the 1-wire DS18B20 digital temperature sensor)
Other stuff like PCA954x expanders can also be added. Just do a find for "i2c" in the configuration file to see the huge amount of I2C devices that can be used.

ARCH=arm CROSS_COMPILE=${CCPREFIX} make menuconfig
After that, everything should be ready for the cross-compilation. It can take a few hours.
ARCH=arm CROSS_COMPILE=${CCPREFIX} make
Compilie also the modules
ARCH=arm CROSS_COMPILE=${CCPREFIX} INSTALL_MOD_PATH=../modules make modules_install
The result of the compilation is the kernel image file and a directory with all the modules compiled. Now we have to pass it to the raspberry PI. Since the modules are within a directory, its better to compress it in a tgz file for an easier transfer.
cd ..
cd tools/
cd mkimage/
./imagetool-uncompressed.py ../../linux/arch/arm/boot/zImage
scp kernel.img [email protected]:/home/pi/
cd ..
cd ..
cd modules/
tar czf modules.tgz *
scp modules.tgz [email protected]:/home/pi/
In the RPI, you just need to place the files in the correct places, but first, backup your current kernel image:
sudo cp /boot/kernel.img /boot/kernel.orig
sudo cp kernel.img /boot/kernel.img
(assuming you are currently in directory where you have copied your compiled stuff - /home/pi in my example)
cd /
sudo tar xzf /home/pi/modules.tgz
Verify that the modules have been deflated to the right directory. In /lib/modules you should have at least two directories with the kernel release name (the original and the new one - something like 3.12.18+).

Make sure your /etc/modules file includes the following modules to be loaded:

snd-bcm2835
i2c-bcm2708
i2c-dev
gpio-pcf857x


and reboot the system. When up, it should be running with the new kernel release and you should be able to perform the tasks I described in the first post.


As always, your milenage my vary, but if you follow carefully the steps and get further information in http://sysprogs.com/VisualKernel/tutori ... ildkernel/, it should be easy to go through it.

Hope this helps.

Cheers,
Jabss

suicidal_orange
Posts: 217
Joined: Sun Mar 16, 2014 10:56 am

Re: Sharing my use of I2C GPIOs

Sat May 10, 2014 7:34 am

Great! A cross compile guide that's not distro specific, I'll be giving this a go.

One question though
jabss wrote:From this point onwards, the Operating System treats each of the PCF8574 pins as they were internal GPIO’s. Cool huh?
The internal GPIOs have "built in interrupts" (not sure the proper language) while the PCF8574 has an interrupt pin which can be used to trigger a read - does the kernel module really implement them as if they are internal (with interrupts)? That would make this very cool.

If I knew what it was called I could try searching, but I don't :|

User avatar
joan
Posts: 14015
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Sharing my use of I2C GPIOs

Sat May 10, 2014 7:43 am

suicidal_orange wrote:Great! A cross compile guide that's not distro specific, I'll be giving this a go.

One question though
jabss wrote:From this point onwards, the Operating System treats each of the PCF8574 pins as they were internal GPIO’s. Cool huh?
The internal GPIOs have "built in interrupts" (not sure the proper language) while the PCF8574 has an interrupt pin which can be used to trigger a read - does the kernel module really implement them as if they are internal (with interrupts)? That would make this very cool.

If I knew what it was called I could try searching, but I don't :|
I'd say this approach is more of an interesting curio than anything else. Faffing about building kernels just to get kernel support for an I2C chip is (in my opinion) not worth the effort. Just use the perfectly good drivers already available to read/write /dev/i2c-x.

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Sharing my use of I2C GPIOs

Sat May 10, 2014 7:48 am

This looks really really useful :)

If this was included in default image then it looks like it could save an awful lot of wheel re-inventing and head scratching to include standard i2c chips into projects :)

Simon
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

suicidal_orange
Posts: 217
Joined: Sun Mar 16, 2014 10:56 am

Re: Sharing my use of I2C GPIOs

Sat May 10, 2014 8:23 am

joan wrote:I'd say this approach is more of an interesting curio than anything else. Faffing about building kernels just to get kernel support for an I2C chip is (in my opinion) not worth the effort. Just use the perfectly good drivers already available to read/write /dev/i2c-x.
If you're looking at it from the perspective of an individual with a chip and a Pi I agree - you'd may as well use userland code.

If you're using some normal onboard GPIOs and some over I2C in the same script though you have to remember to read/write them correctly, using this method they are all the same.

Also with each expander having it's own address it makes it hard to write transferable code while using this method you could assign the same "onboard" pin numbers to different chips which is nice.

It has it's uses, though without interrupts the first benefit above actually becomes a weakness - you can easier forget that that pin has no interrupt, hence my question...

jabss
Posts: 65
Joined: Thu May 09, 2013 11:47 am

Re: Sharing my use of I2C GPIOs

Mon May 12, 2014 1:48 pm

suicidal_orange wrote:Great! A cross compile guide that's not distro specific, I'll be giving this a go.

One question though
jabss wrote:From this point onwards, the Operating System treats each of the PCF8574 pins as they were internal GPIO’s. Cool huh?
The internal GPIOs have "built in interrupts" (not sure the proper language) while the PCF8574 has an interrupt pin which can be used to trigger a read - does the kernel module really implement them as if they are internal (with interrupts)? That would make this very cool.

If I knew what it was called I could try searching, but I don't :|
Not sure if we are using the same terms, but when I say "Internal GPIO's" I mean the same type of GPIO's as the GPIO bus of the raspberry PI and I believe those do not have interrupt support (I might be wrong). That is also unfortunately the case of the GPIO's for the PFC8574's.

However, if you can afford to use an additional GPIO from the RPI (and if the PCF8574 is "relatively" close to your RPI) you can try to connect the /INT (interrupt) PIN to it and pool it instead of pooling each and every PCF8574 pins. I never tried, because in my case, most of the PCF's are really far away from the RPI (different rooms - I have an I2C bus over all of my house), but I think it might work.

Hope this helps,
Jabss

jabss
Posts: 65
Joined: Thu May 09, 2013 11:47 am

Re: Sharing my use of I2C GPIOs

Mon May 12, 2014 1:56 pm

joan wrote: I'd say this approach is more of an interesting curio than anything else. Faffing about building kernels just to get kernel support for an I2C chip is (in my opinion) not worth the effort. Just use the perfectly good drivers already available to read/write /dev/i2c-x.
How can you use the good drivers already available for I2C?
Could you set it individually and define positive/negative logic from the command line? How?

Thanks,
Jabss

suicidal_orange
Posts: 217
Joined: Sun Mar 16, 2014 10:56 am

Re: Sharing my use of I2C GPIOs

Mon May 12, 2014 5:44 pm

jabss wrote:Not sure if we are using the same terms, but when I say "Internal GPIO's" I mean the same type of GPIO's as the GPIO bus of the raspberry PI and I believe those do not have interrupt support (I might be wrong). That is also unfortunately the case of the GPIO's for the PFC8574's.
Yes that's what I meant too :)

The onboard ones do have interrupts, see this series of articles for details
However, if you can afford to use an additional GPIO from the RPI (and if the PCF8574 is "relatively" close to your RPI) you can try to connect the /INT (interrupt) PIN to it and pool it instead of pooling each and every PCF8574 pins. I never tried, because in my case, most of the PCF's are really far away from the RPI (different rooms - I have an I2C bus over all of my house), but I think it might work.

Hope this helps,
Jabss
Guess I will still have to do this module or not then - the PCF8574 will be inside a small case with a Pi with two GPIOs available, so it should work :lol:

Your house sounds like fun!

suicidal_orange
Posts: 217
Joined: Sun Mar 16, 2014 10:56 am

Re: Sharing my use of I2C GPIOs

Thu May 15, 2014 12:40 am

So I've compiled a kernel and have the module loaded but am stuck on the next step:

Code: Select all

[email protected] ~/scripts $ sudo echo pcf8574 0x20 > /sys/bus/i2c/devices/i2c-1/new_device
-bash: /sys/bus/i2c/devices/i2c-1/new_device: Permission denied
I don't think it's going to work anyway as the address keeps changing anywhere between 20 and 27, sometimes appearing as up to three addresses at once - is there anything wrong with my setup? (apart from it being my first attempt at wiring up a chip on a breadboard :lol:)

EDIT: It was me. I assumed that as illustrated in both the tutorials I read the address pins could be left floating, but they cannot for me - grounded them all and now the address is always 20 :)

The permission problem persists...

jabss
Posts: 65
Joined: Thu May 09, 2013 11:47 am

Re: Sharing my use of I2C GPIOs

Fri May 16, 2014 5:37 pm

Hi,

You have three options:

a) You do it as root

Code: Select all

sudo su - 
(and then echo pcf8574 0x20 > /sys/bus/i2c/devices/i2c-1/new_device)
b) Put that command in /etc/rc.local so it will be ran as root during boot. Check above the links to my /etc/rc.local files

c) Add pi user to the gpio group (/etc/group)
example:

Code: Select all

[email protected] ~/HIDAPI/usbrelay $ cat /etc/group | grep pi
root:x:0:www-data,pi
adm:x:4:pi
dialout:x:20:pi
cdrom:x:24:pi
sudo:x:27:pi
audio:x:29:pi
video:x:44:pi,motion
plugdev:x:46:pi
games:x:60:pi
users:x:100:pi
pi:x:1000:
netdev:x:105:pi
input:x:999:pi
spi:x:1002:pi
gpio:x:1003:pi,www-data
i2c:x:111:pi,www-data
Indeeed strangely the sudo command doesn't seem to work in this.

Hope this helps,
Jabss

suicidal_orange
Posts: 217
Joined: Sun Mar 16, 2014 10:56 am

Re: Sharing my use of I2C GPIOs

Fri May 16, 2014 7:26 pm

Thanks Jabss, It works after a "sudo su" so now I can have a play :D

I did add pi to the gpio group and rebooted when testing earlier but that didn't help, I notice that on yours pi is also in the i2c group so I just added that but still no joy. Very strange, much like sudo not working for this command...

Edit: This gets me all the way to the next line:

Code: Select all

 [email protected]:/home/pi# echo 248 > /sys/class/gpio/export
bash: echo: write error: Invalid argument
:(

Edit 2: Found the other thread discussing this in new kernels. Kernel patched to allow more GPIOs and currently building on the Pi - hopefully it remembers that 99% of it is already done!

suicidal_orange
Posts: 217
Joined: Sun Mar 16, 2014 10:56 am

Re: Sharing my use of I2C GPIOs

Sat May 17, 2014 8:40 am

It didn't remember it was compiled so I left it overnight and now it's done and nearly works - everything after initialising the chip runs as pi (in gpio and i2c groups)

The only problem is I can't set an output to 1?

Code: Select all

[email protected] ~ $ echo out > /sys/class/gpio/gpio248/direction
[email protected] ~ $ echo 1 > /sys/class/gpio/gpio248/value
[email protected] ~ $ cat /sys/class/gpio/gpio248/value
0
And if I did, how do I know which gpio is which pin? I assume the lowest number (248) is P0, but it won't go high so I can see. So close and yet so far :lol:

jabss
Posts: 65
Joined: Thu May 09, 2013 11:47 am

Re: Sharing my use of I2C GPIOs

Sun May 18, 2014 11:17 am

You are almost there...

Not sure why it should't be working, I would try to firstly do all the commands as root, and double check if the port is really set as output by issuing "cat /sys/class/gpio/gpio248/direction"

After you do the initialization, does the corresponding chip appears as "UU" when you do "i2cdetect -y 1"?

If you want I can share my kernel file and compiled modules. Have you compiled the your kernel with the same options as stated above? (you can re-use the .config file).

Cheers,
Jabss

suicidal_orange
Posts: 217
Joined: Sun Mar 16, 2014 10:56 am

Re: Sharing my use of I2C GPIOs

Sun May 18, 2014 11:54 am

Hmm kernel config... I must confess that I made my own by stripping features out of one someone made for the Wolfson audio card (I plan is to get this working alongside the Wolfson as it eats nearly all your GPIOs!)

It's so close it's hard to believe it's the kernel but what else could it be? I'll give it a go later as it's still not working even as root. I was even omiting the p from the model name which got me hopeful this morning, but no...

Code: Select all

[email protected]:/home/pi# echo pcf8574p 0x20 > /sys/bus/i2c/devices/i2c-1/new_device
[email protected]:/home/pi# echo 248 > /sys/class/gpio/export
[email protected]:/home/pi# echo out > /sys/class/gpio/gpio248/direction 
[email protected]:/home/pi# cat !$
cat /sys/class/gpio/gpio248/direction
out
[email protected]:/home/pi# echo 1 > /sys/class/gpio/gpio248/value 
[email protected]:/home/pi# cat !$
cat /sys/class/gpio/gpio248/value
0
Edit: just tried it with a different address (just incase) and reading values from the all the GPIOs set as inputs and they all return 0. The switch works in python-smbus so it must be the kernel, realtime shouldn't be an issue I would hope? I could be the first person to try the combination so I don't expect an answer to that, I'll have to test it.

jabss
Posts: 65
Joined: Thu May 09, 2013 11:47 am

Re: Sharing my use of I2C GPIOs

Sun May 18, 2014 4:06 pm

Hi again,

Not sure if it will have any effect, but maybe you can just issue "echo pcf8574 0x20 > /sys/bus/i2c/devices/i2c-1/new_device" (wihtout the "P").

Check dmesg right after you do it: dmesg | tail -10 You should see something like (your numbers will vary):

Code: Select all

[   52.378980] pcf857x 1-003b: probed
[   52.379031] i2c i2c-1: new_device: Instantiated device pcf8574 at 0x3b
[   52.403907] pcf857x 1-003d: no platform data
[   52.405970] gpiochip_find_base: found new base at 224
[   52.406182] gpiochip_add: registered GPIOs 224 to 231 on device: pcf8574
Good luck!
Jabss

suicidal_orange
Posts: 217
Joined: Sun Mar 16, 2014 10:56 am

Re: Sharing my use of I2C GPIOs

Sun May 18, 2014 5:07 pm

I had no p yesterday, it doesn't help.

I've now connected the Wolfson and the PCF8574 at the same time and the module is not happy it seems

Code: Select all

[email protected]:/home/pi# dmesg | tail -10
[   33.435438] wlan0: authenticated
[   33.437409] rt2800usb 1-1.1:1.0 wlan0: disabling HT/VHT due to WEP/TKIP use
[   33.443239] wlan0: associate with cc:33:bb:0f:c8:72 (try 1/3)
[   33.446282] wlan0: RX AssocResp from cc:33:bb:0f:c8:72 (capab=0x411 status=0 aid=4)
[   33.468579] wlan0: associated
[   37.155615] Adding 102396k swap on /var/swap.  Priority:-1 extents:1 across:102396k SSFS
[   66.006353] i2c i2c-1: new_device: Instantiated device pcf8574 at 0x20
[   66.185030] gpiochip_find_base: cannot find free range
[   66.185072] gpiochip_add: gpios -1..6 (pcf8574) failed to register
[   66.185110] pcf857x: probe of 1-0020 failed with error -28
Yet it still does the same (no settable value)

Thanks for trying, I hope someone else is successful in following your guide (they should be, I'm sure it's just the damn Wolfson!)

jabss
Posts: 65
Joined: Thu May 09, 2013 11:47 am

Re: Sharing my use of I2C GPIOs

Sun May 18, 2014 8:06 pm

Code: Select all

[66.185030] gpiochip_find_base: cannot find free range
I'm no expert but I think it might be the same it happened to me before.
Check out the 3rd post in http://www.raspberrypi.org/forums/viewt ... 3&p=549568

What kernel version are you using? If you are compiling your own kernel and need your specific .config file, and don't want to mess too much around, maybe you could just add the I2C/GPIO modules in your .config file.

And how can you know which modules to add? Try these:

Code: Select all

[email protected] ~/snapshots $ zcat /proc/config.gz | grep -i gpio | grep =y
CONFIG_NEED_MACH_GPIO_H=y
CONFIG_BCM2708_GPIO=y
CONFIG_I2C_MUX_GPIO=y
CONFIG_I2C_GPIO=y
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_PCF857X=y
CONFIG_W1_MASTER_GPIO=y
CONFIG_LEDS_TRIGGER_GPIO=y

[email protected] ~/snapshots $ zcat /proc/config.gz | grep -i i2c | grep =y
CONFIG_REGMAP_I2C=y
CONFIG_BMP085_I2C=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_GPIO=y
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_BCM2708=y
CONFIG_I2C_GPIO=y



Cheers,
Jabss

suicidal_orange
Posts: 217
Joined: Sun Mar 16, 2014 10:56 am

Re: Sharing my use of I2C GPIOs

Sun May 18, 2014 8:27 pm

Thanks, that's the thread I stole the "extra gpio" patch from :D

Seems you have had the problem before so maybe I should persevere, will be interesting to see how many modules I guessed correctly...

Edit: not many :D Time for a recompile!

Edit 2: New kernel hangs when setting direction, tail | dmesg in another ssh session shows nothing

jabss
Posts: 65
Joined: Thu May 09, 2013 11:47 am

Re: Sharing my use of I2C GPIOs

Sun May 18, 2014 10:45 pm

I think I also had that problem in older kernel versions?
What kernel are you using currently?

Cheers,
Jabss

Return to “Interfacing (DSI, CSI, I2C, etc.)”