GPIO: should I learn sysfs or direct register access?

[g8tr1522]

Hello everyone, I'm new to the forums

I plan on making silly IoT stuff just to get experience. Right now, I'm building an automatic trading card sorter, with camera, motors, price database APIs and everything. I figured I'd start with the motors, and from there, start with simple GPIO programs.

I've seen two main ways for configuring GPIO pins: using "direct register access", and using sysfs 'calls'. Question is, what should I learn? And what do you recommend? Keep in mind that I'm also asking for what is preferred in the industry, in case I include my projects on a resume or in an interview. Also, I'd prefer to stick with C/C++ for various reasons.
I don't expect every question to be answered. I'd rather get more detailed answers for individual questions and eventually, all will be answered by different people. Bold questions are priority questions.

I'm experienced with programming Atmel atXmega chips using C/C++ in Atmel Studio. Thus, I'm very comfortable with the "direct register access" method for configuring GPIO pins. But the process isn't as straightforward on the BCM2835.
Questions about this method:
(1) Is it as easy as including a header file?
- The .h would have define statements that have hardware nicknames assigned to register addresses (in the I/O space). No functions. Just writing a combination of bits to the I/O addresses. (this is what I'm used to).
- Eg, PORTF_OUT_SET = 0x80; would make pin 7 turn on by assigning 0x80 to address 0x12B (or whatever).
(2) Do I need a library that does what I described in (1)? Specifically, I need special functions to write to the I/O space.
- If so, what advantages does this have over method (1)? Eg, Linux OS permissions prevent direct access, library functions prevent misuse, etc.
(3) Is this method acceptable for general IoT stuff? I'm more concerned about the security. Let's say I made a Wi-Fi light switch. What (dis/)advantages does this method have over others?
- I'm not wanting to, say, flash pin states at 25MHz, so I don't need the advantage of speed.
(4) Any recommendations (eg, libraries or tutorials) for methods (1) or (2) in C/C++?
(5) Are there any IDEs/applications I can use to view the ram contents (ie, so I can view the I/O space) for debugging purposes?

I've read about the sysfs method. Seems more useful down the road, but it also seems like I'll need to do some homework to take full advantage of it.
(6) What does this do that is different than method (1)? (maybe see question (9)).
(7) What (dis/)advantages does this have over direct register access? I know that sysfs accounts for user permissions and contradictory mis-configurations.
(8) For IoT applications in mind, is this method more secure? Or more preferred in the industry?
(9) My understanding of the Linux OS and Unix stuff is pretty much nothing. I have no idea how permissions work, what a root user is, how to use the terminal, how to call to the terminal in a program, etc. Do I need this knowledge to fully take advantage of (or just scrape by) the sysfs method? Do I need this knowledge to excel in the industry?
(10) Any recommendations of resources where I can quickly learn the stuff described in (9)? Or maybe a textbook to get an in depth education?
(11) Recommendations for resources on learning the sysfs method in C/C++?

General Questions:
(12) Are there other methods that are more preferred?
(13) In tutorials that I'll be watching, is there any reason why I can't watch in one language and then translate to C/C++?
- Eg, (if a library can be used for both, then) I can watch Python tutorials and translate the concepts to C/C++?
(14) Any mistakes in my assumptions?

[KnarfB]

Using sysfs is easy, e.g. from terminal:

Code: Select all

sudo echo 18 > /sys/class/gpio/export
sudo echo out > /sys/class/gpio/gpio18/direction 
sudo echo 1 > /sys/class/gpio/gpio18/value

This can be translated to many prog. languages including C.
The advantage compared to WiringPi and other libs is: sysfs works for most embedded Linux systems, it is not Raspi specific.

A drawback is: you don't have tight control over the timing because it is a long way from a user app/command line to the kernel module which does the real work. Therefore, you may want to use direct register access, especially when you want to set several pins simultaneously (precisely at the same clock tick).

You may do so from user code. But, the timing between two statements cannot be precisely controlled (e.g. if you want to do PWM or emulate some fast HW protocol in software by "bit-banging"). So you might end up with writing a dedicated kernel module which gives you more precise control over the timing.
hth Frank

[rpdom]

Using sysfs is easy, e.g. from terminal:

Code: Select all

sudo echo 18 > /sys/class/gpio/export
sudo echo out > /sys/class/gpio/gpio18/direction 
sudo echo 1 > /sys/class/gpio/gpio18/value

The use of sudo here is pointless. The pi user has access to /sys/class/gpio without it, and "sudo echo blah" just runs the echo command as root. It doesn't run the redirect ">" as root.

Code: Select all

echo 18 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio18/direction 
echo 1 > /sys/class/gpio/gpio18/value

should be all you need.

Although if programming in C I would use a library like WiringPi or pigpio (actually I use my own code, but that's just my choice and because I wanted to know how to do it)

[gordon@drogon.net]

Make life easy for yourself and use a library - there are a couple to choose from. wiringPi (mine) and PiGPIO are the popular ones.

both include command-line tools to let you do stuff without even writing a program.

e.g. in wiringPi - blink an LED on physical pin 11:

gpio -1 blink 11

(the -1 tells it to use physical pin numbers)

and so on. http://wiringpi.com/ however it's installed with raspbian by default. (as is pigpio IIRC)

wiringPi is a pin based library and has stuff like pinMode(), digitalWrite() and so-on.

-Gordon

[skypi]

seems quite simple to use the gpio file heirarchy, some delays required, and it's portable between say beaglebone and raspberry pi I think.

https://github.com/halherta/RaspberryPi ... master.zip

see the notes on "issues" following my testing needs some delays.

depending what you want to do... pwm on any pin then use a library.... just turn a pin on or off then use file heirarchy.

reason I went that way is becos bosch bsec library static linking and avoiding minefield of brick walls using a library that might entail and just want to turn some pins on or off.

[joan]

GPIO sysfs is deprecated. I expect it will be around for another 10 years or so at least. I'm not very impressed with the /dev/gpiochip replacement.

[iammegatron]

An interesting read regarding this sysfs deprecate issue

https://github.com/rust-embedded/gpio-c ... ter-device

[6by9]

Direct register access leaves you responsible for updating your code should anything change within the hardware - note how libraries have had to be updated for the minor hardware changes in the Pi4. The kernel is there to isolate you from needing to do that.

The sysfs API is officially deprecated and has been for a couple of years.
gpiolib should be adopted unless there are very good reasons not to.

[hippy]

gpiolib should be adopted unless there are very good reasons not to.

The main reasons not to adopt it seems to be that it isn't supported out of the box with Raspbian Buster, it doesn't offer the same flexibility or provide the same capabilities as register access does, direct or through a library, and there's a dearth of knowledge, information and examples available for using it.

I would describe gpiolib as a work in progress, and am not convinced it is fit for purpose yet.

Using "gpioinfo" is considerable less accurate and reflective of reality than "gpio allreadall" is. There is a problem that gpiolib represents an abstraction which is inaccurate unless everyone is using that. As soon as anything acts using direct access, goes behind gpiolib's back, gpiolib cannot reflect reality.

But, above all, I cannot see most coders choosing to go through the layers of a library when they can just hit a register directly.

[joan]

I have done a little with the /dev/gpiochip system. It can do somethings better, e.g. time-stamps at source mean you can just about read things like the DHT22 reliably. The downside (if I remember correctly) is the time taken to swap a GPIO between being an output to being an input. My impression was that the authors have never actually used the GPIO for real life applications.

[trejan]

I use the gpiochip character device because my requirements for GPIO twiddling are fairly basic so it does everything I need. No need to worry about the GPIO peripheral moving around in memory or any of the registers changing.

[hippy]

My impression was that the authors have never actually used the GPIO for real life applications.

I get the impression it was invented by "programmers" rather than "software engineers".

Ignoring any overheads in its implementation it does seem like a fine idea; that signals can be referred to by name and we don't have to worry when they move about with every board revision, ensuring only one thing can take control of an output, that one cannot make a pin an output when others have subscribed to reading that as an input, that something locked as an input or output cannot have its direction changed.

All beneficial things which stop one thing, maliciously or accidentally, adversely interfering with something else which direct register access dangerously allows. In this day and age, with all the mechanisms we have within Linux and other OS's to protect ourselves, an errant non-privileged userland Python program really shouldn't be able to completely take down a Pi or anything else. And until everything is forced via gpiolib we are not going to escape that it can.

But everything beyond pin setting or reading seems to be an after-thought with some things not even yet considered.

Plus the current implementation appears to be flawed, or not integrated well enough, with Raspbian. Even using only gpiolib from userland it still seems potentially possible to take down a Pi.

It is taking us in the right direction - I'm really not against it - but it's not there yet.

[hippy]

I use the gpiochip character device because my requirements for GPIO twiddling are fairly basic so it does everything I need. No need to worry about the GPIO peripheral moving around in memory or any of the registers changing.

I would agree with the benefits. For the GPIO use most Pi users require it is no worse than using any other GPIO library, and it is the library C, C++ and native language programmers should be using in preference to direct register access.

Unfortunately, not having any marshalled GPIO access enforced from day one, direct register access having been encouraged and widely adopted, it is going to be hard to wean people off that. It probably won't happen until direct register access is removed and any access to the peripheral area throws a segfault.