I understand the Raspberry PI uses the previous Kernel and the Beaglebone Black uses the one after and both do a great job for different applications.

I would like to know what is the difference in procedure making a GPIO high in both systems. i.e. is Raspberry Pi as well as the Beaglebone Black.

I understand there are scripts to do this job very easily but I am interested what are the differences in the system that makes this simple task so differently achieved in both systems.

  • I don't know what you mean. The Pi's gpios are memory mapped so you set them high/low by writing to memory. What happens on the Beaglebone?
    – joan
    Dec 2, 2014 at 11:20
  • exactly! just like in a normal microcontroler. sounds simple to me. But it seems according to the new Linux kernel its not possible any longer. Please refer to this video of you have time. I am really interested in this two different methods required to change status of a GPIO just because of the change in kernel. youtube.com/…
    – Denis
    Dec 2, 2014 at 11:23
  • I don't use Linux device tree support or the Linux sysfs interface to the gpios. Any changes in that area are irrelevant to many people. That is a Linux interface and will be common between the Pi and the Beaglebone. I access the gpios via a library which bypasses Linux and uses memory mapping to manipulate the gpios. Most people do the same, mainly for performance reasons, partly because Linux doesn't expose the full functionality of the gpios.
    – joan
    Dec 2, 2014 at 12:48
  • I find that information very important as a student and a learner. to truly know the this system, I believe we must know how this works. Its jurst that most tutorials are too complicated.
    – Denis
    Dec 2, 2014 at 13:24

1 Answer 1


I am interested what are the differences in the system that makes this simple task so differently achieved in both systems.

They aren't necessarily different, although there may be different methods available for you to choose between. You can choose to use exactly the same method on both boards.

If you stick to using the sysfs interface, your code should run without modification on both devices, so if that is a priority then that is what you should do. If you are unclear on this, see the kernel docs. If you have specific questions about that, feel free to ask.

The sysfs interface uses file nodes and hence is language agnostic. The use of file nodes does NOT mean there is some significant I/O overhead involved. There may still be some extra cost in the use of read() and write() because these are system calls, meaning, they require the execution of kernel space code, but that does not mean that they require waiting on I/O with some peripheral device other than main memory, which pretty much everything including mmap'd methods must do also.

Things like wiringPi instead use mmap() to access a region of memory exposed via the the kernel's /dev/mem interface. So the major difference between the two would be that using the sysfs method uses the kernel gpio driver, whereas the mmap method bypasses that. It does not, however, really bypass the kernel -- the kernel implements mmap() just as it implements the gpio driver. However, manipulating the map can be done completely in userspace code without invoking the kernel (hence no overhead for system calls).

So, the advantage to using the hardware specific mem-mapped method is that you may get lower latency with very fast transitions. However, this may or may not be significant depending on context: you still have to do this from userspace on a multi-tasking system. Again, if you want your code to work on something other than the pi, don't use a pi specific method unless you are sure you have no other choice -- use the kernel sysfs based interface.

  • that is a great explanation. one more question, does the new Kernel have the sysfs file system? Can the sysfs method of accessing GPIOs be done in the devices that use the new Kernel?
    – Denis
    Dec 2, 2014 at 17:08
  • I'm using a 3.17.1 kernel on the pi. Sysfs itself is a pretty major aspect of the kernel, that's not going anywhere. I can't see why they would change the gpio subsystem specifically either without a really good reason -- that would break all the existing software that uses it. And a GPIO pin is a GPIO pin, the nature of hardware on that level is almost eternal ;)
    – goldilocks
    Dec 2, 2014 at 17:24
  • well I think you have a lot of good points. And the main problem we as students suffer of is that we don't know where to start learning these stuff when such drastic changes have happened. But I guess its a part of the learning experience. May I know how you are using the newest Kernel on the Raspberry PI? As per the knowledge I had I thought Raspberry PI only supports the previous Kernel.
    – Denis
    Dec 2, 2014 at 17:51
  • wiringPi makes no use of DMA. There is a considerable overhead involved in read/write file system calls to update gpios. They are implemented in the kernel. Direct writes to memory to update the gpios completely bypass the kernel. The needed mmap call to access memory is made once at program initialisation, not for each gpio access.
    – joan
    Dec 2, 2014 at 18:00
  • 1
    I have written my own gpio library and am reasonably familiar with how wiringPi and others manipulate the gpios. Last point, the hardware MMU (Memory Management Unit) controls access to memory for both the kernel and user programs. The kernel will validate the (once-off) user mmap request and program the MMU to grant access for that memory to the user process. Thereafter user program memory read/write does not involve the kernel.
    – joan
    Dec 2, 2014 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.