**** BEGIN LOGGING AT Tue Nov 19 02:59:58 2019 Nov 19 16:02:46 m Nov 19 19:37:30 Hi I have an easy problem with a confusing solution for my non-linux brain Nov 19 19:37:43 I want to initialize an input pin on beagle blue. https://github.com/adafruit/adafruit-beaglebone-io-python/issues/248 Nov 19 19:39:05 I'm running an example code provided onboard. cloud9/beaglebone/blue/python/button.py Nov 19 19:40:00 The error: Set gpio mode failed, missing file or invalid permissions. Nov 19 19:40:28 I think the solution is in the link I attached but theres way too much going on in that thread for me to follow. Nov 19 22:10:38 hmm Nov 19 22:11:50 davidM: what's that overlay you have configured? Nov 19 22:12:40 also why are you using sudo when you're already logged in as root? also why are you logged in as root? :P Nov 19 22:13:02 my guess would be that whatever that BB-W1-P9.12-00A0 overlay is, it broke cape-universal Nov 19 22:13:27 hmm it's actually a standard overlay? Nov 19 22:13:39 ah for 1wire Nov 19 22:15:05 davidM: uhh, I just noticed the github issue you linked to is an old one and was already resolved Nov 19 22:16:09 why did you link to it? Nov 19 22:19:13 Hi again, sorry I was away for a bit. I linked it because I was confused by the many comments on the issue Nov 19 22:19:23 I need an answer for a 10-year old. Nov 19 22:20:15 davidM: the issue you linked to was about an overlay being loaded that was incompatible with cape-universal, which was fixed by updating the overlay Nov 19 22:20:42 OK. My particular issue is that I can't run the example code on the beagle. Nov 19 22:21:04 I googled, and ended up at the link I provided. Nov 19 22:21:08 are you running the latest image? what does the example look like? (share with e.g. pastebin.com) Nov 19 22:21:40 the error just means the pin you're trying to reconfigure isn't reconfigurable, it doesn't provide any information as to *why* it isn't reconfigurale Nov 19 22:22:06 https://gist.github.com/dmalawey/5a38554d3fff1bab5a7a9699def27334 Nov 19 22:24:31 please run my show-pins script and share its output: https://github.com/mvduin/bbb-pin-utils/tree/blue#show-pins Nov 19 22:25:13 My image: BeagleBoard.org Debian Image 2018-10-07 Nov 19 22:25:32 I think this is the second-to-latest image. Nov 19 22:25:48 yeah it should be recent enough Nov 19 22:26:37 pretty sure that "P8_9" should be "P8_09" Nov 19 22:27:18 (kinda annoying anyway that the pins are named after BBB expansion headers rather than having names meaningful for the bbblue, but I digress) Nov 19 22:28:44 wow I didn't know this existed. Nov 19 22:28:45 https://pastebin.com/YsUZDV0m Nov 19 22:29:50 uhhhhh Nov 19 22:30:55 looks like the pause/mode buttons are not reconfigurable pins, although they are setup as gpios anyway Nov 19 22:31:27 although, hmm, not sure, they don't seem to be exported gpios at least Nov 19 22:32:17 lemme look at the bblue dts Nov 19 22:32:44 what's a dt? Nov 19 22:32:56 dt = device tree, dts = device tree source Nov 19 22:35:13 Ah! That's why you guys get paid the big bucks! Nov 19 22:35:22 ? Nov 19 22:35:38 strong knowledge of acronyms. Just playin Nov 19 22:37:35 well, this example can't possibly work with the device tree as it's written currently, not only are pause/mode not reconfigurable pins, none of the gpios are exported by default Nov 19 22:37:39 rcn-ee[m]: ping Nov 19 22:37:59 eeek, ok. Nov 19 22:38:42 davidM: I don't suppose simply omitting the GPIO.setup for the button works? Nov 19 22:39:04 (and changing "P8_9" to "P8_09") Nov 19 22:40:54 oh never mind it is actually P8_9 in adafruit's library Nov 19 22:40:58 confusing Nov 19 22:42:30 actually it should accept "PAUSE" or "MODE" as well I think, not sure Nov 19 22:55:22 davidM: not sure what the easiest workaround would be right now... I guess I could probably try fixing the dt for you, but I don't really have the energy for that right now Nov 19 22:56:17 manually exporting the gpio isn't hard but presumably wouldn't do anything to make the adafruit library happy Nov 19 22:58:50 I suspect a lot of bbblue users use the librobotcontrol instead, which uses the gpio chardev instead of the sysfs interface, which is how it wasn't noticed that the adafruit gpio library is currently broken on the blue Nov 19 23:46:52 interesting is their a reason to use chardev instead? Nov 19 23:51:59 no clue Nov 19 23:57:30 Ok ... I was wondering if I missed something apparently either no or more than just me were. Nov 19 23:57:50 it probably fits under "doesn't matter" Nov 19 23:58:13 probably they heard it was neato and The Way Of The Futureā„¢ (*vomit*) Nov 19 23:59:57 as they say a dog returns to it's... material releases. Nov 20 00:08:14 kernel driver. Nov 20 00:09:35 is that random utterence supposed to mean something in this context? Nov 20 00:13:01 doing user space gpio access is madness Nov 20 00:13:33 GenTooMan: if chardev == /dev/mem, it could be much faster Nov 20 00:14:06 nobody is talking about /dev/mem Nov 20 00:14:25 we're talking about the two official userspace-kernel APIs for gpios Nov 20 00:16:14 saying "doing user space gpio access is madness" is idiocy Nov 20 00:17:20 sometimes a gpio is exactly the interface you want. what do you suggest, moving your entire userspace application to kernelspace? I'm sure that would be great for security and system stability, why even bother with a kernel-userspace interface :D Nov 20 00:17:56 and obscure drivers are the horror-freakshow of the kernel, the fewer of those the better Nov 20 00:18:35 I suggest defining what that GPIO is - if it is a button, use an input device driver, if it an LED.... Nov 20 00:19:38 and if it's none of those? not to mention a led often still needs to be controlled by software, and the sysfs interface for leds is no better than the sysfs interface for gpios (in fact it is worse, it encourages poor security practices) Nov 20 00:20:54 except it limits the amount of hw foot shooting you can do Nov 20 00:21:00 no it doesn't Nov 20 00:21:09 you can't turn a LED into an input and have floating lines Nov 20 00:21:16 LED interface I mean Nov 20 00:21:32 same is true for the sysfs gpio interface if you properly setup your gpios in DT, like I always do Nov 20 00:21:47 (same is not true for the new gpio chardev, which is one of the reaons I think it sucks) Nov 20 00:23:30 for example declaring https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi#L35-L65 results in https://pastebin.com/raw/YKW7Wcqu (note how the 'direction' attribute is read-only except when the DT explicitly marks the gpio as bidirectional) Nov 20 00:24:04 that's half way going down a kernel driver path Nov 20 00:24:16 I don't even know what you mean by that Nov 20 00:24:37 it's using the driver available for its intended use, which does exactly what I want in most cases Nov 20 00:25:56 for miscellaneous digital signals the userspace application needs to monitor or control, this is perfect Nov 20 00:26:49 it even allows per-signal access control, and the gpios are named in DT (and symlinks are created by an udev rule) so the application doesn't need to know or care which physical pin is used (which is extremely useful since gpios tend to move around when pcb revisions are done) Nov 20 00:27:40 the kernel thus all the safety, security, and abstraction I could hope for Nov 20 00:27:44 *thus provides Nov 20 00:30:25 unnecessarily moving application-specific code from userspace to the kernel sounds like a terrible, terrible idea to me. it would be awful for development and it's an insane thing to do from the point of view of security and safety Nov 20 00:33:02 as for using e.g. gpio-keys for a button instead of exporting it as gpio, they're basically equivalent except for the API used, so that's a matter of preference/convenience Nov 20 00:38:23 IIRC - gpio-keys uses interrupts Nov 20 00:39:42 well duh it better, so does the gpio sysfs interface and I'm sure the gpio chardev offers it too Nov 20 00:40:27 I doubt we'll ever agree on these things... back to convolving for me Nov 20 00:40:29 you're really grasping at straws now to make a point that just puzzles me Nov 20 00:49:20 For those of you who have a stake in beaglebone.org, you'll be happy to know we've created the most extensive open source project for the Blue (I think) Nov 20 00:49:56 This isnt' new but it continues to grow. https://mxet.github.io/SCUTTLE/ Nov 20 00:50:40 68 youtube videos to date on how to build and program Nov 20 00:50:41 https://www.youtube.com/playlist?list=PLHkrnCQ5sDmdyelgZAIN76-Y_Tug1E4Ug Nov 20 00:51:22 Nice! Nov 20 00:52:58 (y) ;D Nov 20 00:55:43 I think this is the first time I've ever seen Computer Vision, 2D Lidar, Embedded Linux, Wifi-based control, or Lithium-ion Power management in an Undergraduate Lab Syllabus Nov 20 00:57:05 The platform is for "Mobile Robotics" course in the Multidisciplinary Engineering Technology program at Texas A&M. Nov 20 00:58:16 Oh and MQTT communication Nov 20 00:58:26 is the CV on the BBAI? Nov 20 00:59:01 blue Nov 20 00:59:12 everything is on the Blue Nov 20 00:59:33 AI would be a nice upgrade but it wouldn't happen without a huge amount of revising of documentation. Nov 20 01:02:22 For that reason, we hope the Blue has continued support for at least 2 years Nov 20 01:03:19 what kind of CV algs are you running on the Blue? Nov 20 01:04:11 the blue is still pretty recent, it seems unlikely it'd be discontinued any time soon Nov 20 01:04:25 keeping it simple. HSV mask to find a color, draw a circle around the largest pixel cluster, and return the x,y,radius of the circle. Nov 20 01:04:49 ah the basics Nov 20 01:06:08 https://youtu.be/SsiPskFvzfE Nov 20 01:06:34 We need 5 or 10 fps to drive by target, so it needs to be simple. Also all computing is onboard. Nov 20 01:07:19 couldn't you slave a BBAI for the alg stuff Nov 20 01:08:24 We could do a lot of things if we focus on one area. But we have inventory to manage, basic elements to teach, and Campus Wifi to fight with Nov 20 01:08:55 There's a reason you don't see undergraduate classes having students build robots from scratch. Nov 20 01:09:46 Teams of 2. Extreme variation in project experience across enrolled students. Junior level. Nov 20 01:10:06 davidm56: doesn't the MIT senior ME class count? Nov 20 01:10:43 ha ha IDK. Please share a link! Nov 20 01:16:53 davidm56: this is footage from an old old PBS episode of something (NOVA?) - https://www.youtube.com/watch?v=e9ijA4UBCQ0 Nov 20 01:17:17 I can't find the course number... Caltech has something like it too but again I can't find the course number Nov 20 01:19:27 ds2: btw, "back to convolving for me" ... audio? Nov 20 01:19:47 zmatt: no, video.. messing with the BBAI and the Jetson Nano Nov 20 01:19:55 ah Nov 20 01:20:18 ds2, will keep my eyes open - always looking for more ideas Nov 20 01:20:49 convolution should be something EVEs are pretty good at? Nov 20 01:21:17 davidm56: Nov 20 01:22:29 blah Nov 20 01:22:41 I'd hope so Nov 20 01:23:02 the tidl API makes it hard to figure things out (C++ layers) Nov 20 01:23:33 ah yes, the joy of frameworks Nov 20 01:24:06 examples aren't that helpful either... calls magic opencv support libraries Nov 20 01:24:22 I been unwrapping things and discarding opencv Nov 20 01:25:33 time for a uio-eve library that just runs code on EVEs and nothing more? ;-) Nov 20 01:32:39 hehehe Nov 20 01:36:06 looks like there's no hwmod data for the eves in the 4.19-ti kernel series though, so that would need to be added first Nov 20 01:37:06 otherwise you'd need to manually fiddle the prcm registers via /dev/mem, and even I will admit that's kinda undesirable ;) **** ENDING LOGGING AT Wed Nov 20 02:59:58 2019