<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?
<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]