<set_> GPIO80 on the BBBlue is what pin on what ball? I am looking in the Subartic 2.x pins under the BBBlue now.
<set_> I think I do not know how to handle P8_14 as gpioN_NN. for instance, P8_14 is gpio what? I think for instance, GPIO1_22 is 1 * 32 - 22 + 12?
<set_> Off to find out. If you have an extra bit of time, please describe it.
<set_> Okay. Phew. Got it. +12.
<set_> sorry. + the pin number.
thinkfat_ has quit [Ping timeout: 252 seconds]
thinkfat has joined #beagle
<set_> Hello...sorry for my confusion. I got it figured out.
<set_> B/C of four GPIOchips {0, 1, 2, 3}, how will I know if I am messing w/ P8 or P9 on the BBB? Further more, how will I bring it over to the BBBlue for pinmuxing and .dts files?
<set_> For instance, if I have GPIO1_15. That would be P(N)_47?
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
<set_> SiP on the BBBlue uses what am335x BGA?
<set_> I mean...is it the same as the BBB?
<set_> I am lookin' in Ref. Man. of the BBBlue and it is empty...
<set_> Would anyone w/ time and effort like to work w/ me on makin' it filled up on the Wiki?
starblue has quit [Ping timeout: 252 seconds]
<set_> BZCZ?
starblue has joined #beagle
<set_> Hello...would I set up px4.config on the PX4 cross-compiled source on the BBBlue to handle each of the uboot-overlays? Also...
GenTooMan has quit [Ping timeout: 260 seconds]
<set_> Would I need to change out the uboot-overlay .dts file to handle updated versioning in kernel 4.19.x. The .dts file only goes up to 4.14.x so far.
GenTooMan has joined #beagle
<zmatt> set_: overview of gpio numbers (and other information) for the beaglebone blue (pins on external connectors and various other signals): https://pastebin.com/hBiyzGWL
<set_> Thank you...I think I am at a loss b/c of the .dts file that came w/ what they say works.
<set_> I know it is too late now.
<set_> I will check back tomorrow.
<set_> Would I still need to set up pinmuxing or uboot-overlays in /boot/uEnv.txt to handle those specific pins if my .dts turned .dtb already signifies those entries?
<zmatt> I have no idea what you're talking about
<set_> The PX4 cross-compilation came w/ a kernel 4.14.x .dts file that did not get compiled along w/ my cross-compilation.
<set_> I was thinking I could use this file to use it as my .dtb file in /boot/uEnv.txt.
<set_> Also...if librobotcontrol says use P8_16 but I want to use P8_15 for the PRU Encoder Input, I need to change the .dts file. Right?
<set_> Anyway...okay. No issue. I will wait until tomorrow or another day. It is already 10:00.
<zmatt> set_: "use P8_15 for the PRU Encoder Input" ... that is complete nonsense
<zmatt> the "PRU Encoder Input" refers to both pins (since an encoder uses 2 signals, generally called A and B). the pru eCAP functionality, used by some applications (e.g. ardupilot's S-BUS input) is only available on the B input (pin 4 of the header, corresponding to BBB pin P8.15)
<set_> Why?
<set_> Oh!
<set_> Hmm...no wonder why it never worked on the BBBlue.
<zmatt> ??
<zmatt> I'm talking about the bbblue
<set_> Oh.
<set_> Okay. I must have misread you again.
<set_> PX4 is different than ardupilot. I switched to PX4. It is light weight and cross-compiles easier.
<set_> But, you are right. That does not change the fact that P8.15 on the BBBlue is ecap PRU B.
<zmatt> ... that's what I said (in a more coherent way)
<set_> Is it true that handling PRUs has to be done w/ sudo or w/ root permissions?
<zmatt> depends on what you mean by "handling PRUs", but generally no
<zmatt> unless the software does stupid things, which is certainly a possibility
<set_> Hmm. okay...I am receiving errors on my start up script w/ PX4 stating that PRU handling needs to be done w/ root access.
<set_> It does!
<set_> I am trying to figure it out or how to bypass it for now.
<zmatt> (doing stupid things includes switching from uio-pruss to remoteproc-pru, discovering it lacks the needed functionality, and then use /dev/mem as a workaround instead of going back to uio-pruss)
<set_> Oh.
<set_> Okay.
<set_> That is what is going on. I am currently trying to read about how offsets and resets can be turned into Hexadecimal format.
<set_> i.e. w/ the PRU portion of the .dts file.
<set_> I do not know where they grabbed these hex formatted characters yet.
<zmatt> putting hex constants in a dts file is moronic
<zmatt> generally
<zmatt> instead of using named constants
<set_> Let me show you this line...if I can find it again.
<set_> 0x038 0x36 /* P8_16,PRU0_r31_16,MODE6 */
<set_> That is the line for the P8_16 pin on the BBBlue but I need to switch it to P8_15.
<set_> See...how in the ______ did they come up w/ those specific entries in hex format for the PRU0_r31_16?
<set_> Is it a GPI in the PRU?
<set_> Anyway, in the PX4 source, once cloned, here is pwd: /home/mort/PX4-Autopilot/build/beaglebone_blue_default/librobotcontrol-prefix/src/librobotcontrol/device_tree/dtb-4.14-ti
<set_> They have a .dts file in the mix.
<zmatt> 0x36 is mode 6, input enabled, pull-up enabled. mode 6 for both P8.15 and P8.16 is pru_in (specifically inputs 15 and 14 of pru0 respectively)
<set_> Oh.
<set_> Okay. HOw did you figure that out?
<set_> prudebug?
<zmatt> hmm, their comment says input 16, my spreadsheet says input 14 ... let me double-check
<set_> Okay.
<zmatt> nah they're wrong my spreadsheet is right
<set_> Okay. B/c...nothing works.
<zmatt> anyway, "I need to switch it to P8_15" makes no sense... P8_15 probably has its own pin config line
<set_> NOt in this .dts file.
<set_> It is from 2012 and TI.com.
<set_> dated
<set_> and for the 4.14.x kernel.
<zmatt> why are you messing with this anyway? these custom dtbs are obsolete
vagrantc has quit [Quit: leaving]
<zmatt> as the README.txt in that directory says: "The overlay and device tree source files here don't actually get compiled or installed since they are part of the beagleboard image now."
<set_> Oh. Okay.
<set_> I know they have not been compiled. But, I can make them get compiled once I figure out how to handle memory mapping or another form to handle P8_15...
<set_> But, you are right.
<zmatt> and the am335x-boneblue.dts dts has a pinmux helper for P8_15
<zmatt> allowing runtime configuration using config-pin
<set_> It is outdated from years ago and...
<set_> Oh. Okay.
<zmatt> (even the one in this directory)
<set_> I will try config-pin, okay.
<zmatt> (I'm not sure why it uses hardcoded pinmux instead of a pinmux-helper for P8_16, but it doesn't affect you anyway)
<set_> Oh. So, I can use P8_15 w/out error? I ask b/c it seems nothing from their compilation process is fool proof.
<set_> Everything turns into a deadend.
<set_> I can connect to their QGroundControl source w/ the BBBlue being noticed. So, this is nice. But, everything fails when trying to run through their 'calibration' processes.
<set_> fail here, fail there. I guess no flying for me.
Shadyman has quit [Remote host closed the connection]
buzzmarshall has quit [Quit: Konversation terminated!]
akaWolf has quit [Ping timeout: 252 seconds]
thinkfat has quit [Quit: Konversation terminated!]
akaWolf has joined #beagle
giort has joined #beagle
sshrubber has quit [Ping timeout: 260 seconds]
giort has quit [Quit: giort]
Guest50 has joined #beagle
<kveremitz> rcn-ee: are you still doing stuff with imx[6,7] ?
<kveremitz> I've adopted/migrated the old #wandboard channel over here, if you'd care to join (At your leisure) :D
Guest50 has quit [Client Quit]
xet7 has quit [Quit: Leaving]
xet7 has joined #beagle
buzzmarshall has joined #beagle
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #beagle
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #beagle
starblue has quit [Ping timeout: 265 seconds]
sshrubber has joined #beagle
starblue has joined #beagle
nerdboy has quit [Ping timeout: 252 seconds]
nerdboy has joined #beagle
nerdboy has joined #beagle
nerdboy has quit [Changing host]
GenTooMan has quit [Ping timeout: 252 seconds]
otisolsen70 has joined #beagle
GenTooMan has joined #beagle
vagrantc has joined #beagle
russ has quit [Ping timeout: 260 seconds]
troth has quit [Quit: Leaving.]
russ has joined #beagle
<RossSchulman[m]> What chip do people use to add wifi or BT to a pocketbeagle? I know you could solder on a usb port and use a wifi dongle, but I'm thinking more about if you were breadboarding?
<zmatt> the pocketbeagle has very little available in terms of interfaces
<zmatt> in particular no sdio
<RossSchulman[m]> It has SPI and I2C, doesn't it?
<zmatt> it does, so maybe there are spi wifi/bt chips, dunno. i2c is too slow to be useful for such applications
<RossSchulman[m]> Pretty sure the ESP32s have SPI
russ has quit [Ping timeout: 260 seconds]
otisolsen70 has quit [Quit: Leaving]
russ has joined #beagle
sshrubber has quit [Ping timeout: 245 seconds]
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #beagle
charlie5 has quit [Quit: Leaving.]
charlie5 has joined #beagle
johanhenselmans has quit [Ping timeout: 265 seconds]
johanhenselmans has joined #beagle
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #beagle
GenTooMan has quit [Ping timeout: 260 seconds]
sshrubber has joined #beagle
sshrubber is now known as CrazyEddy