**** BEGIN LOGGING AT Mon Jan 09 02:59:56 2023 Jan 09 03:00:55 P8_9, that is. Jan 09 03:01:00 yes Jan 09 03:02:07 all digital I/O on P8 and P9 that isn't already in use by a kernel device will default to gpio mode Jan 09 03:03:56 to inspect your pinmux state at runtime, see if my show-pins utility works: https://github.com/mvduin/bbb-pin-utils/#show-pins I've never tested it on a mainline kernel, but I think it should work Jan 09 03:06:16 Hmm, maybe there's another way to solve this: I just went back to the code I wrote ~6 months ago.  It's still using Adafruit_BBIO.GPIO to control the pins, and it's failing to toggle P8_7 & P8_9.  This was before you suggested using iio instead, which I did, but not on this project that I'm now revisiting.  But I *can* toggle 7 & 9 via sysfs. Jan 09 03:06:17 Perhaps I'll try it with iio instead, just to see if there's a difference.  I know Adafruit_BBIO is getting a bit long in the tooth. Jan 09 03:06:46 I suggested iio? iio is for using the ADC, not gpio Jan 09 03:07:04 sysfs is how you control gpio Jan 09 03:07:15 Yes, you did, and it worked great.  But that was for the ADC. Jan 09 03:07:40 (there's also a newer API for gpio but it kinda sucks so I'd still recommend using sysfs gpio) Jan 09 03:08:09 Yeah, I think I looked at that API; syntax seemed...a bit odd. Jan 09 03:08:38 my problem isn't with its syntax but with its semantics :P Jan 09 03:09:15 Well, if sysfs is the way to go, I can do that.  Feels a bit funny in python, but whatever. Jan 09 03:09:39 how does it feel "funny" ? Jan 09 03:10:57 Having to deal with file handles and such instead of just object methods or function calls.  But that's probably just me. Jan 09 03:12:53 I'll just end up creating my own class to abstract the file stuff anyway.  I get spoiled because most everything I tend to want to do, someone else has already done and done better than I would, so I try to not re-invent the wheel. Jan 09 03:14:48 I mean, with pathlib it can be literal one-liners.... Path('/sys/class/gpio/gpioN/value').write_text('0') ... that's not very efficient, but then again python isn't very efficient in general ;) Jan 09 03:16:05 for more efficiency you'd want to keep an open file handle, like https://pastebin.com/UwDFNb9Z (this example doesn't deal with initializing the direction of the gpio, just with getting/setting the value) Jan 09 03:17:45 (note: the '/dev/gpio' on line 10 is for people like me who use udev to create symlinks for gpios in that location, that doesn't apply to you with buildroot but it doesn't affect using this class with gpio numbers) Jan 09 03:20:09 Thanks for that.  I've got something similar that I suspect I partially stole from you/from one of your pastebins last summer when I was last working on this particular project. Jan 09 03:21:56 Hey. Jan 09 03:22:04 What does the buffering=0 mean in that source? Jan 09 03:22:47 it disables buffering, creating a raw filehandle where read and write correspond directly to calls to the kernel (which is definitely what you want in this case) Jan 09 03:22:58 Oh. Jan 09 03:23:00 Nice. Jan 09 03:23:12 No buffering, i.e. buffering=0. Jan 09 03:23:53 So, it is like using system calls in C? Jan 09 03:26:09 yes Jan 09 03:29:15 Hmm. That is neat. So, is that what decorators do? Jan 09 03:34:12 Oh! I see decorators are used to call the function, too. Jan 09 03:36:29 either from the current file or a multitude of files, decorators can do it! Jan 09 03:36:40 ?? Jan 09 03:36:57 I was reading about decorators some more just now. Jan 09 03:37:10 I found a site online. Jan 09 03:37:55 From this site: https://realpython.com/primer-on-python-decorators/ has some ideas/theory and then a real working example for debugging or timings. Jan 09 03:40:38 They wrote about functools also! Jan 09 03:40:43 import functools! Jan 09 03:41:43 Man...w/ import time, one can slow down the execution of the actual output! Jan 09 03:41:56 That is like a slow mo' timer! Jan 09 03:43:32 I may create my first singleton one day... It has been done but it has not been done by me! Jan 09 03:44:12 It is like a boolean... It is just more complicated in source. Jan 09 16:25:08 Hello all! When trying to order a BeagleBoard X15 in Europe, it seems to have some restriction for all european countries on Mouser. Is this something others have seen? If so, does anyone know why? Jan 09 17:28:50 Writing a custom overlay and I want to configure four GPIOs in the DT. Can anyone see what if anything I have done wrong? It compiles cleanly, but the /sys/class/gpio information is not correct. Jan 09 17:28:52 #include Jan 09 17:28:52 #include Jan 09 17:28:53 #include Jan 09 17:28:54     compatible = "ti,am335x-pocketbeagle", "ti,am335x-bone", "ti,am33xx"; Jan 09 17:28:54     // Identification Jan 09 17:28:55     part-number = "TEST"; Jan 09 17:28:55     version = "00A0"; Jan 09 17:28:56     // Resources used by this cape Jan 09 17:28:56     exclusive-use = Jan 09 17:28:57         // Header Pins Jan 09 17:28:57         "P1.36", /* AB1_UART_TX_EN1 */ Jan 09 17:28:58         "P2.02", /* LED_BB */ Jan 09 17:28:58         "P2.17", /* CELL_A0 */ Jan 09 17:28:59         "P2.19"; /* CELL_A1 */ Jan 09 17:28:59     // Helper to show the loaded overlays under: /proc/device-tree/chosen/overlays/ Jan 09 17:29:00     fragment@0 { Jan 09 17:29:00         target-path="/"; Jan 09 17:29:01         __overlay__ { Jan 09 17:29:12                 gpio-hog; Jan 09 17:29:12                 gpios = <14 GPIO_ACTIVE_HIGH>; Jan 09 17:29:13                 ouput-low; Jan 09 17:29:13                 line-name = "AB1_UART_TX_EN1"; Jan 09 17:29:14             }; Jan 09 17:29:14         }; Jan 09 17:29:15     }; Jan 09 17:29:15     fragment@3 { Jan 09 17:29:16         target = <&gpio1>; Jan 09 17:29:16         __overlay__ { Jan 09 17:29:17             P2_02-hog { Jan 09 17:29:17                 gpio-hog; Jan 09 17:29:18                 gpios = <27 GPIO_ACTIVE_HIGH>; Jan 09 17:29:18                 ouput-low; Jan 09 17:29:19                 line-name = "LED_BB"; Jan 09 17:29:19             }; Jan 09 17:29:20         }; Jan 09 17:29:20     }; Jan 09 17:29:32 }; Jan 09 17:55:07 KevinP: when pasting more than a few lines, please use a paste service and post the link here Jan 09 18:45:32 Apologies for the long post. Jan 09 18:53:26 sorry i don't have anything substantive about the issue, but maybe someone else will eventually chime in Jan 09 19:09:52 KevinP: gpio hogging is mutually exclusive with gpios being exported by cape-universal (or any other kernel user of gpios), if you want to use gpio-hog then you need to disable the relevant gpios in cape-universal Jan 09 19:10:15 if your intent is to still have the gpios exported to userspace, then gpio-hog is the wrong mechanism to use Jan 09 19:10:44 I do not want them exported to userspace. Jan 09 19:10:56 I will look into cape universal. Jan 09 19:11:27 okay, then assuming you're using cape-universal you still need to disable the gpios, which also requires a new enough kernel revision (see https://pastebin.com/2w2XtJBP ) Jan 09 19:12:16 you may be interested in my overlay-utils project which takes care of this if you use its USES_PIN macro: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi#L8-L12 Jan 09 19:12:20 (and in general is more readable) Jan 09 19:12:52 I will take a look. Thank you. Jan 09 19:12:59 also, "ouput-low;" is a typo :P Jan 09 19:14:08 more proof that more that one set of eyes is always a good thing. Jan 09 19:14:42 also keep in mind you're not configuring pinmux for the pins you're hogging... this isn't a problem necessarily since they default to gpio mode although it's generally preferred to have pinmux for them anyway to ensure the pins are claimed in the kernel and can't be accidently used by another device Jan 09 19:15:29 with gpio-hog this is a bit annoying since there's no good choice of device to attach the pinmux to, although it's permissible to just attach it to the gpio controller itself Jan 09 19:16:00 I've tried this Jan 09 19:16:00     fragment@2 { Jan 09 19:16:01         target = <&am33xx_pinmux>; Jan 09 19:16:01         __overlay__ { Jan 09 19:16:02             aegis_pins: pinmux-aegis-pins { Jan 09 19:16:02                 pinctrl-single,pins = < Jan 09 19:16:03                     AM33XX_IOPAD(PB_P1_36, PIN_OUTPUT | MUX_MODE7) /* AB1_UART_TX_EN1 */ Jan 09 19:16:03                     AM33XX_IOPAD(PB_P2_02, PIN_OUTPUT | MUX_MODE7) /* LED_BB */ Jan 09 19:16:04                     AM33XX_IOPAD(PB_P2_17, PIN_OUTPUT | MUX_MODE7) /* CELL_A0 */ Jan 09 19:16:04                     AM33XX_IOPAD(PB_P2_19, PIN_OUTPUT | MUX_MODE7) /* CELL_A1 */ Jan 09 19:16:05 STOP PASTING Jan 09 19:16:05                 >; Jan 09 19:16:05             }; Jan 09 19:16:06         }; Jan 09 19:16:06     }; Jan 09 19:16:07     fragment@3 { Jan 09 19:16:07         target-path="/"; Jan 09 19:16:08         __overlay__ { Jan 09 19:16:08             aegis { Jan 09 19:16:40 apparently did not understand what i meant earlier ... :/ Jan 09 19:21:08 KevinP: you may want to look at https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi ... it uses gpio-of-helper to configure gpios, which does export the gpios to userspace but is otherwise similar to gpio-hog in that it allows for configuring gpios, but has the benefit of grouping your gpios together in one device (instead of having to stick them on the gpio controller) which also gives ... Jan 09 19:21:14 ...a place to attach pinmux Jan 09 19:22:20 and overlay-utils makes the ugly boilerplate of overlays unnecessary and has nicer pinmux macros Jan 09 19:22:48 of course if you really don't want them exported to userspace then gpio-hog is still the way to go Jan 09 19:23:03 I'm definitely going to look into it. Jan 09 19:26:47 exporting them using gpio-of-helper also makes the label you use show up e.g. in the output of my show-pins utility, which can be useful for diagnostics Jan 09 19:27:21 (my show-pins utility: https://github.com/mvduin/bbb-pin-utils/#show-pins ) Jan 09 19:30:06 I've used show-pins a couple of times. Nice utility. Jan 09 22:05:01 Question, if accessing GPIOs in userspace through /sys/class/gpio is deprecated, what is the preferred userspace access method? Jan 09 22:05:56 sysfs gpio is not going away and in my opinion still the best way to use gpio on linux Jan 09 22:06:22 I was just wondering if I should update my code. Jan 09 22:06:42 no, the linux kernel has a very strict "don't break userspace" policy Jan 09 22:14:17 the "replacement" is the gpio chardev and libgpiod, but it conflicts with gpio-of-helper (and hence with cape-universal), has no alternative way to configure gpios in DT, doesn't support per-pin access control, and most obnoxiously it resets outputs to high-z if the process that set them exits (or more precisely if the gpiod device is closed) **** ENDING LOGGING AT Tue Jan 10 02:59:57 2023