Nucleus_dk
Posts: 13
Joined: Sat Apr 18, 2015 9:53 am
Location: Denmark

Linux’s New GPIO User Space

Fri May 11, 2018 11:45 am

Im posting my question here, as this might only be valid for Fedora 26-28 OS atm.
(im on F27 not yet upgraded to 28)

I have made an GUI (Gtkmm) application in C++ for working with GPIO, and different chips like mcp23017 port expander (and more to come)
All based on the new gpiochip char device, so no need for any additional libs.
Screenshot from 2018-05-11 13-19-47.png
Screenshot from 2018-05-11 13-19-47.png (44.28 KiB) Viewed 2683 times

It all works fine, even my threads for polling GPIO Events (interrupts), so its a nice GUI to work with GPIO pins on RPI3 B, and chips.
Ive tested it with mcp23017 int pins to a gpio pin (ex. 25) and GPIO events works. (using poll)

My question is, as im a novice in GPIO, what are all the 54 Offset lines referring too, as there is only 40 Pins ?

.... any information on this is welcome, as i dont really got any, but just went ahead making this application.
(im in the progress of polishing the code and bind it together etc.)

hippy
Posts: 4027
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Linux’s New GPIO User Space

Fri May 11, 2018 12:22 pm

Nucleus_dk wrote:
Fri May 11, 2018 11:45 am
My question is, as im a novice in GPIO, what are all the 54 Offset lines referring too, as there is only 40 Pins ?
The Pi SoC has 54 GPIO signals.

The 40-pin GPIO connector only exposes some of those GPIO signals, and not all pins on that connector are actual GPIO signals.

Nucleus_dk
Posts: 13
Joined: Sat Apr 18, 2015 9:53 am
Location: Denmark

Re: Linux’s New GPIO User Space

Fri May 11, 2018 12:31 pm

Thanks for reply.

So if i use the Broadcom GPIO pin numbering, i kind of get the correct amount of exposed gpio signals ?
Ive not tested if they are all equal to gpiochip lines numbering, yet, but looks like it.

I will narrow my coding to those exposed pins then ;)

User avatar
joan
Posts: 13616
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Linux’s New GPIO User Space

Fri May 11, 2018 12:42 pm

I also have a new gpiochhip liibrary. I have not released it as it is only a small improvement over syfs. Do you think differently?

Nucleus_dk
Posts: 13
Joined: Sat Apr 18, 2015 9:53 am
Location: Denmark

Re: Linux’s New GPIO User Space

Fri May 11, 2018 1:12 pm

Your great pigpio lib made me start to work with GPIO and electronics, thanks ! ;)
Im no where near your understanding of all this stuff, i just try to make an easy to use GUI for simple stuff, not a lib.

Ex. requesting an output line or similar for input
Screenshot from 2018-05-11 14-55-15.png
Screenshot from 2018-05-11 14-55-15.png (35.57 KiB) Viewed 2624 times

Or setting up an event for interrupt on a GPIO pin
Screenshot from 2018-05-11 14-58-24.png
Screenshot from 2018-05-11 14-58-24.png (30.22 KiB) Viewed 2624 times
.

But as i read it, syfs is "outdated" and we should use gpiochip now, so if you have made a lib for it, maybe we/i could benefit from that too ?

I have no idea of how to do PWM or stuff like that, which you did and i love it as it drives my greenhouse fans now :D

Thanks again ! :)

User avatar
joan
Posts: 13616
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Linux’s New GPIO User Space

Fri May 11, 2018 8:26 pm

I had high hopes of the new gpiochip based kernel interface. I hope I am not using it properly as they have been dashed. It feels like the kernel interface only expects people to read a button or switch a LED on or off. As far as I can see a GPIO can only be in one mode at any one time - INPUT, OUTPUT, or EVENT which are mutually exclusive. My personal benchmark was seeing if the kernel interface could reliably read a DHT11/DHT22. It can't, I can only get circa 90% reliability. I'm trying not to cheat, I set the GPIO to write to send the trigger, then have to close the GPIO and set it to EVENT. That transition takes a few more microseconds than I would hope.

User avatar
joan
Posts: 13616
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Linux’s New GPIO User Space

Sat May 12, 2018 7:34 am

I forgot to complement you on the GUI, it looks good.

Will you be publishing your work?

Nucleus_dk
Posts: 13
Joined: Sat Apr 18, 2015 9:53 am
Location: Denmark

Re: Linux’s New GPIO User Space

Sat May 12, 2018 9:31 am

joan wrote:
Fri May 11, 2018 8:26 pm
I had high hopes of the new gpiochip based kernel interface. I hope I am not using it properly as they have been dashed. It feels like the kernel interface only expects people to read a button or switch a LED on or off. As far as I can see a GPIO can only be in one mode at any one time - INPUT, OUTPUT, or EVENT which are mutually exclusive. My personal benchmark was seeing if the kernel interface could reliably read a DHT11/DHT22. It can't, I can only get circa 90% reliability. I'm trying not to cheat, I set the GPIO to write to send the trigger, then have to close the GPIO and set it to EVENT. That transition takes a few more microseconds than I would hope.
Oh no, that was the one thing i had not yet solved, how to change state while open :shock:
Thats why my GUI only show how to request a input , output or event, and no way to change it , as i thought i could figure it out later on.
Just to reset, when done, require a close, reopen, reset, close :evil:

Now i have no idea of how the github works, or how to make correct code etc. for publishing,
but as a starter i can put the application somewhere for download, when its usable enough. :idea:

The code is just C++ classes kind of wrapping the /linux/gpio.h, and some threads for events.
The MCP23017 and stuff like that, is made into Classes too, but my knowledge is very limited.

The GUI creation is really taking a lot of time, ex. this is 64 widgets needed to be imported, signals, functions etc. just to set 8 pins.
(slow work in progress)
The i2c seems to work fine.
Screenshot from 2018-05-12 10-59-40.png
Screenshot from 2018-05-12 10-59-40.png (38.16 KiB) Viewed 2545 times

Return to “Pidora / Fedora”