**** BEGIN LOGGING AT Tue Feb 16 03:00:33 2021 Feb 16 05:28:17 Yay! Feb 16 05:28:26 Oops. Past 10:00... Feb 16 07:22:38 hi, I've been trying to get my mac catalina to ssh into my BeagleBone Blue, found the drivers and installed them, but now the bone doesn't even show up its DHCP server, did I screw something up? Feb 16 07:23:34 the drivers were a pain to find, but I found a compatible one here: https://github.com/jwise/HoRNDIS/issues/102, seems like the common fix. Now I'm just hoping to at least see the bone Feb 16 07:41:46 Akristoffersen: you shouldn't need to install any driver Feb 16 07:42:05 Akristoffersen: if you're using the latest image on the beaglebone, it should just show up plug and play without any third-party driver Feb 16 07:44:13 zmatt ah okay. I've been using whatever is pre-installed on the beagle. I was using the driver from the https://beagleboard.org/getting-started page, just updated since that one was not updated for catalina Feb 16 07:45:36 you mean the one below "With the latest images, it should no longer be necessary to install drivers for your operating system" Feb 16 07:45:42 ? :P Feb 16 07:45:49 Yep, I dont have an sd card writer haha Feb 16 07:46:11 ah, that does make things less convenient Feb 16 07:46:48 nevertheless it would be a good idea to find one instead of using an image of unknown age and working around its problems Feb 16 07:47:28 I honestly think it might be better if beaglebones didn't ship with any image at all... you never know how long they sit on some shelf in a warehouse, by the time you get the beaglebone its system could be ancient Feb 16 07:48:00 it def gives a false sense of security Feb 16 07:48:18 i figured I'd be fine without updating but its been debugging hell Feb 16 07:48:37 yeah, and with the latest image it would (or at least should) be plug-and-play Feb 16 07:49:22 lets hope! thank you for the help! Feb 16 07:49:37 since Apple this time apparently managed to break things (somehow it no longer recognizes CDC-ECM devices when they're part of a composite device apparently, or at least that's what it seems like) but CDC-NCM still does work so the latest images use that Feb 16 07:51:08 you should also be able to just connect it via Ethernet... even a point-to-point connection between laptop and beaglebone should allow you to ssh to beaglebone.local Feb 16 07:53:23 oh never mind, the blue doesn't have ethernet Feb 16 07:53:35 I forgot you mentioned you had a Blue Feb 16 07:54:16 It should have wifi though right? Feb 16 07:54:36 I broke something somehow and now its not even showing tha Feb 16 07:54:38 *that Feb 16 07:55:07 yeah in the default config it should set up a wifi hotspot too afaik Feb 16 08:03:22 huh yeah its not doing that anymore, not sure why at all Feb 16 17:51:13 <_austin> afternoon/morning all! yesterday i was able to access my beaglebone over network no issue.  I plugged it in USB today and the driver failed to install so I was getting ready to update the image and thought I'd back up before doing so.  I cannot access the BBB now over network...any ideas? Feb 16 17:51:42 <_austin> I've double/triple checked the IP, it's showing up as pulling an IP from my router, but I can't access it via IP:3000 or beaglebone:3000 to get to cloud9 and I can't access it via putty either Feb 16 17:52:50 <_austin> Nevermind, I'm silly.  Or work is silly....after I disconnect from our work VPN I can access it. That seems very very strange. Feb 16 19:46:41 <_austin> zmatt is there an issue with the adafruit lib and Linux kernal 4.14 on the PWM?  I try to set my pwm and I get "RuntimeError: Problem with a sysfs file".  I'm trying to do:  PWM.start(ROTATE_MOTOR_PWM_PIN, 50, 0.1) and ROTATE_MOTOR_PWM_PIN is "P9_14" Feb 16 19:49:24 <_austin> Running Debain Buster IoT Image 2020-04-06 Feb 16 19:49:58 <_austin> Also correction: kernal is 4.19.94-ti-r42 Feb 16 20:07:12 I don't know anything about the adafruit libs Feb 16 20:07:33 they're kinda terrible (as you can tell by the very informative error message "Problem with a sysfs file") Feb 16 20:08:06 one thing to beware of with the ehrpwm outputs is that the two outputs of one ehrpwm instance need to use the same frequency Feb 16 20:08:17 they have independent duty cycle, but not independent frequency Feb 16 20:17:26 <_austin> interesting. ehrpwm1 and ehrpwm2 can have different frequencies tho right? Feb 16 20:17:41 yes those are separate peripherals Feb 16 20:18:16 <_austin> i'm trying to update the adafruit lib now Feb 16 20:18:16 <_austin> fingers crossed that fixes it Feb 16 20:18:20 it's just 0a that's tied to 0b, 1a to 1b, and 2a to 2b Feb 16 20:20:52 <_austin> hmmm everything seems up to date Feb 16 20:20:58 <_austin> wonder if i need to do a full reflash Feb 16 20:24:48 _austin: note that setting up a pwm is pretty trivial in pure python, since you're just writing values to the sysfs attributes of the pwm instance, which you can find by name via the symlinks in /dev/pwm/ (if you have an uptodate image, or at least an uptodate bb-customizations package): https://pastebin.com/r92QY0SC Feb 16 20:26:17 if you want to be able to change the enable-attribute with as little overhead as possible (to allow controlling it with as much precision as possible) it may help to keep it open as an unbuffered IO object Feb 16 20:28:16 <_austin> I may try that if the adafruit doesn't update right Feb 16 20:29:04 <_austin> just tried sudo apt-get update and upgrade Feb 16 20:29:20 pretty sure the adafruit lib is installed with pip3, not with apt Feb 16 20:29:27 <_austin> it is Feb 16 20:29:48 <_austin> i'm updating debian to see if there's an issue there Feb 16 20:30:00 I can't imagine anything on the debian system having relevant input Feb 16 20:30:07 <_austin> me either :shrug" Feb 16 20:30:14 in general, assume problems with adafruit libs are problems with adafruit libs, since they suck Feb 16 20:30:14 <_austin> I've had it working before.  It's just finniky Feb 16 20:30:25 <_austin> XD Feb 16 20:30:38 <_austin> Is there an easy way to not use the lib to setup inputs/outputs easier? Feb 16 20:30:47 gpios you mean? Feb 16 20:30:57 <_austin> ye Feb 16 20:31:10 <_austin> light_enable = data_uncoded[3:4] Feb 16 20:31:10 <_austin> LIGHT_ENABLE_PIN = "P8_26" Feb 16 20:31:10 <_austin> GPIO.setup(LIGHT_ENABLE_PIN, GPIO.OUT) Feb 16 20:31:13 <_austin> Like that's what I'm doing right now Feb 16 20:31:42 https://pastebin.com/MMC6u7pR save this as /etc/udev/rules.d/gpio-symlinks.rules Feb 16 20:32:01 then sudo update-initramfs -u Feb 16 20:32:05 and reboot Feb 16 20:32:11 you'll have symlinks for gpios in /dev/gpio/ Feb 16 20:32:37 <_austin> so then how would i setup an input/output? Feb 16 20:33:35 by writing their "direction" attribute.. all gpios default to "in", and you can change one to output by writing the initial output level, either "high" or "low" to it. (it supports writing "out" but that's treated as equivalent to "low") Feb 16 20:34:02 <_austin> interesting. Feb 16 20:34:21 this because it obviously needs to know the desired initial output level when changing to output (otherwise output *what* exactly?) Feb 16 20:34:26 <_austin> i might keep the I/O as is as it makes it a tad easier to read. but the pwm i might have to do another way. again, i've had it working before so i wonder what the issue is Feb 16 20:35:02 so in bash it would be echo low >/dev/gpio/P8_26/direction Feb 16 20:35:53 you can use pathlib to do this with a one-liner in python, Path("/dev/gpio/P8_26/direction").write_text("low") Feb 16 20:36:27 after initial setup you can read/write the "value" attribute (which is 0 or 1) Feb 16 20:37:38 using this, a clean pure-python gpio library would probably be a few dozen lines of code at most :P Feb 16 20:38:35 you could of course also optimize things by keeping open file descriptors for GPIO value-attributes to avoid doing open/(read or write)/close each time Feb 16 20:52:15 <_austin> i'll def look into it. right now confused why in the cloud9 editor i can't see my ~ folder tree :( Feb 16 20:52:33 <_austin> I'm trying to do it this way to help keep it clean for my other team members...it's making my job 100x harder Feb 16 20:52:45 I think cloud9 frighteningly runs as root Feb 16 20:53:04 <_austin> i think it does. but i can't see my ~/work/ directory now Feb 16 20:53:07 <_austin> after an update/upgrade Feb 16 20:54:16 ok, well I don't really know anything about cloud9, I don't have it installed personally Feb 16 20:54:29 <_austin> I need to uninstall and say "oops, dunno what happened" Feb 16 20:54:36 lol Feb 16 20:55:33 <_austin> it does make it convienent doing my dev in vscode then copy/pasting over Feb 16 20:56:04 can't vscode sync via ssh/sftp ? Feb 16 20:56:24 <_austin> :shrug: Feb 16 20:56:52 "vscode-sftp. Edit remote Linux files in VS Code directly" Feb 16 20:57:06 <_austin> may have to look at that Feb 16 20:57:20 <_austin> i still think my VPN issue earlier was funny. my boss just sighed Feb 16 20:57:22 looks like there are multiple ones Feb 16 20:57:42 I mean, VPN tends to interfere with LAN access I think Feb 16 20:58:00 not sure, don't really have experience with VPNs Feb 16 21:02:50 <_austin> adafruit did go from 1.1.1 to 1.2 Feb 16 21:02:52 <_austin> so hopefully that fixes Feb 16 21:02:56 a lot of vpn clients replace all routes by default Feb 16 21:03:37 most can be convinced to only set up routes for the specific subnets they use Feb 16 21:09:28 <_austin> now to get my root directory to show back up in cloud9 and i'll be good Feb 16 21:10:40 <_austin> got it Feb 16 21:10:41 <_austin> now to get started Feb 16 21:19:53 <_austin> zmatt got it fixed. they changed how the pwm was initialized Feb 16 21:29:18 party \o\ /o/ Feb 16 21:33:01 <_austin> #PWM.start(channel, duty, frequency, polarity) Feb 16 21:33:04 <_austin> used to be that Feb 16 21:33:15 <_austin> PWM.start("P9_14", 50) Feb 16 21:33:16 <_austin> PWM.set_duty_cycle("P9_14", 25.5) Feb 16 21:33:16 <_austin> PWM.set_frequency("P9_14", 10) Feb 16 21:33:17 <_austin> Now it's this **** ENDING LOGGING AT Wed Feb 17 02:59:56 2021