**** BEGIN LOGGING AT Sat Oct 01 02:59:56 2022 Oct 01 11:47:27 BB-Flash we probably can't provide any support with details Oct 01 14:41:53 they've left anyway, but it looks like eMMC was changed to turn it into a flasher Oct 01 19:25:18 I've got some relays attached to GPIO pins.  When the BBB boots up, the pins default to input, so I change them to output by writing 'out' to the direction file in sysfs.  But when I do that, it turns the relay on which is premature.  Is this because the value on the pin seems to be 1, so setting it to output effectively means it's being set Oct 01 19:25:18 high thus toggling the relay? Oct 01 19:25:53 Guest4494: when changing a pin to output you need to specify its initial value, write either "low" or "high" to the direction attribute Oct 01 19:26:08 (for some reason, writing "out" is also accepted but it's treated as a synonym for "low") Oct 01 19:27:10 zmatt, ah, ok.  How do I do that via sysfs? Oct 01 19:27:32 it sounds like in your setup the relay is wired up such that it is active-low (i.e. relay activates when the pin is driven low), hence write "high" to it to change its direction to out without triggering the relay Oct 01 19:27:44 ehh the same as you've been doing before Oct 01 19:28:02 except write "high" to the direction attribute instead of "out" Oct 01 19:29:19 That works!  Thanks. Oct 01 19:30:11 since your relay is active-low you may also want to set the active_low attribute to 1, that way the kernel will invert the meaning of the value attribute for you (so that 0 means relay off and 1 means relay on, instead of being the other way around) Oct 01 19:31:22 (saying the "relay is active-low" is a slight mis-nomer, whether it's active-low or active-high depends on how you hooked the relay up to the pin) Oct 01 19:31:26 Yes, that's what I've been doing.  But if I do that, should I then set direction to low to make it output? Oct 01 19:31:45 no, the active_low attribute only affects the meaning of the value attribute Oct 01 19:32:31 Ah, ok. Oct 01 19:33:42 BTW, I noticed that /sys/class/gpio is being (has been) deprecated (since what? 2017?).  Yet there are still lots of recommendations to use it.  Is it expected to be around for several more years? Oct 01 19:34:20 i.e. active_low=0 means 0=low and 1=high while active_low=1 means 0=high and 1=low .. but when writing the direction attribute you directly specify "low" or "high" so active_low doesn't matter Oct 01 19:34:25 I don't expect sysfs-gpio to ever go away Oct 01 19:34:33 and honestly its "replacement" just sucks Oct 01 19:34:48 I guess gpiod is the replacement.  But the syntax and concept are...different. Oct 01 19:35:11 I'm not sure the person who made gpiod understands gpio Oct 01 19:35:48 Why was sysfs-gpio deprecated? Oct 01 19:36:33 no clue Oct 01 19:36:51 btw, the kernel doc for sysfs gpio states it will simply not get new features, "it will just be maintained" Oct 01 19:37:01 fortunately it doesn't need any features, it does exactly the job it needs to :P Oct 01 19:37:44 I can live without new features.  Not sure what they would even be. Oct 01 19:40:42 Thanks zmatt.  As always, you've been very helpful. Oct 01 19:40:44 imho the best way to use gpio on production embedded systems is by using gpio-of-helper, which is a tiny out-of-tree driver in rcn's kernels (used on beagleboard.org images) that lets you export gpios from device tree, give them a name, set their initial direction, and determine whether or not userspace is allowed to switch direction Oct 01 19:41:35 cape-universal (which is enabled by default) uses it to export bidirectional (default input) gpios for all pins, which is convenient for prototyping Oct 01 19:42:33 but I like naming the gpios in device tree, since that allows gpios to be moved around between pcb revisions of our hardware without software having to know or care (since it accesses the gpios by name) Oct 01 19:43:21 and it offers per-gpio access restriction, making sure userspace can't e.g. change an input to output and damage hardware by doing so Oct 01 19:43:35 I generally use the gpio number.  But perhaps that's not the best practice(?) Oct 01 19:43:50 gpiod completely lacks the ability to do this, since it has a device per gpio controller rather than per gpio Oct 01 19:44:10 (while software generally absolutely has no reason to care about how gpios are grouped together on gpio controllers) Oct 01 19:45:38 using gpio numbers is common practice... it's definitely not *my* preferred practice Oct 01 19:50:23 I prefer using a udev rule (https://pastebin.com/MMC6u7pR) to create symlinks that allow gpios to be accessed by name instead of by number... when using cape-universal, this allows gpios to be accessed by header pin, which is certainly an improvement over using gpio numbers I think: https://pastebin.com/nSfD8JzH Oct 01 19:52:52 for comparison, this shows the result of using a custom overlay for setting up gpios: https://pastebin.com/YKW7Wcqu Oct 01 19:53:03 (with cape-universal disabled) Oct 01 19:55:57 Why isn't that udev rule included in the OS by default? Oct 01 19:57:45 dunno, that's up to rcn Oct 01 19:58:22 maybe it is in testing images, haven't checked Oct 02 00:42:44 I'm trying to detect a button press using gpio 117/P9_25.  I've got power coming from the 3.3v line, through the switch, and then the path splits with one branch to to pin P9_25 and the other going through a 1k resistor then to ground.  But when I press the button, /sys/class/gpio/gpio117/value still shows zero. Oct 02 00:44:05 If I try to use Adafruit's BBIO python library, I get an error saying "missing file or invalid permissions".  But if I use, say, P8_26. it works fine. Oct 02 00:44:21 Is there something special about P9_25? Oct 02 00:44:39 P9.25 is used by hdmi audio (when enabled) Oct 02 00:44:57 Enabled where? DT? Oct 02 00:45:21 if you want to be able to use it as gpio you need to disable either hdmi in general or hdmi-audio specifically by uncommenting disable_uboot_overlay_video=1 or disable_uboot_overlay_audio=1 respectively in /boot/uEnv.txt Oct 02 00:45:54 I have a utility that shows for all pins what their currently configured usage is: https://github.com/mvduin/bbb-pin-utils/#show-pins Oct 02 00:46:36 I don't need hdmi so disabling the video sounds like the best choice. Oct 02 00:46:38 you do need to be careful with these things... hopefully you didn't end up damaging the audio oscillator by shorting its output Oct 02 00:47:57 yeah if you don't need hdmi, disabling it frees up a whole bunch of pins for other use Oct 02 00:48:13 Is the audio oscillator used for anything besides sound (for which I have no need)? Oct 02 00:48:19 nope Oct 02 00:48:51 Then I don't care even if I do damage it. Oct 02 00:50:26 well that depends on what the consequences of said damage are.. a damaged I/O cell could end up e.g. shorting the pin to ground or to 3.3v :P Oct 02 00:50:45 Is there any reason I can't disable the video AND the audio in uEnv.txt? Oct 02 00:50:59 can't==shouldn't Oct 02 00:51:17 if video is disabled, the audio setting is ignored Oct 02 00:52:28 so there's no reason to *not* disable both for clarity if you prefer Oct 02 00:53:41 And...that works.  Pressing the button changes value from 0 to 1 as expected. Oct 02 00:53:44 Thanks. Oct 02 00:53:45 in case you're curious, here's the schematic of how the audio-related pins are hooked up: https://pastebin.com/raw/nXRxCARu Oct 02 00:54:36 it's possible the audio osc wasn't even enabled in your case since nothing was connected to hdmi Oct 02 00:54:52 (dunno if it's dynamically switched or not) Oct 02 00:55:25 Yeah, I'm just using a serial console or ssh. Oct 02 00:55:27 now that I think of it, it probably is dynamically switched, so there was no danger in that case **** ENDING LOGGING AT Sun Oct 02 02:59:57 2022