GPIO on Debian (build 83)

Products Support DragonBoard410c
#1

I am unable to get GPIO_A working on Debian.

It seems that the offset of 902 is not valid for Debian and using it will cause the kernel to report an error.

If I attach and LED with + pin on pin 23 of the LSC and the - pin on either pin 1 or 2, then log in via SSH, su to root, cd to /sys/class/gpio and execute the following commands:

echo 36 > export
cd gpio36
echo out > direction
echo 1 > value

nothing happens. I’ve checked with multiple LEDs and a meter.

Can someone verify that they have GPIO_A (or any other GPIO for that matter) working as an output on Debian?

Thanks in advance.

#2

I’m using GPIO_A as an output in Debian (1604 build) without issue, along with B, C, and G. If you cat the value after performing those steps you listed, does it report that it’s 1?

Also, you should not be using any gpio to drive an LED directly, you need a current limiting resistor to keep from shorting out the gpio. 1.8V might not be enough to illuminate the LED either, it depends on the color.

#3

yes, the value reports back as 1 via cat.

I’ll put a resistor inline but I was following the Qualcomm Developer Network instructions here (and several other similar places): Using GPIOs on low speed connector on DragonBoard™ 410c - YouTube

except for Debian and not Android. He doesn’t use a resistor and his LED lights. He is using Red, I’ve tried green and white, but I also don’t see any voltage on a meter that has no issue accurately measuring 1.8v on the DC output pin that I use successfully as a reference for my level converter in the UART connection we have previously discussed. It’s a decent meter and measure mV and other much lower signals with no problem all the time.

I appreciate your help once again; I may try another GPIO now and see if that works.

#4

It was the color of the LED.

SMDH

RED is the only color that works (and faintly at that). Turns out my meter was low on battery.

feeling very noob today.

Thank you again.

#5

LEDs usually take 2V+ to be turned on, and DB410c GPIOs will only output a signal of 1.8V, so we need an amplifier to do that, for example an operational amplifier (e.g. NTE987).

I’m using Bi-Directional Logic Level Converters from SparkFun for all GPIOs: https://www.sparkfun.com/products/12009 for all GPIOs.

For I2C buses I use a PCA9306 Level Translator Breakout from Saprkun too: https://www.sparkfun.com/products/11955

#6

You definitely don’t want to use an opamp to increase the gpio voltage. Opamps are linear devices, which means they’re designed for analog signals and have low efficiency. They’ll be bigger, slower, more expensive, less efficient, require careful part selection to work properly at the rail, and require more supporting parts than necessary. All you need is an NPN BJT or logic-level Nch MOSFET to act as a digital switch.

Those level shifters will work for slow logic signals, but they aren’t ideal and won’t work well for LEDs either due to the open-collector design and high drive impedance. They’re good for I2C or any other signals that truly need to be bidirectional, otherwise you’d be better off with a “real” level shifter, eg SN74LVC1G125 (multiple channel versions also available). It’s faster, lower power, has built in ESD protection, and has higher drive strength.

#7

Does anyone have a good idea how to access these GPIOs from userspace?

I have a systemd unit file that successfully exports the pin; but it seems no amount of chmoding or chowning to the linaro user or the dialout group (which my linaro user belongs to) allows that user to set the GPIO value.

It seems really useless if I have to give root privileges to any application that wants to use a single GPIO pin.

The Rasberry PI seems to allow this according to posts I’ve read; wondering if anyone has tried this on the DB410c?

#8

Run the following as root:
groupadd -f --system gpio
adduser linaro gpio

Then create a file in /etc/udev/rules.d/ called 91-gpio.rules (or pick whatever number/name combo you want) with the following contents:
SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys%p; chmod -R g+rwX /sys%p'"

Then reboot.

If successful, GPIOs will need to be exported as root (you can do so in an init.d script on boot), but once exported any member of the “gpio” group will be able to change the direction/value.

#9

Ok great man!

I hadn’t figured out udev stuff yet, so that makes sense. Thanks yet again!

#10

Well, first, the groupadd command should be “groupadd -f -r gpio”; but that aside this did not work for me.

I’ll revisit it soon, as I perhaps made some error; but I can’t afford to track it down today due to deliverables and must run my service as root for the time being :(.

Just fyi.

#11

Yes -r will work as well, my original post had two dashes in front of system, which is the same as -r, but the forum software combined them into one longer dash. My fault for not putting it in code tags and not noticing the change.

As for it not working, that’s the same rule I have set up on all of my systems and it works great. Is it not changing the group ownership of the files to the “gpio” group, or is it changing them but linaro still doesn’t have access? If the former, make sure there are no typos or missing quotes in the rule. If the latter, run “id linaro” to make sure it’s in the “gpio” group and make sure you’ve rebooted for the group add to take effect.