10:47 <jfsimon1981> BB-Flash we probably can't provide any support with details

13:41 <zmatt> they've left anyway, but it looks like eMMC was changed to turn it into a flasher

18:25 <Guest4494> 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

18:25 <Guest4494> high thus toggling the relay?

18:25 <zmatt> Guest4494: when changing a pin to output you need to specify its initial value, write either "low" or "high" to the direction attribute

18:26 <zmatt> (for some reason, writing "out" is also accepted but it's treated as a synonym for "low")

18:27 <Guest4494> zmatt, ah, ok.  How do I do that via sysfs?

18:27 <zmatt> 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

18:27 <zmatt> ehh the same as you've been doing before

18:28 <zmatt> except write "high" to the direction attribute instead of "out"

18:29 <Guest4494> That works!  Thanks.

18:30 <zmatt> 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)

18:31 <zmatt> (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)

18:31 <Guest4494> Yes, that's what I've been doing.  But if I do that, should I then set direction to low to make it output?

18:31 <zmatt> no, the active_low attribute only affects the meaning of the value attribute

18:32 <Guest4494> Ah, ok.

18:33 <Guest4494> 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?

18:34 <zmatt> 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

18:34 <zmatt> I don't expect sysfs-gpio to ever go away

18:34 <zmatt> and honestly its "replacement" just sucks

18:34 <Guest4494> I guess gpiod is the replacement.  But the syntax and concept are...different.

18:35 <zmatt> I'm not sure the person who made gpiod understands gpio

18:35 <Guest4494> Why was sysfs-gpio deprecated?

18:36 <zmatt> no clue

18:36 <zmatt> btw, the kernel doc for sysfs gpio states it will simply not get new features, "it will just be maintained"

18:37 <zmatt> fortunately it doesn't need any features, it does exactly the job it needs to :P

18:37 <Guest4494> I can live without new features.  Not sure what they would even be.

18:40 <Guest4494> Thanks zmatt.  As always, you've been very helpful.

18:40 <zmatt> 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

18:41 <zmatt> cape-universal (which is enabled by default) uses it to export bidirectional (default input) gpios for all pins, which is convenient for prototyping

18:42 <zmatt> 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)

18:43 <zmatt> 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

18:43 <Guest4494> I generally use the gpio number.  But perhaps that's not the best practice(?)

18:43 <zmatt> gpiod completely lacks the ability to do this, since it has a device per gpio controller rather than per gpio

18:44 <zmatt> (while software generally absolutely has no reason to care about how gpios are grouped together on gpio controllers)

18:45 <zmatt> using gpio numbers is common practice... it's definitely not *my* preferred practice

18:50 <zmatt> 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

18:52 <zmatt> for comparison, this shows the result of using a custom overlay for setting up gpios: https://pastebin.com/YKW7Wcqu

18:53 <zmatt> (with cape-universal disabled)

18:55 <Guest4494> Why isn't that udev rule included in the OS by default?

18:57 <zmatt> dunno, that's up to rcn

18:58 <zmatt> maybe it is in testing images, haven't checked

23:42 <Guest4494> 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.

23:44 <Guest4494> 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.

23:44 <Guest4494> Is there something special about P9_25?

23:44 <zmatt> P9.25 is used by hdmi audio (when enabled)

23:44 <Guest4494> Enabled where? DT?

23:45 <zmatt> 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

23:45 <zmatt> I have a utility that shows for all pins what their currently configured usage is: https://github.com/mvduin/bbb-pin-utils/#show-pins

23:46 <Guest4494> I don't need hdmi so disabling the video sounds like the best choice.

23:46 <zmatt> you do need to be careful with these things... hopefully you didn't end up damaging the audio oscillator by shorting its output

23:47 <zmatt> yeah if you don't need hdmi, disabling it frees up a whole bunch of pins for other use

23:48 <Guest4494> Is the audio oscillator used for anything besides sound (for which I have no need)?

23:48 <zmatt> nope

23:48 <Guest4494> Then I don't care even if I do damage it.

23:50 <zmatt> 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

23:50 <Guest4494> Is there any reason I can't disable the video AND the audio in uEnv.txt?

23:50 <Guest4494> can't==shouldn't

23:51 <zmatt> if video is disabled, the audio setting is ignored

23:52 <zmatt> so there's no reason to *not* disable both for clarity if you prefer

23:53 <Guest4494> And...that works.  Pressing the button changes value from 0 to 1 as expected.

23:53 <Guest4494> Thanks.

23:53 <zmatt> in case you're curious, here's the schematic of how the audio-related pins are hooked up: https://pastebin.com/raw/nXRxCARu

23:54 <zmatt> it's possible the audio osc wasn't even enabled in your case since nothing was connected to hdmi

23:54 <zmatt> (dunno if it's dynamically switched or not)

23:55 <Guest4494> Yeah, I'm just using a serial console or ssh.

23:55 <zmatt> now that I think of it, it probably is dynamically switched, so there was no danger in that case