OpenWrt Forum Archive

Topic: gpio package source code

The content of this topic has been archived on 18 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi developers,

could someone please tell me where I could find the source code for the gpio package? I've been told that probably mbm is the developer and I wrote him an e-mail last week, but he didn't answer yet. Maybe he's not the original author.

I'm also new in "package writing", so any hint is much appreciated.

Thanks

Andreas

Just google for gpio.tar.gz.

If you look in utils directory on download site you will find gpio.tar.gz.

However last time I tried it, it contained only this statement:

What happened to the GPIO utility?

GPIO is a 'general purpose io', which depending on your point of view
is either a register that controls a hardware io or vice versa. The
gpio util was a diagnostic tool for controlling the GPIO pins, it was
never an intended as abstraction. Each device has the GPIO pins wired
slightly different, which is why we have abstractions like the ones in
/proc/sys/reset and /proc/sys/diag; using the gpio util to hardcode
GPIO numbers into scripts is just ignorant and stupid.

- mbm

So looks like you should use the /proc/sys/* interfaces.

The correct gpio.tar.gz is still available. Google will find it. wink

vincentfox wrote:

However last time I tried it, it contained only this statement:

(...)
which is why we have abstractions like the ones in
/proc/sys/reset and /proc/sys/diag; using the gpio util to hardcode
GPIO numbers into scripts is just ignorant and stupid.

- mbm

Well, the problem is that currently the diag interface let's you control at most the DMZ and DIAG leds (on some models). Although I agree that controlling leds should probably be done via the diag interface rather than through the gpio utility, this is currently not possible.
IMHO removing the gpio utility altogether isn't a wise move, as it is a useful diagnostic-utility and also referenced in the wiki so ALuedtke won't be the last one to ask why it has disappeared.
Just my two cent...

(Last edited by wtzm on 5 Mar 2006, 18:10)

The binary is still up in people/inh , and I have the source code saved.

[removed per request]

[mbm] must have had good reason to take it down, so his warning still applies. If you mess up your router by using this code, don't sue me (or [mbm] for that matter). [mbm] please dont sue me either. Thanks.

- Yasha

"<[olli]> Flyashi, why the hell do you think [mbm] removed it?"

(Last edited by flyashi on 5 Mar 2006, 18:24)

Thanks for all your replies.

I wanted to modify the gpio package that is needed for the cisco-button package. The gpio "poll" mode is eating nearly all cpu cycles and I want to reduce this.

So, maybe there is a little difference between the polling gpio package and the gpio.tar.gz mentioned earlier in this thread?

I could also use the modified diag.o mentioned in this thread (http://forum.openwrt.org/viewtopic.php?pid=21112#p21112). But as eatnumber1 said, he had problems using it. Is it advisible to use that diag.o on a WRT54GSv4 with RC4?

Andreas

gpio.tar.gz is an archive, containing the gpio binary (most probably the same one you are using) and the sourcecode. If you want less cpu-usage, write your own program which usleep()s for some time between reading again from /dev/gpio/in.

I know that you can still download the utility; hell you can even get the utility directly from me if you ask nicely. You're missing the point entirely; I removed the sources for a reason, and I'm getting rather sick of people trying to post links to the sources without understanding the reason they were removed in the first place.

Yes the gpio util can be used to toggle the gpio pins or to poll them, you can even do it directly with manipulation of the /dev/gpio files. The point is that you shouldn't do it directly; you should not just blindly flip a bit in memory and hope that it was the right gpio pin .. that's a horrible programming technique. There needs to be a validation of "am I running on ____?" before you can say for certain which gpio pin is mapped to what. This is why we have the /proc/sys/diag and /proc/sys/reset .. these will always be mapped to the correct gpio pins regardless of what device openwrt is running on; it's a concept known as a hardware abstraction. That's the whole point of this.

Yes, I'm fully aware of the fact that you can't access every gpio device via /proc/sys and that not all platforms are properly supported. That's why I wrote the gpio utility; people could check which gpio pins their device used and could send in patches to fix the diag module. I never intended the gpio utility as a generic way of accessing the gpio.

Wiki house-cleaning time then? Tons of references to gpio in there. Example:

http://wiki.openwrt.org/OpenWrtDocs/Cus … 681c50cbb5

I am new here, so not sure it's appropriate for me to edit main-area documentation willy-nilly.

(Last edited by vincentfox on 6 Mar 2006, 03:22)

mbm wrote:

you should not just blindly flip a bit in memory and hope that it was the right gpio pin .. that's a horrible programming technique.

Well, I certainly agree with your opinion; nevertheless the gpio util is useful and if someone uses it, it's their own responsibility - so if they screw up it's their own fault.

(...)send in patches to fix the diag module.

Ticket #349. I only have one wl-500g and one wl-500g deluxe, so that's all I can do.

(Last edited by wtzm on 6 Mar 2006, 10:43)

Well I have to confess I'm a little bit puzzled - on the one hand we were asked to provide patches for the diag module to get our hardware supported - on the other hand no one seems to care if such patches are provided.
Ticket #349 is still "new". Could someone please take a look at it?
I have noticed that diag_led.c in whiterussian is newer than the kamikaze version (support for SES and AOSS leds); will this changes be ported over to kamikaze and/or should I provide a patch which applies to the whiterussian diag_led.c?

The discussion might have continued from here.