RasPi GPIO

[CentralWare]

Good day everyone!

RAS-PI2B in question right now; I know Pi3 had I2C0 issues but haven't known Pi2 to have the same beyond HAT EEPROM conflicts:

I threw together a quick script due to anomalies found when booting up which left me with one last issue I cannot seem to find reason for.
The first "issue" was, when trying to initialize (BCM) GPIO's 21, 20, 16 and 12, twelve failed with a permission denied error...  while root...  thus leading me to say things (somewhat grumbled) asking "So what's so special about GPIO 12 (pin 32) that 'nix tells me NO??"  Come to find out that for SOME reason, GPIO 9, 10 and 12 are already exported (for an unknown reason) at boot time and must be UNexported in order to gain control over the pin.  Pins 16 and 18 (GPIO 23-24) however are seemingly being held captive by I2C-0 though I don't know how those pins are related???

If I disable the dtoverlay=i2c-gpio I can do what I do with GPIO 9, 10 and 12 and gain control over them.
With I2C enabled, these two IO pins are reserved/locked.  Any ideas as to why that might be?

[bmarkus]

If I disable the dtoverlay=i2c-gpio I can do what I do with GPIO 9, 10 and 12 and gain control over them.
With I2C enabled, these two IO pins are reserved/locked.  Any ideas as to why that might be?

Isn't GPIO 9, 10 the SPI port?

[CentralWare]

@bmarkus: GPIO 9/10; yes they are, though I would have imagined 7, 8 and 11 would also have been exported as well if it's just SPI support...

GPIO 23/24 are the biggest challenge as they're not marked for anything on any of the pin-outs I have (ie: Pins 27/28 being reserved by I2C0 DATA/CLOCK respectively thus I get why those two would be locked) yet if I enable I2C1 support, pins 16/18 return Device or Resource Busy Permission Denied when I attempt to initialize those GPIO and I cannot see any coorelation between I2C1 and those pins.  Any thoughts?

https://pinout.xyz/pinout/pin16_gpio23

[CentralWare]

[SOLVED]

It turns out kernel updates (since TCL9?) have modified i2c support.
dtoverlay=i2c-gpio creates a new I2C bus on RasPi where by default it uses: BUS=3, DELAY=1 SCL=GPIO24 SDA=GPIO23
THUS...  why 23/24 are now locked if I2C support is enabled.

[CentralWare]

*EDIT: Turns out there's a firmware bug which we need to update TCL's GZ image.
overlays/i2c-gpio.dtbo is a little outdated.  I grabbed a copy of the newer firmware file from github and my issues were resolved.

[CentralWare]

https://github.com/raspberrypi/firmware/tree/master/boot/overlays

[CentralWare]

This is mainly for my own notes should I misplace mine, but for anyone tinkering with I2C-GPIO...

I've tested pre and post v4.14.21 of RasPi firmware releases and there are some screwy things to know about before spending hours trying to figure out why it's not working.

First, if you want to create additional "software" i2c ports similar to that found on GPIO-2/GPIO-3 when you read the docs it'll mention the new command-line argument of bus=##; thus far I have yet to find a release that actually WORKS with bus= so assume up front that the first bus number you'll be assigned is bus=3.  It's also a good idea to DISABLE i2c=on in config.txt to give you more control over the process.

Secondly, there's a flaw in the way RPi handles dyoverlay=i2c-gpio in the config file...
If you add ONE overlay instance calling it bus=3, this seemingly works fine.
Add a SECOND instance (say bus=4) and the buses will SHIFT (first one gets pushed down the list and 2nd one takes the top position) thus bus=3 as you've assigned it becomes bus 4.

To accomplish i2c instances in a somewhat stable environment, it should be done in userland (AFTER the device boots, not during.)  This is done by the following:

1. Install rpi-vc.tcz which contains the executable dtoverlay program
2. TinyCore doesn't have "direct" device-tree support compiled/enabled in the kernel by default, so you'll need to clone your own with the following mount in order to build the directory structure dtoverlay is expecting to find:

Code: [Select]

mount -t configfs none /sys/kernel/config  Doing so creates a home for i2c ports to live when you reach #4 below.
3. If it's not already, you'll need to mount mmcblk0p1 where the overlays are housed (dtoverlay was not built for Tiny thus it cannot find the overlays itself.)
4. Finally, call the binary and tell it the same you would have done in config.txt (just with spaces instead of commas)

Code: [Select]

dtoverlay -d /mnt/mmcblk0p1/overlays i2c-gpio bus=3 i2c_gpio_scl=14 i2c_gpio_sda=15* dtoverlay will leave notes about pre and post processing; disregard these.