1

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.

Denis
  • 147
  • 6
  • 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 02 '14 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.

    https://www.youtube.com/watch?v=wui_wU1AeQc&list=PLF4A1A7E09E5E260A&index=11

     – Denis Dec 02 '14 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 02 '14 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 02 '14 at 13:24

1 Answers1

0

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.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • 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 02 '14 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 02 '14 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 02 '14 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 02 '14 at 18:00
  • I suggest you look at the generated assembly. You will then see the difference between direct writes to memory and using a system call. I'm not sure what you mean by fake DMA hack. Nobody uses DMA just to write or read an individual gpio. DMA is a technique for carrying out bulk data transfers without requiring continued software involvement. – joan Dec 02 '14 at 18:22
  • @joan Fair enough -- manipulating the map may be more efficient than read/write calls. But it is still not "direct writes to memory" (I am inappropriately using DMA to refer to this, will edit); it is writes to a virtual map thereof, and that is managed by the kernel. You can't write direct to memory from userspace, period. – goldilocks Dec 02 '14 at 18:31
  • BTW, you should write an answer, you certainly know more about wiringPi than I do. – goldilocks Dec 02 '14 at 18:32
  • @joan Actually I've re-written this a bit to be more fair to the mmap method, which would potentially have lower latencies. Cheers/thanks for your input. – goldilocks Dec 02 '14 at 18:47
  • 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 02 '14 at 18:49
  • @joan Yeah, I see now how manipulating the map to the hardware can be done completely in userspace. All apologies. I'd still say you aren't bypassing the kernel because it makes the arrangements, but you don't have to invoke it subsequently. Made more edits ;) – goldilocks Dec 02 '14 at 18:55
  • @QwertyCoolGuy "how you are using the newest Kernel on the Raspberry PI?" -> That's a decent question in itself. It's from the git repo; I cross compile and configure them myself. – goldilocks Dec 02 '14 at 22:48