warthog618 / go-gpiocdev

A native Go library for accessing GPIO lines on Linux platforms using the GPIO character device

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

gpiod.WithPullUp question

iesrbt opened this issue · comments

commented

Hello,
Thank you for your library. I'm currently trying to use it on a ROCK 4C Plus card (Rasp clone).
Works pretty well, except I'm not able to use (or just don't understand) the gpiod.WithPullUp option. I think I do have an appropriate kernel: Linux rock-4c-plus 5.10.110-21-rockchip #d4b5d0d1d SMP Thu Nov 9 07:07:47 UTC 2023 aarch64 GNU/Linux.

I run the following code:

opts := []gpiod.LineReqOption{
gpiod.AsInput,
gpiod.WithBothEdges,
gpiod.WithEventHandler(gpioHandler),
gpiod.WithLines([]int{GPIO_PIN18}, gpiod.WithPullUp) }

gpio, err := gpiod.RequestLines(GPIO_CHIP, []int{GPIO_PIN16, GPIO_PIN18}, opts...)

and err IS nil at that point.

Then, pins not connected to anything, I read lines with gpio.Values(vv).
I get no err again and vv as [0, 0]. Shouldn't it be [0,1] instead?

Any hints/help appreciated.
Thanks again.

Yeah, it should.
Have you allowed time for the pullup to take effect, or is that Values() immediately after the request?
Do you have strace available, and if so what version?
If you have a recent version of strace (5.11 or later IIRC) you can run strace --trace=ioctl <your program> to see the commands being sent to the kernel and what the response is.
That would identify whether the problem is in gpiod or your kernel.

commented

Hi,
yes plenty of time. Values() is in a loop and stick to [0,0].

Also line info reports:
err: nil ; {Offset:28 Name: Consumer:dla Used:true Config:{ActiveLow:false Direction:1 Drive:0 Bias:2 EdgeDetection:3 Debounced:false DebouncePeriod:0s EventClock:0}}

Bias == 2 looks good according to the constant definition.

Here is the strace:
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
ioctl(3, GPIO_GET_CHIPINFO_IOCTL, 0x4000094b1c) = 0
ioctl(3, GPIO_V2_GET_LINEINFO_IOCTL, 0x4000094510) = 0
ioctl(3, GPIO_V2_GET_LINE_IOCTL, 0x40000b9600) = 0
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=2572, si_uid=1000} ---
ioctl(3, GPIO_GET_CHIPINFO_IOCTL, 0x40000b99bc) = 0
ioctl(3, GPIO_V2_GET_LINEINFO_IOCTL, 0x40000b95b0) = 0
ioctl(3, GPIO_V2_GET_LINEINFO_IOCTL, 0x40000b95b0) = 0
{Offset:28 Name: Consumer:dla Used:true Config:{ActiveLow:false Direction:1 Drive:0 Bias:2 EdgeDetection:3 Debounced:false DebouncePeriod:0s EventClock:0}}
ioctl(7, GPIO_V2_LINE_GET_VALUES_IOCTL, 0x40000b9d60) = 0
[0 0]
ioctl(7, GPIO_V2_LINE_GET_VALUES_IOCTL, 0x40000b9d60) = 0
[0 0]
ioctl(7, GPIO_V2_LINE_GET_VALUES_IOCTL, 0x40000b9d60) = 0
[0 0]

Hope you can find something useful within ;-)

Looks like you have an old strace - the more recent versions decode ioctl payload, rather than just print the pointer.
I was hoping for the request ioctl to confirm the config, but the info output will do.
So the bias is set as expected in the kernel. That means the problem is either in the device driver or your particular hardware, not in gpiod.

commented

Ok, thanks for your time and help.
I'll go with an external pull-up resistor then.

You can close this non-issue ;-)