**** BEGIN LOGGING AT Thu Apr 22 02:59:57 2021
Apr 22 03:21:09 <mattb00ne> zmatt: when you get back I cannot change the votlage of P9_14 in py uio
Apr 22 03:22:06 <mattb00ne> I am changing ld_comapre_a
Apr 22 03:23:18 <mattb00ne> I assign Pwmss("/dev/uio/pwmss1") to a variable
Apr 22 03:25:25 <mattb00ne> testing with the multimeter
Apr 22 03:25:30 <zmatt> has it been properly initialized?
Apr 22 03:26:31 <mattb00ne> motor.initialize(period,1)
Apr 22 03:26:35 <mattb00ne> period = 10000
Apr 22 03:27:22 <mattb00ne> going to make a simpler test.py file to check this easier
Apr 22 03:33:10 <zmatt> mattb00ne: https://pastebin.com/KA3jFUnS  this should set both outputs to 50% I think
Apr 22 03:37:44 <mattb00ne> that works
Apr 22 03:39:18 <mattb00ne> no pwoer on issue either
Apr 22 03:39:20 <mattb00ne> weird
Apr 22 03:53:04 <Kirk10> May I ask questions about BeagleBone AI here?
Apr 22 03:53:21 <mattb00ne> NO!
Apr 22 03:53:23 <mattb00ne> yes
Apr 22 03:54:08 <Kirk10> Sorry, I'm freshman with this platform
Apr 22 03:55:52 <Kirk10> I'm updating the kernel with BBAI, and it failed to execute the command with the following message
Apr 22 03:55:52 <Kirk10> E: Unable to locate package seeed-modules-4.14.108-ti-r140
Apr 22 04:03:09 <buzzmarshall> its probably because of differences in the default pin states and the timing sequence as the bbb sets its pins as it boots
Apr 22 04:03:58 <buzzmarshall> sorry that was meant for mattb00ne from before...
Apr 22 04:04:18 <mattb00ne> but why does it stay on
Apr 22 04:04:54 <mattb00ne> like if I do not unplug the motor doesn't stop
Apr 22 04:05:01 <mattb00ne> i am cool with it
Apr 22 04:05:06 <mattb00ne> just moved to different pins
Apr 22 05:21:27 <buzzmarshall> my quess would that because of the default drivers initialization settings that depending on when the bbb starts up and initializes its pin muxes the drivers not seeing a signal to shut it off until something in the bbb is triggering a pin mux change that would shut off the motor
Apr 22 05:22:51 <buzzmarshall> it could be as you say a bad board but seeing you say that it seems to kinda work in both on/off would make me think its a pin mux setting in how the 2 peices go about initializing themselves
Apr 22 05:25:28 <buzzmarshall> ive come across drivers before where depending on the mcu's setting where the order of setting the pin's level and direction will decide if the internal pullups are enabled or not which can affect how the device connected to the pin reacts
Apr 22 05:26:14 <zmatt> nah I think the output just remained high-z for some reason, and it had internal pull-up
Apr 22 05:27:04 <buzzmarshall> old atmels were like that... if you set the pin states in the wrong order it lead to random settings in regards to the pullups
Apr 22 05:27:32 <buzzmarshall> could be as you say something holding it up
Apr 22 05:28:21 <buzzmarshall> i just no ive run across motor drivers where the drivers default is flipped logic from the typical off state
Apr 22 05:29:11 <zmatt> no I mean, it definitely had internal pull-up configured, but switching pinmux to eHRPWM *should* result in the pin immediately being driven low (if no config of the peripheral has been done yet)... or so I thought at least, maybe I'm mistaken
Apr 22 05:29:48 <zmatt> regardless, using a pin with default pulldown fixed the problem, so it's not a hardware issue at least
Apr 22 05:30:19 <buzzmarshall> your probably right as i sure youve got more experience with the ti stuff then i have
Apr 22 05:30:39 <buzzmarshall> im just guessing as to things ive seen with other boards
Apr 22 05:31:28 <buzzmarshall> cool so its just a matter of adjusting the startup defaults
Apr 22 05:31:32 <zmatt> it doesn't help that with mattb0ne the probability of user error is not negligible :P
Apr 22 05:31:41 <buzzmarshall> hehe
Apr 22 05:31:49 <mattb000ne> haha
Apr 22 05:31:51 <zmatt> lol
Apr 22 05:32:10 <mattb000ne> on this one the space for mattbooone errors is small
Apr 22 05:32:27 <mattb000ne> but i do have my ways
Apr 22 05:32:41 <buzzmarshall> making errors is good in my book as its how one truly learns
Apr 22 05:32:42 <zmatt> I mean, that's what I thought when I asked you to do a voltage measurement, and yet
Apr 22 05:32:54 <mattb000ne> lol
Apr 22 05:33:00 <buzzmarshall> were not all Sheldon Coopers
Apr 22 05:33:02 <buzzmarshall> lol
Apr 22 05:33:44 <zmatt> mattb000ne: so I'm curious, can you try connecting it to P9_22 again and after boot do  echo low >/dev/gpio/P9_22/direction   to see if the motor turns off?
Apr 22 05:34:14 <mattb000ne> I can do it tomorrow, left the lab
Apr 22 05:34:19 <zmatt> ok
Apr 22 05:34:20 <mattb000ne> i will check it out for sure
Apr 22 05:34:29 <zmatt> motor would be running until you can do that command of course
Apr 22 05:34:38 <mattb000ne> that is fine
Apr 22 05:36:11 <mattb000ne> i ideally would like something a bit more basic than the BBB
Apr 22 05:36:16 <mattb000ne> to play with
Apr 22 05:36:44 <mattb000ne> or just a better understanding of linux and basic computer operation
Apr 22 05:37:01 <mattb000ne> like that whole modprobe thing I would never know to look at that
Apr 22 05:37:40 <zmatt> that's not a generic linux or basic computer thing though
Apr 22 05:37:56 <zmatt> that's a caveat very specific to this single (fairly obscure) driver
Apr 22 05:38:10 <mattb000ne> oh
Apr 22 05:40:37 <buzzmarshall> ive played with a lot of different boards over the years and to be honest find the beagles are probably one of the better boards to learn how to interface and work with linux
Apr 22 05:40:57 <mattb000ne> really
Apr 22 05:41:10 <buzzmarshall> all be it the bbb's a little short on sdram compared to others
Apr 22 05:41:24 <buzzmarshall> but the support and info for them is good
Apr 22 05:41:24 <mattb000ne> i wish there was just more content out there
Apr 22 05:41:44 <mattb000ne> if you could take the rasberry pi's suport and beagles functionality it would be great
Apr 22 05:41:57 <mattb000ne> outside of trolling this irc channel not much help out there
Apr 22 05:42:03 <mattb000ne> like for the AI forget it
Apr 22 05:42:10 <buzzmarshall> most of the things like the duino's or even rasp to some extent tend to dumb things down to using their goof proof ide's
Apr 22 05:42:24 <mattb000ne> i like goof proof
Apr 22 05:42:27 <mattb000ne> i am a goof lol
Apr 22 05:42:39 <buzzmarshall> which is good if thats your scene but when it comes to linux their not very good
Apr 22 05:43:48 <buzzmarshall> at least not in my opinion
Apr 22 05:43:48 <buzzmarshall> i goof up all the time as well
Apr 22 05:43:48 <buzzmarshall> lol we all do
Apr 22 05:44:53 <mattb000ne> i just want more tutorials for the BBB
Apr 22 05:45:09 <mattb000ne> like an updated version of the derek molloys book
Apr 22 05:45:14 <mattb000ne> and more like it
Apr 22 05:45:29 <buzzmarshall> ya i got the molloy books which are good but a bit dated
Apr 22 05:45:40 <buzzmarshall> still tho most of the concepts in it are still in place
Apr 22 05:47:52 <buzzmarshall> check around for Fastbit Embedded Brain Academy's videos
Apr 22 05:48:03 <buzzmarshall> i think i found them on Youtube
Apr 22 05:48:43 <buzzmarshall> dudes got a bit of a accent but not bad videos as he covers the device tree and kernel stuff really well
Apr 22 05:49:21 <buzzmarshall> again like molloy's he's a bit dated but still good info without over the top technical stuff
Apr 22 05:52:13 <buzzmarshall> ive spent years playing with various Rockchip, Amlogic, Rasp and currently Allwinner based boards which are more resourceful but they all have some limitations because of propriatary stuff so there more time consuming to learn
Apr 22 05:53:03 <buzzmarshall> bbb's i find kinda nice and things like the pru's set them aside from alot of other boards
Apr 22 05:53:38 <buzzmarshall> ive still got a lot to learn tho as well
Apr 22 05:56:12 <mattb000ne> damn well if you have a lot to learn i got 2 orders of magnittude more lol
Apr 22 05:56:23 <mattb000ne> fun though
Apr 22 05:56:31 <mattb000ne> espcially when you can bug zmatt
Apr 22 05:56:45 <zmatt> buzzmarshall: short on sdram for what purpose?
Apr 22 05:57:39 <zmatt> on our beagles nearly all of RAM is used as disk cache since it has no better use for it
Apr 22 06:01:36 <buzzmarshall> for my purposes i find them ok but others i know that run alot of crap on their linux install's complain about it, that and the cost when comparing the bbb to most other boards
Apr 22 06:02:20 <buzzmarshall> i don't run much on the installed linux so i can work with them fine sofar
Apr 22 06:03:03 <buzzmarshall> i bought a AI as well just to get up to the 1g if i needed it
Apr 22 06:03:52 <buzzmarshall> sofar ive not even taken it out of the box...lol
Apr 22 06:04:22 <zmatt> there's also the BBE if you want an am335x-based beaglebone with 1G
Apr 22 06:04:28 <zmatt> (along with gigabit ethernet)
Apr 22 06:05:49 <buzzmarshall> im used to years of much smaller setups so its not really a concern for me and to be honest when i 1st started messing with the bbb i put alot of crap onto my own linux install just to see how far i could push it
Apr 22 06:06:14 <buzzmarshall> was impressed it even compiles somethings i tried
Apr 22 06:06:36 <buzzmarshall> a bit slow but addin a swap partition seemed to fix it up and make the builds work
Apr 22 06:07:08 <zmatt> swap? ew
Apr 22 06:07:39 <zmatt> I use distcc to distribute compilation to a cross-compiler on a server here on the network
Apr 22 06:08:14 <buzzmarshall> the other thing i like is the idea of playing with TI stuff... ive way to much time invested in the other major players which really don't help that much with linux and their socs
Apr 22 06:08:31 <zmatt> gets you most of the performance of cross-compilation without any of the headache (preprocessing and linking is still done locally, build systems don't even realize a cross-compiler is being used)
Apr 22 06:08:55 <buzzmarshall> normally when i build i do the same kinda thing as i have a rack here with about a half dozen servers
Apr 22 06:10:05 <buzzmarshall> i was more or less just saying how suprised i was at being able to do local building on the bbb
Apr 22 06:10:44 <buzzmarshall> typically i build on my rack and text using tftp
Apr 22 06:10:49 <zmatt> I mean, why wouldn't you be able to?  though now that I'm used to the performance of the distcc setup I wouldn't want to go back :P
Apr 22 06:10:55 <buzzmarshall> sorry test
Apr 22 06:12:02 <buzzmarshall> i kinda did it to prove to some buds that are big time rpi4 and rockchip guys with 4g boards to prove a point to them
Apr 22 06:12:33 <buzzmarshall> they all were trying to make a bbb build something that failed all the time when building locally onboard
Apr 22 06:13:50 <buzzmarshall> i still mess with the same boards as they do but find the TI's kinda nice
Apr 22 06:14:20 <buzzmarshall> i see people here sometimes having trouble with things like pin muxing
Apr 22 06:14:48 <zmatt> it's mostly fine I think
Apr 22 06:15:00 <buzzmarshall> lol... try working with that crap on a RK or AMlogic soc where docs aren't full
Apr 22 06:15:15 <zmatt> for simple uses there's config-pin, and u-boot overlays makes it easier to customize the DT when needed
Apr 22 06:16:14 <buzzmarshall> i agree i like them... its kinda sad more people don't see it
Apr 22 06:17:18 <buzzmarshall> with most i am around there all caught up in the more of everything socs that tend to have most open developments in a narrowed media oriented scene
Apr 22 06:17:34 <buzzmarshall> that they don't see the potential of things like the bbb's
Apr 22 06:18:14 <buzzmarshall> nobody needs to sell me on the TI's
Apr 22 06:18:32 <zmatt> I like TI SoCs quite a bit (and their documentation!)
Apr 22 06:18:56 <buzzmarshall> i agree
Apr 22 06:19:45 <buzzmarshall> i find it refreshing not having to worry about trying to reverse engineer something just to get a better understanding and use out of their soc
Apr 22 06:20:09 <buzzmarshall> TI's got lots of good info
Apr 22 06:20:52 <buzzmarshall> they remind me of how Atmel was in the old days
Apr 22 06:21:05 <buzzmarshall> which is probably why TI now has Atmel
Apr 22 06:21:07 <buzzmarshall> lol
Apr 22 11:17:09 <kremlin> m
Apr 22 16:44:24 <gpunk> does patience pay ?
Apr 22 16:47:40 <mru> whatever gave you that idea?
Apr 22 16:57:08 <gpunk> the description of the channel :p
Apr 22 17:11:56 <mru> oh, that
Apr 22 17:12:02 <mru> we just like making people wait
Apr 22 17:23:46 <zmatt> gpunk: it happens too often that people ask a question and then leave when they don't get an answer immediately
Apr 22 17:24:59 <zmatt> like they're expecting a helpdesk or something rather than a community chat where people probably only occasionally glance at chat
**** BEGIN LOGGING AT Thu Apr 22 18:39:32 2021
Apr 22 19:22:05 <john_doe> I'm playing around with this pin configuration checking utility that zmatt wrote
Apr 22 19:22:09 <john_doe> https://github.com/mvduin/bbb-pin-utils
Apr 22 19:22:32 <john_doe> just trying to figure out if the show-pins command queries the current state of GPIO pins, or just the boot configuration?
Apr 22 19:22:55 <john_doe> i.e. when I look at one of the pins' configurations, like so:
Apr 22 19:22:56 <john_doe> show-pins | grep P8.15
Apr 22 19:24:02 <john_doe> does the << hi refer to the state of the pin at boot (high or low), or the current state, high or low?
Apr 22 19:30:53 <zmatt> current state
Apr 22 19:31:26 <zmatt> I thought the README made that reasonably clear
Apr 22 19:34:34 <zmatt> the state of a pin at boot is not information that's even recorded anywhere
Apr 22 19:34:51 <zmatt> (not sure why it would be useful information either)
Apr 22 19:35:08 <john_doe> gotcha
Apr 22 19:35:48 <zmatt> unless you count the sysboot pins, whose state is latched at power-on to provide basic settings to bootrom
Apr 22 19:37:09 <john_doe> as for the README, maybe it's just due to my lack of background, but I was reading through it prior to asking the question, and still wasn't sure
Apr 22 19:37:20 <john_doe> for sure
Apr 22 19:37:28 <john_doe> yeah I'm just wondering about the normal GPIO ones
Apr 22 19:37:31 <john_doe> thanks for the clarification
Apr 22 19:37:43 <zmatt> well those pins are also normal gpios
Apr 22 19:40:10 <zmatt> though the fact that they're sampled at power-on to determine bootrom configuration means you need to be careful with connecting stuff to them to avoid unintentionally changing boot configuration and causing failure to boot, which is why my pins spreadsheet has a warning for those: https://goo.gl/Jkcg0w#gid=1847985463
Apr 22 19:40:30 <zmatt> bbl
Apr 22 20:08:02 <john_doe> interesting. could you elaborate on that?
Apr 22 20:08:33 <john_doe> meaning if something externally drives any of the pins while booting the beaglebone won't boot?
Apr 22 20:10:11 <john_doe> is this the warning you're talking about?
Apr 22 20:10:28 <john_doe> * Caution: boot config pins with on-board pull.  Internal pull should be disabled.
Apr 22 20:11:46 <zmatt> the line below it
Apr 22 20:12:52 <john_doe> ah I see
Apr 22 20:15:24 <zmatt> if something externally drives/pulls them to the non-default level at the moment of power-on (not "while booting")
Apr 22 20:15:33 <zmatt> bbl
Apr 22 20:21:20 <john_doe> gotcha
Apr 22 20:21:24 <john_doe> thanks again!
Apr 22 21:34:12 <zmatt> john_doe: I also clarified the GPIO section in the README: https://github.com/mvduin/bbb-pin-utils/blob/master/README.md#gpio
Apr 22 21:34:15 <zmatt> does that help?
Apr 22 22:12:16 <john_doe> yes! thanks!
Apr 23 00:07:20 <john_doe> hey guys, I am using this boot overlay utility that zmatt wrote: https://github.com/mvduin/overlay-utils
Apr 23 00:07:29 <john_doe> to adjust the GPIO pin configs at boot
Apr 23 00:07:55 <john_doe> now I am trying to read and set the pins (high/low) at runtime, and am trying to use this python library:
Apr 23 00:07:58 <john_doe> https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/gpio
Apr 23 00:08:26 <john_doe> I'm running into a permission error when I try to setup an output pin:
Apr 23 00:08:27 <john_doe> ValueError: Set gpio direction failed, missing file or invalid permissions.
Apr 23 00:09:14 <john_doe> I googled it and found some stuff about disabling .dtbo boot overlays, so I was wondering, does the overlay-utils utility interfere with traditional methods of setting and getting GPIO state at runtime?
Apr 23 00:24:18 <john_doe> *correction: when I try to set an input pin
Apr 23 00:24:24 <john_doe> output pins get set without issue
Apr 23 00:27:11 <john_doe> *correction: when I try to set an input or an output pin, but seemingly only the ones that I've configured with the boot overlay
Apr 23 00:27:17 <john_doe> now I'm thinking it is probably related
Apr 23 00:48:09 <zmatt> john_doe: that's just because the adafruit library sucks
Apr 23 00:48:27 <john_doe> gotcha
Apr 23 00:48:33 <john_doe> is there one that you reccomend instead?
Apr 23 00:49:17 <zmatt> have I already given you the udev rule to create /dev/gpio/ with symlinks for each gpio?
Apr 23 00:49:33 <john_doe> I don't think so
Apr 23 00:50:03 <zmatt> https://pastebin.com/qZZmQQQg
Apr 23 00:50:44 <zmatt> saveas /etc/udev/rules.d/gpio-symlinks.rules  or whatever, then update initramfs with "sudo update-initramfs -u" (unless you're not using initramfs) and reboot
Apr 23 00:51:23 <john_doe> ok, and what does this do, exactly?
Apr 23 00:51:33 <zmatt> make it really easy to find your gpios
Apr 23 00:52:46 <zmatt> and since they're already configured in DT, that also means you don't really need a library for using gpios, they're trivial to use directly... I'll give an exmaple, but the udev rule is step one
Apr 23 01:00:58 <john_doe> gotcha
Apr 23 01:01:14 <john_doe> so do that, then I can access them in code without the adafruit or similar libraries? that sounds good
Apr 23 01:01:26 <john_doe> according to an example that you'll send?
Apr 23 01:01:44 <zmatt> yeah, with a miniscule amount of pure python (and it's easy in every language, even C)
Apr 23 01:08:52 <zmatt> were you able to install the udev rule, does it work?
Apr 23 01:15:55 <john_doe> yeah, it seems to work
Apr 23 01:17:05 <john_doe> would you mind sending the example?
Apr 23 01:17:13 <john_doe> thanks for the help again btw
Apr 23 01:27:13 <zmatt> the absolute simplest is using pathlib: https://pastebin.com/n54hkvw8
Apr 23 01:27:33 <zmatt> three versions of a micro-gpio-library based on that: https://pastebin.com/z2p618S6
Apr 23 01:28:11 <zmatt> performance can however definitely be much improved without much more complexity
Apr 23 01:31:28 <john_doe> ok great
Apr 23 01:31:37 <john_doe> I'm not too worried about performance honestly
Apr 23 01:31:49 <john_doe> I just want to change the pin configs at boot
Apr 23 01:31:53 <john_doe> then set and read them at runtime
Apr 23 01:31:58 <john_doe> seems like this should work though!
Apr 23 01:33:06 <john_doe> I'll try that out and let you know how it goes
Apr 23 01:33:08 <john_doe> thanks again!
**** ENDING LOGGING AT Fri Apr 23 02:59:56 2021