Tiny Core Base > Raspberry Pi
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:
--- Quote from: centralware on June 21, 2018, 01:08:53 AM ---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?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version