adafruit / Adafruit_Blinka

Add CircuitPython hardware API and libraries to MicroPython & CPython devices
https://learn.adafruit.com/circuitpython-on-raspberrypi-linux
MIT License
456 stars 342 forks source link

Beaglebone Black and MPC23017 PortExpander via I2C #309

Closed VirToReal closed 4 years ago

VirToReal commented 4 years ago

I'm not able to access a MPC via I2C on the Beaglebone Black with the python3 circuitpython library. Beaglebone Black has 3x I2C Ports. 2x are accessable via header. The Pins are P9_17 SCL1 / P9_18 SDA1, and P9_19 SCL2 / P9_20 SDA1.

I want to use the MCP23017 Library to expand the GPIO of the Beaglebone with 2x different I2C-Ports. My first try was to detect simply just one and failed. This is how I want to access the MCP:

import board
import busio
from adafruit_mcp230xx.mcp23017 import MCP23017

i2c = busio.I2C(board.SCL, board.SDA)
mcp = MCP23017(i2c, address = 0x20)  # MCP23017

I see the devices with i2cdetect -y -r 1 if i connect them with P9_17 / P9_18. and with i2cdetect -y -r 2 if i connect them with P9_19 / P9_20.

i2detect -lshows me all 3x ports.

i2c-1   i2c             OMAP I2C adapter                        I2C adapter
i2c-2   i2c             OMAP I2C adapter                        I2C adapter
i2c-0   i2c             OMAP I2C adapter                        I2C adapter

My guessing, the standard board.SCL and board.SDA is pointing at the I2C Port which is not accessable over the P9 header: ValueError: No I2C device at address: 20

Loading the Board-Pins I get following results:

>>> import board
>>> dir (board)
['CE0', 'CE1', 'I2C', 'LED_USR0', 'LED_USR1', 'LED_USR2', 'LED_USR3', 'MISO', 'MISO_1', 'MOSI', 'MOSI_1', 'P8_10', 'P8_11', 'P8_12', 'P8_13', 'P8_14', 'P8_15', 'P8_16', 'P8_17', 'P8_18', 'P8_19', 'P8_20', 'P8_21', 'P8_22', 'P8_23', 'P8_24', 'P8_25', 'P8_26', 'P8_27', 'P8_28', 'P8_29', 'P8_3', 'P8_30', 'P8_31', 'P8_32', 'P8_33', 'P8_34', 'P8_35', 'P8_36', 'P8_37', 'P8_38', 'P8_39', 'P8_4', 'P8_40', 'P8_41', 'P8_42', 'P8_43', 'P8_44', 'P8_45', 'P8_46', 'P8_5', 'P8_6', 'P8_7', 'P8_8', 'P8_9', 'P9_11', 'P9_12', 'P9_13', 'P9_14', 'P9_15', 'P9_16', 'P9_17', 'P9_18', 'P9_19', 'P9_20', 'P9_21', 'P9_22', 'P9_23', 'P9_24', 'P9_25', 'P9_26', 'P9_27', 'P9_28', 'P9_29', 'P9_30', 'P9_31', 'P9_41', 'P9_42', 'SCK', 'SCK_1', 'SCL', 'SCLK', 'SCLK_1', 'SDA', 'SPI', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'ap_board', 'board_id', 'detector', 'pin', 'sys']
>>> 

Using the direct pin where my MPC is connected right now, I get following error:

ValueError: No Hardware I2C on (scl,sda)=(P9_19, P9_20)
Valid I2C ports: ((1, I2C1_SCL, I2C1_SDA), (2, I2C2_SCL, I2C2_SDA))

Tried P9_17 / P9_18 as well of course. Same result. Maybe I'm simply just using the wrong addressing of the pin? I tried some but couldn't get it to work.

Please help!

ladyada commented 4 years ago

@pdp7 please take a look

pdp7 commented 4 years ago

Please run this and paste the results:

sudo /opt/scripts/tools/version.sh

This will indicate the system configuration.

Also, please paste the output of:

ls -ltar /dev/i2c*

so we can check if the i2c device names match the offset in i2cPorts

VirToReal commented 4 years ago

of course:

git:/opt/scripts/:[73593ebe3b7d3cc381eeb502d45ccb33a6ec5e78]
eeprom:[A335BNLT00C03614BBBK5925]
model:[TI_AM335x_BeagleBone_Black_RoboticsCape]
dogtag:[BeagleBoard.org Debian Image 2018-08-30]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.03-00002-gac9cce7c6a]:[location: dd MBR]
kernel:[4.14.67-ti-r73]
nodejs:[v6.17.0]
device-tree-override:[dtb=am335x-boneblack-roboticscape.dtb]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20200430.0-0~stretch+20200430]
pkg:[bb-wl18xx-firmware]:[1.20200420.1-0~stretch+20200424]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~stretch+20190327]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M]
dmesg | grep pinctrl-single
[    1.079618] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
crw-rw---- 1 root i2c 89, 1 Jun 24 08:27 /dev/i2c-1
crw-rw---- 1 root i2c 89, 0 Jun 24 08:27 /dev/i2c-0
crw-rw---- 1 root i2c 89, 2 Jun 24 08:27 /dev/i2c-2
pdp7 commented 4 years ago

I would like you to run the Python program with strace so we can determine which i2c device file it is actually opening: sudo strace -o blinka-strace-log.txt python3 <YOUR PYTHON PROGRAM> then: grep i2c blinka-strace-log.txt

Also, the 2018-08-30 image is a bit old. It has u-boot 2018.03 whereas we are now using 2019.04. This can cause problems as how @robertcnelson has configured the image to use u-boot overlays has evolved.

If possible, please try the current Debian image: "AM3358 Debian 10.3 2020-04-06 4GB SD IoT" on http://beagleboard.org/latest-images

VirToReal commented 4 years ago

Its not very easy to just upgrade to a new Debian Image. But if we can't make any further progress here I surly will update to your mentioned Image.

Here the Results for board.P9_19,board.P9_20:

stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", {st_mode=S_IFREG|0644, st_size=7402, ...}) = 0
stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", {st_mode=S_IFREG|0644, st_size=7402, ...}) = 0
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/__pycache__/i2c_device.cpython-35.pyc", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", {st_mode=S_IFREG|0644, st_size=2879, ...}) = 0
stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", {st_mode=S_IFREG|0644, st_size=2879, ...}) = 0
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/__pycache__/i2c.cpython-35.pyc", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
write(2, "    i2c = busio.I2C(board.P9_19,"..., 46) = 46
write(2, "    (scl, sda), i2cPorts\n", 25) = 25

board.P9_17 / board.P9_18:

stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", {st_mode=S_IFREG|0644, st_size=7402, ...}) = 0
stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", {st_mode=S_IFREG|0644, st_size=7402, ...}) = 0
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/__pycache__/i2c_device.cpython-35.pyc", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", {st_mode=S_IFREG|0644, st_size=2879, ...}) = 0
stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", {st_mode=S_IFREG|0644, st_size=2879, ...}) = 0
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/__pycache__/i2c.cpython-35.pyc", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
write(2, "    i2c = busio.I2C(board.P9_17,"..., 46) = 46
write(2, "    (scl, sda), i2cPorts\n", 25) = 25

board.SCL / board.SDA:

stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", {st_mode=S_IFREG|0644, st_size=7402, ...}) = 0
stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", {st_mode=S_IFREG|0644, st_size=7402, ...}) = 0
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/__pycache__/i2c_device.cpython-35.pyc", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", {st_mode=S_IFREG|0644, st_size=2879, ...}) = 0
stat64("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", {st_mode=S_IFREG|0644, st_size=2879, ...}) = 0
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/__pycache__/i2c.cpython-35.pyc", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
open("/dev/i2c-2", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 4
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
write(2, "    self.i2c.writeto(self.device"..., 47) = 47
write(2, "    return self._i2c.writeto(add"..., 57) = 57
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
write(2, "    self._i2c_bus.write_bytes(ad"..., 58) = 58
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
write(2, "    self.i2c.readfrom_into(self."..., 56) = 56
write(2, "    return self._i2c.readfrom_in"..., 63) = 63
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
write(2, "    readin = self._i2c_bus.read_"..., 60) = 60
write(2, "    mcp = MCP23017(i2c, address "..., 52) = 52
write(2, "    super().__init__(i2c, addres"..., 35) = 35
write(2, "    self._device = i2c_device.I2"..., 54) = 54
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
open("/home/hardy/.local/lib/python3.5/site-packages/adafruit_bus_device/i2c_device.py", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
pdp7 commented 4 years ago

Thanks for the results. That is interesting that is only appears to actually open an i2c devices in the third log:

board.SCL / board.SDA: open("/dev/i2c-2", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 4 I'm interested in what happens with file descritpor 4 after that.

Could you attach the full log in your reply?

VirToReal commented 4 years ago

of course, here is the log-file with "board.SCL" / "board.SDA" in busio (i2c = busio.I2C(board.SCL, board.SDA)):

blinka-strace-log2.txt

pdp7 commented 4 years ago

Thanks, this looks like it opens it but the read fails:

open("/dev/i2c-2", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 4
fstat64(4, {st_mode=S_IFCHR|0660, st_rdev=makedev(89, 2), ...}) = 0
ioctl(4, TCGETS, 0xbec74014)            = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(4, _IOC(0, 0x07, 0x03, 0x00), 0x20) = 0
write(4, "", 0)                         = -1 EINVAL (Invalid argument)
ioctl(4, _IOC(0, 0x07, 0x03, 0x00), 0x20) = 0
read(4, 0xb60c01f8, 1)                  = -1 EREMOTEIO (Remote I/O error)

Could you also please run strace on i2cdetect?

VirToReal commented 4 years ago

I did the strace on i2cdetect -y -r 2. Would be P9_19 P9_20 on the Beaglebone. With "strace" the result of i2cdetect is empty... Strange. I attached the corresponding log.

hardy@beaglebone:~/Steuerung$ i2cdetect -y -r 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
hardy@beaglebone:~/Steuerung$ strace -o blinka-strace-log3.txt i2cdetect -y -r 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --       

blinka-strace-log3.txt

Here the Log forstrace -o blinka-strace-log4.txt i2cdetect -l blinka-strace-log4.txt

pdp7 commented 4 years ago

@VirToReal sorry, I forgot to specify the "-f" switch which causes strace to follow child tasks. Could you please run again with this:

strace -f -o blinka-strace-log3.txt i2cdetect -y -r 2
VirToReal commented 4 years ago

@pdp7 sorry, I might have a hardware problem here. If i do a watch i2cdetect -y -r 2, it sometimes results in an empty table (1 of 10 times). So as he might not see Address #20 for a short moment. If I call up the command with strace it always ends up in not detecting the MPC Address #20 as an result of the call of the programm i2cdetect. I just want this to mention in case you bump into some "address not found" errors.

Here the log: blinka-strace-log3.txt

pdp7 commented 4 years ago

@pdp7 sorry, I might have a hardware problem here do you mean a wiring issue?

or just the odd behavior with strace?

I will see if I can find a MCP23017 to reproduce the error you are seeing. I believe I have one from a previous project somewhere.

VirToReal commented 4 years ago

I'm not sure. Might be a strace problem as well. Can't really tell. I'm trying to check on the MPC with a different approach. But nevertheless, even with no working address it should be able to access the bus until I get some kind of response as it is with i2c = busio.I2C(board.SCL, board.SDA). The beaglebone black has 2x different I2C Bus Terminals on the Pin-Header and an internal one. I don't know how to access the other two... I think, i2c = busio.I2C(board.SCL, board.SDA) is referring to the internal one. It's just guessing... could be one on the Header as well but I'm not able to check due to the potential wiring/hardware problem. Even so, the second one stays hidden and can't be accesses with this MPC Library.

I should get a ValueError: No I2C device at address: 20 with i2c = busio.I2C(board.P9_19, board.P9_20) or a response if my wiring is correct. Instead I receive:

ValueError: No Hardware I2C on (scl,sda)=(P9_19, P9_20)
Valid I2C ports: ((1, I2C1_SCL, I2C1_SDA), (2, I2C2_SCL, I2C2_SDA))

This is all very confusing, I hope my description help a bit. My English is not the best if a description needs to be precise... (even in German ^^)

pdp7 commented 4 years ago

Thanks for the followup. I really need to reproduce this so I can better understand what is going on. I've been in the (virtual) Embedded Linux Conference but it ends tonight, so I will try to reproduce this tomorrow.

BTW, I moved from Chicago to Berlin last year, are you in Germany as well? Unfortunately, I've not done a very job at learning Deutsch yet.

VirToReal commented 4 years ago

No problem - Take you're time. I try to determent my problem with the fluctuating recognition of the MPC and its cause.

Berlin is very nice, good choice. The prices are very cheap for a huge city like that (except the flats ;-). But still not comparable with Munich. Awesome nightlife and a lot of things to do. Im living in germany too, more landscape like in the northern region of Bavaria near "Weiden in der Oberpfalz". Welcome to Germany, I'm pretty sure you will like it here.

pdp7 commented 4 years ago

No luck finding a MCP23017 but I do have various I2C sensors with CircuitPython libraries so I will test those out with Blinka. It should help us determine if it is an issue with I2C support for the BeagleBone in the Blinka, or an issue specific to the MCP23017 library.

pdp7 commented 4 years ago

@VirToReal I spoke to soon! Conrad stocks them here in Berlin. I'm always impressed by Conrad! There is no retail store with electronic component inventory like that in America (though there are Adafruit resellers on Amazon Prime which is nice).

I'll pick one up and wire it up to the BeagleBone.

VirToReal commented 4 years ago

@pdp7 many thanks for your efforts! Conrad is quite good for fast picup things for small amounts of standard electronics. If you can spare a few days and don't want to invest much in transportation fees for still an awesome price, I found this shop here for stuff like that: http://csd-electronics.de

pdp7 commented 4 years ago

@VirToReal darn, it turns out Conrad did not actually have the 1 piece in stock that their system claimed when I ordered it. They've ordered from their warehouse and I should have it on Friday.

pdp7 commented 4 years ago

I have wired up the MCP23017 to P9.19 (I2C2_SCL) and P9.20 (I2C2_SDA) and I am able to detect it ok with i2cdetect:

debian@beaglebone:~/Adafruit_CircuitPython_MCP230xx$ sudo i2cdetect -y -r 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

Without any changes, I ran the mcp230xx_leds_and_buttons.py demo ok:

debian@beaglebone:~/Adafruit_CircuitPython_MCP230xx$ sudo python3 ./examples/mcp230xx_leds_and_buttons.py
Button # 3 pressed!
Button # 3 pressed!
Button # 3 pressed!
Button # 3 pressed!
Button # 3 pressed!
Button # 3 pressed!
Button # 1 pressed!
Button # 1 pressed!
Button # 1 pressed!
Button # 1 pressed!
Button # 1 pressed!
Button # 1 pressed!
Button # 1 pressed!
Button # 1 pressed!
Button # 1 pressed!

Here are some photos of the wiring. It is messy but I thought I would include for completeness: IMG_20200713_124208 IMG_20200713_124139

Could you post a photo of your wiring?

VirToReal commented 4 years ago

@pdp7 Thanks Drew for your efforts. It's not a mess compared to my setup ;)

IMG_20200715_124729 IMG_20200715_124746

I have a Voltage-Level-Shifter to run the MPC at 5V instead of 3.3V. Maybe this might be the problem. I gonna check that out. But good to know that the board.SCL and board.SDA is pointing to P9_19 / P9_20. Thanks alot.

But could you do me a favor and try getting the MPC running at P9_17 / P9_18. Due to the Schematics (https://vadl.github.io/images/bbb/P9Header.png) it should be the second I2C Terminal. I don't know how to adapt the code to get the second I2C Terminal running. I need both of them :(

pdp7 commented 4 years ago

@VirToReal yeah, I will give it a try on those pins and let you know the results. Also, that looks like an interesting setup!

VirToReal commented 4 years ago

[comment accidentally edited by @pdp7]

romilly commented 4 years ago

Benjamin, I'm puzzled. Each mcp23017 has 16 GPIOs, and you can have 8 of them on one I2C bus - so that's 128 GPIO pins you can control. Do you really need more than that?

On Sat, 18 Jul 2020 at 16:47, Benjamin Hirmer notifications@github.com wrote:

Alight, one of the MPC was brocken end pulled down the I2C Bus. That was the reason for the flickering recognition.

I renovated my flat and have these MPC pulling some Chinese Relais boards. These Chinese Relais boards are triggering some impulse relais from eltako which are controlling lights ( https://www.eltako.com/fileadmin/downloads/de/datenblatt/Datenblatt_ES12-200-UC.pdf). The second potential contact is giving me a 5V feedback in which state it is in on those MPCs. Also have some of those Eltaco Dimmer-Unit to regulate the light intensity. https://www.eltako.com/fileadmin/downloads/de/Gesamtkatalog/Eltako_Gesamtkatalog_Kap9_low_res.pdf. Again with those Chinese Relais boards.

The goal was to get a independent control of the lights and stuff over the pushbuttons mountet on the wall (as usual). But I wanted to control these ones with the beaglebone as well. So, if something is wrong with the beaglebone or one of the MPCs, the relais fall back in its original state and are controlled over the wall mounted buttons again.

That arduino you see above those chinese relais boards is just controlling the blinds of the windows. There is a central panel on the wall with buttons to controll it. Yet again, the beaglebone can do that too!

This is a very "easy" and durable and cheap solution for controlling something by software without depending on it running. I've done no programming so far. In the end it will be python or some kind of mix of python as terminal between hardware and OpenHAB (https://www.openhab.org).

My problem is, those MPCs have a limited amount of addresses. I've got to much of them to handle all at once on one I2C Terminal on the beaglebone. Thats the reason I need both of them ^^

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit_Blinka/issues/309#issuecomment-660501022, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABEOPUSZHH7DQ77AE44UTLR4G7X3ANCNFSM4OFB2YOA .

-- personal:@romillyc work:@rareblog skype:romilly.cocking web: http://blog.rareschool.com/

VirToReal commented 4 years ago

Benjamin, I'm puzzled. Each mcp23017 has 16 GPIOs, and you can have 8 of them on one I2C bus - so that's 128 GPIO pins you can control. Do you really need more than that?

Actually, yeah.. got 10 of them :)

romilly commented 4 years ago

Wow! Just wow.

On Sat, 18 Jul 2020 at 17:39, Benjamin Hirmer notifications@github.com wrote:

Benjamin, I'm puzzled. Each mcp23017 has 16 GPIOs, and you can have 8 of them on one I2C bus - so that's 128 GPIO pins you can control. Do you really need more than that?

Actually, yeah.. got 10 of them :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit_Blinka/issues/309#issuecomment-660508406, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABEOPSE7ANFMFNCMUZ5KJTR4HF5RANCNFSM4OFB2YOA .

-- personal:@romillyc work:@rareblog skype:romilly.cocking web: http://blog.rareschool.com/

VirToReal commented 4 years ago

Wow! Just wow.

I know I know, this project went a liddl overboard. I'm happy its built to grow in time ;)

pdp7 commented 4 years ago

@VirToReal sorry, I some how edited your comment when I intended to reply to it a couple days ago. I just noticed that I did that but I don't know how to restore you comment. Apologies for that.

I was trying to write this as a replay:

Alight, one of the MPC was brocken end pulled down the I2C Bus. That was the reason for the flickering recognition.

Is the CircuitPython library working with Blinka now for you?

VirToReal commented 4 years ago

@pdp7 no problem. Yes, it works now. One of the MPCs was broken and seemed to have pulled down the I2C Bus end interfered with the recognition. Now the address-scan works always and I'm able to setup the GPIO with Blinka and the CircuitPython library.

Additionally it would be nice if the CircuitPython Library could be used on P9_17 / P9_18 as well. Due to 10x MPCs I have in total and I'm only able to address 8x differently. Would be a nice to have because the adafruit library is pretty handy for these MPCs. But I can address those other two MPCs without the adafruit library with a different approach too. Just in case its to much effort. I guess not many people are using more than 8x MPC23017 on a beaglebone black.

pdp7 commented 4 years ago

@VirToReal here is how I was able to use P9.17/P9.18

test.py

import board
import busio
from adafruit_mcp230xx.mcp23017 import MCP23017
from adafruit_blinka.board.beagleboard.beaglebone_black import *

#i2c = busio.I2C(board.SCL, board.SDA)
#i2c = busio.I2C(pin.I2C2_SCL, pin.I2C2_SDA)
i2c = busio.I2C(pin.I2C1_SCL, pin.I2C1_SDA)
mcp = MCP23017(i2c, address = 0x20)  # MCP23017
print(mcp.get_pin(0).value)
debian@beaglebone:~$ config-pin P9_17 i2c

Current mode for P9_17 is:     i2c

debian@beaglebone:~$ config-pin P9_18 i2c

Current mode for P9_18 is:     i2c

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

debian@beaglebone:~$ sudo python3 ./test.py 
False
VirToReal commented 4 years ago

@pdp7 I dont know what to say, it works perfectly! I can't thank you enough Drew. Thanks for all your efforts. Sorry for my hardware issue, I testet with just one MPC connected, but murphys law, it was exactly the damaged one out of ten. I should have tested one more. Additionally, I'm able to use both I2C for MPC23017s on the beaglebone black now, thanks alot!