set_ has quit [Remote host closed the connection]
Shadyman has joined #beagle
set_ has joined #beagle
<set_> Aw!
<set_> I think, I think, I think I can.
<set_> So, there is something up w/ the udev rules for /dev/bone/i2c/2.
<set_> It non-there.
<set_> Yep.
<set_> Anyway, I will try some fancy dabbling.
<set_> Something is odd now. The schematic states, i2c2 is used but i2c0 is listed at p9.19/20, right?
<set_> Off to check.
<set_> Okay. choky chalking here. Um, the address is 0x54 but on my system, the BBB, it states 0x34.
<set_> It is open but config pin does not have control over it, udev rules do not work, and changing ownership to a new user is out.
<set_> Anyway, if you are around, @zmatt, please review this short: https://pastebin.com/dbHWz2m4
<set_> Is there a work around?
<set_> GPIO?
<zmatt> ????
<zmatt> what on earth are you talking about?
<zmatt> p9.19/20 is i2c2
<set_> The i2c call for 16 bit addressing via smbus does not allow 16-bit addressing from the kernel source.
<set_> Oh!
<set_> I know...I can add the two u8 structs?
<zmatt> 16-bit addressing? what do you mean by that, and why do you think you need it?
<set_> oh. I thought this chip handles 16-bit addressing.
<zmatt> why are you even trying to do anything in C?
<set_> I am not.
<zmatt> then why did you copy/paste a snippet of a C header?
<set_> Proof.
<zmatt> ??
<set_> Ha.
<zmatt> proof that you're confused? yeah
<set_> Yes, of course.
<set_> So, the issue is that this chip, the PCA9685, does addressing a bit differently compared to what smbus2 allows b/c of the kernel source.
<set_> Right?
<zmatt> ???????
<zmatt> no
<set_> Oh.
<zmatt> it uses i2c in the most normal, mundane way possible
<set_> I was reading the errors/issues in the smbus2 repo. It seems that is what this fellow is saying.
<set_> Oh.
<set_> So, nothing out of the ordinary?
<set_> Okay.
<zmatt> and you have code for it already, which I wrote for you :P
<set_> Then, why am I not in control of my i2c addresses at 0x34 or 0x54?
<set_> Or...do I need to use an offset?
<zmatt> I have no idea what you mean by that
<set_> Well, from the BBB standpoint, it is open.
<zmatt> ?
<set_> i2c-2 is open and I cannot change that option.
<zmatt> ?
<set_> What is it that I am saying that makes this so difficult?
<zmatt> I have no idea what the words you're typing could possibly even mean
<set_> Fine.
<set_> I will retreat.
<zmatt> like, all I can gather from what you're saying is that something is not working for you
<set_> Right
<set_> So far, your source does not work (no matter how I change and alter it).
<set_> I tried w/ what i2cdetect detects and what the datasheet states is the address of the Cape.
starblue has quit [Read error: Connection reset by peer]
<zmatt> no changes should be needed, you're probably just breaking things
<set_> Fine. Okay. No issue.
<set_> If something is done outside of...forget it. You are right. This should be an easy out for me.
<zmatt> if it's a cape with this thing there might be a kernel driver active for the device though, which means you can control the leds via a pwm interface or a led interface probably
<zmatt> or if you want to control it directly using i2c, disable the cape overlay
<zmatt> this is just a guess though
<set_> Okay. I will look into it.
<set_> I tried the older way of adding the uboot overlay.
<zmatt> I'm still trying to guess what you could possibly mean by the things you've saide
<zmatt> *said
<zmatt> I don't know what you mean by that but it's probably bad
<set_> I added the BeagleBoard-DeviceTrees uboot-overlays for the BBORG_SERVO-00A2.dtbo.
<set_> It broke the board in specific ways, e.g. cannot reboot into the working system.
<set_> Is there a way uboot controls this Cape functionality?
<set_> Is so, I will go that route and test it.
<set_> I will go and check.
starblue has joined #beagle
<set_> NULL?
<set_> Anyway, no issue.
<set_> Try, try, and try again is all I can do!
thinkfat_ has quit [Ping timeout: 248 seconds]
thinkfat has joined #beagle
<set_> it is too bad that uboot and github have not figured out how to allow hyperlinks in .dts files and .dtsi files.
<set_> For instance, I look up am335x-boneblack.dts but the preprocessor directives are unclickable.
<set_> I need like three screens. Blah.
vagrantc has quit [Quit: leaving]
<set_> Does the ServoCape not have the inputs already placed and seated?
<set_> I mean, are the input pins already soldered on?
balrog has quit [Ping timeout: 260 seconds]
balrog has joined #beagle
otisolsen70 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
Shadyman has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 260 seconds]
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
starblue has joined #beagle
vagrantc has joined #beagle
starblue has quit [Ping timeout: 260 seconds]
vagrantc has quit [Ping timeout: 246 seconds]
vagrantc has joined #beagle
brook has joined #beagle
brook has quit [Remote host closed the connection]
starblue has joined #beagle
lucascastro has joined #beagle
lucascastro has quit [Quit: Leaving]
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #beagle
xet7 has quit [Remote host closed the connection]
buzzmarshall has joined #beagle
demirok has joined #beagle
xet7 has joined #beagle
demirok has quit [Read error: Connection timed out]
otisolsen70 has quit [Quit: Leaving]
Shadyman has joined #beagle
Shadyman has quit [Remote host closed the connection]
lucascastro has joined #beagle
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
xet7 has quit [Remote host closed the connection]
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle